Healthcare Interoperability

Plan hospital data exchange, confirm supported interfaces, and prepare the specifications, tests, and operating handoff for an integration.

Use this guide to plan data exchange with a hospital and prepare the handoff to its technical team. Start with the workflow, the system that owns each record, and the changes the integration must receive or send.

HL7 version 2 (HL7v2) feeds commonly carry patient-administration messages, known as ADT, and scheduling notifications, known as SIU. Scope each feed alongside the hospital's electronic health record (EHR) APIs and other interfaces. Confirm Concurrence's supported options in the connector inventory.

Choose the Exchange Pattern

A hospital can use several standards for the same patient journey. Start with the event or task, then identify the system that owns the record and the interface it can provide.

Pattern	Typical purpose	Questions for the hospital team
HL7v2 event feed	Send patient-administration, scheduling, order, or result events	Which message profiles, identifiers, acknowledgments, and replay rules apply?
FHIR API	Read or write healthcare resources on demand	Which FHIR version, resources, operations, profiles, access scopes, and limits are enabled?
Bulk export or extract	Load a historical population or establish a baseline	How are exports authorized, resumed, and reconciled with later updates and deletions?
C-CDA clinical documents	Share clinical summaries across organizations	Which documents are available, who authored them, and how are versions and patient identity matched?
SMART app launch	Open an application within an EHR workflow	What launch context and access are available, and who approves the EHR setup?
CDS Hooks decision support	Return information at a defined point in a clinical workflow	Which hooks are supported, and what information can the service return?

FHIR stands for Fast Healthcare Interoperability Resources; C-CDA stands for Consolidated Clinical Document Architecture. These standards describe different ways to exchange data. Their presence in a hospital does not establish support in a particular Concurrence deployment.

Confirm the selected pattern with the implementation owner. A FHIR data connection does not by itself provide an embedded EHR application or a CDS Hooks service. SMART Backend Services authentication and interactive SMART app launch also require different setup and authorization.

Scope Each Interface Separately

Interface	Intended role	What to confirm
HL7v2 inbound ADT	Patient administration events, including admissions, transfers, discharges, and demographic updates	A native HL7v2 receiver and its acknowledgment behavior have not been verified in the current supported connector contract. Requires an explicitly designed and validated integration.
HL7v2 inbound SIU	Scheduling notifications such as booking, rescheduling, modification, and cancellation	Requires a hospital-specific feed profile, identity mapping, freshness target, and reconciliation tests. An inbound notification is not permission to change a schedule.
HL7v2 outbound	Send a message accepted by the receiving hospital interface	A native HL7v2 sender has not been verified. Agree on the message family, trigger, direction, authorization, and application acknowledgment before committing to delivery.
FHIR APIs and notifications	Read or write supported resources; receive events where the server and adapter support them	Use the current connector inventory. Resource, operation, authentication, subscription, and destination support vary independently.

Confirm each interface with the implementation owner before committing to the integration. Receiving events and sending changes back require separate access and validation.

Use these two paths to plan an integration. The diagram does not establish native support for a particular hospital interface. Verify both usable inbound data and the authoritative result of an outbound action.

HL7 defines ADT patient-administration events and SIU scheduling notifications separately. The receiver's supported version, trigger events, required segments, local extensions, and identifiers determine the actual contract. Receiving SIU notifications does not establish scheduling requests in the opposite direction. See HL7 patient administration and HL7 scheduling.

Design for Measured Freshness

For scheduling, start with the hospital's source of truth and the updates it can emit. Evaluate HL7v2 feeds, supported FHIR subscriptions, vendor notifications, and scheduled reads against the same end-to-end target. FHIR supports event notifications; the format alone does not determine latency, and actual subscription support must be confirmed.

Measure how long it takes for a source change to become usable by the agent. Record the source event time, receipt, durable acceptance, mapped record availability, and agent-visible state. For outbound work, also record action submission and target confirmation.

Report percentile latency and outage recovery against agreed thresholds. A sync heartbeat or ingestion timestamp alone cannot show how old the source information was when the agent acted.

Qualify Inbound and Outbound Paths

Record these decisions in the technical evaluation packet:

1. Feed scope: originating and receiving systems, directions, HL7 version and profile, ADT/SIU triggers, and separately scoped order or result messages. Use synthetic messages and the hospital's interface specification.
2. Transport and access: approved transport, network boundary, authentication, encryption, credentials owner, and environments. If the feed uses Minimal Lower Layer Protocol (MLLP) message framing, specify transport security separately.
3. Acceptance and failure: acknowledgment of durable receipt, application acceptance or rejection, timeouts, replay authority, quarantine, and escalation ownership. The agreed HL7 acknowledgment mode determines which acknowledgment means what.
4. Identity and ordering: source-scoped patient, encounter, appointment, and message identifiers; duplicates; late and out-of-order events; corrections, cancellations, and identity changes. Preserve provenance through mapping.
5. Outbound authority: allowed operations and records, approvals, conflict detection, loop prevention, and receiving-application evidence. An acknowledgment is not automatically proof of a completed appointment change.
6. Recovery: retention, replay controls, metrics, downtime behavior, reconciliation procedures, and the evidence required after an interruption.

A hospital interface engine or integration partner may adapt the feed for Concurrence. Test its mappings, acknowledgments, and handoff as part of the complete integration.

Prepare the Hospital Handoff

Prepare these documents with the hospital's interface analysts, EHR application team, security reviewers, and operating owner. Record the configuration and tested behavior for the selected deployment.

Document	Contents
Integration overview	Systems, data flows, exchange patterns, responsibilities, and excluded scope
Interface specification	Per-feed message profiles, events, required fields, local extensions, acknowledgments, expected volume, and failure handling
FHIR or API specification	Supported resources and operations, authentication, granted scopes, applicable key-discovery URLs, and measured or contractual limits
Data mapping	Source field, target meaning, terminology, identity mapping, provenance, and treatment of missing or conflicting values
Connectivity and security packet	Agreed network path, encryption, certificates, access ownership, security questionnaires, and applicable assurance materials and agreements
Test plan and sign-off	Synthetic admissions, discharges, scheduling changes, corrections, identity changes, duplicates, malformed data, outages, and expected results
Go-live runbook	Cutover, monitoring, downtime, recovery, escalation contacts, support coverage, and agreed service levels
EHR build guide	Customer-side registration, configuration, validation, and promotion steps for the specific EHR and environment

Assign an owner to each document and keep the approved versions with the technical evaluation packet. Obtain the hospital's feed profile, access approvals, and sign-off before go-live.

Verify a Scheduling Outcome

Use a synthetic appointment to test create, reschedule, cancellation, and correction events. Repeat messages, deliver them out of order, interrupt the connection, and reject a malformed message. Verify the resulting appointment state and that the agent uses the current state without duplicating an external action.

Test an outbound change separately: obtain authorization, submit through the agreed receiving interface, capture its acknowledgment, and verify the authoritative appointment record. If the result is ambiguous, reconcile before retrying. Keep lab, blood-bank, and other clinical-result workflows outside the scheduling pilot until their message profiles and validation cases are separately agreed.