Physician

Physician assistant using AI scribing technology during a shared visit with a collaborating physician in a hospital setting

AI Scribing for Physician Assistants (PA): Shared Visits — The 2026 Split/Shared Compliance Playbook

Author: Lead Clinical Consultant, Scribing.io · Audience: APP Directors (PA-C), Hospital Medicine · Last Updated: January 2026

TL;DR

2026 CMS split/shared rules require that when modifier FS is billed, the rendering NPI must match the clinician who performed the substantive portion (typically MDM). Most EHRs collapse co-signed notes into a single author block, destroying the attribution trail auditors demand. Scribing.io resolves this by auto-tagging every MDM action to the correct NPI via FHIR Provenance, inserting dual Independent Review attestations for both the PA and attending, and validating that the 837P claim construction (FS in SV101-3, rendering provider in Loop 2310B/2420A) reconciles to the MDM performer before charge export. This playbook is the definitive clinical operations reference for APP Directors in Hospital Medicine who need to protect shared-visit revenue in 2026 and beyond.

Contents

  • The 'Substantive Portion' Gap: What Every Competitor Misses

  • Clinical Logic: Decompensated Diabetes Shared Visit

  • FHIR Provenance Architecture for Multi-Provider Attribution

  • Dual Independent Review Attestations: Requirements and Automation

  • 837P Claim Construction: FS + NPI Reconciliation

  • Technical Reference: ICD-10 Documentation Standards

  • Operational Rollout for Hospitalist APP Programs

  • Audit Response Protocol: FS Claims Under Payer Review

  • Book Your Compliance Demo

The 'Substantive Portion' Gap: What Every Competitor Misses About 2026 Split/Shared Billing

The competitor landscape for AI medical scribes in 2026 centers on adoption frameworks, charting-time reduction, and general workflow optimization. These are necessary conversations—but they are dangerously incomplete for physician assistants practicing in shared-visit hospital medicine models. Not a single major competitor addresses the structural billing vulnerability that causes the most expensive denials and recoupments for hospitalist groups today: the Substantive Portion Gap.

Scribing.io was engineered to close this gap because we build from claim-level compliance backward into documentation—not the other way around. Before discussing architecture, the gap itself needs precise definition.

What the Gap Is

Under 2026 CMS Final Rule guidance for split/shared visits (services furnished in facility settings where both a physician and an APP provide face-to-face care), the modifier FS signals a split/shared encounter. The billing/rendering NPI on the claim must correspond to the clinician who performed the substantive portion of the visit—which, for E/M levels selected on the basis of medical decision-making (MDM) per AMA CPT E/M guidelines, means the provider who performed the MDM.

Here is where most documentation systems—and most AI scribe vendors—fail:

  1. Co-signature conflation. EHRs treat the attending physician's co-signature as a single authorship event. The note does not discretely record who performed the history/exam versus who performed the MDM. In a payer audit, "co-signed by Dr. Smith" is not the same as "MDM performed and independently documented by Dr. Smith."

  2. Missing dual Independent Review attestations. CMS and an increasing number of commercial payers expect both the PA and the physician to include explicit, separately authored statements confirming their independent review of relevant data (e.g., prior notes, lab trends, imaging). When these attestations are absent, auditors cannot verify that each provider met their respective documentation obligations.

  3. FS + NPI mismatch at the claim level. Even when clinical documentation is correct, the 837P professional claim may route the FS modifier while listing the PA's NPI as the rendering provider—despite the attending having performed the MDM. This mismatch triggers automated payer edits, manual review queues, and ultimately denials or post-payment recoupments.

What Competitors Miss

The competitor articles reviewed for this playbook—leading AI scribe vendors' adoption guides and workflow optimization content—focus exclusively on implementation logistics: goal-setting, budget, clinician sentiment, rollout sequencing, and data security. They contain zero mention of:

  • Split/shared visit documentation requirements

  • Modifier FS handling or substantive-portion attribution

  • NPI reconciliation at the claim level

  • Dual Independent Review attestation requirements

  • FHIR Provenance or any interoperability standard for author-level tracking

