Organizations and exchanges

Every exchange enters once and follows one path into the case record.

Hospitals, clinics, laboratories, insurers, claims processors, underwriters, payment providers, and document systems each send data in the format they already use. The integration layer keeps each exchange as it was sent, converts it step by step, and merges the result into one governed case record. AI works on that record, and a person approves what leaves it.

1. 01Organizations and exchanges
2. 02Epic and other EHR systems (EMRs)
3. 03FHIR
4. 04HL7 v2
5. 05Integration engines
6. 06Azure integration boundary
7. 07Case record and workflow
8. 08Human-approved AI

The path, step by step

From the organization to the approved decision, in eight steps.

1. 01

   Organizations and exchanges

   Each organization sends its data in the format it already uses.

   Receives

   A message, file, document, or event from the organization, with its sender identity and its time.

   Converts

   Nothing yet. The exchange is kept exactly as sent, so the original can be shown at any time.

   Sends on

   The exchange, to the channel that matches its format.

   If it fails

   Unknown senders and unreadable files are refused at the channel and logged.

   Owned by

   The organization and its connection agreement

2. 02

   Epic and other EHR systems (EMRs)

   Epic and the other EHR systems are the source of the record, read through FHIR and interface feeds.

   Receives

   Read requests through the FHIR API under the consent scope, and interface feeds of admissions, orders, results, and documents.

   Converts

   Requests carry the SMART on FHIR authorization. Feed messages are passed to the engine unchanged.

   Sends on

   FHIR resources and HL7 v2 messages to the next step.

   If it fails

   A failed read is retried with back-off. A feed message that fails is held in the engine queue, not dropped.

   Owned by

   The hospital or clinic, with the Epic interface team

3. 03

   FHIR

   FHIR R4 is the common model for health data in the case.

   Receives

   FHIR resources from Epic and other EHR systems, and FHIR resources converted from HL7 v2 and CCD.

   Converts

   Resources are validated against the FHIR R4 profile. Identifiers are linked across organizations. Codes are normalized to standard terminologies.

   Sends on

   Validated FHIR resources to the Azure Health Data Services FHIR service.

   If it fails

   A resource that fails validation is quarantined with the reason and the field that failed.

   Owned by

   The integration layer, with the FHIR mapping

4. 04

   HL7 v2

   HL7 v2 carries admissions, orders, results, and documents from hospitals and laboratories.

   Receives

   HL7 v2 messages such as ADT for admissions, ORM for orders, ORU for results, and MDM for documents, sent over MLLP.

   Converts

   Each segment is parsed. Acknowledgments are returned to the sender, and the message is queued for the engine.

   Sends on

   Parsed messages to the integration engine.

   If it fails

   A message with a bad segment is returned with an error acknowledgment and copied to the error channel.

   Owned by

   The sending laboratory or hospital interface team

5. 05

   Integration engines

   Mirth Connect, Rhapsody, or HealthShare route, validate, and transform each message.

   Receives

   HL7 v2 messages and file exchanges from the channels.

   Converts

   Channel rules route each message by type and sender. Transformations map the message to FHIR and to the case events. Acknowledgments are sent per message.

   Sends on

   Mapped resources and case events to the Azure integration boundary.

   If it fails

   Messages that fail a rule are held in the channel queue with the reason. Retries are set per channel, and the operator sees the queue depth.

   Owned by

   The integration team, with one channel per source

6. 06

   Azure integration boundary

   Azure Integration Services carries the exchange into the platform, behind identity and policy checks.

   Receives

   Mapped resources and events from the engines, and requests from the portal and the partner APIs.

   Converts

   API Management checks the token and the rate limit. Service Bus queues each event. Logic Apps and Functions run the workflow steps.

   Sends on

   Events and resources to the case record and the services that subscribe to them.

   If it fails

   Dead-letter queues hold each event that cannot be delivered, with its attempts. Alerts go to Azure Monitor.

   Owned by

   The platform team, with managed identities and Key Vault

7. 07

   Case record and workflow

   Every exchange is merged into one governed case record, with its source kept on every field.

   Receives

   Validated resources and events from the boundary.

   Converts

   Each field is merged with its source, time, and version. A field that conflicts with another source is flagged, not overwritten.

   Sends on

   The case state to scheduling, reports, billing, Salesforce, and the document store.

   If it fails

   A merge that cannot be decided is held for a coordinator, with both values shown.

   Owned by

   The case coordinator, with the audit trail

8. 08

   Human-approved AI

   AI drafts, extracts, and flags on the case record. A person approves each output before it is released.

   Receives

   The case record, through retrieval that applies the access rules.

   Converts

   Models produce drafts, extracted fields, and flags, each with a citation and a confidence value. Guardrails check the output.

   Sends on

   Suggestions to the screen the person already uses. Nothing is written to the case record or sent outside until it is approved.

   If it fails

   If a model is unavailable, the step falls back to the rule-based path or a queue for a person.

   Owned by

   The person who approves the output