Managing Editor
@ShahidNShah
@ShahidNShah
A healthcare product rarely starts with an interoperability problem that looks unmanageable. The first requirement might be to pull patient demographics and appointments from one EHR. The team builds the connection, maps the fields, handles authentication, and then moves on.
Then the product grows.
A second EHR enters the picture. A customer needs lab results. Another wants payer data. The platform expands into a new state or adds analytics that depend on information collected elsewhere. Before adding another connector, teams dealing with recurring integration problems may decide to get an independent assessment of the architecture instead of extending the same design again.
The difficulty is not simply that there are more APIs to maintain. Each external system brings assumptions about how patients are identified, how clinical concepts are represented, which fields are required, when data changes, and what happens when an exchange fails. As those assumptions accumulate, interoperability starts affecting the architecture of the product itself.
One More Integration Rarely Means One More Connector
Imagine a platform that has spent its first two years working with one EHR. Its internal patient model, appointment logic, as well as reporting pipeline have naturally evolved around the data that system provides.
Now a customer uses another EHR.
The second vendor may expose the same broad clinical concepts through FHIR, yet the details can differ. One implementation may populate a field that another treats as optional. Organizations may use different coding systems or local codes. Extensions can carry information that does not fit neatly into the base resource. Update behavior and supported search parameters may also differ.
The engineering work is no longer confined to the connector. Developers have to decide whether to translate those differences at the integration boundary or modify the application’s shared model.
That choice has consequences.
Keeping vendor-specific behavior inside adapters limits their reach, but those adapters become more complicated. Expanding the internal model can support more use cases, but it may require changes to databases, business logic, analytics, and existing integrations.
This is why estimating system integration work by counting endpoints can be misleading. An API may take days to connect and months to fit cleanly into a product, which was designed around different assumptions.
FHIR Gives Teams a Common Language, Not Identical Implementations
FHIR has changed the technical baseline for healthcare interoperability. Instead of designing every exchange from scratch, developers can work with defined resources, API conventions, implementation guides, as well as established terminology.
That is a major improvement. It does not make integrations interchangeable.
Two systems can both expose a FHIR Patient resource and still require different integration work. They may support different profiles, extensions, search capabilities, terminology, or authentication arrangements. A field permitted by the standard can be absent in one implementation and important to another workflow.
The standards are moving too.
ONC released USCDI Version 7 in July 2026, adding 31 data elements and two data classes. In a separate 2026 update, ONC finalized newer versions of several FHIR implementation guides covering prior authorization and payer-provider exchange. The new versions replace those adopted only a year earlier under the HTI-4 final rule when the FY2027 rule takes effect on October 1, 2026.
For developers of health data platforms, this creates a less visible maintenance obligation. Supporting an interoperability standard is not a one-time implementation task. Interfaces and implementation guides have versions, customers upgrade at different times, and older connections may have to remain operational during a transition.
The platform has to live with that overlap.
The Internal Data Model Eventually Shows Its Weak Spots
Early architectural decisions tend to look reasonable when there is only one source of data.
Suppose an application stores an EHR’s appointment status values almost as they arrive because the product initially supports that system alone. The frontend learns those values. Reporting logic uses them. Automated workflows start checking for them.
Then another EHR represents appointment states differently.
The team can add a mapping. When a third system arrives, it adds another. Soon, business logic contains conditions for individual vendors, and a change to appointment handling has to be tested against every integration.
This is a common form of technical debt because the original shortcut becomes expensive only after the integration surface expands.
One way to contain the problem is to give the platform a stable internal representation and translate external formats at its boundaries. Tools such as Mirth Connect (NextGen Connect), Redox, or cloud integration services can help with transport and transformation in some architectures, while custom adapters remain appropriate in others. None removes the need to decide what the product itself considers a patient, encounter, order, observation, or appointment.
There is a tradeoff here. A canonical model reduces vendor-specific logic elsewhere in the application, but building an enormous universal healthcare schema can become a project of its own. The internal model needs to cover what the product actually does, not every possible field supported by every connected system.
An architecture review is useful when that boundary has become difficult to see. If adding an integration repeatedly requires changes deep inside unrelated product features, the connector may not be the real problem.
Passing Data Through an API Does Not Make the Data Usable
Transport gets much of the attention in interoperability discussions because it is easy to demonstrate. Send a request. Receive a FHIR resource. The connection works.
The harder question is what the application can safely do with the result.
Take patient identity. A hospital, laboratory, payer, and digital health application can each have a valid identifier for the same person. Those identifiers are usually meaningful within their respective systems. Connecting the systems does not automatically establish that two records belong to the same individual.
Clinical meaning creates similar problems. A source can use SNOMED CT, LOINC, RxNorm, ICD-10-CM, as well as its own local codes depending on the type of information involved. Free text may contain details that never appear in structured fields. A receiving platform may therefore need terminology mapping, provenance tracking, validation, and also rules for information it cannot confidently normalize.
These problems become more important when exchanged data feeds analytics or AI. A dashboard can produce the wrong aggregate because values were mapped inconsistently. An AI feature can receive technically valid data that lacks the context required for its intended use.
An HTTP 200 response proves that an exchange succeeded at one level. It says nothing about whether the information is complete, correctly matched, or suitable for the next decision.
Integration Debt Shows Up in Operations Before Anyone Calls It Architecture
Poor integration design does not always announce itself as an architectural problem. More often, teams see symptoms.
A vendor changes an API and three unrelated features need regression testing. One customer requires a mapping exception that breaks another customer’s export. Failed messages have to be investigated manually because each connector logs errors differently. Engineers become reluctant to change shared code because nobody is certain which interfaces depend on it.
At that point, the cost is higher than the hours required to maintain connectors.
Healthcare integrations deal with data that often sits inside operational workflows. A delayed lab result, duplicate record, missing authorization status, or incorrectly mapped value can affect what staff sees and what downstream systems do. That makes error handling, auditability, retries, idempotency, as well as monitoring part of the integration design rather than optional infrastructure work.
Some duplication is still reasonable. A team should not build a generic framework for three integrations just because the code looks similar. Abstractions introduced too early can be harder to change than a few explicit adapters.
The warning sign is repeated work whose differences are incidental rather than meaningful. If every new interface requires another authentication implementation, retry mechanism, monitoring setup, and mapping framework, the platform is paying for the same infrastructure repeatedly.
At Scale, Interoperability Becomes Part of the Product
A small engineering team can keep the behavior of three integrations in its collective memory. That approach does not survive 30.
Once external connectivity becomes a regular part of customer onboarding or product expansion, teams need repeatable ways to build and operate it. Shared authentication components, mapping conventions, contract tests, observability, version policies, as well as consistent failure handling begin to matter because they reduce the amount of bespoke work attached to each connection.
The scale of healthcare exchange itself makes that shift visible. TEFCA began production exchange in December 2023 with five Qualified Health Information Networks. By February 2026, 11 QHINs had signed the Common Agreement, the network covered more than 70,000 sites, and more than 474 million documents had been exchanged since launch.
More connectivity does not mean every healthcare product needs to participate in every network or support every standard. It does mean platforms are increasingly built in an environment where data is expected to move between organizations, applications, and workflows.
That changes the economics of integration work.
When each new customer requires weeks of custom mappings and one-off code, growth increases engineering cost almost alongside revenue. A better integration strategy looks for the parts that can genuinely be reused while leaving source-specific behavior where it belongs.
The distinction matters. Standardizing everything creates rigid abstractions. Standardizing nothing leaves the company maintaining a collection of custom projects.
The Real Scaling Problem Is the Cost of the Next Change
A mature healthcare platform will never reach a point where its interoperability work is complete. Vendors update APIs. FHIR implementation guides change. Customers bring different systems. New products need data that earlier versions of the platform never consumed.
The useful measure is therefore not the number of integrations already running. It is what happens when the next one arrives.
If engineers can add it through a defined boundary, reuse established operational controls, and test the change without touching unrelated product logic, the platform has room to grow.
If they first have to discover which vendor assumptions are embedded in the database, application code, reports, and customer-specific fixes, another connector is the least of their problems.