This is not a minor omission. For a hospitalist PA-C whose daily census includes 8–14 shared visits, every single encounter carries FS exposure. Split/shared claim denials and recoupments can represent 15–30% of a hospitalist APP's professional charges when attribution is absent or misaligned. For related specialty implementations where these same principles apply, see how Scribing.io extends this logic to Cardiology and Family Medicine shared-visit workflows.

How Scribing.io Closes the Gap

Rather than treating documentation as a monolithic narrative, Scribing.io models each encounter as a multi-provider, multi-action graph where every clinical action (history-taking, physical exam, data review, MDM formulation, order entry) is tagged to the performing clinician's NPI at the moment of capture.

Substantive Portion Gap: Industry Status vs. Scribing.io

Requirement

Typical EHR / Competitor AI Scribe

Scribing.io

MDM performer attribution

Collapsed into co-signed note; single author block

Each MDM action NPI-tagged via FHIR Provenance + PractitionerRole resource

Dual Independent Review attestations

Not generated; relies on clinician free-text (rarely present)

Auto-inserted, mapped to each provider's NPI, with discrete timestamps

FS modifier placement

Applied at charge capture without NPI reconciliation

FS placed in 837P SV101-3 only after rendering NPI (Loop 2310B / line-level 2420A) is validated against the MDM performer

Pre-export claim validation

No FS-specific edit logic

Automated FS + NPI reconciliation check blocks charge export on mismatch

Audit-readiness

Requires manual chart reconstruction

Provenance trail exportable as structured FHIR Bundle for payer or CMS audit response

Scribing.io Clinical Logic: Decompensated Diabetes Shared Visit — From Documentation Failure to Revenue Preservation

This section dissects a real-world clinical scenario that crystallizes the Substantive Portion Gap and demonstrates how Scribing.io resolves it at every layer: documentation, attestation, and claim construction.

The Scenario

A hospitalist PA-C evaluates a 62-year-old patient admitted with decompensated Type 2 diabetes (glucose >450 mg/dL, mild anion-gap metabolic acidosis, HbA1c 13.2%). The PA performs a comprehensive history and multi-system physical examination, documents the patient's medication reconciliation, and enters initial nursing orders.

Two hours later, the attending hospitalist arrives. The attending independently reviews the patient's prior endocrine clinic notes, three months of glucose logs, the most recent BMP and VBG results, and the PA's documented findings. Based on this independent review and the data complexity, the attending formulates the MDM: adjusts the insulin regimen from a sliding-scale protocol to a basal-bolus approach, orders a repeat VBG in four hours, initiates an endocrinology consult, and documents a moderate-to-high complexity assessment addressing the differential between DKA and hyperosmolar hyperglycemic state (HHS)—a clinical distinction outlined in ADA Standards of Care 2024, Section 16.

What Goes Wrong Without Scribing.io

  1. Documentation collapse. The EHR merges both providers' contributions into a single note. The attending co-signs the PA's note. There is no discrete section identifying who performed the MDM. The note reads as though a single clinician performed the entire encounter.

  2. No Independent Review attestations. Neither the PA nor the attending includes an explicit statement confirming their independent review of data. The PA reviewed medication lists; the attending reviewed endocrine notes and lab trends. Both reviews occurred—but neither is documented as a discrete attestation.

  3. Claim construction error. The charge is exported with modifier FS on CPT 99223 (initial hospital care, high complexity). The rendering NPI in Loop 2310B is the PA's NPI—because the PA initiated the encounter, and the charge-capture system defaults to the initiating provider. The substantive portion (MDM) was performed by the attending.

  4. Payer audit outcome. The payer's audit team requests documentation supporting the FS modifier. The collapsed note cannot demonstrate that the rendering provider (PA) performed the MDM. The claim is downgraded from 99223 to 99221 (low complexity), and the difference—exceeding $200–$350 depending on payer and geographic adjustment—is recouped. The absence of dual Independent Review attestations is flagged as an additional documentation deficiency, placing the entire group under enhanced post-payment review per OIG Work Plan priorities.

