HL7 Integration for Mobile Health Apps:
v2 Messaging and Interfaces
HL7 integration for mobile health apps connects your app to the HL7 version 2 messages that most hospitals still use to share admissions, orders, results and scheduling events between systems. While FHIR is the modern API standard, HL7 v2 remains the backbone of hospital interfaces, so many real mobile health app development projects need both. We build HL7 v2 interfaces through interface engines and secure middleware, then expose clean APIs your mobile app can use safely. Read the HL7 v2 vs FHIR comparison below, then talk to our interface engineers about your integration.
Talk to Our Interface EngineersHL7 v2 Basics
What HL7 v2 Is and Why It Still Matters
HL7 version 2 is a messaging standard created decades ago and still used by the vast majority of hospitals for internal data exchange. Systems send pipe-delimited messages when events happen, such as a patient admission, a new lab order or a completed result. HL7 v2 interface development remains essential because many hospital data flows, especially real-time events, are not yet available through FHIR APIs at every site or for every department.
Event-Driven Messaging
HL7 v2 pushes messages when events occur, rather than waiting for apps to ask. This makes it ideal for real-time notifications such as admissions, discharges, transfers and newly available lab results.
Huge Installed Base
Laboratory systems, radiology, pharmacy, billing and EHRs have exchanged HL7 v2 messages for decades. Replacing every interface is unrealistic, so new apps usually integrate with existing v2 flows. Integration usually beats replacement.
Flexible but Inconsistent
HL7 v2 allows optional fields and local customisation through Z-segments. Every hospital's implementation differs slightly, so careful mapping and testing are needed for each site you connect. Never assume two sites match.
Not Built for Mobile
HL7 v2 travels over MLLP connections inside hospital networks, not the public internet. Mobile apps cannot consume it directly and need secure middleware that receives, translates and exposes the data.
Comparison
HL7 v2 vs FHIR: When to Use Which
Choosing between HL7 v2 and FHIR is rarely an either-or decision. FHIR suits on-demand queries from apps, while HL7 v2 suits real-time events already flowing between hospital systems. Most production deployments use both: FHIR for reading patient records and HL7 v2 for event feeds or data not yet exposed through FHIR. The table compares the two standards on the factors that matter most for HL7 integration in mobile health apps.
| Factor | HL7 v2 | FHIR |
|---|---|---|
| Style | Event-driven messages | RESTful API queries and subscriptions |
| Format | Pipe-delimited text segments | JSON or XML resources |
| Transport | MLLP over TCP inside networks | HTTPS over the internet |
| Typical use | ADT events, orders, results, scheduling | Patient data access for apps |
| Mobile suitability | Needs middleware | Designed for app access |
| Standardisation | Highly customised per site | More consistent with US Core profiles |
| Availability | Nearly every hospital | Most certified EHRs, scope varies |
| Best for | Real-time feeds from hospital systems | App queries and patient access |
Use FHIR When
Your app needs on-demand access to patient records, such as medications, allergies or results, and the EHR exposes the required resources. FHIR is easier to secure, test and maintain. It suits most queries.
Use HL7 v2 When
You need real-time hospital events, such as admissions or discharges, or data from departmental systems without FHIR APIs. Many care coordination and alerting apps depend on these feeds. Events arrive within seconds.
Use Both When
Most enterprise integrations combine FHIR queries for record access with HL7 v2 event feeds for timeliness. An integration layer merges both into one consistent data model for your app. Users never notice the difference.
Plan for Migration
FHIR coverage keeps growing. Design your integration layer so v2 feeds can be replaced by FHIR subscriptions later, without changing the mobile app or its user experience. This protects your investment long term.
Message Types
HL7 v2 Message Types for Health Apps
HL7 v2 defines many message types, but a handful cover most mobile health use cases. Understanding these messages helps you scope integrations, request the right feeds from hospital interface teams and estimate mapping effort. Each message type contains segments, such as PID for patient identification or OBX for observations, which must be parsed and mapped carefully. These are the message types we integrate most often in mobile health projects. Each needs careful mapping.
ADT: Admit, Discharge, Transfer
ADT messages announce admissions, discharges, transfers and demographic updates. Hospital apps use them to trigger discharge follow-ups, notify care coordinators and keep patient lists current in real time. Census views stay accurate.
ORM and OML: Orders
Order messages carry new, changed or cancelled orders for labs, imaging and procedures. Apps use them to show pending tests, prepare patients and coordinate care tasks across teams. Status updates follow automatically.
ORU: Results
ORU messages deliver lab results, vital signs and reports in OBX segments. Apps use them to notify clinicians of abnormal results or share released results with patients securely. Release rules are respected.
SIU: Scheduling
SIU messages communicate appointment bookings, changes and cancellations. Patient engagement apps use them to keep schedules accurate and send reminders, reducing missed appointments and front desk calls. Cancellations update instantly.
Architecture
How Mobile Apps Consume HL7 v2 Safely
Because HL7 v2 is designed for internal hospital networks, mobile apps need an architecture that receives messages securely, translates them and exposes only appropriate data. Connecting a phone directly to an interface engine would be insecure and unreliable. Our hl7 interface engine integration approach places a secure integration layer between hospital systems and the app, with clear responsibilities for transport, translation, storage and access control at every step. Each layer is independently tested.
Interface Engine Connection
Hospital interface engines, such as Rhapsody, Corepoint or Mirth Connect, route messages to our integration endpoint over secure connections, usually a VPN or private link with acknowledgements configured. Connections are monitored continuously.
Translation Layer
Messages are parsed, validated and translated into a consistent internal model or FHIR resources. Site-specific fields and Z-segments are mapped through configuration, not hardcoded into the app. Mapping rules are version-controlled.
Secure Storage and APIs
Translated data is stored encrypted and exposed to the mobile app through authenticated APIs with role-based access, following our HIPAA-compliant app development approach. Only the data each user needs ever reaches the device.
Monitoring and Replay
Interface monitoring tracks message volumes, errors and acknowledgements. Failed messages are queued and replayed after fixes, so no admissions, orders or results are silently lost. Alerts reach our on-call engineers within minutes.
FAQ
Frequently Asked Questions About HL7 Integration
These answers cover what product teams and hospital IT leaders ask most about HL7 integration for mobile health apps, including HL7 v2 versus FHIR, message types, interface engines and timelines. They reflect common hospital integration practice. Every site's interfaces differ, so confirm details with the hospital's interface team, and see our EHR integration app development page for the wider integration picture. We will explain your realistic options clearly. No obligation applies.
Is HL7 v2 still used in hospitals?
Yes. HL7 v2 remains the most widely used standard for internal hospital data exchange, carrying admissions, orders, results and scheduling events between systems. FHIR adoption is growing quickly, but most hospitals will run HL7 v2 interfaces alongside FHIR APIs for many years.
Can a mobile app connect directly to HL7 v2?
Not safely. HL7 v2 is designed for internal networks using MLLP connections. Mobile apps should connect through secure middleware that receives messages from the interface engine, translates them and exposes appropriate data through authenticated, encrypted APIs. Direct connections create security risks.
What is an HL7 interface engine?
An interface engine routes, transforms and monitors messages between healthcare systems. Hospitals use engines such as Rhapsody, Corepoint or Mirth Connect to connect EHRs, labs and other systems. New apps usually receive HL7 feeds through the hospital's existing engine. Most hospitals already run one.
How long does an HL7 integration take?
A single inbound feed, such as ADT messages, often takes six to twelve weeks, including connectivity, mapping, testing and approvals. Multiple message types or bidirectional interfaces take longer. Hospital interface team availability is often the main factor affecting timelines. Plan resourcing early.
Should I use HL7 v2 or FHIR for my app?
Use FHIR for on-demand record access when the EHR supports the resources you need. Use HL7 v2 for real-time events or data not available through FHIR. Many apps use both, combined through an integration layer that gives the app one consistent data model.
Get Started
Book your strategy session
Free architecture review. Expert HIPAA compliance advice. No hard sell — just an honest conversation about your project.