Connect the clinical record to its required exchanges
Care supports HL7 and FHIR exchange with acknowledgements retained. Review the relevant clinical exchange, claims route and coding scope for your facility before agreeing the connection and its implementation responsibilities.
Separate clinical exchange from insurance transactions
Clinical information exchange and insurance transactions serve different purposes. A facility may need both, but a connection to one does not establish the other. Start by identifying the receiving system, the records or transactions it needs and the selected Care capabilities that produce them.
Care builds HL7 v2.5.1 messages and FHIR R4 resources, and keeps each exchange with the acknowledgement that came back. Clinical coding lookup supports ICD-10, CPT and LOINC by name or number. Radiology keeps images and DICOM files against a study and opens them in a browser viewer. None of this means an external endpoint, device or message profile is enabled without site-specific work.
Use the matrix below as a scoping map. It separates what Care builds from a live activation at a particular facility. No facility is described here as connected. Each route needs the exchange’s onboarding, credentials and testing, and conformance to an exchange’s implementation guide is confirmed during that testing. Confirm any Riayati activation before including it in a deployment commitment. Care has no NPHIES connection today.
Illustrative example: an exchange that needs attention
This example uses synthetic data. A synthetic patient, Omar Siddiqui, is registered in Care. Care builds the registration message, queues it and sends it to the exchange, then stores the message and the acknowledgement together on the exchange record. An accepted message shows as acknowledged.
If the exchange rejects the message or cannot be reached, the record shows a failed status. Care retries a limited number of times at increasing intervals. A failed exchange stays visible in the interface monitor, where a person can send it again once the cause is fixed. The text of an error comes from the receiving system, so what each error means and who resolves it are agreed with the exchange during testing. The example shows how Care records the outcome. It does not show a live connection.
Interface matrix: what Care builds and what activation needs
Each row gives the transport, direction, content and prerequisites. Status describes the product build. It is not an activation at any facility.
- NABIDH, Dubai clinical exchange
- Transport: FHIR R4, creating individual resources. Direction: from Care to the exchange. Content: patient demographics, encounters with diagnoses and vital signs, allergies, medications, laboratory results, radiology reports, referrals and immunisations. Status: built, with a test mode that records the message and a placeholder acknowledgement. Prerequisites: DHA onboarding and credentials, then testing against the exchange’s implementation guide.
- Malaffi, Abu Dhabi clinical exchange
- Transport: HL7 v2.5.1 over MLLP. Direction: from Care to the exchange. Content: patient registration and updates, admissions and discharges, appointments, laboratory and radiology results, vital signs, medication orders, dispenses and administrations, immunisations and referrals. Status: built, with a test mode that records the message and a placeholder acknowledgement. Prerequisites: Malaffi onboarding, which sets ports, address allow-listing and the provider code, then testing with Malaffi.
- Riayati, national record context
- Transport: HL7 v2.5.1 over MLLP. Riayati is the UAE National Unified Medical Record programme. Status: an adapter and message builder exist in Care. Prerequisites: Riayati onboarding for the facility. Confirm the required Care connection and its activation for the site before describing the facility as connected.
- Dubai claims: eClaimLink and DHPO
- Transport: the DHPO web service, with claims as XML. Direction: Care sends claims and downloads remittance advice. Status: built, with a test mode that records a placeholder acknowledgement. Prerequisites: facility credentials from the gateway, and agreed code sets and schema checks. Transmission is not acceptance or payment.
- Abu Dhabi claims: Shafafiya
- Transport: the DHPO web service, with claims as XML checked against the Department of Health schema. Direction: Care sends claims and downloads remittance advice. Status: built, with a test mode that records a placeholder acknowledgement. Prerequisites: facility credentials from the gateway. Review claim formats separately from Malaffi connectivity.
- Saudi claims: NPHIES
- Care has no NPHIES connection today. NPHIES defines insurance transaction workflows including eligibility, authorisation and claims. A Saudi claims requirement needs a scoped assessment before it forms part of a deployment commitment.
- Imaging: DICOM files and viewing
- Transport: files attached to a radiology study, opened in a browser viewer. Status: built as study storage and viewing. Not part of the confirmed scope: DICOM network exchange with modalities or a PACS, including a modality worklist. Confirm the modality and the route images take into Care before scoping.
Inspect the coding and exchange scope
Use the library to distinguish implemented formats and coding support from evidence-oriented standards and items that still need confirmation.
Define how each connection will be handled
Use these steps to agree an interface plan. They are evaluation and acceptance steps, not a promise of a managed service or an automated monitoring dashboard.
- Agree onboarding scope
- Identify the facility, receiving system and required messages or transactions. Confirm licensing, selected product scope and who is responsible for each part of onboarding.
- Validate representative exchanges
- Agree test cases using representative workflows before activation. Review the actual message content and response, rather than assuming standards support proves a complete site connection.
- Review acknowledgements
- Care retains exchange acknowledgements. Inspect them in the demonstrated workflow and agree how the facility will recognise and address a response that needs attention.
- Assign ongoing responsibility
- Define who reviews connection issues and how they are escalated. Monitoring arrangements and support commitments must be agreed rather than inferred from an exchange capability.
Common questions
-
No. FHIR R4 support does not establish every resource, operation or external endpoint. Review the required interface profile and the actual implementation for your use case.
-
Care has connectors for both: NABIDH over FHIR R4 and Malaffi over HL7 v2. They run in a test mode until a facility completes its onboarding, licensing and the applicable regulatory pack, so no facility is described here as connected.
-
Only after the live connection and agreed transactions are confirmed for the deployment. Listing NPHIES as a supported standards context is not proof of active submission.
-
Yes. Acknowledgements are retained in the described Care exchange workflow. Inspect the record during the demonstration and agree how your team handles responses requiring attention.
-
That requires a site-specific interface assessment. General HL7, FHIR or DICOM support does not establish a tested connection to every named device or middleware product.
Not answered here? Contact the team
NXH Flow