Clinical Update — June 2026: This playbook has been revised to reflect CMS's finalized 2026 E/M Documentation Guidelines, the AMA's updated MDM complexity table effective January 2026, and OIG audit enforcement patterns observed in Q1–Q2 2026 targeting high-acuity ED encounters with insufficient Category 2 and Category 3 MDM substantiation. FHIR R4B Provenance resource specifications have been updated to align with HL7's May 2026 errata. If your organization evaluated ambient AI scribes using pre-2026 criteria, this guide identifies the specific technical and compliance gaps that current audit activity is now exploiting.

Clinical Reasoning vs. Transcription: The 2026 Accuracy Standard

The Operations Playbook for CMIOs Evaluating AI Documentation Intelligence

TL;DR — Why This Matters to Your Organization

Every AI scribe on the market in 2026 can transcribe words. Almost none can reconstruct the clinical reasoning that justifies Level 5 billing. This playbook explains why the gap between "what was said" and "why it was ordered" is the single largest source of preventable revenue loss and audit exposure in emergency and procedural medicine — and how Scribing.io's clinical reasoning engine closes it using FHIR-native MDM documentation, causal inference from EHR signals, and auditable Provenance resources that survive the 6-year Medicare lookback window. If you are a CMIO evaluating ambient AI platforms, this is the technical and clinical framework your compliance, revenue cycle, and physician leadership teams need before signing a contract.

Contents

• From Speech-to-Text to Clinical Reasoning: The Paradigm Shift Defining 2026

• Scribing.io Clinical Logic: ED Evaluation of Suspected Pulmonary Embolism Post-Arthroplasty

• Step-by-Step: How the Clinical Reasoning Engine Solves the PE Scenario

• The MDM Documentation Gap: What Transcription-First Platforms Cannot Capture

• FHIR Provenance Architecture and the 6-Year Medicare Lookback

• Technical Reference: ICD-10 Documentation Standards

• CMIO Evaluation Framework: 12 Questions Your Vendor Cannot Answer

• See the Clinical Reasoning Graph in Action

From Speech-to-Text to Clinical Reasoning: The Paradigm Shift Defining 2026

2024 was about speech-to-text. The entire ambient scribe market coalesced around a single value proposition: listen to the encounter, produce a note, reduce pajama time. That value was real. It addressed burnout. It returned hours to clinicians. And Scribing.io delivered it — but we treated transcription as the foundation, not the ceiling.

The ceiling is clinical reasoning: the ability of an AI system to identify not merely what a physician said, but why they made specific diagnostic and therapeutic decisions. This distinction is not academic. It is the difference between a note that describes an encounter and a note that justifies the medical decision-making (MDM) complexity required for high-acuity E/M codes, survives retrospective payer audit, and satisfies CMS's finalized MDM guidelines. Organizations deploying Epic Integration workflows that rely solely on ambient transcription inherit this gap regardless of how deeply the scribe embeds in the EHR.

Why transcription alone fails at high-acuity billing

The AMA's E/M MDM framework evaluates three categories for code-level determination:

A JAMA Internal Medicine analysis of ED billing patterns found that MDM documentation deficiency — not undercoding of clinical work — drives the majority of high-acuity downgrades on retrospective audit. The physician performed Level 5 work. The note failed to prove it. Published OIG audit reports from 2024–2025 confirm that 30–40% of emergency department encounters billed at 99285 face downgrades, with Category 2 and Category 3 deficiencies cited most frequently.

Every competitor in the current market — from enterprise platforms at $830/month to lightweight tools at $84/month — evaluates AI scribes on note accuracy, EHR integration speed, and template customization. None addresses MDM completeness as a core metric. Organizations that connect AI scribes to their athenahealth API or Cerner workflows without clinical reasoning capability are automating the production of audit-vulnerable notes at scale.

Scribing.io Clinical Logic: ED Evaluation of Suspected Pulmonary Embolism Post-Arthroplasty

The Scenario: An ED physician evaluates a 54-year-old woman presenting with sudden pleuritic chest pain 8 days after right knee arthroplasty. The pod is noisy. The physician performs a focused assessment, reviews the vitals monitor (HR 118, SpO2 90% on room air), notes the patient's OCP use and recent surgical history, and orders a CTA pulmonary angiogram. She does not verbalize the Wells score calculation. She does not narrate why she deferred D-dimer. The history is provided primarily by the patient's spouse, which the physician does not announce aloud. She briefly calls the patient's orthopedic surgeon to coordinate anticoagulation timing but does not dictate this interaction.

What a transcription-only scribe produces

