TL;DR — Note-Lock Mapping in 60 Seconds

• The Gap: Tebra's (Kareo's) Note Lock permanently blocks writes after clinician sign-off. Competing scribes that use a "Push to EHR" model (e.g., a Chrome-extension push button) attempt to write the note without verifying lock state first — a post-signature injection that silently fails against Tebra's lock.

• The Clinical Cost: Missing MDM (risk stratification, chronic-condition management) downcodes 99214 → 99213 and forfeits the G2211 add-on for lack of pre-signature attestation.

• The Scribing.io Difference: A Pre-Lock Check verifies Composition.status != "final" and DocumentReference.status != "superseded" before signature, writes a US Core DocumentReference typed LOINC 34108-1, links it to the active Encounter, and stamps Provenance — guaranteeing content is present and auditable before the lock.

• For Clinical Ops Directors: This converts a silent, revenue-leaking failure mode into a deterministic, audit-defensible workflow.

• How Tebra Note Lock Works

• Pre-Lock Check FHIR Crosswalk

• Family Medicine Clinical Logic

• Operational Rollout Checklist

How Tebra (Kareo) Note Lock Actually Works — and Where "Push" Models Break

CLINICAL UPDATE 2026: Revised for new CMS CPT G2211 standards, SB 1120 compliance, and FHIR interoperability.

Tebra's Note Lock is a finality control: once a clinician signs, the encounter note transitions to a locked, immutable state. Any subsequent write attempt is rejected at the persistence layer. This is a compliance feature by design, and Scribing.io treats it as a hard sequencing dependency rather than an obstacle.

The dominant competitor pattern is a browser-extension "Push to EHR" button. The published workflow is explicit: install a Chrome extension, open Tebra, record, then click a single push button that "automatically maps and transfers notes." Most scribe integrations do not respect the lock sequence, and Scribing.io Pro was built specifically to close that gap.

The transfer is triggered by the user at whatever moment they choose — including after the note has been signed. Nothing in that single-button flow reads the note's lock state before writing. This produces a race condition against Note Lock.

If the push fires post-signature, Tebra rejects the write. Worse, the failure is frequently silent to the clinician: the button reports a transfer action, but the locked target never accepts the payload. For a Clinical Operations Director, this is the worst class of defect — incomplete charts without an error surfaced at the point of care.

Clinical and billing content stay synchronized across these states in our Scribing.io Ai Scribe For Tebra Kareo Clinical Vs Billing Sync Reference.

Scribing.io Pro Pre-Lock Check: Crosswalking Note Lock to FHIR R4

This is the information-gain core: rather than treating Note Lock as an opaque EHR feature, Medical AI Scribing from Scribing.io Pro maps it deterministically onto FHIR R4 resource states. The Pre-Lock Check is a preflight gate that runs immediately before the clinician's EHR signature.

The check enforces two invariants before any write is committed:

1. First invariant requires Composition.status != "final" — the note has not yet reached its terminal, immutable state, so a write is still legal.

2. Second invariant requires DocumentReference.status != "superseded" — the reference is current and has not been replaced, preventing writes to a stale reference.

When both invariants hold, Scribing.io Pro writes the note as a US Core DocumentReference typed with LOINC 34108-1 (Outpatient Note), links it to the active Encounter, and attaches a Provenance resource where agent = scribe and recorded <= signature time. This ordering is the entire point.

Fallback logic runs deterministically: if a FHIR endpoint is unavailable for a given Tebra tenant, the same decision logic executes against Tebra's native note-status endpoint. The invariant is preserved regardless of interface — content is confirmed present and referenceable before the lock.

What competitors miss (Anchor Truth): the published competitor workflow surfaces a single "Push to EHR" button with automatic SOAP-field mapping — but exposes no lock-state gate and no Provenance guarantee. That model can transfer a note; it cannot prove the note was present and current before the signature closed the record.

For the upstream summarization behavior that feeds this DocumentReference, review the Scribing.io Ai Scribe Tebra Kareo Automating Encounter Summary Reference.

Scribing.io Clinical Logic: Family Medicine Medication-Titration Visit

Scenario details as follows. A 57-year-old established patient presents to a family medicine clinic on Tebra for medication titration. Active problems: I10 (ICD-10-CM) and E11.9 (ICD-10-CM).

The clinician performs medication management across two stable-but-active chronic conditions — the classic profile supporting a 99214 office visit plus the G2211 complexity add-on for longitudinal primary care.

Failure Path — Competitor Push Model

1. Clinician signs the note in Tebra. Note Lock engages; the record is now immutable.

2. A competing scribe app attempts to inject the MDM section (risk stratification, chronic-condition management) after sign-off via its push button.

3. Tebra's Note Lock blocks the write. The MDM detail never lands.

4. The signed note lacks documented risk stratification and chronic-condition management. MDM cannot support moderate complexity.

5. Claim is downcoded 99214 → 99213. The payer denies G2211 for lack of pre-signature attestation.

Success Path — Scribing.io Pro Pre-Lock Check

1. Pre-Lock Check detects the imminent lock at signature time.

2. It verifies both invariants: Composition.status != "final" and DocumentReference.status != "superseded".

3. It posts a LOINC 34108-1 DocumentReference linked to the active Encounter, containing the full MDM narrative (I10 + E11.9 management and risk stratification).

4. It records a Provenance entry with recorded <= signature time.

5. It prompts one-click finalize — the clinician confirms, then signs.

6. Result preserves 99214 + G2211, MDM documented pre-signature, audit integrity intact.

Note on coding authority: G2211 is an add-on reported with an office/outpatient E/M for visit complexity inherent to longitudinal care. Per the 2026 NCCI Policy Manual, add-on codes are adjudicated against their primary codes and are rarely payable alone.

Documentation supporting the primary E/M must exist at the time of the claim — which is exactly why pre-signature capture matters. This is the deterministic difference between a defensible chart and a silent revenue leak.

Operational Rollout for Clinical Operations Directors

Rollout begins with tenant verification. Confirm whether your Tebra tenant exposes a FHIR R4 endpoint or requires the native note-status fallback. Both paths preserve the Pre-Lock Check invariant.

Governance under SB 1120 requires that any Ambient Clinical Intelligence disclose its role in documentation. The Provenance resource with agent = scribe satisfies this attribution requirement at the record level.

• Verify Note Lock behavior in a sandbox before production sign-off training.

• Train clinicians on the one-click finalize prompt as the last step before signature.

• Audit Provenance timestamps monthly to confirm recorded <= signature time holds across encounters.

Model the financial impact before deployment using our AI Medical Scribe ROI Calculator, then compare tiers on Scribing.io Pricing & Plans.

For state-specific disclosure obligations, review current requirements before configuring Clinical-Grade Scribing across multi-state clinics. The Pre-Lock Check remains identical; only the disclosure surface changes by jurisdiction.