What Happens With Scribing.io: Step-by-Step Logic Breakdown

Step-by-Step: Scribing.io Shared Visit Workflow — Decompensated Diabetes

Step

Provider

Scribing.io Action

Technical Mechanism

1. History & Exam

PA-C

Ambient capture of PA's patient encounter; HPI, ROS, and PE auto-documented and NPI-stamped

FHIR Provenance resource links DocumentReference to PA's PractitionerRole (NPI). Timestamp: T+0.

2. PA Independent Review Attestation

PA-C

Auto-generated attestation: "I independently reviewed the patient's medication reconciliation, admission labs (BMP, CBC), and nursing intake assessment."

Discrete attestation block inserted with PA NPI, timestamp (T+0), and referenced FHIR Observation/MedicationStatement resource IDs

3. MDM Performance

Attending

Ambient capture of attending's clinical reasoning: insulin adjustment rationale, VBG interpretation, DKA vs. HHS differential, and care plan formulation

MDM actions tagged to attending's NPI via FHIR Provenance; MDM complexity auto-scored against AMA MDM table elements

4. Attending Independent Review Attestation

Attending

Auto-generated attestation: "I independently reviewed prior endocrine clinic notes (3/15/25, 6/20/25), 3-month glucose trend, BMP [1/12/26], VBG [1/12/26], and the PA's documented history and examination findings."

Discrete attestation block inserted with attending NPI, timestamp (T+2h), and referenced FHIR DocumentReference/Observation resource IDs

5. Note Assembly

System

Final note presents both providers' contributions with clear attribution headers; co-signature preserved but authorship is granular per section

Composed FHIR DocumentReference with multiple author entries and section-level Provenance. Each note section carries an author element referencing the performing provider.

6. Substantive Portion Determination

System

System evaluates: E/M level selected by MDM → MDM performer = attending → substantive portion = attending. Rendering NPI set to attending.

Rules engine cross-references Provenance MDM tags against E/M selection criteria (MDM vs. total time). Deterministic, auditable logic.

7. Claim Validation

System

FS modifier staged in SV101-3. Attending NPI set as rendering provider in Loop 2310B / line-level 2420A. Mismatch check: PASS.

Pre-export validation engine compares Provenance MDM-performer NPI against 837P rendering NPI; blocks export on mismatch; generates exception report for billing team on failure.

8. Clean Charge Export

System

837P transmitted. FS + attending NPI + dual attestations = audit-ready claim with full Provenance trail archived.

FHIR Provenance Bundle archived with 7-year retention; retrievable by encounter ID for payer audit response within 24 hours.

The Revenue Impact

In this single encounter, the difference between a 99223 and a 99221 recoupment exceeds $200–$350 depending on payer and geographic adjustment. Multiply this across a 12-provider hospitalist group running 10+ shared visits per day, and the annual exposure from Substantive Portion Gap failures reaches $500,000–$900,000—before accounting for extrapolated audit penalties that CMS and commercial payers increasingly apply under CERT program methodology.

Scribing.io does not merely document faster. It documents correctly for the billing reality that shared visits demand.

FHIR Provenance Architecture for Multi-Provider Attribution

The technical foundation that enables Scribing.io's shared-visit compliance is the FHIR R4 Provenance resource. Most AI scribe platforms treat the clinical note as a flat document—a single blob of text with one or two author fields. This mirrors how EHRs were built in the 2000s, before split/shared visit rules created a documentation burden that flat documents cannot satisfy.

How Scribing.io Structures Provenance

