Interoperability: FHIR and HL7 interfaces, enterprise master patient index and DHIS2 export

FHIR R4/R5 RESTful server, client, mappings, subscriptions, SMART-on-FHIR registry, terminology bindings

+$38.40/mo at 20 practitioners. Free instant access, no credit card required.

Works with
  • HMS Core
Interoperability in the Bridge HMS Suite: FHIR and HL7 interfaces, enterprise master patient index and DHIS2 export
01

HL7 v2 that you can see

Every message parsed and stored, segment logs, the ACK log and the MLLP connections of each analyser and system.

Interoperability: HL7 v2 that you can see
02

A FHIR server inside the hospital

FHIR resource instances, bundles, subscriptions that notify on change and ValueSet bindings to your terminology.

Interoperability: A FHIR server inside the hospital
03

SMART apps and connections

SMART-on-FHIR apps registered, resource types, connections and mapping rules per partner.

Interoperability: SMART apps and connections
04

DHIS2 reporting that sends itself

Sync runs push data values into the national data sets and data elements — every run logged.

Interoperability: DHIS2 reporting that sends itself

What's inside

Everything in Interoperability

46 items in 9 areas, every one shipping with the app today.

  • FHIR RESTful API Server

    • CapabilityStatement ServiceGET /fhir/r4/metadata returns a live FHIR R4 CapabilityStatement listing active resource types with read and search-type interactions.
    • Patient Read ServiceGET /fhir/r4/Patient/<id> serialises a patient record into a conformant FHIR R4 Patient, or a 404 OperationOutcome if missing.
    • Patient Search ServiceGET /fhir/r4/Patient?name= runs an ilike name search and returns a FHIR searchset Bundle of up to 50 matching patients.
    • Patient Create ServicePOST /fhir/r4/Patient accepts a FHIR Patient JSON body and creates a patient record, returning HTTP 201 with the stored resource.
    • FHIR-Compliant ResponsesAll responses use application/fhir+json and emit proper OperationOutcome resources on invalid JSON, bad resourceType or errors.
    • Automatic Patient FHIR SerialisationMaps HMS gender/name/dob into FHIR name components, gender codes, meta.versionId, lastUpdated and StructureDefinition profile.
  • Resource Type Catalog

    • 30+ FHIR R4 Resource TypesShips a seeded catalog of 32 canonical R4 resource types like Patient, Encounter, Observation and MedicationRequest with StructureDefinition URLs.
    • R4 and R5 Version TaggingEach resource type carries a FHIR version selector supporting both R4 and R5 for multi-version interoperability.
    • Stored Instance CounterEach resource type shows a computed count of how many resource instances of that type are currently stored.
    • Profile / StructureDefinition URLsEvery resource type records its canonical profile URL used when advertising conformance in the CapabilityStatement.
    • Unique Code EnforcementThe app guarantees each resource type code is unique across the catalog.
    • Resource Type Management ViewsDedicated list, form and search views under Configuration let staff manage the resource type registry.
  • Connection Registry

    • Server / Client / Bidirectional ConnectionsRegister FHIR peers by direction: inbound server, outbound client, or bidirectional exchange partners.
    • Multi-Scheme AuthenticationEach connection sets its sign-in as None, HTTP Basic, OAuth 2.0, SMART-on-FHIR or Bearer Token.
    • Supported Resource MappingEach connection is linked to the specific FHIR resource types it supports.
    • Connection Status LifecycleEndpoints track an Active/Disabled/Error status with a statusbar in the form header and last-sync timestamp.
    • Connection Board and PivotConnections show as a status-grouped kanban board plus a pivot cross-tabbing direction against status.
    • Connection Search FiltersPrebuilt filters for Active, Server and Outbound connections plus group-by status and direction.
  • Resource Instance Store

    • Generic FHIR Resource StoreA universal store keeps the standard FHIR form of any resource type, linked back to its local BridgeERP record.
    • Versioning and ETagsEach instance carries a version id, ETag and last-updated timestamp for FHIR-style concurrency and history tracking.
    • Instance Lifecycle StatesInstances move through Active, Superseded and Deleted states to follow FHIR resource versioning.
    • Source Connection ProvenanceEvery stored instance can record which connection it came from for inbound-data provenance.
    • Instance Kanban and Pivot AnalyticsResource instances display as list, kanban, form and a pivot cross-tabbing resource type against status.
    • Instance Search GroupingSearch view offers an Active filter plus group-by resource type and status.
  • Field Mapping Engine

    • Bidirectional Field Mapping RulesDefine per-resource mapping rules with direction outbound-to-FHIR, inbound-from-FHIR, or bidirectional between FHIR and local records.
    • Field MapsEach rule stores a field map translating FHIR element paths like valueQuantity.value to local BridgeERP fields.
    • Python Transform HandlersRules reference a named Python transform handler for custom serialisation logic beyond simple field mapping.
    • 9 Prebuilt Clinical MappingsShips mappings for Patient, Practitioner, Organization, Encounter, Observation vitals, Condition, MedicationRequest, Allergy and Immunization.
    • Sequenced Rule PriorityMapping rules carry a sequence field controlling execution order and can be individually activated or deactivated.
  • Subscriptions & Notifications

    • FHIR Subscription ChannelsCreate subscriptions delivering over REST Hook, WebSocket, Email, SMS or Message Bus channels.
    • FHIR Criteria ExpressionsEach subscription stores a FHIR search criteria expression such as Observation?code=8867-4 to filter notified events.
    • Message Content ControlChoose whether notifications carry an empty body, ID only, or the full resource.
    • Subscription Status LifecycleSubscriptions track Requested, Active, Error and Off states with a configurable heartbeat period.
    • Automatic connection checkAn hourly check keeps the message channel of every active subscription open.
  • Bundles

    • Seven FHIR Bundle TypesStore bundles as document, message, transaction, batch, collection, searchset or history per the FHIR specification.
    • Entry CountingThe app reads the bundle and reports the number of entries it contains.
    • Bundle Processing LifecycleBundles move through Draft, Processed and Error states with processed timestamp and error-message capture.
    • Auto-Expiring Bundle CleanupA daily scheduled check deletes processed bundles older than 30 days to keep the store lean.
    • Auto-Numbered Bundle SequenceAn FB- prefixed 6-digit sequence numbers stored bundles.
  • Terminology & Value Sets

    • FHIR ValueSet BindingsBind FHIR ValueSet canonical URLs to local value sets for coded-data governance.
    • Binding Strength LevelsEach binding records its strength as required, extensible, preferred or example per FHIR binding semantics.
    • 8 Seeded Standard BindingsShips bindings for AdministrativeGender, ObservationCategory, clinical status sets, EncounterStatus, MedicationRequestStatus, LOINC and SNOMED-CT.
    • Concept Dictionary IntegrationBindings link into the concept dictionary's local value sets.
  • More in this app

    • One patient across every facilityThe EMPI dashboard, a review queue of probable matches, scored candidates, the merge log and unmerge requests when a merge was wrong.
    • Org units and field mappingsOrg units, the DHIS2 instances you report to and the field mappings from HMS to each element.
    • Exchange volumes and failuresMessages, sync runs, candidates, subscriptions, data values, unmerges, resources and bundles in pivot and graph.

Put Interoperability to work

Add it to your Bridge HMS Suite plan, priced per practitioner, or start a free trial and see it running first.