Two hospitals both tell you they send standard HL7 ADT messages. You build one interface, point it at the second hospital, and nothing works.
Neither of them lied. HL7 v2 permits so much local variation that two fully conformant systems can produce structurally different messages for the same event. This is the single most expensive misunderstanding in healthcare interoperability, and it is why experienced integration engineers are scarce and costly.
This is a working reference rather than an argument. Which standard does which job, what the version question actually is, what consumes the timeline, and what to obtain before anyone writes code.
Which standard does which job
Healthcare has several standards because they solve different problems. You will meet most of them on any serious project.
StandardWhat it carriesWhere you meet itFormatHL7 v2Real time clinical events, admissions, orders, resultsHospital interfaces, labs, pharmacy, billing feedsPipe delimited text over TCP/IPFHIR R4Clinical, administrative, financial data as API resourcesModern APIs, patient access, apps, TEFCA exchangeREST, JSON or XML, OAuth 2.0C-CDAWhole clinical documents, summaries at transitions of careReferrals, discharge summariesXMLX12Claims, eligibility, remittancePayer transactionsEDI, HIPAA mandatedDICOMImaging studies and metadataRadiology, PACSBinary
The common mistake is treating this as a migration from old to new. It is not. HL7 v2 was introduced in 1987, v2.5.1 remains the most widely deployed release, and parallel operation of HL7 v2 and FHIR R4 is the realistic expectation for most organisations over the next five to ten years. Most healthcare API development in practice means translating v2 into FHIR at a gateway, not replacing one with the other.
The version question, settled
For US work, build on FHIR R4. This is not a preference, it is where the regulation sits.
The 21st Century Cures Act information blocking rule requires certified EHRs to expose patient data through FHIR R4 APIs, the data elements are defined by USCDI, and TEFCA participants exchange on R4. Every US health system has an R4 endpoint as a consequence. R5 was published in 2023 and brings real improvements, notably a substantially reworked Subscription resource for reliable real time notification, but no US mandate has moved to R5 and R4 remains the production baseline into 2027.
There is a wrinkle worth knowing. Firely's 2026 State of FHIR survey found R4 named as the main standard by 36 percent of respondents, down from 40 percent in 2025 and 58 percent in 2024, while R5 rose from 2 respondents to 8. That decline is not R4 losing ground in mature programmes. It reflects the field broadening, with new entrants starting on a mix of versions. The practical consequence is version diversity: national systems increasingly have to support more than one version simultaneously.
What to do with that. Build on R4, but profile resources cleanly and keep terminology services separate so the architecture is version aware. Done properly, R5 becomes an upgrade rather than a rebuild. Woltrio designs FHIR integration work this way by default, using backend development and cloud engineering patterns that assume more than one version will be in play eventually.
What actually consumes the timeline
Five things, in rough order of how often they wreck an estimate.
1. Local variation in HL7 v2. Covered above, and it is the biggest one. Two systems claiming the same standard require separately built and tested mapping tables.
2. Acknowledgement handling. HL7 v2 uses ACK messages to confirm receipt. Interfaces built without proper ACK logic fail silently, which is the worst failure mode available, because nobody notices until reconciliation.
3. Terminology mapping. LOINC for labs, RxNorm for medications, SNOMED CT for clinical concepts. Source systems frequently carry local codes that must be mapped, and this work is neither glamorous nor optional.
4. Authentication and scope. FHIR uses OAuth 2.0, but which scopes a given EHR grants, and what its app review process requires, varies by vendor. This is a calendar problem as much as a technical one.
5. Failure handling. What happens when the upstream system is down, sends a malformed message, or replays an old one. Almost never in the initial estimate, always in the final bill.
Notice what is missing from that list. Writing the code that parses a message is rarely the hard part. That is why demo quality tells you very little about whether a partner can deliver healthcare API development in production.
The pre-flight checklist
Obtain these before writing code, not after. Each missing item is a rework cycle waiting to happen.
Real sample messages from every source system, covering normal cases and edge cases. Not the vendor's documentation examples, actual production samples.
The interface specification each system claims to implement, plus its documented deviations.
A code set inventory, showing which terminologies each system uses and where local codes appear.
API credentials and confirmed scopes for every FHIR endpoint in play.
Named technical contacts at each system, with the vendor's app review timeline written down.
A test environment with representative data volumes.
If a partner proposes a fixed timeline before these exist, the timeline is decorative. Woltrio treats assembling this list as the first billable phase, because the alternative is estimating in the dark and correcting later at the client's expense.
HIPAA compliant software development at the integration layer
The integration layer carries the same obligations as any system touching protected health information, and a few of its own.
The baseline applies in full: encryption in transit and at rest, access control, audit logging, and signed business associate agreements with every party in the chain. What is specific to integration work is that data at rest inside a message queue, an error log, or a dead letter store is still protected health information. Debug logs are a common and avoidable exposure, because engineers instrument aggressively during a build and forget what those logs now contain.
Two further points. Minimum necessary applies to interfaces as much as to people, so an interface that pulls a full patient record because it was easier than filtering is a compliance problem as well as a performance one. And retention rules apply to intermediate stores, not only to the destination system.
Woltrio scopes HIPAA compliant software development alongside the integration itself rather than as a review at the end, which matters because most of these decisions are architectural. Where the integration touches the record system directly, that work runs together with custom EMR and EHR development.
Where Woltrio fits
Woltrio builds the connective layer: HL7 v2 to FHIR gateways, FHIR integration against certified EHR endpoints, terminology mapping, and the monitoring that tells you an interface has gone quiet before a clinician does.
Most engagements begin with the pre-flight list above, because it is the cheapest way to find out how hard the project actually is. Where the scope is genuinely uncertain, a scoped MVP against a single source system settles it faster than another round of estimates. Downstream, once data moves reliably, the same foundations support workflow automation and AI development work that would otherwise have nothing trustworthy to run on.
Healthcare interoperability is not a product you buy. It is a set of connections you maintain, and the organisations that treat it that way spend less over five years than the ones that treat each interface as a one off.
Start with a scoped discovery from Woltrio.