Every clinical action captured during a shared visit generates a Provenance resource with these elements:

  • target: The specific DocumentReference section (HPI, PE, MDM, Assessment/Plan) or Order resource the action produced

  • agent.who: Reference to the performing provider's Practitioner resource (carrying NPI)

  • agent.onBehalfOf: Reference to the PractitionerRole resource (establishing the provider's role—attending vs. APP—within the encounter's organizational context)

  • recorded: Server-side timestamp of capture (not editable post-facto)

  • activity: Coded action type (e.g., CREATE for original documentation, REVIEW for Independent Review, APPROVE for co-signature)

This structure means that when an auditor asks "Who performed the MDM?", Scribing.io does not produce a narrative note and ask the auditor to infer authorship. It produces a machine-readable Provenance chain that unambiguously links the MDM section to the attending's NPI, timestamped to the minute, with a coded activity type of CREATE.

PractitionerRole: Why It Matters for FS Logic

The FHIR PractitionerRole resource is what allows Scribing.io's rules engine to distinguish between "Dr. Martinez, attending hospitalist" and "Sarah Chen, PA-C, hospitalist APP." Both are Practitioner resources with NPIs. But PractitionerRole carries the role classification (physician vs. APP) and organizational affiliation that the FS modifier logic requires. When the system determines the substantive portion performer, it validates: (a) the MDM was performed by a provider whose PractitionerRole is physician, and (b) the FS modifier is appropriate because a second provider with a PractitionerRole of advanced-practice-provider also furnished face-to-face services in the same encounter.

Dual Independent Review Attestations: Requirements and Automation

The Independent Review attestation is the documentation element most frequently missing from shared-visit notes—and most frequently cited in OIG audit findings related to APP billing. The requirement is straightforward in principle: each provider who participates in a shared visit must document that they independently reviewed relevant patient data, rather than relying solely on the other provider's documentation.

Why Free-Text Attestations Fail

When attestations exist at all in current EHR workflows, they appear as free-text sentences buried in the note body—"I reviewed the PA's note and agree with the plan" or "Seen and discussed with attending." These fail audit scrutiny for three reasons:

  1. No specificity. "Reviewed the PA's note" does not identify what data was independently reviewed. Auditors require enumeration of reviewed elements (specific lab results, imaging, prior notes with dates).

  2. No discreteness. A sentence embedded in a paragraph is not a structured attestation. It cannot be programmatically extracted, validated, or cross-referenced against the Provenance chain.

  3. No dual presence. Typically, only the attending's review statement exists (if any). The PA's independent review of their own data set—medication reconciliation, admission labs, nursing notes—is almost never documented.

Scribing.io's Automated Attestation Engine

Scribing.io generates Independent Review attestations as discrete, structured documentation blocks with the following properties:

Independent Review Attestation: Structure and Validation

Attestation Element

PA-C Attestation

Attending Attestation

Provider identity (NPI)

PA-C's NPI, auto-populated

Attending's NPI, auto-populated

Timestamp

Server-side, at point of PA documentation

Server-side, at point of attending MDM documentation

Reviewed data elements

Medication reconciliation, admission labs (specific tests + dates), nursing intake

Prior specialty notes (with dates), lab trends (specific panels + date ranges), PA's documented H&P, imaging

FHIR linkage

References to Observation, MedicationStatement, DocumentReference resources reviewed

References to Observation, DiagnosticReport, DocumentReference resources reviewed

Activity code

REVIEW

REVIEW

The attestation content is generated from the ambient capture context. When the PA discusses the medication list with the patient, Scribing.io identifies the MedicationStatement resources referenced and populates the attestation. When the attending verbally references "the VBG from this morning" or "the endo note from June," the system resolves those references to specific FHIR resources and includes them in the attestation by date and type. The clinician reviews and confirms; the attestation is inserted as a visually distinct block in the final note.

837P Claim Construction: FS + NPI Reconciliation Engine

Documentation correctness means nothing if the claim is constructed incorrectly. The 837P professional claim format—governed by HIPAA transaction standards (ASC X12 005010X222A1)—contains specific loops and segments where the FS modifier and rendering provider NPI must appear. Errors at this level bypass clinical documentation entirely; the payer's front-end edits reject or flag the claim before any note is reviewed.

