FHIR
FHIR Interoperability turns BridgeERP HMS into a standards-compliant FHIR R4 server and client. Clinical data captured in the suite — patients, encounters, observations, medications, allergies, conditions and immunizations — can be read by any FHIR-aware system, while outbound endpoints let the hospital push records to, or pull them from, regional shared-record platforms and partner systems. This page covers the resources supported, the server routes, authentication, mapping and how to troubleshoot a connection.
Where to find it
The FHIR tooling lives under HMS Core → Integration → FHIR Interoperability:
| Menu | Opens |
|---|---|
| Configuration → Endpoints | Server / client connections (hms.fhir.endpoint) — base URL, direction, auth and supported resources. |
| Configuration → Resource Types | The catalogue of FHIR resources the server exposes (hms.fhir.resource.type). |
| Configuration → Mapping Rules | Field-level mapping between platform models and FHIR elements (hms.fhir.mapping.rule). |
| Data → Resource Instances | Stored / exchanged resource records (hms.fhir.resource.instance). |
| Data → Bundles | Transaction and search bundles (hms.fhir.bundle). |
| Data → Subscriptions | FHIR Subscription registrations for push notifications (hms.fhir.subscription). |
| SMART Apps → Registered SMART Apps | Third-party SMART-on-FHIR apps cleared to read data (hms.fhir.smart.app). |
| Terminology → ValueSet Bindings | Bindings of coded elements to value sets (hms.fhir.terminology.binding). |
Server endpoints (routes)
The built-in FHIR R4 server publishes a discoverable CapabilityStatement and a read / search interface for each supported resource. All paths are rooted at /fhir/r4:
| Route | Method | Returns |
|---|---|---|
/fhir/r4/metadata | GET | The CapabilityStatement (FHIR 4.0.1, format application/fhir+json), listing every active resource type and its read / search-type interactions. |
/fhir/r4/Patient/{id} | GET | A single Patient resource; a miss returns a FHIR OperationOutcome with HTTP 404. |
/fhir/r4/Patient?name= | GET | A searchset Bundle of Patients matching the name. |
/fhir/r4/Patient | POST | Creates a Patient (requires an authenticated user). |
/fhir/r4/Encounter/{id}, /fhir/r4/Encounter | GET | Read and search Encounters. |
/fhir/r4/Observation/{id}, /fhir/r4/Observation | GET | Read and search Observations. |
/fhir/r4/MedicationRequest/{id}, /fhir/r4/MedicationRequest | GET | Read and search medication requests. |
/fhir/r4/AllergyIntolerance/{id}, /fhir/r4/AllergyIntolerance | GET | Read and search allergies. |
/fhir/r4/Condition/{id}, /fhir/r4/Condition | GET | Read and search problem-list conditions. |
/fhir/r4/Immunization/{id}, /fhir/r4/Immunization | GET | Read and search immunizations. |
metadata route advertises only resource types flagged active under Resource Types. If a partner cannot see a resource in your CapabilityStatement, confirm the resource type record is active and set to R4.Publishing, push and pull
An endpoint’s Direction decides how data moves:
- Server (inbound) — external systems read from the
/fhir/r4routes above. This is the default. - Client (outbound) — the suite pushes resources to a partner’s FHIR server at its base URL.
- Bidirectional — both directions on one connection.
For event-driven push, register a Subscription so that changes to matching resources notify a downstream system. The Last Sync At timestamp on the endpoint records the most recent successful exchange.
Step-by-step: connect a FHIR partner
- Open Configuration → Resource Types and confirm the resources you intend to share are present and active (R4).
- Open Configuration → Endpoints and create a record. Give it a unique Code, set Direction, and enter the Base URL.
- Choose the Auth Type and paste the credentials into Auth Config (JSON) (see the auth table below).
- Tick the resources to expose under Supported Resources.
- Leave Status as Active. Verify by fetching
/fhir/r4/metadataand one resource read from the partner side. - If the partner is a SMART app, also register it under SMART Apps → Registered SMART Apps with its scopes.
Authentication options
| Auth type | Use when |
|---|---|
| None | Internal, network-isolated test links only. |
| HTTP Basic | The partner issues a username / password. |
| OAuth 2.0 | Token-based machine-to-machine access. |
| SMART-on-FHIR | Patient- or user-scoped app authorization. |
| Bearer Token | A static long-lived token supplied by the partner. |
Endpoint field reference
| Field | Meaning | Required |
|---|---|---|
| Name / Code | Label and unique key for the connection. | Yes (code unique) |
| Direction | Server (inbound), Client (outbound) or Bidirectional. | Yes |
| Base URL | The partner’s FHIR root (outbound) or this server’s advertised root. | Yes |
| Auth Type / Auth Config (JSON) | How the connection authenticates and its credentials. | Yes / as needed |
| FHIR Version | R4 or R5. | Yes |
| Supported Resources | Which resource types this endpoint exchanges. | No |
| Status | Active, Disabled or Error. | Yes |
| Last Sync At | Timestamp of the last successful exchange. | Read-only |
Mapping & terminology
Use Mapping Rules to align platform fields with FHIR elements where the default serialization is not enough, and ValueSet Bindings to bind coded elements (such as gender, allergy status or condition codes) to the correct value set. Combine this with the Terminology tooling under Integration so that exchanged codes resolve to recognised concepts on both sides.
Resources supported
The server exposes the clinical resources that matter most for a shared patient record. Each is read individually by id and searched as a Bundle:
| FHIR resource | What it carries from the suite |
|---|---|
| Patient | Demographics — name, gender, birth date and identifiers. Also creatable by POST. |
| Encounter | Visits and admissions. |
| Observation | Vitals and result values. |
| MedicationRequest | Prescriptions and medication orders. |
| AllergyIntolerance | Recorded allergies. |
| Condition | Problem-list diagnoses. |
| Immunization | Vaccinations administered. |
Add or retire a resource by activating or deactivating its Resource Type record; the change is reflected immediately in the metadata CapabilityStatement.
Roles & access
- FHIR Viewer (read-only) — can browse endpoints, resource instances and bundles.
- FHIR Integrator — configures mappings and endpoints.
- FHIR Administrator (full) — full control, including SMART app registration.
Troubleshooting
| Symptom | Likely cause & fix |
|---|---|
| Resource missing from CapabilityStatement | Its Resource Type record is inactive or set to R5; activate it and set R4. |
| 404 OperationOutcome on a read | The record id does not exist; confirm the id from a search Bundle first. |
| POST Patient rejected | The create route needs an authenticated user and resourceType: Patient in the body. |
| Endpoint shows status Error | Auth or reachability failed; recheck the Base URL and Auth Config, then re-test. |