The short answer
Custom applications connect to a hospital information system (HIS) in one of four ways: HL7 v2 messages through the interface engine, FHIR APIs, vendor APIs or scheduled files. HL7 v2 carries events such as admissions, orders and results; FHIR increasingly handles on-demand queries and updates. The hard part is rarely the standard but the mapping, testing, monitoring and agreeing with the interface team how changes and outages are handled.
How hospital systems exchange information
A main HIS (such as Epic, Oracle Health, formerly Cerner, or MEDITECH) runs alongside lab, imaging, pharmacy, scheduling and dozens of departmental systems. An interface engine in the middle receives, transforms and routes messages, queuing them when a receiving system is down.
HL7 v2: the event messages
Text messages in segments, mostly sent when something happens.
| Message | Carries | Typical use |
|---|---|---|
| ADT | Admissions, discharges, transfers, patient updates | Current patient lists, triggering follow-up |
| ORM, ORU | Orders and observation results | Lab results, order status |
| SIU | Scheduling | Reminders, clinic flow |
| MDM | Medical documents | Notice that a report or note is ready |
Feeds differ by hospital (version, optional fields, local codes, custom "Z" segments), so code built to the standard alone breaks: write the mapping specification from the hospital's sample messages first. MLLP, the usual transport, has no encryption of its own, so run it over TLS or a private network.
FHIR, vendor APIs and files
FHIR exchanges resources (Patient, Encounter, Observation, Appointment, DocumentReference) as JSON through web APIs, usually authorized with OAuth 2.0, often SMART on FHIR, so access can be limited to a user, a patient or a defined data set. It suits looking up or writing back data when a user acts but does not replace events: many applications query with FHIR and hear of changes through HL7 v2.
More detail: FHIR versions, vendor APIs and flat files
- Many vendor FHIR APIs are based on Release 4 (R4), though later releases exist. What a vendor's API exposes, and what each hospital has switched on, varies.
- Some data is only available through a vendor's own API or scheduled extracts, such as CSV files by secure file transfer. Both suit reporting and batch work.
- Treat files as interfaces: define the format, validate every file, alert on missing or late files and encrypt the transfer.
Canadian standards and law to watch
Canada Health Infoway's CA Core+ (pan-Canadian core FHIR profiles) and HL7 Canada's Canadian Baseline are still evolving, and provinces have their own specifications: confirm which profiles a project must follow.
Doing it properly
Map in writing
Every field, code and transformation agreed. LOINC and SNOMED CT matter; Infoway keeps Canadian editions.
Test the edge cases
Synthetic or de-identified messages in the hospital's test environment: merges, cancellations, corrected results, no health card.
Handle errors
Acknowledge correctly, make repeats create no duplicates, send failures to a queue a person reviews.
Monitor every feed
Alert when a feed stops, slows or rejects messages, not when a clinician notices.
Plan downtime and replay
Agree behaviour during an HIS or engine outage, and how missed messages are replayed and reconciled.
Protect privacy
Only the data needed, no message content in ordinary logs, access recorded, encrypted in transit and at rest.
What usually goes wrong: coding before sample messages and a mapping specification; no place in the interface team's queue, so go-live slips; an unmonitored feed failing silently for days; corrected results and merges ignored, so data is outdated; one developer and no documentation.
Example: a discharge follow-up app
A hospital wants an app that reminds discharged patients about appointments. It subscribes to ADT discharge and SIU scheduling messages through the interface engine, stores only the fields it needs, and looks up the patient's preferred language with a FHIR query at send time. After an outage it processes the engine's queued messages in order and flags any discharge without a matching appointment for staff review.
Rather talk it through? If your application needs data from the hospital information system, tell us what it needs and we will map the messages or APIs and the steps to go live. Talk to a Promatics specialist
When to bring in help
A standard feed and developers who know HL7 v2 or FHIR may need only the interface team's specification and test time. Bring in help when the application must receive events and write back, several systems or hospitals are involved, nobody owns monitoring after go-live, or an integration fails and nobody knows why. Our clinical systems integration service maps, builds, tests and monitors interfaces with your interface team; our hospital software partner checklist covers what else to ask.
Sources and further reading
Product capabilities and guidance change. These are the primary sources this article relies on, checked on the review date above.
- HL7 Version 2 Product Suite, HL7 International
- FHIR specification, HL7 International
- CA Core+ Implementation Guide, Canada Health Infoway
- Canadian Baseline (FHIR implementation guide, continuous build), HL7 Canada
- Bill S-5, Connected Care for Canadians Act, Parliament of Canada (LEGISinfo)
This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.