Critical 837P Elements for FS Claims

  • SV101-3 (Professional Service segment, modifier field): This is where modifier FS must appear. If FS is absent on a shared visit, the payer processes the claim as a standard APP encounter—potentially at a reduced fee schedule. If FS is present but the rendering NPI is the APP (and MDM was performed by the physician), the claim fails reconciliation.

  • Loop 2310B (Rendering Provider at claim level): This loop carries the NPI of the rendering provider for the entire claim. For FS claims, this must be the NPI of the clinician who performed the substantive portion.

  • Loop 2420A (Rendering Provider at service-line level): When a claim contains multiple service lines with different rendering providers, each line can carry its own rendering NPI. For hospitalist encounters with a single E/M code, 2310B typically suffices—but mixed encounters (E/M + procedure with different performers) require line-level 2420A precision.

Scribing.io's Pre-Export Validation Logic

Before any charge is transmitted to the practice management system or clearinghouse, Scribing.io's validation engine executes the following checks:

  1. FS presence check: Is this encounter flagged as a shared visit (two providers with distinct PractitionerRoles documented face-to-face services)? If yes → FS required in SV101-3.

  2. Substantive portion determination: Was the E/M level selected based on MDM or total time? If MDM → identify the MDM performer from Provenance. If total time → identify the provider with the greater face-to-face time.

  3. NPI reconciliation: Does the rendering NPI staged in Loop 2310B/2420A match the substantive-portion performer's NPI? If yes → PASS. If no → BLOCK export and generate exception alert to the billing team with the specific mismatch identified.

  4. Dual attestation presence check: Are both Independent Review attestation blocks present in the DocumentReference? If no → generate documentation-completion alert to the provider(s) missing the attestation before charge export is permitted.

This four-gate validation ensures that no FS claim leaves Scribing.io's system without matching documentation, attestations, and claim-level NPI alignment. The blocked-export pattern is deliberate: a rejected charge that never reaches the payer costs zero dollars; a paid claim that is later recouped during audit costs the original payment plus administrative burden plus potential extrapolation penalties.

Technical Reference: ICD-10 Documentation Standards for Hospitalist Shared Visits

Shared visits in hospital medicine frequently involve high-prevalence chronic conditions that, when under-documented, invite auditor scrutiny and code-level denials. Two of the most common codes in inpatient E/M encounters illustrate documentation pitfalls that AI scribing must address:

I10 - Essential (primary) hypertension; E11.9 - Type 2 diabetes mellitus without complications

I10 — Essential (Primary) Hypertension

Clinical documentation standard: I10 is appropriate only when hypertension is documented without specification of stage, cause, or end-organ involvement. In hospitalist practice, the danger is under-specificity—a decompensated patient with hypertensive urgency (I16.0), hypertensive heart disease (I11.x), or hypertensive chronic kidney disease (I12.x/I13.x) may be coded as I10 simply because the note lacks sufficient MDM detail to support a more specific code.

Scribing.io approach: When ambient capture detects clinical language suggesting acuity beyond essential hypertension (e.g., "BP 210/120 on arrival," "echo shows LVH with diastolic dysfunction," "creatinine trending from 1.4 to 2.1"), the system flags a documentation prompt to the MDM-performing provider. The prompt surfaces the ICD-10-CM hierarchy for hypertensive disease categories, enabling code specificity that supports both accurate severity reporting and appropriate E/M level selection. For shared visits, this prompt routes to the attending (the MDM performer), not the PA—because code specificity is an MDM function.

E11.9 — Type 2 Diabetes Mellitus Without Complications

Clinical documentation standard: E11.9 indicates Type 2 diabetes with no documented complications. In the decompensated diabetes scenario above, E11.9 would be incorrect. The patient has hyperglycemia with ketoacidosis (E11.10 or E11.65 depending on presence/absence of coma), and potentially E11.22 (diabetic chronic kidney disease) or E11.621 (foot ulcer) if comorbidities are present. Using E11.9 when complications exist is a documentation deficiency that understates severity, reduces CMI (case mix index), and can trigger DRG downgrades on the facility side.