"54-year-old female presents with chest pain. CTA chest ordered. History obtained."

This note supports 99283 at best. A payer auditor sees no documented risk stratification, no independent historian attribution, no external physician discussion, no linkage between the order and a suspected high-risk condition, and no independent data interpretation. The claim submitted at 99285 gets downgraded to 99284 or 99283. Multiply this across 15 high-acuity encounters per shift, 3 shifts per week, 48 weeks per year: the revenue impact is six figures per physician annually.

What Scribing.io's clinical reasoning engine produces

Scribing.io does not simply transcribe the encounter. It fuses the audio stream with real-time EHR signals to reconstruct the complete clinical reasoning chain:

The generated note reads:

"High-risk pulmonary embolism considered in the setting of acute pleuritic chest pain 8 days post right total knee arthroplasty, tachycardia (HR 118), hypoxemia (SpO2 90% RA), and active OCP use. D-dimer deferred given high pretest probability — CTA pulmonary angiogram obtained as definitive study. History obtained from independent historian (spouse) due to patient's respiratory distress. External record review performed; discussed anticoagulation timing with Dr. [Name], Orthopedic Surgery (NPI: [auto-populated]), at [timestamp]. Shared decision-making regarding imaging risk/benefit performed with patient and spouse."

The claim holds at 99285. Three of three MDM categories are met at high complexity. Every element is discretely traceable in FHIR resources with full Provenance.

Step-by-Step: How the Clinical Reasoning Engine Solves the PE Scenario

The anchor truth: 2024 was about "Speech-to-Text"; 2026 is about "Clinical Reasoning." Frontier models identify the why behind a doctor's questions, whereas specialized tools only record the what, missing the logic needed for Level 5 billing. Here is the granular, step-by-step breakdown of how Scribing.io's engine operates in this scenario:

1. Multi-stream ingestion (T+0 seconds). The engine simultaneously opens three data channels: (a) the ambient audio feed from the room microphone, (b) a SMART-on-FHIR subscription to the patient's chart in Epic/Cerner, and (c) facility system event hooks (phone system, PACS viewer, medication dispensing). These are not polled sequentially. They run as concurrent event streams with sub-second latency alignment via NTP-synced timestamps.

2. Speaker diarization and role assignment (T+8 seconds). Within the first seconds of audio capture, the engine identifies three distinct voice profiles: physician, patient, and a third speaker. The third speaker's voice does not match the patient. The engine queries the patient's emergency contact record in the EHR and flags the third speaker as a probable family member. When the physician directs clinical history questions to this speaker and the speaker responds with medical history details, the engine classifies the speaker as an independent historian — a specific CMS MDM Category 2 data element. It writes a RelatedPerson resource and a corresponding Provenance resource with the role, timestamp, and the audio segment reference.

3. EHR signal fusion — vital signs (T+15 seconds). The SMART-on-FHIR subscription receives the triage nurse's vital sign entry: HR 118, SpO2 90%, BP 104/68, RR 24, Temp 37.2°C. The engine does not passively store these values. It runs them against the clinical significance classifier — a model trained on NIH-published clinical decision rule datasets — and flags HR 118 and SpO2 90% as abnormal with diagnostic significance in the context of chest pain. These Observations are immediately linked to the nascent Condition resource via Condition.evidence.detail.

4. EHR signal fusion — medication and surgical history (T+22 seconds). The engine pulls the active medication list and identifies an active OCP prescription (MedicationStatement). It pulls the procedure history and identifies right total knee arthroplasty performed 8 days prior (Procedure, date: 2026-03-07). Both are recognized as established VTE risk factors per the ACEP clinical policy on thromboembolic disease. The engine links these resources to the Condition as contributing risk factors.

5. Negative-action detection — D-dimer deferral (T+3 minutes 40 seconds). This is the step that no transcription engine can perform. The physician opens the order entry panel. The EHR event hook logs that the D-dimer order option was displayed in the search results. The physician does not select it. She selects CTA pulmonary angiogram instead. The engine recognizes this as a deliberate negative action — the deferral of a lower-acuity screening test in favor of a definitive diagnostic study. Combined with the accumulated risk factor profile (recent surgery + OCP + tachycardia + hypoxemia + pleuritic pain), the engine infers that the physician's pretest probability assessment was high enough to bypass the D-dimer pathway, consistent with ACEP guidelines and the Wells criteria threshold. It generates the ServiceRequest for CTA-PE with reasonReference pointing to the Condition "Pulmonary embolism — suspected" and adds a clinical note: "D-dimer deferred given high pretest probability per clinical assessment."

