Bridge HMS Suite · health

Interoperability

$0.25 per user/mo

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

Add it to your plan Start free trial

Works with

HMS Core

FHIR RESTful API Server

GET /fhir/r4/metadata returns a live FHIR R4 CapabilityStatement listing active resource types with read and search-type interactions.

Patient Read EndpointGET /fhir/r4/Patient/<id> serialises an hms.patient into a conformant FHIR R4 Patient, or a 404 OperationOutcome if missing.

Patient Search EndpointGET /fhir/r4/Patient?name= runs an ilike name search and returns a FHIR searchset Bundle of up to 50 matching patients.

Patient Create EndpointPOST /fhir/r4/Patient accepts a FHIR Patient JSON body and creates an hms.patient, returning HTTP 201 with the stored resource.

FHIR-Compliant JSON 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

Ships 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 EnforcementA SQL constraint 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.

Endpoint Registry

Multi-Scheme AuthenticationEach endpoint configures auth as None, HTTP Basic, OAuth 2.0, SMART-on-FHIR or Bearer Token, with a JSON auth-config field.

Supported Resource MappingA many-to-many links each endpoint to the specific FHIR resource types it supports.

Endpoint Status LifecycleEndpoints track an Active/Disabled/Error status with a statusbar in the form header and last-sync timestamp.

Endpoint Kanban and PivotEndpoints render as a status-grouped kanban board plus a pivot cross-tabbing direction against status.

Endpoint Search FiltersPrebuilt filters for Active, Server and Outbound endpoints plus group-by status and direction.

Resource Instance Store

A universal store persists canonical FHIR JSON for any resource type, linked back to its local BridgeERP model and record id.

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 model FHIR resource versioning semantics.

Source Endpoint ProvenanceEvery stored instance can record which endpoint it originated 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

Define per-resource mapping rules with direction outbound-to-FHIR, inbound-from-FHIR, or bidirectional between FHIR and local models.

JSON Field MapsEach rule stores a JSON 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

Create 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.

Payload 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.

Automated Heartbeat CronAn hourly scheduled job stamps every active subscription with a last-notification timestamp to keep channels alive.

Bundles

Store bundles as document, message, transaction, batch, collection, searchset or history per the FHIR specification.

Entry CountingA computed field parses the bundle JSON 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 cron 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

Bind FHIR ValueSet canonical URLs to local hms.concept.valueset records 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 BridgeERP_hms_concept_dictionary module's local ValueSet model.