Scaling a digital health product across more than one market is not a UI problem or even a regulatory-checklist problem. It is an interoperability engineering problem: can the product reliably exchange patient data with EHR systems, labs, payers, and national health exchanges that were never designed to talk to each other in the first place. HL7 v2.x, HL7 v3, and FHIR (Fast Healthcare Interoperability Resources) each solve this differently, and a product that assumes one standard will carry it into a second country usually hits a wall at the first hospital integration.
This article breaks down the technical differences between HL7 and FHIR, the compliance gates that sit in front of cross-border expansion, and the specific engineering decisions a delivery team needs to get right before go-live, not after.
TL;DR
HL7 v2.x uses point-to-point, event-driven messaging with a pipe-and-hat delimiter syntax; FHIR uses RESTful APIs and modular JSON/XML resources over HTTP/HTTPS, enabling granular access with sub-second latency instead of batch messages.
The US 21st Century Cures Act mandated FHIR API adoption by December 31, 2022, and full electronic health information export compliance by December 31, 2023, which is why most new EHR integration services default to FHIR today.
Cross-border data exchange requires layered security work: ISO 27001:2022 technological controls (including encryption policy) for data protection, NIST SP 800-111/800-52 for technical baselines, GDPR for data protection and transfer requirements, and HIPAA's Security Rule, each covering a different part of the stack.
Scaling into a new country is a compliance exercise as much as a code exercise: HIPAA Business Associate Agreements and HITRUST CSF for the US, GDPR and PDPA-style laws elsewhere, and medical device clearance (e.g., Australia's TGA) if the software is classified as a medical device.
The highest-risk engineering decision is not "which standard" but how the team designs the mapping and translation layer between legacy HL7 v2 feeds and a FHIR-based product core.
About the author: 724SOFTWARE is a Vietnam-based engineering partner with delivery experience in Digital Healthcare alongside Fintech and Edtech, and its teams have built eKYC-integrated financial platforms with real-time data exchange requirements comparable to what healthcare interoperability demands (sub-second latency, audit logging, regulatory-grade data handling). This piece draws on that integration engineering experience, applied specifically to HL7/FHIR interoperability patterns.
What Is the Difference Between HL7 and FHIR?
HL7 v2.x and FHIR are both HL7 International standards for healthcare data exchange, but they solve the integration problem with different architectures. HL7 v2.x is event-driven messaging: a system fires a message (an ADT for patient admission, an ORU for a lab result) using pipe-and-hat delimiter syntax, sent point-to-point, often through an integration engine that each hospital configures differently. FHIR, the newer standard, represents clinical data as modular "resources" (Patient, Observation, MedicationRequest) exchanged over RESTful APIs in JSON, XML, or RDF, supporting granular data access over HTTP/HTTPS with sub-second latency rather than batch files.
The practical difference shows up in how a mobile health app or telehealth app development project actually gets built. A HL7 v2 integration usually means custom parsing logic tied to one hospital's message format, which requires significant rework to adapt to the next client's system. A FHIR implementation guide gives the team a resource schema and API contract that is far closer to what a normal mobile backend team already builds, which is one reason FHIR adoption has accelerated across EHR integration services globally.
Dimension | HL7 v2.x | FHIR
|
|---|---|---|
Architecture | Event-driven messaging | RESTful API, resource-based |
Format | Pipe-and-hat delimited text | JSON / XML / RDF |
Access pattern | Batch, point-to-point | Real-time, granular |
Typical integration effort | Custom integration engine per site | Standardized resource mapping |
Common use today | Legacy hospital ADT/lab feeds | New product APIs, patient apps, HIE connections |
Neither standard replaces the other outright. Most digital health products still have to speak HL7 v2 to older hospital systems while exposing FHIR APIs to their own front end, which means the real engineering work is the translation layer between the two, not a one-time choice of "HL7 vs FHIR."
Why Does EHR Interoperability Break When a Product Expands Into a New Market?
EHR interoperability breaks across markets because each country's dominant EHR vendors, national health information exchange (HIE) networks, and regulatory mandates assume a different baseline standard. A product built around a single hospital's HL7 v2 feed in one country will not automatically connect to a different vendor's FHIR server in the next country, even though both claim HL7 compliance.
Building on the standards comparison above, the harder problem for a scaling product is version and profile drift. FHIR itself has multiple versions (DSTU2, STU3, R4, R5), and different national HIEs publish their own FHIR implementation guide with country-specific extensions and required fields. A resource that validates against a US-based FHIR profile can fail validation against an Australian or EU profile because the required fields or coding systems (e.g., different national drug or diagnosis code sets) do not match. A team that hardcodes a single profile's assumptions into its data model will need a rework, not a patch, when it adds the second country.
The regulatory layer compounds this. The US 21st Century Cures Act mandated FHIR API adoption by EHR vendors by December 31, 2022, and full electronic health information export compliance by December 31, 2023, which is why US hospital systems increasingly expose FHIR endpoints. In the EU, GDPR Article 20 enforces a right to data portability, and the European Health Data Space (EHDS) is introducing cross-border interoperability mandates on a phased timeline starting in 2025. These are not the same rule, and a product's data architecture has to satisfy both without maintaining two incompatible codebases.
What Security and Compliance Work Has to Happen Before Cross-Border Data Exchange?
Cross-border patient data exchange requires a layered security architecture, not a single checkbox. Encryption policy needs to follow a risk-based standard like ISO 27001:2022 technological controls, backed by prescriptive technical baselines such as NIST SP 800-111 for data-at-rest and NIST SP 800-52 for TLS configuration in transit. On top of that technical baseline sit regional legal requirements: GDPR Article 32 requires appropriate technical and organizational measures, such as encryption and access controls, for the security of personal data generally, while any transfer of that data outside the EU is separately governed by GDPR Chapter V, which requires a specific legal transfer mechanism such as Standard Contractual Clauses (SCCs) or an adequacy decision. HIPAA's Security Rule requires equivalent safeguards for protected health information in the US.
A related but distinct question is certification, which is separate from the technical controls above. Entering the US market typically requires a signed HIPAA Business Associate Agreement (BAA) with every vendor touching patient data, and increasingly a HITRUST CSF certification to satisfy enterprise health system procurement. Expanding into other markets layers on local privacy law (Thailand's PDPA, for example) and, if the software performs any diagnostic or clinical decision function, medical device clearance from the relevant regulator, such as Australia's Therapeutic Goods Administration (TGA).
For a hipaa compliant software development effort, this means the compliance scope has to be mapped before the first line of integration code is written, because adding encryption-at-rest or consent-tracking into a live FHIR data model after launch costs 3-5x more than designing it in from the schema level.
What Should a Vietnam Engineering Team Prioritize Before Go-Live?
The priority order is: map the real integration surface first, then build the standards layer, then layer compliance on top. Concretely:
Audit every HL7 v2 and FHIR touchpoint the product will need in each target market, including the specific HIE or EHR vendor's implementation guide, before writing the data model.
Build a translation layer, not a single hardcoded parser, so new HL7 v2 message types or FHIR profile variants can be added without rewriting the core.
Separate the compliance layer from the integration layer so a BAA, consent-tracking, or audit-logging requirement for one market does not force a rewrite of the FHIR resource handling for another.
Treat encryption and access control as architecture, not configuration, aligned with ISO 27001:2022 and the relevant NIST baselines from the first sprint rather than retrofitted before an audit.
724SOFTWARE applies this sequencing from its work building regulatory-sensitive, real-time data platforms, including eKYC-integrated banking features and audit-logged financial transaction engines, where the same rigor in mapping the integration surface, isolating compliance logic, and building for real-time exchange under load determined whether the system held up under production traffic. A custom healthcare software development effort that skips this sequencing typically discovers the gap during the first external hospital or payer integration test, the point at which remediation costs are highest.
Frequently Asked Questions
Is FHIR replacing HL7 v2 completely?
Most health systems still run HL7 v2 for legacy ADT and lab feeds while exposing FHIR APIs for newer integrations, so products need to support both.
Do we need a different FHIR implementation for every country?
Usually yes at the profile level. The base FHIR resource model stays consistent, but national extensions, required fields, and code systems differ by country's HIE or regulator.
What is a health information exchange (HIE) in this context?
An HIE is a regional or national network that lets hospitals, labs, and payers share patient data electronically, typically through standardized HL7 or FHIR interfaces rather than one-off point-to-point connections.
Does HIPAA compliance cover GDPR requirements automatically?
No. HIPAA and GDPR overlap in intent (protecting health data) but differ in specific obligations, such as GDPR's data portability right under Article 20, so both need explicit compliance work.
How long does a typical FHIR integration take for a telehealth app?
Duration depends on the number of external systems, the FHIR version in use, and whether custom profile mapping is required; teams should scope this per integration rather than assume a fixed timeline.
Can an offshore engineering team work on HIPAA-regulated healthcare software?
Yes, provided the vendor operates under a signed BAA, documented encryption controls aligned with recognized standards, and audit logging built into the data layer from the start.
About 724SOFTWARE
724SOFTWARE is a Vietnam-based engineering partner delivering custom software development, dedicated teams, and embedded staff augmentation for Digital Healthcare, Fintech, and Edtech clients across 10+ countries. The company's 200+ engineers, 58% of them senior-level, bring direct experience building regulatory-sensitive, real-time systems, including eKYC onboarding, audit-logged transaction engines, and multi-channel platforms under peak load, the same engineering rigor that healthcare interoperability work demands. Delivery is Compliant with ISO 9001 and ISO 27001:2022 standards and GDPR Compliant, with a follow-the-sun support model and sub-10-minute incident response. Teams scale from 1 to 50+ pre-vetted engineers within 2-4 weeks, letting a digital health product add integration or compliance capacity without a lengthy hiring cycle.
If your team is mapping an HL7-to-FHIR migration or planning a cross-border EHR integration, reach out at 724SOFTWARE to talk through the architecture before you scope the build.
