00 / Solution overview
Health Care Workflows Integration Platform
The integration layer, the reference implementations, and the reading path.The Health Care Workflows Integration Platform connects the clinical, administrative, interoperability, and financial systems used across a health care journey. It is configured around the organization that runs it and connects hospitals and clinics through Epic and other EHRs, laboratories, imaging centers, pharmacies, HIEs and QHINs, public health, payers, clearinghouses, payment networks, document management, CRM, and accounting platforms.
The integration layer runs on Azure Integration Services with Azure Health Data Services for governed health data. AI is applied inside the workflow: deterministic rules first, then classic and neural models, domain-specific small language models, and a large language model only where justified. Consequential AI output is cited, checked by guardrails, and approved by an accountable person before release.
Read the documents in order, or jump to any part. Every page links to the others.
Read in order: Problems -> How We Solve Them -> Where The Data Comes From -> The AI Integration Solution -> The AI Technology Map -> Report Drafting and Records Summary
1. Problems We Solve (start here)
The integration and data problems that slow health care workflows: fragmented identity, records trapped in incompatible formats, scheduling across disconnected calendars, incomplete acknowledgments, delayed decisions, claims and remittance exceptions, and evidence that cannot be traced.
2. How We Solve Them
One pipeline receives, preserves, translates, validates, and correlates every exchange into a governed workflow record. Around that record sit configurable services for identity, coordination, scheduling, documents, decisions, billing, and audit.
3. Where The Data Comes From
The full territory the integration layer connects: hospital and clinic EHR systems reached through Epic FHIR APIs and HL7 v2 feeds, laboratories and imaging centers, insurance companies and claims processors, payment providers including Stripe and Infinicept, invoices and receipts in document management, contacts in Salesforce, and the Azure data estate. Every format and abbreviation is spelled out.
4. The AI Integration Solution
How AI is added without replacing the systems in use. Exchanges enter through governed boundaries, pass through standards validation and canonical mapping, and reach the workflow record. AI acts as an advisor: it drafts, extracts, summarizes, ranks, and flags, while an accountable person decides.
5. The AI Technology Map
Every component placed: Azure services, the model tiers (static rules, neural and classic models, domain small language models, large language models), retrieval with citations, guardrails, caching, evaluation, and the monitoring loop that keeps each model under review.
6. Clinical Document Drafting and Records Summary
The reusable workflow lifecycle from service request to delivery, revenue cycle, and audit, with the system, AI boundary, and accountable approval at every stage.
How the layers connect
The pages cross-reference each other throughout: a problem links to the mechanism that solves it and the technology that delivers it. Read top to bottom for the full design, or follow the links wherever your question leads.
A health care workflow moves across many participants: patients and members, hospitals and clinics, laboratories and imaging centers, pharmacies, independent providers, HIEs, payers, clearinghouses, public-health agencies, financial networks, and operational teams. Each participant works in its own system. The problems below are where work stops, repeats, becomes unsafe, or loses traceability between those systems.
The problems are grouped into five groups. Each problem states what happens on an ordinary day and what it costs.
Group A -- Records arrive in the wrong shape
A1. Hospital and clinic records arrive as faxes and PDFs
Records requested from a hospital or a private clinic often come back as a fax, a scanned bundle, or a PDF exported from the EHR. To every downstream system these are pictures, not data.
Ordinary day: a staff member opens a 60-page fax, reads it page by page, and re-keys dates, names, and procedure codes into the case file.
Cost: hours of keying per case, typos that reach the report, and a case file that cannot be searched.
A2. Epic and other EHR data is reachable, but not in one shape
Epic and the other EHR systems expose data through FHIR R4 APIs, HL7 v2 feeds, and CCD or C-CDA documents. Each site configures these differently. The same encounter can appear with different identifiers, units, and code systems.
Ordinary day: a scheduling system shows one identifier, the hospital record shows another, and a partner export uses a local code for the same service.
Cost: records that belong together cannot be joined, and reconciliation is manual.
A3. Identity does not match across organizations
The same person is a patient at a provider, a member at a payer, a customer in a partner workflow, and a record number at a hospital. Names, addresses, identifiers, and date formats differ between systems.
Ordinary day: a records request is sent to the wrong file because two people share a surname and a birth year.
Cost: wrong-file disclosures, and a privacy incident to report and close.
Group B -- Work waits on people and calendars
B1. Care-team and resource matching is done by phone and spreadsheet
Finding a qualified provider, facility, equipment, and time for a request is often done by calling around. Credentials, dependencies, and availability live in separate systems, calendars, and spreadsheets.
Ordinary day: a coordinator makes eleven calls to book one examination, then records the appointment in two places.
Cost: days of delay per case and double bookings.
B2. Appointment changes do not reach the people who need them
Confirmations, reminders, and rescheduling are sent by hand. A change made by a provider or facility does not reach the patient, care team, requesting organization, and authorized partners at the same time.
Ordinary day: a rescheduled examination is discovered on the morning of the appointment.
Cost: missed appointments, unused capacity, repeat work, and poor patient and partner experience.
B3. Report requests have no clock
A report request carries a service level for delivery, but nothing tracks it. Escalation depends on someone remembering the due date.
Ordinary day: a time-sensitive document or decision is three days late before anyone notices, and the requesting organization asks for an update by email.
Cost: missed service levels, penalties under contract, and lost referrals.
Group C -- Money moves in the wrong place
C1. Invoices and receipts are not linked to the case
Invoices, receipts, and payment confirmations are stored in document management. The case file, the accounting system, and the CRM each hold part of the picture.
Ordinary day: an accountant searches three folders to find the receipt for one examination.
Cost: slow month-end close and disputes that take weeks to resolve.
C2. Multi-payer billing is split across systems
A single workflow can bill a payer, organization, patient, member, or responsible third party. Each route has different rules, codes, enrollment, remittance, and settlement formats. Clinical, claims, accounting, and payment systems hold different parts of the financial state.
Ordinary day: one examination produces three invoices in three systems, and the payments are matched by hand.
Cost: unmatched payments, duplicate invoices, and manual reconciliation at month end.
C3. Card and bank payments are not reconciled to invoices
Payments taken through Stripe, Infinicept, or a bank transfer settle on their own schedule. Refunds, chargebacks, and partial payments are handled in the provider's dashboard and copied across by hand.
Ordinary day: a settlement report shows a payment that matches no invoice.
Cost: cash that cannot be allocated, and refunds issued twice.
C4. Claims and underwriting files arrive in batches
Claims processors and underwriters send files in batches, by SFTP, email, or portal download. Each file has its own layout, and a failed batch is noticed only when someone checks.
Ordinary day: a batch of 400 records fails on row 212 and the rest wait until the next morning.
Cost: delayed decisions and rework on partial data.
Group D -- Trust, evidence, and audit
D1. Reports are drafted without visible sources
A report draft written from records has to show which page, which sentence, and which date supports each statement. Without that, the reviewer checks every line against the source.
Ordinary day: a reviewer spends half of the review time looking for the source of one sentence.
Cost: slow review, and reports that are challenged because the basis is unclear.
D2. Access and disclosure cannot be proven
Records are shared by email, shared drives, and printed copies. It is hard to show who received which record, when, and under what authority.
Ordinary day: a request asks who viewed a file, and the answer takes days to assemble across mailboxes.
Cost: gaps in the audit trail and exposure during an external review.
D3. Automation has no safe boundary
Teams that try automation often connect a model directly to a live system. A wrong output then changes a record or a payment without review.
Ordinary day: an automated summary is released to a partner or patient before an accountable person reviews it.
Cost: errors that are discovered by the recipient, and a loss of confidence in the whole tool.
Group E -- Change breaks what works
E1. Each new source needs custom work
Adding a new hospital, laboratory, insurer, or payment provider means new mapping, new tests, and new deployment. Engines and mappings are rebuilt for every site.
Ordinary day: onboarding a new laboratory takes six weeks, most of it spent on one message type.
Cost: slow growth and high cost per new partner.
E2. Spreadsheet and email workflows do not scale
Case tracking runs on spreadsheets that one person maintains. Status changes are sent by email and copied into the spreadsheet later.
Ordinary day: two people update the same spreadsheet row, and one change is lost.
Cost: lost status updates and no single view of the case.
E3. Model quality drifts without notice
Models trained on last year's records lose accuracy as formats, codes, and forms change. Nobody sees the drop until a reviewer reports it.
Ordinary day: a summary template changes after an EHR upgrade and the extraction quality falls quietly.
Cost: wrong output that is only caught by reviewers.
The problem list at a glance
| Group | Problems | Where the work stops |
|---|---|---|
| A. Records arrive in the wrong shape | A1, A2, A3 | Reading, joining, and matching records |
| B. Work waits on people and calendars | B1, B2, B3 | Booking, notifying, and tracking deadlines |
| C. Money moves in the wrong place | C1, C2, C3, C4 | Invoices, payments, and batch files |
| D. Trust, evidence, and audit | D1, D2, D3 | Sources, disclosure, and safe automation |
| E. Change breaks what works | E1, E2, E3 | Onboarding, tracking, and model drift |
Every problem above has a mechanism in How We Solve Them. The sources of each problem are in Where The Data Comes From.
Every problem in Problems We Solve comes from the same gap: each exchange lands in a different system in a different shape. The solution is one pipeline that every exchange passes through, one case record that every system reads from, and small services around the record that do one job each.
The pipeline
Each message, file, document, or event goes through the same stages. Each stage can be run on its own, tested on its own, and replaced without touching the others.
| Stage | What it does | Where it runs |
|---|---|---|
| 1. Receive | Accepts the exchange from its channel: HL7 v2 over MLLP, FHIR REST, SFTP, email, webhook, or document upload | Azure Integration Services, the integration engine, Logic Apps, or Functions |
| 2. Validate | Checks the envelope, the schema, the identifiers, and the sender. Anything that fails goes to a quarantine queue with a reason | Engine rules and schema validation |
| 3. Translate | Converts the source format into the canonical model: FHIR R4 resources for health data, and typed case events for workflow | Engine mappings and FHIR converters |
| 4. Enrich | Adds standard codes, normalizes units and dates, and links identifiers across systems | Terminology services and the identity match |
| 5. Judge | Applies the rules first, then the models, then the language models where needed. Each step returns a result and a confidence value | Cascade described in The AI Technology Map |
| 6. Merge | Writes the result into the case record. Every field keeps its source, time, and version | Azure Health Data Services FHIR service and the case store |
| 7. Govern | Checks the role of the person or service, the purpose of the request, and the approval state before data is shown or sent | Microsoft Entra ID, role checks, and policy decisions |
| 8. Publish | Sends the result to the next system: the scheduling service, the report, the invoice, Salesforce, or the payment provider | Service Bus topics and the adapters |
| 9. Observe | Records every step with a correlation ID and writes the audit entry | Azure Monitor and the audit ledger |
The case record
All systems read from one case record. The case record holds:
- the case identity, the referring party, the requested service, and the service level
- the care team, resources, appointment, and status history
- the records received, each with its source, its hash, and its format
- the extracted facts, each linked to the page, sentence, and date it came from
- the report drafts, the approvals, and the signed version
- the invoices, receipts, and payment status, linked to the same case
- the contacts and accounts, kept in step with Salesforce
Nothing in the case record is trusted without its source. A field that cannot be traced is shown as unverified.
Small services around the record
Each service does one job and publishes events when its job changes state.
| Service | Responsibility | Events it publishes |
|---|---|---|
| Records intake | Receives records and documents, classifies them, and extracts facts | document.received, document.classified, document.extracted |
| Scheduling | Matches eligible providers and resources on credentials, specialty, location, dependencies, and availability; holds and confirms appointments | appointment.requested, appointment.confirmed, appointment.changed |
| Notifications | Sends confirmations, reminders, and rescheduling notices by email and SMS | notice.sent, notice.failed |
| Report workflow | Tracks each report request against its service level and escalates on time | report.requested, report.escalated, report.delivered |
| Billing | Creates invoices for each payer, posts them to Xero or MYOB, and tracks balances | invoice.issued, invoice.paid, invoice.returned |
| Payments | Takes payments through the provider adapters and reconciles them to invoices | payment.initiated, payment.settled, payment.returned |
| Document management | Stores invoices, receipts, reports, and records with version history | document.stored, document.superseded |
| Audit | Writes hash-chained entries for every human and AI action | agent.action.recorded, access.recorded |
Mechanisms by problem group
| Group | Mechanism | The change in the working day |
|---|---|---|
| A. Records arrive in the wrong shape | The intake pipeline reads faxes and PDFs with Azure Document Intelligence, maps the fields to FHIR, and matches identifiers with the identity service | Records are searchable within minutes of arrival. Keying is replaced by checking the extracted fields against the page |
| B. Work waits on people and calendars | The scheduling service matches eligible providers, facilities, and equipment, and holds dependent resources until confirmation. Every change publishes an event to authorized participants | One coordinated booking, recorded once, with the same change reaching the patient or member, care team, facility, and requesting organization |
| B. Time-sensitive work has no clock | The durable workflow starts a timer at the request and escalates at defined points before the service level is missed | The owner sees the due date, and escalation reaches the accountable team and requesting organization without a manual reminder |
| C. Money moves in the wrong place | Invoices are created from the case record, stored in document management with the receipt, and posted to Xero or MYOB. The payment adapter reconciles each settlement to the invoice it pays | One invoice per payer per case, one receipt in the same folder, and a reconciliation report at the end of each day |
| C. Batch files arrive without a check | Claims and underwriting batches are validated row by row. Failed rows go to quarantine with the reason, and the rest of the batch continues | A failed row is fixed and resubmitted. The rest of the batch does not wait |
| D. Reports are drafted without visible sources | The drafting service cites the page and sentence for each statement, and the reviewer approves each statement before the report is signed | The reviewer checks the citation, not the whole file |
| D. Access and disclosure cannot be proven | Every read and write goes through the governance step and the audit ledger. Disclosure reports are produced from the ledger | A request for who viewed a file is answered from the ledger in minutes |
| D. Automation has no safe boundary | The AI services only draft, extract, and flag. They cannot write to the case record, send a report, or move money. A person approves each release | Automation removes the typing, and the person keeps the decision |
| E. Each new source needs custom work | New sources are added as adapters that map to the same canonical model. Mappings are tested against the same conformance suite | A new laboratory is added as one adapter and one test set, without changing the pipeline |
| E. Spreadsheet and email workflows | The case record replaces the spreadsheet. Status changes are events, not emails | One status for each case, visible to everyone who is allowed to see it |
| E. Model quality drifts | Each model is evaluated against reviewed cases before release and monitored after release for drift | A drop in quality raises an alert and the previous version stays in service until the new one passes |
How the solution fits the existing systems
The solution attaches beside the systems already in use. It does not replace Epic, the other EHR systems, the laboratory systems, the claims systems, Xero, MYOB, or Salesforce. Each of them keeps its responsibilities:
- Epic and the other EHR systems remain the record of care. The integration layer reads from them through FHIR and HL7 v2 and writes back only through approved interfaces.
- Xero and MYOB remain the accounting ledger. The billing service posts invoices and receives payment status.
- Salesforce remains the system of record for contacts, accounts, and referrals. The integration layer keeps the contact and account fields in step.
- Stripe, Infinicept, and the other payment providers remain the payment processors. The payment adapters call their APIs and receive their webhooks.
The path from exchange to case record is described in Where The Data Comes From. The AI placement is described in The AI Integration Solution.
The integration layer connects every authorized participant in a health care workflow. This page lists each source family, its format and transport, and the system or participant that uses the data next.
On this page: 1. Hospitals and clinics: Epic and the other EHRs | 2. Integration engines and the exchange boundary | 3. Laboratories and imaging centers | 4. Insurance companies, claims processors, and underwriters | 5. Payments: Stripe, Infinicept, and the adapters | 6. Document management: invoices and receipts | 7. Salesforce: contacts, accounts, and referrals | 8. Accounting: Xero and MYOB | 9. The formats, spelled out | 10. The transports | 11. Cadence and volumes | 12. The Azure data estate
1. Hospitals and clinics: Epic and the other EHRs
Hospitals and clinics hold records required across health care workflows: encounters, admission and discharge summaries, operative and procedure notes, test results, medication lists, orders, care plans, and imaging reports. Epic is widely used in hospital settings, while clinics and partners may operate many other EHR systems.
| Source | What it holds | How it reaches the platform | Used next by |
|---|---|---|---|
| Epic (FHIR R4 APIs) | Patient, encounter, observation, document reference, and diagnostic report resources, with consent scope | FHIR REST calls through the Epic FHIR endpoints, with OAuth 2.0 and SMART on FHIR authorization | Records intake, case record, report drafting |
| Epic interface feeds | ADT admissions and discharges, orders, results, and document notifications | HL7 v2 messages through the Epic interface bridges to the integration engine | Scheduling, case status, records intake |
| Other EHR systems | The same record families, with local identifiers and code sets | HL7 v2, FHIR R4 where offered, CCD and C-CDA documents, or PDF exports | Records intake, case record |
| Hospital records departments | Requested records as bundles, scans, or PDFs | Secure upload, SFTP, or fax-to-document conversion | Records intake, document management |
| Private clinic systems | Visit notes, referral letters, and invoices | Exports as CCD, C-CDA, PDF, or CSV, with email or upload as delivery | Records intake, billing |
2. Integration engines and the exchange boundary
The integration engine is the boundary between each outside system and the platform. It receives messages, applies the mappings, and forwards the result. Three engines are supported, and each site uses the one it already runs.
| Engine | Role in this solution |
|---|---|
| Mirth Connect (NextGen Connect) | Channels for HL7 v2 and FHIR messages, channel-level error handling, and acknowledgments |
| Rhapsody | Interface routing and transformation for hospital and laboratory feeds |
| InterSystems HealthShare | Routing and a health data repository where a hospital already runs it |
| Azure Integration Services | API Management for FHIR and REST exchanges, Service Bus for queued messages, Logic Apps for workflow, and Event Grid for events |
The engine and the Azure services form one exchange layer. The engine handles the protocols that come from the hospital and the laboratory. Azure Integration Services handles the internal exchange and the outside API calls.
3. Laboratories and imaging centers
| Source | What it holds | Format and transport | Used next by |
|---|---|---|---|
| Laboratory systems | Test orders and results | HL7 v2 ORM and ORU over MLLP; PDF reports by secure email or portal download | Records intake, case record |
| Imaging centers | Exams and radiology reports | DICOM exams through DICOMweb (STOW, QIDO, WADO) into Azure Health Data Services DICOM service; HL7 v2 or PDF reports | Records intake, report drafting |
| Imaging attachments on claims | Exam references and attached images | DICOMweb query and retrieval, with the exam linked to the claim through the change feed | Claims processing, report drafting |
4. Insurance companies, claims processors, and underwriters
Insurers, claims processors, and underwriters send and receive the financial and coverage messages of a case. Most of them use X12 EDI. Some offer FHIR APIs.
| Transaction | Direction | Meaning in a case |
|---|---|---|
| 270 / 271 | Request and response | Eligibility and benefits for the patient or member |
| 276 / 277 | Request and response | Status of a claim |
| 278 | Request and response | Prior authorization for a service |
| 837 | Outbound | Professional claim for a service |
| 835 | Inbound | Remittance advice with payments and adjustments |
| 997 / 999 / 277CA | Inbound | Acknowledgments that each batch was received and accepted |
| Batch files | Inbound and outbound | Bulk records, underwriting files, and reconciliation extracts, by SFTP or secure portal |
Claims processors and underwriters that do not offer X12 send files in their own layout. Each layout is mapped once in the engine and tested against the same conformance suite.
5. Payments: Stripe, Infinicept, and the adapters
Payments reach the platform from the payment providers the business uses. Each provider sits behind one adapter interface, so charges, refunds, and settlement reports follow the same internal path whichever provider handled them.
| Provider | Role | How the platform connects |
|---|---|---|
| Stripe | Card payments, payment links, refunds, and payouts | Stripe API for charges and refunds; signed webhooks for payment and refund events |
| Infinicept | Payment processing for the business | Infinicept API for payment requests and status; webhooks or scheduled settlement reports |
| Adyen, Usio, AndDone | Additional providers where a site uses them | The same adapter interface and the same normalized events |
| Bank transfer and direct debit | Settlement by file | Bank files and settlement reports, matched to invoices by reference |
Every webhook is verified by its signature before its contents are read. Each provider's event is normalized into the same internal payment event, so the reconciliation service does not need to know which provider sent it.
6. Document management: invoices and receipts
Invoices, receipts, reports, and records are kept in document management. Each document has a version history, a link to its case, and a record of who stored it.
| Document | Created by | Stored with | Used next by |
|---|---|---|---|
| Invoice | Billing service | Case, payer, and invoice number | Accounting, payment matching |
| Receipt and payment confirmation | Payment adapter | Case, invoice, and provider reference | Reconciliation, accounting |
| Draft and approved artifact | Document workflow | Workflow, version, evidence, and approver | Delivery to an authorized recipient or partner |
| Records as received | Records intake | Case, source, hash, and receipt date | Records intake, audit |
| Correspondence | Notifications service | Case and recipient | Audit, case history |
7. Salesforce: contacts, accounts, and referrals
Salesforce is the system of record for contacts, accounts, and referrals. The integration layer keeps the case record and Salesforce in step through the Salesforce REST and Bulk APIs and through platform events for near-real-time changes.
| Salesforce object | Direction | What moves |
|---|---|---|
| Organization (provider, payer, partner, agency) | Two-way | Name, address, endpoint, and identifiers |
| Contact (solicitor, claims handler, clinic staff) | Two-way | Name, role, and contact details |
| Service request or workflow | Two-way | Purpose, status, service level, owner, and assigned care team |
| Opportunity or contract | Inbound | Service agreement, rates, and payment terms |
| Attachments | Outbound | Signed reports and invoices, linked to the referral |
8. Accounting: Xero and MYOB
Invoices are posted to Xero or MYOB, whichever the business uses. The billing service sends invoices, receives payment status, and reads the chart of accounts. The accounting system remains the ledger of record.
9. The formats, spelled out
| Format | Full name | Used for |
|---|---|---|
| HL7 v2 | Health Level Seven version 2 | Admissions, orders, results, and documents from hospitals and laboratories |
| FHIR R4 | Fast Healthcare Interoperability Resources, release 4 | Health resources from Epic and the other EHRs, and the canonical case data |
| CCD | Continuity of Care Document | Summaries of care from EHR systems |
| C-CDA | Consolidated Clinical Document Architecture | Health documents exchanged between organizations |
| X12 EDI | ANSI X12 Electronic Data Interchange | Eligibility, claims, prior authorization, and remittance transactions |
| DICOM | Digital Imaging and Communications in Medicine | Imaging exams and their attributes |
| DICOMweb | DICOM over HTTP (STOW, QIDO, WADO) | Storing, searching, and retrieving imaging exams |
| Portable Document Format | Reports, invoices, receipts, and scanned records | |
| CSV and XLSX | Comma-separated values and Excel spreadsheet | Batch files from claims processors and underwriters |
| JSON | JavaScript Object Notation | Webhooks, API payloads, and events |
| SMART on FHIR | Substitutable Medical Applications, Reusable Technologies on FHIR | The authorization profile for Epic FHIR access |
10. The transports
| Transport | Used for |
|---|---|
| MLLP | HL7 v2 messages over TCP between the engine and the hospital or laboratory system |
| HTTPS REST | FHIR, Salesforce, Xero, MYOB, and payment provider APIs |
| SFTP | Batch files from claims processors, underwriters, and banks |
| Webhooks | Payment provider events, with signature verification |
| Service Bus | Queued messages between the platform services |
| Event Grid | Events that notify subscribers of a change |
| Email and SMS | Notices to patients or members, care teams, facilities, and authorized partners, plus inbound records where permitted |
11. Cadence and volumes
| Cadence | Sources | Handling |
|---|---|---|
| Seconds | Payment webhooks, appointment changes | Event-driven handling with the notifications service |
| Minutes | HL7 v2 results and admissions, FHIR changes | Engine channels with acknowledgment and retry |
| Hours | Batch files from claims processors and underwriters | Scheduled batch handling with row-level quarantine |
| Daily | Bank settlement reports and accounting extracts | Scheduled reconciliation |
| Weekly and monthly | Payer and processor rule updates, code set releases, and FHIR and HL7 version updates | Rules and mappings are updated as configuration, not as code |
12. The Azure data estate
Every service below is hosted on Azure. Each one is reached through an abstraction interface, and a local mock stands in for it during development, so the platform can be built and tested without a live subscription.
| Azure service | Role in this solution |
|---|---|
| Azure Integration Services: API Management | Front door for FHIR, REST, and partner APIs; signed tokens and rate limits |
| Azure Integration Services: Service Bus and Event Grid | Queued messages and events between platform services |
| Azure Integration Services: Logic Apps and Functions | Workflow steps, timers for service levels, and webhook handlers |
| Azure Integration Services: Data Factory | Scheduled batch loads and extracts |
| Azure Health Data Services: FHIR service | The canonical FHIR store for health resources |
| Azure Health Data Services: DICOM service | Imaging exams, queried by the same identity as the case |
| Azure Health Data Services: MedTech service | Device and monitor data where a case needs it |
| Azure Document Intelligence | Reading faxes, scans, and PDFs into structured fields |
| Azure AI Search | Indexing of records and reports for retrieval with citations |
| Azure AI Foundry and Azure OpenAI | Hosted language models, small language models, and embedding models |
| Azure Storage and Data Lake Storage Gen2 | Document storage and the analytics store |
| Azure SQL Database and Azure Cosmos DB | Case, billing, and audit tables; document collections |
| Microsoft Entra ID and Managed Identity | Identity for people, services, and agents |
| Azure Key Vault | Secrets, keys, and certificates |
| Azure Monitor and Application Insights | Telemetry, dashboards, and alerts |
The data estate follows the same rule everywhere: each source writes its record once, the case record is the single read point, and the audit ledger records every write.
AI is added to health care workflows without rebuilding the systems that run them. The governed AI layer reads only authorized data already received by the integration platform, drafts or extracts from it, and shows the result inside the screens people already use. It never independently makes a clinical or coverage decision, writes to a system of record, releases an artifact, submits a claim, or moves money. An accountable person approves every consequential action.
The chain from exchange to decision
Every exchange follows the same chain. AI sits at the judgment stage, after the data is normalized and before the person decides.
| Step | What happens | Where AI sits |
|---|---|---|
| 1. Exchange | A hospital, laboratory, insurer, processor, or provider sends a message, file, document, or event | None |
| 2. Epic and other EHRs | Records are read through FHIR APIs, or received as HL7 v2 feeds through the Epic interface bridges, or as CCD and C-CDA documents | None |
| 3. FHIR and HL7 | Each message is parsed, validated, and mapped to FHIR R4 resources | Document extraction on scanned and faxed records |
| 4. Integration engine | Mirth, Rhapsody, or HealthShare routes the message, applies channel rules, and sends the acknowledgment | None |
| 5. Case record | The normalized result is merged into the case record with its source | Identity suggestions for records that do not match exactly |
| 6. Judgment | Rules, models, and language models produce a result with a confidence value and a citation | The cascade in The AI Technology Map |
| 7. Person | The accountable clinician, operational reviewer, billing coordinator, or finance owner reviews and approves | Drafts and flags, shown in the existing screen |
| 8. Publish | The approved result goes to the report, the invoice, the calendar, Salesforce, or the payment provider | None |
The principles
The solution follows four principles. Each one limits where AI can act.
- Advisory only. AI produces drafts, extracted fields, summaries, and flags. It does not write to the case record, sign a report, post an invoice, or release a payment.
- Cited output. Each statement that AI produces points to the page, sentence, or record it came from. An output without a citation is shown as unverified.
- Failure isolation. If an AI service is slow or unavailable, the workflow continues on the rule-based path. A failed model call never stops an exchange from being received, validated, or merged.
- Smallest capable model first. Each task starts with a rule. When the rule cannot decide, a classic or neural model is tried. A language model is used only where reasoning over text is needed.
The task catalog
The catalog lists the tasks AI performs in this solution. Each task has an owner, an output, and a person who approves it.
| # | Task | Output | Approved by | Stage |
|---|---|---|---|---|
| 1 | Records extraction from faxes and scans | Structured fields with page references | Records coordinator | Intake |
| 2 | Identity suggestion across organizations | Ranked candidate matches with the fields that agree and disagree | Records coordinator | Enrich |
| 3 | Records summary for an authorized reviewer | A summary with a citation for each statement | Clinician or operational reviewer | Judgment |
| 4 | Care-team and resource matching suggestion | Ranked eligible combinations with the reason for each rank | Scheduling coordinator | Judgment |
| 5 | Appointment notice drafting | Confirmation, reminder, or rescheduling notice in the recipient's language | Scheduling coordinator | Publish |
| 6 | Clinical or administrative draft with citations | Draft sections, each statement linked to its source | Accountable professional and reviewer | Judgment |
| 7 | Report completeness check | A list of required sections, missing evidence, and open questions | Report writer | Judgment |
| 8 | Invoice line suggestion | Service codes and amounts drawn from the approved rate schedule | Billing coordinator | Judgment |
| 9 | Payment allocation suggestion | Matches between settlements and invoices, with the reference used | Accountant | Judgment |
| 10 | Batch error explanation | A plain-language reason for each quarantined row and a suggested fix | Batch operator | Validate |
| 11 | Duplicate case detection | Candidate duplicates with the matching fields | Case coordinator | Enrich |
| 12 | Salesforce field enrichment | Suggested contact and account field updates with sources | Account owner | Publish |
| 13 | Anomaly flag on billing and payments | A flag with the rule or pattern that raised it | Accountant | Judgment |
| 14 | Correspondence drafting | Letters and emails based on the case status, with the facts cited | Case coordinator | Publish |
Where the AI runs
| Setting | Where it runs | Why |
|---|---|---|
| Extraction and classification | Azure Document Intelligence and classic models in the integration layer | Fast, low cost, and deterministic for known forms |
| Retrieval over records and reports | Azure AI Search with the case access rules applied at query time | A person sees only the records they may read |
| Summaries, drafts, and explanations | Hosted language models through Azure AI Foundry, reached through Azure API Management | Long-context reasoning over text with citations |
| Domain tasks with fixed scope | Small language models hosted on Azure, fine-tuned on the workflow's own reviewed examples | Lower cost per call and tighter output control |
| Scoring and anomaly detection | Classic and neural models trained on the case history | Patterns across many cases that a rule cannot express |
Guardrails
Every AI call passes through the same guardrails. The guardrails are part of the integration layer, so they apply to every model and every tool.
| Guardrail | Applied at | What it does |
|---|---|---|
| Purpose check | Input | Confirms the purpose of the request, such as payment, scheduling, or report drafting, before any record is read |
| Access check | Input | Reads the caller's role and limits the records retrieved to those the caller may see |
| Redaction | Input and output | Removes identifiers that the task does not need before the text reaches a model, and removes them again from the output |
| Schema check | Output | Rejects output that does not match the expected structure |
| Citation check | Output | Confirms that each statement points to a source that exists and supports it |
| Refusal | Output | Returns "insufficient evidence" when the sources do not support an answer |
| Tool allow-list | Tool calls | Lets a model call only the tools its task needs, with the arguments checked |
| Approval gate | Publish | Blocks any write, send, or payment until a named person approves it |
| Audit entry | Every call | Records the input reference, the model version, the output reference, the approver, and the time |
Inference, caching, and cost
- Routing. A request goes to the smallest model that can handle its task. Simple classification never reaches a language model.
- Prompt caching. Shared instructions and reference text are cached, so repeated prompts do not pay for the same tokens twice.
- Semantic caching. Answers are reused only when the question, the policy version, and the access rules all match. An answer for one role is never returned to another.
- Token budgets. Each task has a maximum input size. Long records are split, retrieved in parts, and summarized before the final step.
- Fallback. If the language model is unavailable, the task falls back to the rule-based path or a queue for a person.
What is measured
The solution is measured against baselines taken from the customer's own workflow before any AI task is switched on. The measures are:
- time from records receipt to the first usable summary
- time from report request to signed report, against the service level
- number of rows quarantined per batch, and time to resolve each one
- number of unmatched settlements at the end of each day
- number of AI outputs rejected by reviewers, by task
- number of guardrail refusals, by reason
A task is kept in service only while its measures improve on the baseline and its rejection rate stays within the level agreed for that task.
How the solution changes the day
| Role | Before | With the overlay |
|---|---|---|
| Records coordinator | Keys fields from a fax into the case file | Checks the extracted fields against the page, with the source shown beside each one |
| Scheduling coordinator | Calls providers and facilities one at a time | Reviews ranked eligible care-team and resource combinations with reasons |
| Clinician or operational reviewer | Reads the full file before writing | Reads a cited summary and checks each statement against its source |
| Report writer | Drafts from memory and notes | Edits a draft in which each statement points to its source |
| Billing coordinator | Builds each invoice line by hand | Reviews suggested lines drawn from the approved rate schedule |
| Accountant | Matches settlements to invoices in three folders | Reviews suggested matches with the reference used for each |
The overlay appears on the screens the people already use. It does not add a new screen to learn.
The technology behind each task is described in The AI Technology Map. The end-to-end case flow, with each approval point, is in Report Drafting and Records Summary.
Every AI component in the solution, where it sits, and what it does. The map is organized in the order the work flows: the Azure services that host the components, the model tiers that produce the judgments, the machinery that keeps the answers grounded, and the loops that keep the models under review.
On this page: 1. Azure services, placed | 2. The model tiers: rules, classic and neural models, small language models, large language models | 3. Retrieval, citations, and validation | 4. Judgment: cross-model checks and evaluation | 5. Learning loops: feedback, evaluation sets, drift, and rollback | 6. The cascade for one case | 7. Reference components in the workspace | 8. The master map
1. Azure services, placed
| Azure service | Layer | Where it plugs in |
|---|---|---|
| Azure API Management | Exchange | Front door for FHIR, REST, and partner APIs; token checks and rate limits before any model call |
| Azure Service Bus and Event Grid | Exchange | Carries the events between the intake, scheduling, reports, billing, and payments services |
| Azure Logic Apps and Azure Functions | Exchange | Workflow steps, service-level timers, and webhook handlers |
| Azure Data Factory | Exchange | Scheduled batch loads from claims processors, underwriters, and settlement files |
| Azure Health Data Services: FHIR service | Data | The canonical store for FHIR resources from Epic and other EHRs |
| Azure Health Data Services: DICOM service | Data | Imaging exams, queried by the same identity as the case |
| Azure Health Data Services: MedTech service | Data | Device and monitor data where a case needs it |
| Azure Document Intelligence | Intake | Reads faxes, scans, and PDFs into fields, with the page and region for each field |
| Azure AI Search | Retrieval | Index over records and reports, with the access rules applied at query time |
| Azure AI Foundry and Azure OpenAI | Models | Hosted language models, embedding models, and the deployment of small language models |
| Azure AI Speech | Intake | Transcription of recorded examination dictation, with the recording kept under the same access rules |
| Microsoft Entra ID and Managed Identity | Governance | Identity for people, services, and agents; no shared keys |
| Azure Key Vault | Governance | Secrets, keys, and certificates for every connection |
| Azure Monitor and Application Insights | Operations | Telemetry for every model call, with latency, token counts, and refusals |
Exchange : API Management -> Service Bus / Event Grid -> Logic Apps / Functions
Intake : Document Intelligence -> Speech (dictation) -> FHIR / DICOM services
Retrieval : AI Search (access rules at query time) -> citations
Models : rules -> classic and neural models -> small language models -> language models
Governance : Entra ID -> Key Vault -> policy checks -> audit ledger
Operations : Azure Monitor -> evaluation and drift dashboards
2. The model tiers: rules, classic and neural models, small language models, large language models
Each judgment starts at the lowest tier that can make it. A tier either decides with a confidence value above its threshold, or passes the case to the next tier with its partial result.
| Tier | What it is | What it decides in this solution | Typical use |
|---|---|---|---|
| 1. Static rules | Versioned rules stored as configuration: field checks, code pairs, required sections, rate schedule lookups | Whether a row is valid, whether an invoice line matches the rate schedule, whether a required section is present | Validation and routing |
| 2. Classic models | Gradient-boosted trees, logistic regression, and similar models trained on governed workflow history | Duplicate workflow candidates, billing and payment anomalies, provider and resource ranking features | Scoring with explainable features |
| 3. Neural models | Sequence and document models for layout, entity recognition, and classification | Field extraction from scans, entity recognition in records, classification of documents | Extraction and classification |
| 4. Small language models | Models of a few billion parameters, fine-tuned on reviewed examples from the workflow | Completeness checks, section labeling, short extraction from known document types | Domain tasks with fixed scope and low cost per call |
| 5. Large language models | Hosted general models, such as GPT, Claude, and Llama families available through Azure AI Foundry | Summaries with citations, report drafts, explanations of quality-check results, letter drafts | Long-context reasoning over several sources |
Rules for the tiers:
- A tier may refuse a case it cannot decide. A refusal moves the case to the next tier and is recorded.
- A large language model is never the first tier for a field, a code, or a total.
- A small language model output that does not match its schema is discarded and retried once at the same tier, then passed on.
- Each tier's version and threshold are recorded with each decision.
3. Retrieval, citations, and validation
| Component | What it does | Source in the workspace |
|---|---|---|
| Records memory with citations | Indexes records and reports with their sensitivity tags. Answers cite the document, version, and span. Answers are trimmed by the caller's role | claims-document-memory |
| Policy and wording search | Hybrid keyword and vector search over policies and wording, with document access rules applied to each result | policy-wording-assistant, insurance-policy-qa-grounded-citations |
| Semantic cache | Returns a cached answer only when the question, the policy version, and the access rules match | benefits-semantic-cache |
| Duplicate candidate search | Ranks records and cases that may be the same, with the matching fields | policy-search-duplicate-claims |
| Extraction flow with quality metrics | Classifies, extracts, and redacts fields from long documents, and records quality metrics for each run | medical-records-extraction-flow, claims-document-intake |
| Streaming extraction with safe retries | Reads long documents in parts and resumes after a failure without repeating completed parts | claims-document-streaming |
| Context compression with facts kept | Shortens long context while keeping negations, numbers, dates, and names, and scores fact retention | clinical-context-compression |
| Guided tool calling | Constrains a model's tool calls to the schemas of the tools the task allows | ehr-guided-tool-calling |
| Output format checks | Compares output formats, including JSON and TOON, for accuracy and token cost, and rejects output that fails its schema | json-toon-claims-underwriting-llm-output-validation |
Each citation is checked after the answer is produced. A citation that points to nothing, or to a span that does not contain the statement, fails the check. The answer is then regenerated with stricter instructions or refused.
4. Judgment: cross-model checks and evaluation
| Mechanism | How it works | Where it is used |
|---|---|---|
| Cross-model check | A second model, from a different family where available, checks the first model's answer against the same sources | Report drafts, summaries, invoice lines |
| Rule check on model output | The output is checked by the static rules for the task, such as the required sections or the rate schedule | Every drafted or suggested output |
| LLM-as-a-judge | A judge model scores outputs against a rubric. Its scores are checked against human scores before it is trusted | Evaluation runs and release gates |
| Claim decision letter alignment | Letter drafts are aligned to approved style and rules using preference data from reviewers | claims-letter-alignment |
| Release gate for prompts and skills | A prompt or skill cannot be released until its graded results pass | claims-prompt-grader-suite, claims-skill-release-gate |
5. Learning loops: feedback, evaluation sets, drift, and rollback
| Loop | What it does | Where it runs |
|---|---|---|
| Reviewer feedback | Every edit, rejection, and approval a reviewer makes is stored with the output it applies to | The approval step of each task |
| Evaluation sets | Reviewed cases are kept as evaluation sets, split by case type and period. The sets are versioned and never changed once used for a release decision | The evaluation service |
| Training splits | Training and holdout splits are reproducible and stratified by line of business | claims-notes-finetune-dataset |
| Per-carrier adapters | Small adapters for routing, one for each carrier or processor, are merged or swapped without retraining the base model | claims-routing-lora |
| Drift monitoring | Input mix, output confidence, rejection rate, and citation failures are tracked by task and week | Azure Monitor dashboards |
| Rollback | When a measure drops below its threshold, the previous model or prompt version is restored, and the event is recorded | The release gate and the audit ledger |
6. The cascade for one case
The example is illustrative: the counts and values are placeholders for the shape of each result. It follows one referral from intake to a decision on the next step. Each row shows the tier that handled the step, the result, and the person who approved it.
| Step | Tier | Result | Approved by |
|---|---|---|---|
| Records received as a 60-page fax | Document Intelligence (tier 3) | 212 fields extracted, each with its page and region | None needed for the extraction; the coordinator checks the flagged fields |
| Identity match across two organizations | Static rule (tier 1), then classic model (tier 2) | Exact match on the identifier fails; a ranked candidate with the agreeing fields is produced | Records coordinator confirms the match |
| Summary for an authorized reviewer | Large language model (tier 5), with retrieval | Summary of 9 sections, each statement cited to a source | Accountable professional reviews each section |
| Completeness check on the draft report | Static rule (tier 1), then small language model (tier 4) | Two required sections missing; one statement without a citation flagged | Report writer resolves each flag |
| Invoice line for the examination | Static rule (tier 1) against the rate schedule | Line matched to the approved rate; no model call | Billing coordinator approves the invoice |
| Settlement matched to invoice | Classic model (tier 2) for the match score, static rule for the amount check | Match with the payment reference shown | Accountant approves the match |
7. Reference components in the workspace
The solution reuses tested components from the repositories in the workspace. The components are listed by the module of the solution they serve.
| Module | Components | Repository |
|---|---|---|
| Records and documents | Document intake, records extraction flow, streaming extraction, records feed | Platform module |
| Case and workflow | Prior authorization workflow with human review, claim appeals graph, property claim flow | Platform module |
| Payments and approvals | ACH reconciliation, payout saga with approvals, payment governance, payments ledger reader | Platform module |
| Governance and agents | Payment guardrails, tool-call guard, egress guard, credential masking, launch configuration, connector registry gate | Platform module |
| Assurance | Audit ledger with hash chain and proofs, release gate, prompt grader, answer streamer | Platform module |
| Exchange engines | Mirth, Rhapsody, and HealthShare channel patterns; acknowledgment and error channels; engine abstraction | Platform module |
| FHIR and HL7 | FHIR R4 handling, HL7 v2 to FHIR mapping, typed model generation | Platform module |
| Retrieval and memory | Retrieval with citations, hybrid search, semantic memory | Platform module |
| Healthcare AI layers | Enrichment stage, governed record, advisory AI overlay | Platform module |
8. The master map
| Layer | Component | Tier | Azure hosting | Approval point |
|---|---|---|---|---|
| Intake | Document Intelligence extraction | Neural | Document Intelligence | Coordinator checks flagged fields |
| Intake | Speech transcription of dictation | Neural | AI Speech | Originating professional reviews the transcript |
| Enrich | Identity match | Rule, classic | Functions, SQL | Coordinator confirms |
| Enrich | Terminology normalization | Rule | Engine and terminology service | Automatic, logged |
| Judge | Records summary | Large language model | AI Foundry | Authorized clinician or operational reviewer |
| Judge | Document draft with citations | Large language model with cross-model check | AI Foundry | Accountable professional and reviewer |
| Judge | Completeness check | Rule, small language model | AI Foundry | Report writer |
| Judge | Care-team and resource ranking | Rule, classic | Functions | Scheduling coordinator |
| Judge | Invoice lines | Rule | Functions and billing service | Billing coordinator |
| Judge | Settlement matching | Classic, rule | Functions and payments service | Accountant |
| Judge | Anomaly flags | Classic, neural | Machine learning endpoint | Accountant |
| Publish | Notices and letters | Large language model with rule check | AI Foundry | Coordinator |
| Govern | Policy and tool checks | Rule | API Management and Entra ID | Automatic, logged |
| Operate | Evaluation, drift, rollback | Judge model with human scores | Azure Monitor and evaluation service | Release owner |
The technology in this map is applied to the workflow in The AI Integration Solution. The sources it reads from are in Where The Data Comes From.
This page describes a reusable health care workflow from service request through delivery, revenue cycle, and audit. It then examines human-reviewed document drafting in detail. Each stage names the system that performs the work, the AI assistance allowed inside the boundary, and the accountable person who approves the outcome.
The workflow lifecycle
| # | Stage | System that does the work | AI assistance | Human approval | Audit entry |
|---|---|---|---|---|---|
| 1 | Service request and intake | Portal, FHIR or partner API, interface engine, and intake workflow | Extracts, classifies, and checks duplicate candidates | Workflow owner confirms identity, purpose, consent context, and priority | Request received, source, purpose, owner, and time |
| 2 | Records exchange | EHR, HIE, laboratory, imaging, pharmacy, payer, and document intake through FHIR, HL7 v2, X12, NCPDP, DICOM, or upload | Extracts fields, suggests identity matches, and preserves provenance | Coordinator resolves uncertain identity or mapping results | Original payload, source, hash, validation, and receipt time |
| 3 | Care-team and resource scheduling | Scheduling service with provider, facility, equipment, and participant availability | Ranks only eligible combinations and explains each rank | Scheduling coordinator selects and confirms resources | Selected option, reasons, holds, and confirmation |
| 4 | Coordination and notifications | Scheduling, workflow, and communication services | Drafts approved-template notices in the recipient's language | Coordinator owns templates and exceptions | Each state change, recipient, channel, and delivery result |
| 5 | Clinical or operational drafting | Document workflow with governed retrieval over the workflow record | Summarizes records and drafts sections with source citations | Authorized clinician or operational reviewer approves each section | Model and prompt version, sources, draft versions, edits, and approvals |
| 6 | Review and decision | Review checklist, rules, and professional workspace | Checks completeness, contradictions, and unsupported statements | Accountable professional decides; high-risk flows can require a second approver | Decision, reviewer identity, evidence, reason, and version |
| 7 | Approved delivery | Document management, exchange API, secure portal, or trusted network | No autonomous release | Accountable professional signs or attests; workflow policy releases | Final hash, signature or attestation, recipient, channel, and outcome |
| 8 | Revenue cycle and audit | Claims, billing, clearinghouse, payer, accounting, and settlement services | Suggests codes or matches and flags anomalies | Billing and finance owners approve exceptions, refunds, and high-value actions | Claim, invoice, remittance, payment, reconciliation, and approval |
Every stage writes to the same governed workflow record. Independent steps may run in parallel, but consequential transitions require their defined evidence and approval. The original payload is preserved at the exchange boundary, and one correlation trail links transport, application acknowledgment, business completion, and audit.
Human-reviewed drafting in detail
Scope
The drafting step prepares a clinical or administrative artifact from records already authorized for the workflow. It does not diagnose, determine coverage, make a utilization decision, establish professional judgment, sign, release, or move money. It organizes evidence, cites sources, exposes missing information, and hands control to the accountable professional.
Inputs
| Input | Source | Access rule |
|---|---|---|
| Clinical and administrative records | FHIR resources, HL7 v2 messages or documents, C-CDA, DICOM metadata, X12 responses, and scanned records | Restricted by role, patient or member identity, consent, purpose of use, and workflow assignment |
| Request and questions | Service-request stage | Read only by the assigned team and services required for the stated purpose |
| Professional notes | Dictation transcribed through speech services and typed notes | Same access and retention policy as the originating recording or note |
| Document template | Organization-approved template held as versioned configuration | Available only to the workflows and roles approved for that template |
| Rules | Required sections, citation rules, terminology profiles, and completeness checklist | Read by the drafting and validation services; changes require governance approval |
Steps
- Check purpose and authority. Confirm the request purpose, patient or member context, consent, assigned role, and permitted output.
- Retrieve within policy. Retrieve only the records the caller may use for this purpose, with access filters applied before content reaches a model.
- Draft by section. Build each section from retrieved passages or structured fields. Every material statement carries provenance to the source.
- Validate citations. Remove or rewrite a statement when its citation is missing, inaccessible, or does not support it.
- Check completeness and terminology. Validate required sections, identifiers, codes, units, dates, contradictions, and missing evidence.
- Cross-check risk. Apply deterministic rules and, where justified, a second model to surface disagreement without silently resolving it.
- Hand over. Save a new version and present evidence, open items, disagreements, and validation results to the accountable reviewer.
Human approval
- The accountable professional accepts, edits, or rejects every required section. Each action is versioned and attributed.
- High-risk workflows may require a second independent reviewer or explicit separation of duties.
- Only approved content can be signed, attested, transmitted, posted, or used to advance the workflow.
What the drafting step does not do
- It does not write directly to the EHR or another system of record outside an approved workflow action.
- It does not send a document, submit a claim, make a clinical decision, determine coverage, or release payment.
- It does not invent a finding when the evidence is silent or contradictory.
- It does not retrieve records from another patient, member, tenant, or workflow.
When the drafting step fails
| Failure | What happens |
|---|---|
| A model is unavailable | The workflow falls back to rules and manual work; source records remain available |
| A citation check fails | The statement is removed and listed as an open issue |
| Identity or consent is uncertain | Processing stops before retrieval and routes to an authorized resolver |
| Records are incomplete or contradictory | Missing or conflicting evidence is displayed; the system does not guess |
| A reviewer rejects content | The rejection and reason are recorded, and a new version starts from the same governed evidence |
| The service level is at risk | Durable workflow rules escalate with the owner, remaining time, and open blockers |
Audit
Every drafting step records the caller, purpose, identity and consent context, records accessed, configuration and model versions, citations, validation outcomes, edits, approvals, and final signature or attestation. Audit records are immutable or tamper-evident and correlated with the original exchanges.
Measures for this workflow
- time from request and records receipt to the first usable, cited summary
- time from request to approved business outcome against the service level
- patient or member match exceptions and time to resolution
- unsupported statements removed by citation validation
- sections rejected or materially edited by reviewers and the reason
- artifacts returned for correction after release
- end-to-end trace coverage from source exchange to business completion
Related pages
The source systems and standards are described in Where The Data Comes From. AI tasks and approval boundaries are in The AI Integration Solution. Models and services are in The AI Technology Map.