What Does Implementation Look Like for an EHR Overlay? A Phased Blueprint to Try a Better EHR Without Switching
EHR overlay implementation is a phased workflow redesign, not a one-day install. Here is a practical blueprint starting with inbox management, documentation, and fax handling.
# Implementing Thyra: A Phased Framework for AI Documentation in Diabetes Care
Thyra is an AI documentation and workflow layer built for diabetes and endocrinology practices; the fastest path to value is a three-phase rollout (pilot with two clinicians, expand with structured feedback loops, then scale with governance) that most practices compress into a rushed all-at-once launch and later regret. This post lays out that framework, the tradeoffs at each phase, and the failure modes we've watched sink otherwise well-intentioned rollouts.
Why documentation burden is the actual problem Thyra solves
Endocrinologists and diabetes care teams spend a disproportionate share of visit time on structured data entry: titration logs, CGM report review, insulin dose adjustments, and the narrative documentation needed to justify coding levels. The ADA's Standards of Care in Diabetes (updated annually) already assumes clinicians are reviewing dense CGM and pump data during visits, but it doesn't account for the charting overhead that review generates afterward. That gap is where ambient and semi-structured AI tools like Thyra sit: they capture the visit, extract the relevant clinical variables, and draft a note a clinician edits rather than writes from scratch.
Published evaluations of ambient AI scribes in clinical settings, including work discussed in JAMA over the past two years, generally report reduced after-hours documentation time and improved clinician-reported satisfaction, though effect sizes vary by specialty and by how well the tool is tuned to the workflow. Diabetes care is a harder case than general primary care documentation because the inputs are heterogeneous: CGM exports, pump reports, lab values, and patient-reported hypoglycemia events all need to land in the right structured fields, not just the narrative note. Generic ambient scribes built for primary care visits often fail here, which is the first thing practices should evaluate before assuming any AI scribe, Thyra included, will work out of the box.
The phased implementation framework
We built this framework after watching practices try to deploy documentation AI as a single-day, clinic-wide switch. That approach fails more often than it succeeds, for reasons detailed below. The alternative is a deliberate three-phase rollout.
Phase 1: Two-clinician pilot (weeks 1 to 4)
Pick two clinicians with different practice styles, ideally one who dictates heavily and one who types directly into the EHR. Run Thyra alongside their existing workflow, not as a replacement, for at least three weeks. The goal isn't efficiency yet; it's error surfacing. You want to find where Thyra misreads a CGM report, mislabels a basal versus bolus adjustment, or drops a hypoglycemia event mentioned mid-visit.
Lesson learned: the clinicians most eager to pilot are usually the worst signal. Early adopters tolerate rough edges and under-report friction. Deliberately include one skeptical, high-volume clinician in the pilot group; their complaints are the ones that predict clinic-wide adoption problems.
Tradeoff: a two-person pilot is slow and produces a small sample of edge cases. Practices under pressure to show ROI quickly often skip to four or five clinicians immediately. That's a mistake unless you already have IT and compliance staff available to triage issues in real time, because a wider rollout with unresolved extraction errors erodes trust faster than it can be rebuilt.
Phase 2: Structured feedback expansion (weeks 5 to 10)
Expand to eight to twelve clinicians and introduce a formal correction log: every time a clinician edits an AI-drafted note for a factual error (not style preference), it gets logged with the error type. Categorize errors into three buckets: data extraction (wrong dose, wrong CGM value), clinical reasoning (correct data, wrong interpretation), and workflow mismatch (right content, wrong location in the note).
This phase is where role-specific guidance starts to diverge, and treating all users the same is the most common mistake we see.
| Role | Primary risk during rollout | What to change | ||
|---|---|---|---|---|
| --- | --- | --- | ||
| Physicians/NPs (attending) | Over-trusting AI-drafted assessment and plan sections | Require manual sign-off on all A&P edits for first 90 days | ||
| Diabetes educators/CDCES | Structured data (carb ratios, correction factors) landing in free text instead of discrete fields | Configure Thyra's field mapping before go-live, not after | ||
| Medical assistants/front desk | Confusion about who owns note finalization | Assign a single "note owner" per encounter type in writing | ||
| Practice administrators | Treating pilot metrics as scalable without adjusting for clinic volume | Re-baseline time savings at each phase, not just at pilot end | ||
| IT/compliance | Assuming HL7/FHIR export handles all downstream reporting needs | Test registry and payer reporting exports before Phase 3 |
Lesson learned: data extraction errors drop fast (usually within the first month) as the model and its configuration adapt to your templates. Clinical reasoning errors, where the AI summarizes correctly but draws the wrong inference about trend direction or titration need, are stickier and don't fully disappear. This is the tradeoff practices underestimate: documentation AI reduces typing time but does not reduce, and shouldn't reduce, clinical review time for the assessment and plan.
Phase 3: Scale with governance (month 3 onward)
Once correction rates for data-extraction errors stabilize below your practice's tolerance threshold (we've seen practices set this anywhere from 2 to 5 percent of encounters, depending on risk appetite), move to clinic-wide deployment. This phase requires governance structures most pilots skip entirely: a named clinical owner for AI-related documentation policy, a quarterly audit of a random note sample, and an incident process for when an AI-drafted note contains a clinically significant error that reaches the chart uncorrected.
HIMSS surveys on AI adoption in healthcare have repeatedly found that governance maturity, not tool capability, is the strongest predictor of sustained use versus abandonment after 12 months. Practices that treat Phase 3 as "turn it on for everyone" rather than "formalize how we monitor it" are the ones we see reverting to manual documentation within a year.
Get early access to Thyra
Built by a practicing endocrinologist. JJ personally reviews every application.
A decision rule for whether to move to the next phase
Don't advance phases on a calendar. Advance on this rule: move to the next phase only when your correction log shows fewer than one clinically significant error (defined as one that would change treatment if uncorrected) per twenty encounters, sustained over two consecutive weeks. If you're still above that threshold, stay in the current phase and add configuration time rather than more clinicians. Adding volume to a workflow with unresolved extraction problems compounds the problem instead of averaging it out.
Concrete failure modes we've observed
Failure mode 1: CGM data misattribution. When a patient's CGM report spans multiple sensor sessions or includes a gap from a sensor failure, some AI tools average across the gap rather than flagging it, producing a falsely smoothed time-in-range figure. This is a data integrity risk, not a style issue, and it's why Phase 1 pilots should specifically stress-test patients with irregular CGM wear.
Failure mode 2: Insulin dose transcription drift. In visits where a clinician verbally walks through a multi-step titration ("increase your evening basal by two units, hold your mealtime bolus the same, reassess in one week"), ambient tools occasionally collapse multi-step instructions into a single ambiguous line. This is the single highest-risk category to review manually until your team has validated the tool against your specific dictation patterns.
Failure mode 3: Coding level mismatch. Documentation AI drafts tend toward verbose, comprehensive notes, which can push visit documentation toward a higher coding level than the actual medical decision-making supports. This creates compliance exposure, not just an inconvenience. ONC's information blocking rules and general documentation integrity guidance both point toward the same principle: the note should reflect the visit, not be inflated by what the tool is capable of generating.
Failure mode 4: Interoperability assumptions. Practices often assume that because a tool exports HL7 or FHIR-formatted data, it will integrate cleanly with their existing EHR's discrete fields for diabetes-specific data like insulin-to-carb ratios or correction factors. In practice, field-level mapping between systems is inconsistent even when both claim FHIR compliance, because FHIR defines a data exchange standard, not a guarantee that every field maps one-to-one. Test this explicitly in Phase 2, not after go-live.
Timelines and risk by practice size
A solo or two-clinician practice can realistically complete all three phases in about eight weeks, since coordination overhead is low. A multi-site group with ten or more clinicians should plan for four to six months, primarily because Phase 2's structured feedback loop takes longer to reach a stable error rate across a more varied set of documentation habits. Practices that compress this timeline under administrative pressure to show fast ROI are the ones most likely to end up back in Phase 1 within a year, re-litigating trust they could have built the first time.
The clinical risk profile also changes with practice size. Solo practices carry higher per-error impact (one clinician's blind spot isn't offset by peer review) but lower coordination risk. Larger groups have more built-in peer oversight but face a harder governance problem: inconsistent adoption across clinicians creates a documentation standard that varies by which physician a patient sees, which is itself a compliance and continuity-of-care risk worth flagging to a practice's medical director before scaling.
What this framework doesn't solve
Documentation AI, including Thyra, doesn't reduce the clinical judgment required to interpret ambiguous CGM patterns or decide on a titration plan. It also doesn't eliminate the need for a clinician to actually read the note before signing it, and any rollout plan that implicitly encourages rubber-stamping is a governance failure waiting to surface in an audit or, worse, a missed clinical finding. The phased framework above is designed to keep human review load appropriately high during the phases where trust hasn't been earned yet, and to formalize where it can safely decrease once the correction data supports it.
Practical next step
If you're evaluating Thyra or a similar tool, start with the two-clinician pilot described above, choose one enthusiastic adopter and one skeptic, and commit to the correction log from day one rather than adding it later once you're trying to reconstruct error patterns from memory. The practices that get the most value from documentation AI are the ones that treat the first month as a data-collection exercise, not a productivity win.