Integration
The Integration area of BridgeERP HMS is where the hospital connects to the wider health ecosystem — national reporting systems, partner laboratories and imaging providers, referral facilities, and modern app developers. It bundles the suite’s support for the major healthcare interoperability standards (FHIR R4, HL7 v2.x and DHIS2) alongside record-matching, terminology and offline-sync tooling, so that data captured once at the point of care can flow to every system that needs it without re-keying.
What this area covers
Interoperability in BridgeERP HMS is delivered by a family of cooperating modules. Each standard has its own configuration tree, its own data logs and its own operator role, but they all live under one menu so an integration engineer can manage everything from a single place. The headline capabilities are:
- FHIR R4 / R5 — a built-in FHIR server that publishes patients, encounters, observations, medications, allergies, conditions and immunizations as standards-compliant resources, plus client endpoints to push to or pull from external FHIR servers. See FHIR Interoperability.
- HL7 v2.x — an MLLP / HTTP bridge that exchanges ADT, ORM and ORU messages with laboratory analysers, radiology systems and legacy hospital systems. See HL7 Bridge.
- DHIS2 — aggregate health-information reporting to national HMIS platforms (KHIS, DATIM/PEPFAR and similar), mapping clinical activity to data elements, org-units and reporting periods. See DHIS2 Reporting.
- Public website & REST API — the patient-facing hospital website and the JSON endpoints that feed it, including online booking and the patient portal. See Website & REST API.
Where to find it
Everything described here lives under HMS Core → Integration. The principal sub-trees are:
| Menu | Opens |
|---|---|
| HMS Core → Integration → FHIR Interoperability | FHIR endpoints, resource types, mapping rules, resource instances, bundles, subscriptions, registered SMART apps and ValueSet bindings. |
| HMS Core → Integration → HL7 Bridge | HL7 endpoints (channels), message types, mapping and routing rules, subscriptions, and the operations logs (Messages, ACK Log, Segment Logs). |
| HMS Core → Integration → DHIS2 | DHIS2 instances, field mappings, data elements, data sets, data values, org-units and sync runs. |
| HMS Core → Integration → EMPI | Enterprise master patient index — match rules, candidates, review queue, merge / unmerge log and cross-facility links. |
| HMS Core → Integration → Terminology | Code systems, value sets, UCUM units, concept crosswalks and the bulk SNOMED import wizard. |
| HMS Core → Integration → PACS / Radiology | PACS servers, modalities, modality worklist, studies, series, instances and imaging reports. |
| HMS Core → Integration → HMS Integrations | Bridges to the platform’s own apps: CRM pipeline for new patients, calendar sync, care-plan projects, documents, helpdesk, live chat, e-sign and CSAT surveys. |
| HMS Core → Integration → HMS PWA Offline and PWA Sync v2 | Offline data capture for field teams and the conflict-resolving sync engine that reconciles it. |
Standards & profiles supported
| Standard | Version(s) | Role of the suite |
|---|---|---|
| FHIR | R4 (4.0.1) and R5 | Acts as a FHIR server publishing a CapabilityStatement, and as a client to external servers. |
| HL7 v2.x | 2.3 through 2.9 (default 2.5) | Sends and receives pipe-delimited (ER7) messages over MLLP/TCP, file hot-folder, HTTP POST, REST or SFTP. |
| DHIS2 | API 39/40/41 | Pushes aggregate data values to and pulls from national HMIS instances. |
| SMART-on-FHIR | OAuth 2.0 based | Registers third-party apps that read FHIR data with scoped tokens. |
| Terminologies | SNOMED CT, ICD, LOINC, UCUM | Concept storage and crosswalks bind local codes to standard value sets. |
External entrypoints at a glance
Each standard exposes a small, fixed set of network entrypoints that partner systems connect to. These are the verified base paths served by the suite; the host and port are your own deployment’s public URL.
| Standard | Entrypoint (path) | Method | Purpose |
|---|---|---|---|
| FHIR | /fhir/r4/metadata | GET | CapabilityStatement — what this server supports; the first call a client makes. |
| FHIR | /fhir/r4/<Resource> | GET / POST | Read or search a resource type (Patient, Encounter, Observation, MedicationRequest, AllergyIntolerance, Condition, Immunization). |
| HL7 v2 | /hl7/inbound | POST | Accepts an inbound ER7 message and returns an ACK; used by partners that send over HTTP rather than MLLP. |
| HL7 v2 | /hl7/health | GET | Liveness probe for the HL7 bridge, for uptime monitors and load balancers. |
| Website / REST | /storefront/api/site | GET | Root site-context call; entry to the full public JSON API documented on the API page. |
Before you start
Interoperability work touches live patient data, so prepare the groundwork first:
- Confirm facilities are configured. Endpoints in every channel are stamped with a partner facility, so your own hms.facility records must exist before you create endpoints.
- Agree the data contract with the partner. For each connection note the direction (do you publish, consume or both?), the resource or message types in scope, and the authentication method the partner expects.
- Load terminology where codes are exchanged. If a partner sends coded results, import the relevant code systems under Terminology so incoming codes resolve to concepts.
- Assign the right roles. Decide who is a read-only viewer, who configures endpoints and who administers each standard (see below).
Roles & access
Each standard ships a three-tier role ladder so you can separate “look” from “configure” from “administer”:
| Standard | Viewer | Operator / Integrator | Administrator |
|---|---|---|---|
| FHIR | FHIR Viewer (read-only) | FHIR Integrator (configure mappings & endpoints) | FHIR Administrator (full) |
| HL7 | HL7 Viewer | HL7 Operator | HL7 Administrator |
| DHIS2 | DHIS2 Viewer | DHIS2 Operator | DHIS2 Administrator |
Each higher tier implies the one below it, so an Administrator can also do everything an Operator and Viewer can.
Tips & troubleshooting
Capture once, report everywhere
The design principle behind this area is that clinical staff should record information once, at the point of care, and never re-key it for an external system. A registration captured at reception can be published as a FHIR Patient, announced to a partner over HL7 as an ADT message, and counted toward a national DHIS2 return — all from the same underlying record. The job of the integration engineer is therefore mostly configuration: define the endpoints, map the fields, choose the codes, and let the suite move the data. When you add a new connection, decide first which of these three roles it plays so you open the right sub-tree:
- Share a clinical record with another care provider → use FHIR (or HL7 for older systems).
- Exchange orders and results with a laboratory or imaging device → use the HL7 Bridge.
- Report aggregate figures to a ministry or programme → use DHIS2.
Connections that bridge to the platform’s own apps — CRM, calendar, documents, helpdesk and so on — are grouped separately under HMS Integrations and need no external credentials.
Common issues & fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Partner reports HTTP 401 / 403 on a FHIR call | Endpoint auth mode does not match what the partner sends. | Open the FHIR endpoint and confirm the Auth Type (None, Basic, Bearer Token, OAuth 2.0 or SMART-on-FHIR) and the matching Auth Config. |
| HL7 messages arrive but are rejected with AE / AR | The message type is not in the channel’s supported list, or a mapping rule failed. | Check the ACK Log for the reason, then add the message type to the endpoint and review the mapping rules. |
| DHIS2 sync run ends as Partial or Failed | Some data values were ignored or errored on the server. | Open the Sync Run and read Values Ignored / Error and the error message; usually a missing org-unit or data-element mapping. |
| Public website shows no data | Records are not published. | Confirm the source records have Website Published set; the API only returns published content. |