6. External physician consultation capture (T+6 minutes 10 seconds). The phone system event hook detects an outbound call from the physician's workstation. The dialed extension resolves to an orthopedic surgery office within the facility directory. The engine cross-references the on-call schedule and identifies the receiving physician by NPI. The audio stream captures the physician's side of the conversation (the engine does not record the consultant's audio for compliance reasons; it captures the ED physician's spoken content referencing "anticoagulation timing," "heparin bridge," and the patient's name). A Provenance resource is written: agent = Practitioner/[orthopedic surgeon NPI], activity = inter-physician consultation, target = the patient's PE Condition resource, recorded = 2026-03-15T14:32:07Z, duration = 94 seconds.

7. Causal graph assembly (T+7 minutes). The engine assembles a directed acyclic graph (DAG) of the clinical reasoning chain: chief complaint (pleuritic chest pain) → risk factors (recent TKA, OCP, tachycardia, hypoxemia) → high pretest probability assessment → D-dimer deferral → CTA-PE order → external consultation for treatment coordination. This graph is serialized into a ClinicalImpression FHIR resource with finding entries linking to each Observation, MedicationStatement, Procedure, and Condition resource. The graph represents the reconstructed MDM logic — the "why" behind every order and decision.

8. Note generation with MDM annotation (T+7 minutes 15 seconds). The natural language generation layer transforms the causal graph into the clinician-readable note shown above. Critically, it does not fabricate reasoning. Every sentence in the note maps to a discrete FHIR resource with provenance. The physician reviews the note in under 30 seconds, confirms accuracy, and signs. The note is committed to the EHR with all underlying FHIR resources simultaneously.

This eight-step pipeline is the operational difference between an AI that records speech and an AI that reconstructs clinical cognition. The anchor truth holds: specialized transcription tools record the "what." Scribing.io's frontier clinical reasoning engine documents the "why" — and the "why" is what payers audit.

The MDM Documentation Gap: What Transcription-First Platforms Cannot Capture

The competitor landscape in 2026 evaluates AI scribes on six dimensions: note quality, ease of use, EHR compatibility, support access, pricing, and organizational fit. These are reasonable purchasing criteria for the transcription use case. They are wholly insufficient for the clinical reasoning use case.

1. Non-verbalized reasoning recovery

Physicians do not narrate their thought process. Published cognitive load studies indicate that experienced emergency physicians verbalize less than 40% of their diagnostic reasoning during patient encounters. The rest occurs silently: glancing at a vitals trend, recognizing a medication interaction from the chart, mentally running a risk score, choosing not to order a test. A transcription engine — regardless of speech recognition accuracy or medical NLP sophistication — captures zero of this silent cognition.

Scribing.io resolves non-verbalized reasoning through a causal graph that integrates three signal streams:

• Audio: what was said, by whom, and when

• EHR state changes: orders placed, results viewed, medications reviewed, vitals trended — captured via SMART-on-FHIR event hooks

• Temporal inference: the sequence and timing of actions reveals intent (viewing a D-dimer order option, not selecting it, then ordering CTA implies a deliberate clinical decision about test characteristics and pretest probability)

2. Category 2 MDM data capture

CMS's Category 2 (data reviewed/ordered) includes specific high-value elements that are almost never verbalized:

• Independent historian: The physician rarely says "I am now obtaining history from the spouse as an independent historian." Scribing.io's speaker diarization identifies non-patient voices and cross-references the patient's emergency contact and family records to attribute the historian role with timestamped Provenance.

• External physician discussion: The physician calls a consultant, discusses the case for 90 seconds, and hangs up. No dictation follows. Scribing.io detects the outbound call, matches the receiving number to the facility directory or CMS NPI registry, and logs a Provenance resource with the external physician's NPI, timestamp, duration, and activity type.

• Independent interpretation of imaging/labs: When the physician reviews CTA images herself rather than relying solely on the radiologist's preliminary read, that independent interpretation is a distinct MDM data element. Scribing.io detects PACS access events and image viewing duration to document this activity discretely.

3. Category 3 risk documentation through order-pattern analysis

The highest-value MDM differentiation occurs in Category 3: risk. A physician who orders IV heparin for a suspected PE is making a high-risk management decision (drug requiring intensive monitoring, per AMA MDM table of risk). A transcription scribe captures "heparin ordered." Scribing.io captures the full reasoning chain: suspected PE → high pretest probability → CTA ordered → confirmed PE → heparin initiated → external consultation for anticoagulation bridge timing → documented risk of bleeding vs. clot propagation. Each link in this chain is a discrete FHIR resource with Provenance. Each link independently substantiates the Level 5 risk designation.

FHIR Provenance Architecture and the 6-Year Medicare Lookback

This is the infrastructure gap that even CMIO-level evaluators frequently overlook. In standard Epic and Cerner SMART-on-FHIR implementations, Observation resources often lose auditability unless Provenance is explicitly posted alongside them. Most ambient scribe vendors write note text to a DocumentReference or push it into a progress note field. They do not write discrete FHIR Provenance resources linking each clinical assertion to its evidentiary source.

When an auditor pulls the chart 4 years later, the consequences are concrete:

The HL7 FHIR Provenance resource specification exists precisely for this use case: to answer "who did what, when, where, and why" for every clinical data element. Scribing.io writes Provenance resources for every MDM-relevant assertion — device ID, performer, timestamp, activity code, and target resource reference. This architecture ensures Level 5 justifications are traceable and machine-verifiable across the full 6-year Medicare lookback period. It is the difference between documentation that describes reasoning and documentation that proves it.

Technical Reference: ICD-10 Documentation Standards

MDM complexity documentation and ICD-10 specificity are interdependent audit targets. A Level 5 encounter billed with an unspecified ICD-10 code triggers automatic review at most MAC contractors. Scribing.io's clinical reasoning engine ensures that ICD-10 codes reach maximum specificity by linking the code selection to discrete clinical evidence.

In the PE scenario above, the engine assigns I26.99 — Other pulmonary embolism without acute cor pulmonale; R07.9 — Chest pain as the primary and secondary diagnosis codes. The code selection logic works as follows:

• I26.99 specificity justification: The engine selects I26.99 (rather than I26.9, I26.01, or I26.02) because (a) the PE is suspected but not yet confirmed by CTA results at the time of documentation, (b) there is no echocardiographic or hemodynamic evidence of acute cor pulmonale documented, and (c) the clinical evidence chain — tachycardia, hypoxemia, post-surgical state, OCP use — supports the "other pulmonary embolism" designation pending imaging confirmation. If the CTA returns positive and shows right heart strain, the engine will auto-escalate to I26.02 (saddle embolus with acute cor pulmonale) or I26.09 as appropriate, with a new Provenance resource timestamped to the imaging result.

• R07.9 secondary code justification: Chest pain is documented as the presenting symptom. The engine assigns R07.9 as the secondary code because the clinical documentation does not yet specify the chest pain as pleuritic in the formal assessment (the physician described it verbally but the confirmed assessment links it to the PE workup). Once the encounter assessment is finalized, the engine can refine to R07.1 (chest pain on breathing) if the physician confirms pleuritic characterization in the signed note.

• Denial prevention: An unspecified code in a high-acuity encounter is the most common trigger for automated payer review. Scribing.io prevents this by requiring every ICD-10 code to have at least one Condition.evidence.detail reference to a supporting Observation, Procedure, or MedicationStatement. If the evidence is insufficient to support a specific code, the engine flags the gap to the physician before note signing — not after claim submission.

This pre-submission specificity enforcement eliminates the retrospective coding query cycle that costs revenue cycle teams an average of 14 minutes per encounter in rework.

CMIO Evaluation Framework: 12 Questions Your Vendor Cannot Answer

If you are evaluating ambient AI documentation platforms for a health system deployment, these are the questions that differentiate clinical reasoning engines from transcription tools. We publish them here because we are confident in the answers for Scribing.io — and because your current vendor's inability to answer them is the finding that should drive your next RFP.

If your current vendor cannot answer questions 1–6 affirmatively, they are a transcription tool. The market has moved past transcription.

See the Clinical Reasoning Graph in Action

See a live demo of our 2026 Clinical Reasoning Graph auto-populating AMA E/M MDM and FHIR Condition.evidence + ServiceRequest.reasonReference with full Provenance in Epic/Cerner — preventing Level 5 downgrades in minutes.

The demo uses the PE scenario described in this playbook. You will see:

• Real-time causal graph assembly from simulated audio + EHR event streams

• Automatic independent historian detection via speaker diarization

• D-dimer deferral detection and pretest probability documentation

• External physician consultation capture with NPI resolution

• Complete FHIR resource export: Condition, Observation, ServiceRequest, ClinicalImpression, Provenance

• Side-by-side comparison: transcription-only note vs. clinical reasoning note, with MDM scoring for each

Request access at Scribing.io. Bring your compliance officer. Bring your revenue cycle director. The demo takes 22 minutes. The Level 5 downgrade problem becomes self-evident within the first 4.