AI in Healthcare
Patient Engagement in Home Health: A Practical Guide
Learn how patient engagement in home health drives outcomes, ROI, and compliance. Practical roadmap with KPIs, AI use cases, and change management tips.
August 28, 2026Read more
A mid-sized hospital network can exchange ADT messages, lab results, and imaging summaries between its EHR, analytics warehouse, and a partner clinic's portal, yet still fail at the moment care depends on the data. A sepsis alert arrives late because a source system stripped the units from a creatinine value. An on-call clinician ignores a duplicate medication list because nobody can tell which version is current. At the quarterly review, the CMO asks why “interoperability” hasn't changed readmissions.
That situation is common for a simple reason: the pipes exist, but trust doesn't. Healthcare data interoperability has moved from an emerging capability to an established infrastructure layer in U.S. care delivery. Federal hospital data shows that the share of hospitals engaging in all four core domains, sending, receiving, finding, and integrating patient health information, rose from 23% in 2014 to 70% in 2023, and remained 70% in 2025 according to the ONC interoperability data brief.
The executive mandate for 2026 is therefore not “connect more systems.” It's to close the semantic, governance, and workflow gap left behind by raw integrations. The right question is whether a clinician can trust the information, understand its context, and act on it without creating a second manual process.
The Executive Reality Behind Healthcare Data Interoperability
A network can report healthy integrations while care still breaks down. Messages pass validation, API response times stay within technical thresholds, and the partner clinic confirms that the referral arrived. Then a patient deteriorates.
An urgent care system sends a creatinine result without a unit. The receiving EHR accepts the structurally valid payload. A rules engine evaluates the number, but the alert arrives after the patient has moved through triage. Meanwhile, medication reconciliation displays two entries for the same prescription, one from the hospital and one from the partner clinic. The clinician sees duplication without reliable context and moves on.
The problem runs deeper than transport. Data moved, but its meaning, provenance, and priority did not survive the journey. That is a trust failure.
Federal data shows real progress alongside a serious operating gap. Individual hospital capabilities rose substantially between 2014 and 2023, with sending increasing from 78% to 92%, receiving from 56% to 87%, finding from 48% to 84%, and integrating from 40% to 78%, as reported in the ONC federal brief. Adoption remains uneven: 43% routine interoperability, 27% occasional interoperability, and 30% not fully interoperable.
The board question has changed
A decade ago, a CTO could defend an interoperability program by listing interfaces delivered. That case is weak now. The U.S. has moved from a minority of hospitals meeting all four exchange domains to a mainstream operating expectation, while federal reporting tied to TEFCA described one billion health records exchanged in 2026 through the national network, according to this Statista overview of healthcare interoperability.
The board should require answers to four questions:
- Meaning: Did the receiving system preserve units, terminology, clinical context, and source attribution?
- Workflow: Did the right person see the information at the right point in care?
- Accountability: Can a named owner explain why a value was transformed, delayed, rejected, or duplicated?
- Value: Did the use case improve a clinical or operating outcome, rather than only increase message volume?
A Healthcare AI Services team can support system connections, but executive ownership must cover clinical informatics, security, product, data governance, and vendor management. Set KPIs for trusted data use, rejected or duplicated records, alert timeliness, and outcome impact. Make vendors prove provenance and failure handling before approving more interfaces.
Practical rule: Treat every new integration as a clinical trust decision, not a plumbing ticket.
What Healthcare Data Interoperability Actually Means
Healthcare data interoperability means that different systems can exchange information, interpret it consistently, and use it safely in a real workflow. A connection that merely delivers a file or returns a successful API response is only the starting point.
A useful maturity model has four layers:
- Foundational interoperability moves data from one place to another. A PDF fax sent from an urgent care to a specialist technically crosses an organizational boundary, but the receiving system may not be able to search, validate, or reuse its contents.
- Structural interoperability gives exchanged data a predictable format. An HL7 v2 message can be parsed into fields, even though the local implementation may still require extensive mapping.
- Semantic interoperability preserves meaning. A coded FHIR Observation can align the test, value, unit, status, and terminology so the specialist understands the result without guessing.
- Organizational interoperability makes the exchange usable across people, policies, and workflows. The specialist receives a shared care plan, consent status, provenance, and task ownership that support coordinated action.
Follow one patient journey
Consider a 58-year-old transferred from urgent care to a specialist. The fax provides a visual summary, but staff must re-enter key details. An HL7 v2 message improves machine readability, yet a locally defined code may still fail to map cleanly. A FHIR Observation can carry a structured, coded result, but it only becomes operationally valuable when the receiving organization knows whether the result is current, who verified it, and how it relates to the care plan.
That final layer requires agreements about consent, identity matching, terminology ownership, downtime handling, and escalation. It also requires a clinician to confirm that the information appears where decisions happen.
Executives should measure maturity against organizational interoperability, not API count. Count whether referrals close, duplicate records fall, clinicians reconcile less manually, and care teams act on shared information with confidence.
FHIR, HL7, CDA, and DICOM Compared
Vendor proposals often treat interoperability standards as interchangeable. They aren't. Each standard solves a different problem, and a strong architecture uses them together instead of forcing every workflow through one format.
FHIR is the modern default for application-level exchange. It uses resource-based representations and web technologies such as REST, HTTP, and JSON, which lets teams use familiar developer tooling. A peer-reviewed analysis notes that FHIR can be easier to implement than HL7 v2 or CDA in many environments, while also warning that profiling choices, ecosystem variation, and uneven adoption still create implementation complexity in the published FHIR analysis.
HL7 v2 remains the entrenched hospital interface layer. Admission, discharge, transfer, lab, and scheduling workflows frequently depend on message structures that have accumulated local variations. Retain these interfaces when they are stable and clinically important, but place transformation, validation, and monitoring around them rather than pretending they'll disappear quickly.
CDA is document-oriented. It fits clinical summaries, continuity-of-care documents, and exchanges where a complete narrative record matters more than granular application queries.
DICOM is the imaging standard. Imaging partners should demonstrate DICOM conformance for modalities, studies, metadata, and image exchange. A generic clinical API cannot replace imaging-specific workflows.
| Standard | Primary Purpose | Data Shape | Best-Fit Use Case |
|---|---|---|---|
| FHIR | Application-level health data exchange | Resource-based JSON or XML | Patient access, apps, referrals, care coordination |
| HL7 v2 | Event and message exchange inside clinical operations | Delimited messages with implementation-specific segments | ADT, lab, scheduling, and legacy EHR interfaces |
| CDA | Exchange of structured clinical documents | Document with narrative and coded sections | Clinical summaries and continuity-of-care records |
| DICOM | Medical imaging communication and management | Imaging objects and metadata | Radiology, cardiology, modalities, archives, and image exchange |
Make the stack decision explicit
Use FHIR for new transactional workflows where consumers need discrete resources. Keep HL7 v2 where replacing it would introduce clinical risk without a clear benefit. Use CDA when the receiving party needs a coherent document, and demand DICOM where images and imaging metadata are involved.
The mistake is not choosing an older standard. The mistake is choosing a standard without defining its validation rules, version policy, terminology mapping, and ownership model.
Architecture Patterns for Connected Health Systems
Architecture decisions determine whether an interoperability program stays manageable after the first few integrations. Three patterns cover most production environments: direct API-first exchange, centralized integration engines, and middleware or broker layers.
Direct API-first FHIR endpoints
Direct APIs suit transactional clinical workflows. They can reduce latency and avoid building a large central transformation layer, but every endpoint creates work for authentication, patient identity, authorization, audit logging, error handling, and rate limiting. This pattern also exposes teams to vendor-specific FHIR profiles and implementation differences.
Use it when the workflow needs an immediate response, the partner has credible FHIR maturity, and your team can operate identity and observability consistently.
Centralized integration engines
Rhapsody, Mirth, and InterSystems can centralize routing, transformation, message validation, retries, and operational monitoring. They fit heterogeneous legacy estates where HL7 v2, CDA, flat files, and partner-specific formats coexist.
The trade-off is concentration risk. The engine becomes a critical dependency, and the organization takes on recurring licensing, specialist administration, and upgrade responsibilities. It can also become a “logic graveyard” if mappings lack ownership and documentation.
Middleware and broker layers
Event buses and Kafka-backed pipelines work well for high-volume imaging, claims feeds, telemetry, and device fleets. They decouple producers and consumers and support analytics without forcing every system into synchronous transactions.
They also create eventual consistency. A clinician may interpret a delayed downstream event as missing data, so the product must expose freshness, processing state, and source timestamps.
| Pattern | Best Fit | Latency Profile | Vendor Lock-In Risk | Estimated TCO Impact |
|---|---|---|---|---|
| Direct API-first | Transactional clinical workflows | Low when partners support compatible APIs | Moderate, driven by vendor profiles | Lower central platform cost, higher per-endpoint engineering effort |
| Integration engine | Heterogeneous legacy environments | Near real time when queues are healthy | Moderate to high, depending on engine-specific mappings | Higher platform and specialist operating cost |
| Middleware or broker | Telemetry, analytics, claims, and device fleets | Variable, often eventual consistency | Moderate, based on cloud and messaging choices | Higher operational complexity, efficient at high volume |
The decision rule is straightforward: APIs for transactional workflows, engines for legacy estates, and middleware for telemetry, analytics, and device fleets. Design the boundaries so USCDI expansion can add fields and mappings without forcing application rewrites.
HIPAA, USCDI, and the 2026 Compliance Baseline
Compliance starts with the handling of protected health information, not with a FHIR endpoint. HIPAA Privacy and Security Rules shape who may access data, why they may access it, how the organization protects it, and how it records that access. Engineering teams translate those obligations into access control, transmission security, encryption, monitoring, incident response, and disciplined vendor agreements.
USCDI defines the minimum data elements and classes that certified health IT must support for exchange. ONC published USCDI v5 on July 16–18, 2024, adding 16 data elements and two data classes, according to the ONC 2024 standards bulletin. The HTI-1 final rule moved the certification baseline from USCDI v1 to USCDI v3 and set January 1, 2026 as the date by which relevant certified health IT modules must support USCDI v3, as described in the ONC HTI-1 overview.
Since January 1, 2023, certified EHR users have been required to make standardized FHIR APIs for patient and population services available for exchange with authorized business partners and patients, tied to HL7 FHIR and USCDI standards in the ONC API data brief.
Map rules to controls
A practical control set includes:
- Access control: OAuth 2.0 and SMART on FHIR scopes, role-based permissions, service-account governance, and explicit break-glass handling.
- Transmission security: Protected channels, certificate lifecycle management, payload validation, and safe retry behavior.
- Traceability: Immutable audit trails recording who accessed data, what was transformed, which source supplied it, and when the event occurred.
- Data minimization: Return only the information required for the authorized workflow, not an unrestricted patient record by default.
Passing an audit proves that controls exist. It doesn't prove that a patient sees a coherent record or that a clinician can distinguish current information from stale information. Organizations building regulated software should involve a regulatory compliance partner early, especially when interoperability intersects with software as a medical device, patient-generated data, or cross-border processing. For teams building SaMD solutions, the compliance baseline must sit beside clinical safety and product requirements, not after them.
Why Connected Systems Still Fail in Practice
More APIs don't automatically produce better care. A health system can expose a broad catalog of endpoints while leaving clinicians with duplicate patients, ambiguous results, and notifications that compete with urgent work.
The recurring failures are operational:
- Semantic drift: Local codes, units, and value sets diverge from the receiving system's interpretation.
- Identity ambiguity: A single patient appears under multiple medical record numbers because matching rules lack governance.
- Missing provenance: Clinicians can't see the source, verification status, timestamp, or transformation history of inbound data.
- Alert overload: Systems push every event instead of ranking information by urgency, responsibility, and clinical context.
ONC reports that exchange across care settings remains difficult, particularly across different data platforms and fragmented regional networks, creating higher costs and poorer user experience, as described in its burden reduction and interoperability policy materials. CMS also connects standards-based prior authorization and payer-provider APIs with reduced burden, while noting that adoption remains uneven and implementation requires substantial system and workflow change.
Trust requires an operating model
The underserved issue is organizational trust. The KLAS 2025 interoperability overview describes a market where records are more available, yet clinician satisfaction with external integration remains poor. It also highlights that API availability alone doesn't guarantee customer satisfaction and that trust remains a major hurdle in payer-provider data sharing.
That finding changes the investment case. A catalog of 200 endpoints without a master patient index, a data quality SLA, and a clinical informatics owner may create more dissatisfaction than a curated catalog of 40 endpoints. Those figures are an editorial planning example, not an industry benchmark. The point is that executives should fund the controls that make data believable.
Every integration should have a clinical owner, a data steward, a freshness expectation, a reconciliation path, and a decision about what happens when the feed fails. Without those commitments, technical delivery only moves uncertainty downstream.
A Phased Roadmap with KPIs That Matter
A board mandate needs a production path, not a collection of pilots. The roadmap below uses 90, 180, and 365-day checkpoints to force decisions about scope, ownership, and measurable value.
Start with evidence
During the first 90 days, inventory systems, interfaces, data owners, terminology dependencies, and workflows where missing or mistrusted data creates friction. Map the inventory against USCDI v3 readiness and run a clinician-led trust audit. Select two anchor use cases, such as referral leakage reduction or duplicate imaging avoidance, and define the baseline before building.
Between days 91 and 180, deploy the chosen integration engine or FHIR facade behind a vendor-neutral API layer. Add identity and consent services, then instrument latency, reconciliation errors, data freshness, rejection causes, and clinician time-to-answer.
From days 181 to 365, retire point-to-point HL7 v2 interfaces where replacement is safe, extend the platform to ambient documentation or population health, and connect results to operating measures such as days in accounts receivable and prior-authorization turnaround.
| Phase | Objectives | Key Deliverables | Technical Milestones | Measurable KPIs |
|---|---|---|---|---|
| Days 1–90 | Establish scope, ownership, and trust baseline | System inventory, USCDI v3 gap map, clinician audit, two approved use cases | Source and terminology map, identity risk assessment, failure taxonomy | Baseline latency, reconciliation error rate, data freshness, clinician time-to-answer |
| Days 91–180 | Put a governed exchange layer into production | FHIR facade or integration engine, identity service, consent service, monitoring | Authentication, audit logging, retry handling, provenance capture, partner testing | Production exchange reliability, unmatched identity rate, rejected payload rate, workflow completion |
| Days 181–365 | Scale value and retire avoidable complexity | Additional workflows, legacy interface retirement plan, executive value report | Expanded resource coverage, event processing, operational dashboards | Referral completion, duplicate imaging avoidance, prior-auth turnaround, days in A/R |
The checkpoint for each phase should be a sign-off, not a presentation. Engineering confirms reliability and security. Product confirms workflow adoption. Clinical leadership confirms that users trust the result. The AI Product Development Workflow can support implementation planning, but the organization still needs an accountable internal owner.
Executive Checklist and Next Steps
A steering committee can use this checklist to expose risk quickly. Each question should have a clear yes or no answer, with evidence attached.
- Standards: Have we chosen FHIR for new app-level transactions, retained HL7 v2 only where justified, defined CDA use cases, and required DICOM conformance for imaging?
- Architecture: Have we made a build-versus-buy decision for the integration engine, API facade, identity layer, consent service, and monitoring platform?
- USCDI readiness: Can every certified module and dependent application demonstrate support for the applicable USCDI v3 baseline by the January 2026 deadline?
- Trust: Can clinicians see provenance, freshness, units, terminology, and source status for every high-risk inbound data element?
- Identity: Does a governed master patient index resolve duplicates, document confidence, and route uncertain matches for review?
- Workflow: Does each use case place information inside the clinician's existing workflow instead of creating another dashboard?
- Ownership: Is one executive accountable for interoperability outcomes, with clinical informatics and data governance represented in decisions?
- Value: Does each production integration have a KPI tied to care coordination, safety, revenue cycle performance, or staff time?
The next 30 days should produce four concrete actions:
- Convene a data governance council with authority over terminology, provenance, identity, and sharing policies.
- Name the accountable interoperability owner and publish decision rights across engineering, clinical operations, security, and vendors.
- Approve one lighthouse use case with a defensible ROI and a clinician satisfaction gate.
- Commission an architecture review that tests FHIR, HL7 v2, CDA, DICOM, identity, consent, observability, and failure recovery against the selected workflow.
Teams that need hands-on delivery can combine custom healthcare software development, internal tooling, and AI strategy consulting rather than commissioning another disconnected strategy artifact. Ekipa AI can also help teams evaluate AI tools for business, define AI requirements analysis, and connect decisions to real-world use cases. Review our expert team before assigning the program.
Frequently asked questions
Is FHIR enough for healthcare data interoperability?
No. FHIR is a strong default for application-level exchange, but production interoperability also requires identity resolution, terminology governance, provenance, consent, security, workflow design, and operational monitoring. HL7 v2, CDA, and DICOM still serve important purposes in hospital and imaging environments.
Should a hospital replace HL7 v2 immediately?
No. Retain stable HL7 v2 interfaces that support critical workflows, then replace point-to-point connections where a governed API or integration layer can reduce risk and maintenance. A rushed replacement can disrupt care without improving trust.
What should a CTO measure first?
Start with data freshness, reconciliation errors, unmatched identities, failed or rejected exchanges, clinician time-to-answer, and workflow completion. Add financial or operational measures, such as prior-authorization turnaround and days in accounts receivable, once the selected use case is stable.
Why do connected systems still frustrate clinicians?
Clinicians often receive data without enough context to trust it. Missing provenance, duplicate records, inconsistent terminology, stale results, and alerts outside the workflow can make technically successful exchange harder to use than a curated manual process.
What should happen in the first 90 days?
Inventory the estate, map data against USCDI v3, identify owners, run a clinician trust audit, and select two anchor use cases. Don't expand the interface catalog until the organization has defined identity, consent, terminology, provenance, monitoring, and escalation rules.
Ekipa AI helps healthtech teams turn interoperability mandates into governed production systems, including EHR integration, FHIR and HL7 implementation, clinical workflows, compliance engineering, and AI-enabled operations. Bring your highest-risk workflow, your current architecture, and your 90-day mandate, then visit Ekipa AI to start an engineering-led assessment.
