> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/data/healthcare-interoperability.md). # 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 data paths in [Connectors and EHR](/data/connectors-and-ehr.md#connector-types). ## 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. 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 supported [data paths](/data/connectors-and-ehr.md#connector-types) and integration endpoints. 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.
Inbound: trace a hospital source change through the agreed interface and mapping, then check the agent-visible state. Outbound: trace an authorized action through the agreed receiving interface, then confirm the hospital record. Scope and test each direction separately.

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](https://www.hl7.eu/HL7v2x/v26/std26/ch03.html) and [HL7 scheduling](https://www.hl7.eu/HL7v2x/v251/std251/ch10.html). ## 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](https://fhir.hl7.org/fhir/subscription.html); 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](/platform-overview/evaluation-packet.md): 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](https://www.hl7.eu/HL7v2x/v251/std251/ch02.html) 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](/platform-overview/evaluation-packet.md). 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.concurrence.com/data/healthcare-interoperability.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.