Scribing.io approach: The system cross-references ambient clinical data (glucose >450, anion gap, HbA1c 13.2%) against the ICD-10-CM diabetes complication matrix. When the attending's MDM captures language about "ketoacidosis" or "hyperosmolar state," the system maps this to E11.10/E11.00/E13.01 as appropriate and presents the code suggestion with the supporting clinical evidence. The PA's documentation of peripheral neuropathy symptoms during the history triggers a separate flag for E11.40–E11.42. Every code suggestion is linked to the specific Provenance-stamped documentation element that supports it—creating a code-to-evidence chain that withstands both automated and human audit review.

Specificity as a Shared-Visit Documentation Discipline

In shared visits, code specificity is uniquely vulnerable because the clinical data that supports specific codes may be split across two providers' contributions. The PA documents the foot exam findings; the attending diagnoses diabetic peripheral neuropathy in the MDM. If the note is collapsed, the code coder (human or automated) may miss the connection. Scribing.io's section-level attribution and cross-referencing ensure that every ICD-10-CM code is traceable to documentation elements from both providers where applicable, with Provenance stamps on each.

Operational Rollout for Hospitalist APP Programs

Deploying Scribing.io's split/shared compliance engine across a hospitalist APP program requires sequenced implementation. The following framework reflects lessons from multi-site deployments.

Phase 1: Baseline Audit (Weeks 1–2)

Before go-live, Scribing.io's implementation team reviews 30–50 recent shared-visit claims from the group. The analysis quantifies:

  • Percentage of FS claims with correct rendering NPI alignment

  • Presence/absence of Independent Review attestations in documentation

  • E/M level distribution and downgrade/recoupment history

  • ICD-10 specificity rates for high-volume diagnoses (diabetes, hypertension, heart failure, pneumonia)

This baseline establishes the group's current Substantive Portion Gap exposure and provides the ROI denominator for post-deployment measurement.

Phase 2: Workflow Configuration (Weeks 2–3)

Each hospitalist group structures shared visits differently. Some use a "PA-first" model (PA sees patient, attending sees patient later). Others use a concurrent rounding model. Scribing.io's ambient capture adapts to both:

Workflow Model Configuration

Model

PA Capture Trigger

Attending Capture Trigger

Substantive Portion Logic

PA-first (sequential)

PA initiates ambient session at bedside

Attending initiates separate ambient session (same encounter ID) hours later

MDM performer identified by Provenance on Assessment/Plan section

Concurrent rounding

PA and attending at bedside simultaneously; dual-device capture

Same session, speaker-diarized to separate providers

MDM performer identified by speaker attribution on clinical reasoning segments

Attending-first (less common)

PA follows up after attending's initial evaluation

Attending initiates ambient session; PA session follows

MDM performer identified by Provenance; FS still required if PA provides face-to-face service

Phase 3: Provider Training (Week 3)

Training focuses on two behavioral changes—both minimal:

  1. Session initiation. Each provider initiates their own ambient capture session (or is automatically assigned via badge/device recognition). This is the single workflow step that enables NPI-stamped Provenance.

  2. Attestation confirmation. After the auto-generated Independent Review attestation is surfaced, the provider reviews it for accuracy (typically 10–15 seconds) and confirms. The attestation is then locked into the note.

Scribing.io does not require providers to manually document who performed the MDM, manually enter attestation language, or interact with claim-level fields. The compliance infrastructure is invisible to the clinician beyond these two touchpoints.

Phase 4: Go-Live and Monitoring (Weeks 4+)

Post-deployment dashboards track:

  • FS claim validation pass rate: Target >98% on first attempt

  • Dual attestation completion rate: Target 100%

  • NPI reconciliation exception rate: Trends toward zero as workflow adherence stabilizes

  • E/M level distribution shift: Expectation is an increase in 99223/99233 sustained rates as MDM attribution eliminates defensive downcoding

  • Payer denial rate for FS claims: Compared against Phase 1 baseline

