> 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). # HL7v2 Integration Scope HL7v2 ADT and SIU feeds and outbound hospital messages, with explicit direction, freshness, acknowledgment, and deployment evidence. Hospital workflows can depend on HL7v2 event feeds for admission, discharge, patient updates, and scheduling changes. Scope these feeds alongside the supported FHIR and EHR integrations, with separate evidence for receiving events and sending changes back. ## Scope Each Interface Separately | Interface | Intended role | Concurrence readiness boundary | | --------------------------- | --------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 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](/data/connectors-and-ehr.md#connector-types). Resource, operation, authentication, subscription, and destination support vary independently. | These are interface-level findings reviewed September 7, 2026, not deployment commitments. Confirm scope with the implementation owner before accepting an integration requirement. 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 source event time, receipt, durable acceptance, mapped record availability, agent-visible state, action submission, and target confirmation separately. Report percentile latency and outage recovery against agreed thresholds. A sync heartbeat or ingestion timestamp cannot prove how old the source event 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. MLLP framing alone does not establish a secure transport. 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 can be evaluated as an adapter boundary. Its mapping fidelity, acknowledgment semantics, and Concurrence handoff still require testing; selecting a partner is not a verified integration. ## 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` 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 optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.