When Does It Make Sense to Try an Overlay Instead of Switching EHRs?

TL;DR

• An overlay makes sense when your core EHR is stable enough to keep for billing, scheduling, and legal record-keeping, but clinicians are drowning in documentation, inbox, or CGM review work that the base system handles poorly.
• A full replacement makes sense when the underlying system itself is the constraint: broken interoperability, an unsupported vendor, failed reporting, or a contract that is forcing your hand anyway.
• Time-to-value favors overlays almost every time. A SMART on FHIR overlay can be live for a pilot group in weeks, since it builds on the HL7 SMART App Launch Framework rather than a new data model. A full migration realistically takes 6 to 18 months depending on specialty complexity and payer mix.
• Data risk is asymmetric. Overlays read and write through FHIR APIs without touching your source-of-truth database. Replacements require a full data migration, which is where most EHR transition problems originate.
• Staff disruption is the variable most IT admins underestimate. Research on ambulatory physician time allocation, including the widely cited Sinsky et al. work published in Annals of Internal Medicine (2016), has documented how much of a clinician's day is already consumed by EHR-related desk work even before a transition adds new friction on top of it.
• The two paths are not mutually exclusive. Many practices run an overlay for 12 to 24 months, prove the workflow value, then use that evidence to justify (or avoid) a full switch later.

What is the difference between an EHR overlay and a full EHR replacement?

An overlay adds a new clinical workflow layer on top of your existing EHR through SMART on FHIR and standard APIs, while a full replacement retires the old system entirely and migrates all data and workflows to a new one.

In practice, an overlay like Thyra sits next to your system of record. It pulls patient context, problem lists, meds, and labs through FHIR calls built on the HL7 SMART App Launch Framework (now in its v2 iteration), and it writes documentation, orders, and results actions back into the chart or into its own layer depending on how deep the integration goes. The base EHR keeps doing what it already does reasonably well: scheduling, claims, patient billing, and the legal medical record. The overlay takes over the parts clinicians actually complain about: note-writing, inbox triage, CGM data review, and protocol-driven decision support.

A full replacement is a different animal. Every workflow, every report, every interface to labs and pharmacies, and every user account gets rebuilt in the new system. There is no coexistence period except for a defined cutover window, and the old system typically goes read-only for legal record purposes shortly after go-live.

When should a clinic choose an overlay instead of switching EHRs?

Choose an overlay when the pain is workflow-specific and the underlying EHR is not itself broken, unsupported, or blocking growth.

The clearest overlay candidates share a pattern: billing and scheduling work fine, the vendor is not going out of business or dropping support, and the practice's revenue cycle is not at risk. The actual complaint is almost always one of three things: clinicians spend too much time on notes, the inbox is unmanageable, or specialty workflows like CGM review and titration protocols are clunky bolt-ons that never fit the base system's design. For endocrinology and primary care panels managing diabetes technology, this last point matters more than IT teams often assume. The ADA Standards of Care in Diabetes (2024 edition) explicitly recommends structured, recurring review of continuous glucose monitor data as part of routine management, but most legacy EHRs were never built with a native CGM viewer, so that recommended workflow gets done manually, outside the chart, or not consistently at all.

Decision rule: if removing documentation, inbox, and CGM/protocol pain entirely would leave nobody wanting to leave the current EHR, choose an overlay. If the honest answer involves interoperability failures, unsupported infrastructure, or a vendor sunsetting the product, an overlay only delays an inevitable and probably more expensive replacement later.

What are the data migration risks in each approach?

Overlays carry API-level integration risk; replacements carry full data migration risk, which is a materially larger and less forgiving category of risk.

With a SMART on FHIR overlay, the risk surface is bounded. You are validating a defined set of FHIR resources (Patient, Observation, MedicationRequest, DiagnosticReport, and similar), confirming the overlay reads and writes them correctly, and monitoring for API rate limits, token expiration, or vendor-side FHIR gaps. Since 2021, ONC's information blocking rules under the 21st Century Cures Act have pushed most certified EHRs toward more reliable FHIR access, which is part of why overlays have become more viable than they were even a few years earlier. If something goes wrong, the fix is usually a mapping correction or a support ticket, not a data recovery project. The source-of-truth database in the base EHR is never touched.

With a full replacement, you are migrating structured and unstructured data across systems that were never designed to be interchangeable, and this is where the concrete failure modes tend to cluster:

• Coding system mismatches: problem lists that used local or legacy codes get force-mapped to ICD-10 or SNOMED, sometimes losing clinical nuance in the process.
• Dosing format drift: med lists built on free-text sig fields in the old system don't translate cleanly into structured dosing in the new one, creating reconciliation work per patient.
• Unit and reference-range mismatches: lab results migrate as numbers but lose the context needed to flag them correctly if reference ranges weren't mapped alongside the values.
• Orphaned scanned documents: PDFs and faxes get imported but detach from the correct patient or encounter, requiring manual re-linking.
• Device data gaps: CGM, pump, and other device feeds that were integrated into the old EHR often need to be re-established from scratch with the new vendor, and that integration work is frequently underscoped in the migration timeline.

Even well-run migrations lose some fidelity, and reconciliation work (comparing old chart to new chart, patient by patient, for active patients) is a real line item that many project plans underestimate. This is also where compliance exposure concentrates: incomplete migrations can create gaps in the legal medical record that surface months later during an audit or a malpractice review.

For an IT admin building a risk register, the honest framing is that overlay risk is operational and recoverable, while replacement risk is structural and sometimes permanent if reconciliation is rushed.

How much staff disruption should you expect?

Overlays allow phased, opt-in adoption by clinician or clinic, while full replacements require a hard, simultaneous cutover for everyone.

Staff disruption during an EHR transition is not just a training problem, it is a productivity and safety problem. During a full replacement, every clinician, front-desk staff member, MA, and biller has to learn new screens, new click paths, and new failure modes on the same go-live date, often while still seeing a full patient schedule. Published evaluations from HIMSS and health system case reports consistently describe temporary productivity dips in the weeks following a go-live, and the practices that handle this best over-staff support during the first two to four weeks and deliberately reduce patient volume during the transition window.

An overlay avoids most of this because adoption can be sequenced. A practice can run a single physician or a single clinic on the overlay for documentation and inbox work while everyone else continues exactly as before. If the pilot group struggles, the blast radius is one physician's workflow, not the whole practice's schedule.

One pattern that shows up repeatedly in early overlay pilots is worth naming directly: the clinicians who adopt fastest are rarely the ones with the highest overall EHR usage. They're the ones carrying the heaviest CGM or chronic-disease panels, because that's where the base EHR's gaps are most acute and the time savings are most visible within the first week, not the first quarter. IT admins running a pilot get a much cleaner read on value if they select for panel type rather than general tech comfort. A related and common early misstep is the opposite: picking the most tech-savvy champion as the pilot user instead of a representative one, which produces adoption data that looks great in a demo and doesn't generalize when the overlay expands to the rest of the practice.

What are the cost tradeoffs between an overlay and a full replacement?

Overlays have lower upfront cost and faster payback, while full replacements have higher upfront cost but can eliminate ongoing licensing and support inefficiencies of a legacy system over a longer horizon.

The overlay cost profile is dominated by subscription fees for the new layer, some integration engineering time (often handled by the vendor if the base EHR has decent FHIR support), and a modest training investment focused on the new workflows rather than an entire new system. Because the underlying EHR is untouched, there is no parallel licensing cost for a system you are trying to retire, and no sunk cost from an interrupted implementation if the pilot does not work out.

The replacement cost profile includes new system licensing, data migration services, interface rebuilds for every connected lab, pharmacy, and clearinghouse, extended go-live support staffing, and often a period of dual licensing while the old system is kept live for legal record access. These costs are real and necessary, but they are also front-loaded, which is why replacement decisions should be tied to a business case that goes beyond clinician satisfaction, such as a vendor sunset, a failed compliance requirement, or a payer or health system mandate.

How do you evaluate readiness for an overlay vs. a full replacement?

Readiness for either path depends on the maturity of your base EHR's FHIR support, the specificity of your workflow complaints, and how much organizational bandwidth you have for change management.

A practical readiness checklist for an IT admin:

