EHR Modernization

What does EHR modernization involve?

EHR modernization is the program that brings an organization's electronic health record back in line with its clinical and business needs, either by optimizing the current system's build, interfaces and data or by replacing it with another certified product. The decision rests on whether the problems sit in configuration, which can be fixed, or in the platform itself.

The two paths look similar from the outside because both bring new screens, training and interface work. Underneath they differ. Optimization keeps the database, the patient identifiers and every interface partner in place. Replacement moves all three, and each move creates its own risk.

That is why the first piece of work is diagnostic, not technical. A steering group that cannot say which complaints come from the build and which come from the product will pick a path by mood.

Is the problem the build or the platform?

Most complaints about an EHR trace back to how it was configured, not to what the product can do. A useful test is to ask whether another customer on the same version has solved the same problem. If one has, the fix is probably a build change.

• Build signals: order sets nobody maintains, alerts that fire on every encounter, note templates copied across specialties, interfaces that fail on unmapped codes, and reports that disagree because each department defined a measure its own way.
• Platform signals: the vendor has announced end of support for the product or hosting model, the product's Certified Health IT Product List entry shows a withdrawn or retired status, the product cannot support an API or workflow the organization must run, or a merger requires one enterprise record across sites.
• Mixed signals: slow performance, poor mobile use and weak reporting can come from either side, so test them on a vendor reference site before counting them.

Write each complaint down with its source, the people affected and an example record. The list becomes the baseline that either path is measured against later.

How should the decision be scored?

Score both paths against the same criteria, with weights the steering group agrees before anyone sees the vendor demos. Agreeing weights first stops the most persuasive presentation from setting the rules.

• 1. Clinical fit: can the target state, optimized or replaced, support the specialties and care settings the organization runs today and plans to add?
• 2. Problem coverage: how many of the logged complaints does each path fix, and how many does it only move?
• 3. Interface load: how many interfaces must be rebuilt, retested or renegotiated with partners such as labs, imaging, payers and the health information exchange?
• 4. Data path: what has to be converted, what can be loaded as documents and what can stay in an archive?
• 5. Workforce cost: how many hours of clinician training and go-live support will each path need, counted from the organization's own staffing plan?
• 6. Exit position: what does the current contract say about data return, export format and post-termination access?
• 7. Certification and programs: which certified criteria does each option meet, and which quality or payment programs depend on them?

A path that wins on clinical fit but loses badly on the data path is not a clear win. The scores show where the risk sits, so the plan can fund that part first.

Run the scoring twice: once against the current vendor's written optimization proposal, and once against a replacement vendor's implementation plan. Comparing two written plans is more reliable than comparing one plan with the frustration people feel about the system they use every day.

Which rules shape the choice?

Federal rules do not choose the path, but they set conditions on both. These are the ones that most often change a replacement plan.

• Certification status: ASTP/ONC publishes every certified product, its criteria and its status (active, suspended, withdrawn or retired) on the Certified Health IT Product List, so check a candidate's listing before signing.
• EHI export: 45 CFR 170.315(b)(10) is a certification criterion that requires certified developers to support export of electronic health information for a single patient and for a whole population. It is the first thing to request from an outgoing vendor.
• Information blocking: under 45 CFR Part 171, an actor such as a certified developer or a provider that blocks or delays access to EHI can be engaged in information blocking unless an exception applies.
• Record retention: the hospital condition of participation for medical record services, 42 CFR 482.24(b)(1), sets a floor of 5 years for keeping records in original or legally reproduced form, and state law often sets a longer period.
• Downtime planning: the contingency plan standard in the HIPAA Security Rule (45 CFR 164.308(a)(7)) covers data backup, disaster recovery and emergency mode operation, which a cutover weekend tests directly.

Certification criteria also change. HTI-5, published in the Federal Register on 28 October 2026, removed 14 criteria and revised 7, so compare each candidate's listing with the criteria the organization's programs still need.

The migration path after a replacement decision

Once replacement is chosen, the migration path decides whether clinicians trust the new record on day one. It runs in a fixed order, because each step depends on the one before it.

• 1. Source inventory: list every system that writes clinical data into the old record, including feeds that bypass the main interface engine.
• 2. Data classes: for problems, medications, allergies, results, notes, images and billing history, decide whether each class is converted, loaded as documents or left in the archive.
• 3. Extract plan: request the EHI export, confirm its format and test it on a sample of real patients before the contract notice period starts.
• 4. Identity matching: reconcile medical record numbers, merged patients and duplicate charts before the first load, not after.
• 5. Mock conversions: run full trial loads, compare counts and samples with the source, and have clinicians review charts they know.
• 6. Cutover: freeze the old system to read-only, load the delta, switch interfaces partner by partner and keep the old screens available.
• 7. Decommission: move remaining history into the archive, confirm retention and access, then end the old license.

Steps 2 and 4 cause most of the late surprises. Both are decisions people would rather defer, and both get harder once the new system holds live data.

Interface cutover deserves its own schedule. Each partner, whether a reference lab, an imaging center or a payer, has to test the new endpoint, and some only test on set days. Sequencing partners by clinical risk, with orders and results first, keeps the go-live weekend from waiting on the slowest one.

How long should the old system stay readable?

The old record must stay readable for as long as retention law, legal holds and patient access require, which is usually longer than the old license. The plan should say where that history lives and who can open it.

• Read-only legacy instance: the quickest to set up and the most familiar to clinicians, but it keeps the old vendor contract and the old servers alive.
• Clinical archive: a separate system that stores converted history and documents, searchable from the new EHR, with its own access controls and audit logs.
• Data warehouse copy: useful for research and reporting, but rarely enough on its own, because release of information staff need the record as clinicians saw it.

Patients keep their right of access to the designated record set under 45 CFR 164.524 after a migration. Whatever option is chosen, release of information staff must be able to find and produce archived records without help from the old vendor.

Archived records still need the access controls and audit controls of a live system. A read-only screen that anyone with an old account can open still holds ePHI under the Security Rule, so accounts must be reviewed and old logins closed when staff leave.

Where replacement projects stall

• Contract exit read too late: the export format, data return fee or termination notice is discovered after the go-live date is set.
• Every complaint blamed on the vendor: the same order sets and alert rules are rebuilt in the new system, and the same problems return.
• Interface partners told last: a lab or payer needs its own test window for a new endpoint, and the cutover waits on it.
• Conversion scope that grows: each department asks for full history, and trial loads stop finishing inside the cutover window.
• No owner for the archive: the old system is switched off before anyone confirms that records can still be produced on request.

Optimization projects stall for a different reason: nobody owns the build after the fix. A governance group that reviews changes each month keeps an optimized system from drifting back.

How Agnotic can help

A replacement or optimization decision usually leaves a list of engineering work that neither EHR vendor will take on. Agnotic Technologies builds that work for the client: interface rebuilds and retests, EHI export parsing, data conversion and validation tooling, patient identity reconciliation and archive access from the new record.

When the organization chooses to optimize instead, Agnotic builds the interface fixes, code mapping and reporting pipelines that the build review identifies.

Sources

• ASTP/ONC: Certified Health IT Product List (CHPL)
• 45 CFR 170.315: ONC certification criteria for health IT, including (b)(10) EHI export
• 45 CFR Part 171: Information blocking
• 42 CFR 482.24: Condition of participation, medical record services
• 45 CFR 164.308: Administrative safeguards, contingency plan
• 45 CFR 164.524: Access of individuals to protected health information