EHR Customization

What does EHR customization mean?

EHR customization is any change that makes a commercial EHR behave differently from the vendor's standard release, from configured templates, order sets and rules to SMART on FHIR apps, CDS Hooks services and interfaces built around it. Good customization changes what the product allows and leaves the vendor's code untouched, so upgrades still apply.

Customization is not the same as building a custom EHR. The organization keeps the commercial product as its record, and every change has to survive the vendor's next release.

Requests usually arrive as complaints rather than specs: a note takes too long, an alert fires at the wrong moment, a referral falls through a gap. Turning each complaint into the right kind of change is most of the skill.

Which layers of customization are there?

There are four layers, from lightest to heaviest: personal settings, shared build, extensions through standard interfaces, and changes to the vendor's code. Each layer costs more to build and more to keep than the one before it.

• 1. Personal settings: Favorites, preference lists, personal note phrases and screen layouts a clinician sets for themselves. They are cheap and local, and they go unused if nobody shows people how to set them.
• 2. Shared build: Templates, order sets, flowsheets, rules, worklists and reports that analysts configure for a department or the whole organization. The vendor supports them through upgrades, but each item needs an owner.
• 3. Standards-based extensions: SMART on FHIR apps launched from the chart, CDS Hooks services that return cards, and HL7 v2 or FHIR interfaces to other systems. They are built outside the EHR, so they survive upgrades as long as the APIs they call do.
• 4. Vendor code changes: Custom code inside the product, or modifications only the vendor can make. This is the most expensive layer to maintain and the one most likely to delay an upgrade.

Push each request to the lowest layer that solves it. An app built for a problem a template would fix adds a system to maintain, and a template stretched over a problem only an app can solve adds clicks.

How do you decide where a request belongs?

Ask four questions in order and stop at the first yes. The answer gives both the layer and the team that owns the work.

• Can the user fix it alone? If a preference list or personal phrase solves it, it is a training task, not a build request.
• Does the standard product already do it? Check the vendor's release notes and the version roadmap first, because a later release may already contain the feature.
• Can shared build do it? Templates, rules and worklists are the vendor-supported way to change behavior for a group of users.
• Does it need data or logic from outside the EHR? If so, build an extension, such as an app, a CDS service or an interface, on the EHR's documented APIs.

Write the answer and the reason on the request. When the same request comes back after an upgrade, the record shows why it was built the way it was and who agreed to it.

Some requests should be declined. A change that serves one user, conflicts with another department's workflow or weakens a safety check needs a clinical owner's decision, not an analyst's best guess.

What can standards-based extensions do?

Extensions can read data, add screens inside the chart and return advice at decision points, but writing data back depends on each vendor. Knowing that limit before design saves rework.

• Read access: 45 CFR 170.315(g)(10) requires certified EHRs to offer a standardized read API for patient and population services, built on US Core, SMART App Launch and Bulk Data.
• Write access: The certified API does not cover filing data into the chart. Writes need the EHR vendor's own write APIs or an HL7 v2 interface, so check each resource in the vendor's documentation.
• In-chart apps: HL7's SMART App Launch guide defines how an app launches from the EHR with the current patient and user context and an OAuth 2.0 token limited by scopes.
• Decision support: A CDS Hooks service lets the EHR call outside logic at points such as opening a chart or signing an order, and show the cards the service returns, where the vendor supports the hooks the use case needs.
• Launch points: Decide where in the workflow an app opens, such as a chart tab, an order step or an inbox item, because each vendor exposes different launch points and the wrong one adds clicks.

An extension is only as stable as the API it calls. Track the vendor's API versions and deprecation notices the same way you track your own releases, and test extensions in the vendor's upgrade environment before go-live.

Each extension also needs its own security review. An app or service that receives patient data from the EHR is another system holding ePHI, so it needs access controls and audit logging, and a business associate agreement when an outside company runs it for the covered entity. Plan that review before the build starts, because the EHR owner will usually ask for it before granting production credentials.

How should change control work for a customized EHR?

Every customization should pass through one intake, one review and one test path, whichever layer it lands in. Change control keeps hundreds of small changes from turning into a system nobody can upgrade.

• 1. Intake: One queue for all requests, each with the problem, the users affected and an example patient scenario.
• 2. Triage: The layer decision, plus a clinical safety rating for any change that touches orders, results, medications or alerts.
• 3. Design review: Clinical owners approve the content, and analysts or engineers confirm the build approach and its effect on other departments.
• 4. Build and test: Work in a non-production environment, with regression tests for related workflows and interfaces.
• 5. Release: A scheduled window, a note to affected users and a rollback plan.
• 6. Inventory: Each live customization recorded with its owner, layer, reason and the vendor version it was tested on.
• 7. Upgrade check: Before each vendor upgrade, rerun the tests for every inventory item and retire anything the new release makes unnecessary.

Federal guidance points the same way. The HIPAA evaluation standard, 45 CFR 164.308(a)(8), calls for periodic technical and nontechnical evaluation in response to environmental or operational changes, and a major build change or upgrade is one. The 2025 SAFER Guides from ASTP/ONC include a System Management guide on configuring, validating and maintaining EHR software.

How much local variation should a multi-site build allow?

As little as clinical practice requires. Each local variant multiplies build, testing and training, so a multi-site organization does best with one standard build and variation only where care really differs.

• Standard by default: One version of each order set, template and rule, owned by an enterprise clinical group.
• Variation by exception: A site or specialty version only where practice, equipment or state rules differ, with the reason recorded.
• Shared extensions: Apps and CDS services deployed once and configured per site, rather than rebuilt for each one.
• Review on a cycle: Local variants reviewed each year and folded back into the standard when their reason no longer holds.

Mergers make this urgent. Two organizations on the same product rarely share the same build, and choosing which version becomes the standard is a clinical decision before it is a technical one.

Where EHR customization goes wrong

• Building for one loud user: A template shaped around one clinician's preferences becomes the standard for a department that works differently.
• Copies instead of edits: Departments clone an order set rather than asking for a change, and soon several versions exist that nobody reconciles.
• Local codes inside apps: An extension carries a site-specific code list in its source and breaks when the site adds a code.
• Write-back assumed: An app is designed to file data into the chart before anyone confirms the vendor exposes a write path for that data.
• No retirement: A customization stays live after the vendor ships the same feature, so users see two ways to do one task.
• Untracked vendor changes: Modifications made by the vendor years ago are on no list, and the next upgrade breaks them.
• Alerts without a volume check: A new interruptive alert goes live without anyone estimating how often it will fire.

The inventory in step 6 prevents most of these. A customization that has an owner, a reason and a test is one that someone will notice when it stops making sense.

How Agnotic can help

The extension layer is where an in-house EHR team often runs short: apps, decision support services and interfaces that need engineering rather than configuration. Agnotic Technologies builds those extensions for the client on the EHR's documented APIs, with the tests and inventory entries that carry them through the next vendor upgrade.

Agnotic also reviews existing extensions and older vendor modifications against the vendor's current APIs, and plans the work to retire them or rebuild them on standards.

Sources

• ASTP/ONC: 170.315(g)(10) standardized API for patient and population services
• HL7 International: SMART App Launch
• 45 CFR 164.308: HIPAA administrative safeguards, including (a)(8) evaluation
• ASTP/ONC: SAFER Guides, 2025 edition including System Management