1. Confirm FHIR maturity. Check whether your current EHR has a functioning FHIR API certified under ONC's Health IT Certification Program. Its absence is itself a signal the base system may be reaching end of useful life, not just an overlay blocker.
2. Separate platform issues from workflow issues. Interoperability failures, unsupported reporting, and vendor instability point toward replacement. Documentation burden, inbox chaos, and poor specialty support point toward overlay.
3. Assess cutover bandwidth honestly. If your organization cannot absorb a hard cutover in the next 12 months, an overlay buys time and value without forcing that decision now.
4. Pilot with a representative group, not your best-case user. Both paths benefit from evidence before scale, and that evidence is only useful if the pilot group reflects your actual panel mix rather than your most enthusiastic adopter.

Can an overlay and a full replacement be part of the same roadmap?

Yes, many practices run an overlay first, gather real adoption and outcome data, and use that evidence to decide whether a full replacement is worth pursuing later.

This sequencing has a practical benefit for IT admins: it converts a speculative, high-stakes replacement decision into an evidence-based one. If a pilot group on an overlay shows measurably better documentation turnaround, inbox response time, or CGM review efficiency, that data becomes the business case for either expanding the overlay practice-wide or, if the base EHR still cannot support scale, informing vendor selection for an eventual replacement. Conversely, if the overlay reveals that the base EHR's API limitations or data quality issues are the real bottleneck, that is also valuable information gathered at low cost before a much larger commitment.

Frequently Asked Questions

Does an overlay require replacing our existing EHR contract?

No. An overlay is designed to run alongside your current EHR under its existing contract. You are adding a workflow layer, not terminating or renegotiating your base system agreement, though it is worth confirming your contract does not restrict third-party API access.

Will an overlay work if our current EHR has limited FHIR support?

It depends on how limited. Basic read access to patient, problem list, medication, and lab data is usually sufficient for core overlay functions like documentation and inbox support. If your EHR's FHIR API is minimal or unreliable despite ONC certification requirements, that is itself a signal worth escalating, since it will eventually limit other integrations too, not just an overlay.

How long should a practice pilot an overlay before deciding to expand it?

Most practical pilots run 60 to 90 days with a defined small group, long enough to see past the initial learning curve and get a real read on documentation time, inbox turnaround, and clinician satisfaction, without dragging on so long that momentum stalls.

Is a rip-and-replace ever the safer choice even with high migration risk?

Yes, when the base EHR itself is the source of compliance exposure, such as unsupported software that can no longer meet current certification requirements, or a vendor that has announced end of life. In those cases, delaying replacement to avoid migration risk simply trades one risk for a larger one.

Does CGM data review need special handling in either approach?

Yes. Because CGM data volume is high and the ADA Standards of Care recommend structured, recurring review rather than occasional spot checks, this is one of the clearest workflow-versus-platform test cases: if your base EHR simply lacks a usable CGM viewer, that's an overlay problem, not a reason to replace the whole system.

Can Thyra run as an overlay and later become the primary EHR?

Yes. Thyra is built to run alongside an existing EHR first, sharing clinical context for documentation, inbox, CGM review, orders, and protocols, and practices that see strong adoption can transition to Thyra as their primary system on their own timeline rather than a forced cutover.

About the Author

This article was prepared by the Thyra clinical and product team. Thyra was founded by Jean Jacques Nya Ngatchou, MD, a physician focused on reducing documentation burden in endocrinology and primary care through connected, context-aware clinical software. Thyra is built to run as a SMART on FHIR overlay alongside existing EHR systems before becoming a practice's primary system, with its Smart Inbox, Longitudinal AI Scribe, CGM viewer, orders, and protocols sharing a single clinical data model.

References

• HL7 International, SMART App Launch Framework (SMART on FHIR), https://hl7.org/fhir/smart-app-launch/
• Office of the National Coordinator for Health IT (ONC), Health IT Certification Program overview, https://www.healthit.gov/topic/certification-ehrs
• ONC, FHIR API and information blocking requirements under the 21st Century Cures Act Final Rule (2020), https://www.healthit.gov/topic/oncs-cures-act-final-rule
• Healthcare Information and Management Systems Society (HIMSS), guidance on EHR transition planning and change management, https://www.himss.org/
• American Diabetes Association, Standards of Care in Diabetes (2024), diabetes technology and CGM data review recommendations, https://diabetesjournals.org/care
• Sinsky C, et al., "Allocation of Physician Time in Ambulatory Practice," Annals of Internal Medicine (2016), referenced widely in JAMA-affiliated discussions of EHR documentation burden
• American Medical Association, EHR usability and documentation burden resources, https://www.ama-assn.org/practice-management/digital