Audit Response Protocol: FS Claims Under Payer Review

When a payer or CMS contractor requests documentation for an FS claim, the response must demonstrate three things simultaneously: (1) two providers furnished face-to-face services, (2) the substantive portion was performed by the rendering provider on the claim, and (3) both providers independently reviewed relevant data. Traditional EHR documentation requires billing staff to manually reconstruct this narrative from a co-signed note—a process that takes 20–40 minutes per claim, frequently fails, and often cannot establish (2) or (3) at all.

Scribing.io Audit Response Package

Scribing.io generates an Audit Response Bundle per encounter, retrievable by encounter ID, containing:

  1. Clinical note with section-level attribution headers (visually clear to human reviewers)

  2. Provenance summary: A one-page table showing each clinical action, the performing provider (name + NPI), timestamp, and activity type

  3. Dual Independent Review attestations: Presented as distinct blocks with provider identity, timestamp, and enumerated reviewed data elements

  4. Substantive portion determination: Explicit statement of which provider performed MDM, with reference to the Provenance records supporting the determination

  5. Claim excerpt: Screenshot/printout of the 837P SV1 segment showing FS modifier and Loop 2310B/2420A rendering NPI, demonstrating alignment with the MDM performer

This package is generated in under 60 seconds. For groups facing volume audits (50+ claims), the packages are batch-exported as a structured ZIP with an index file mapping each encounter to its documentation package. The time savings alone—compared to manual chart reconstruction—can justify the platform cost before any recoupment-prevention is calculated.

Published audit defense benchmarks from hospitalist groups using structured documentation responses (similar to Scribing.io's output) show claim-sustain rates exceeding 90%, compared to 55–65% for groups responding with standard co-signed notes, per analysis of CMS CERT findings and published hospitalist billing compliance literature.

See the FS Split/Shared Engine in Your Workflow

This playbook describes the architecture. A 15-minute demo shows it operating on your encounter patterns.

Book a 15-minute demo to see our FS Split/Shared engine: FHIR-based MDM attribution, dual Independent Review attestations, and 837P (SV101-3 + 2310B/2420A) validation to pass 2026 CMS audits on day one.

Bring a de-identified shared-visit note from your group. We will run it through the Scribing.io pipeline and show you exactly where attribution breaks, where attestations are missing, and how the corrected output aligns documentation, attestation, and claim construction into an audit-ready unit.

→ Schedule at Scribing.io

Still not sure? Book a free discovery call now.

Frequently

asked question

Answers to your asked queries

What is Scribing.io?

How does the AI medical scribe work?

Does Scribing.io support ICD-10 and CPT codes?

Can I edit or review notes before they go into my EHR?

Does Scribing.io work with telehealth and video visits?

Is Scribing.io HIPAA compliant?

Is patient data used to train your AI models?

How do I get started?

Still not sure? Book a free discovery call now.

Frequently

asked question

Answers to your asked queries

What is Scribing.io?

How does the AI medical scribe work?

Does Scribing.io support ICD-10 and CPT codes?

Can I edit or review notes before they go into my EHR?

Does Scribing.io work with telehealth and video visits?

Is Scribing.io HIPAA compliant?

Is patient data used to train your AI models?

How do I get started?

Still not sure? Book a free discovery call now.

Frequently

asked question

Answers to your asked queries

What is Scribing.io?

How does the AI medical scribe work?

Does Scribing.io support ICD-10 and CPT codes?

Can I edit or review notes before they go into my EHR?

Does Scribing.io work with telehealth and video visits?

Is Scribing.io HIPAA compliant?

Is patient data used to train your AI models?

How do I get started?

Didn’t find what you’re looking for?
Book a call with our AI experts.

Didn’t find what you’re looking for?
Book a call with our AI experts.

Didn’t find what you’re looking for?
Book a call with our AI experts.