Cost of EHR

What does the cost of EHR actually include?

The cost of EHR is the total spent over the life of the system, not the license or build quote alone. It covers five buckets: software licensing or core engineering, data migration, interfaces, configuration and go-live, and the hosting, security and regulatory work that continues every year after launch.

Why is the quote only one line of the budget?

A vendor quote prices what the vendor sells. The rest of the work is done by your staff, your integration partner or other vendors, and it rarely appears on the same page.

• Modules priced separately: Patient portal, telehealth, controlled-substance e-prescribing, specialty content and revenue cycle tools can each be add-ons to the base charting seat.
• Interfaces priced per connection: Each lab, imaging center, registry, HIE and clearinghouse connection can carry a setup charge and a recurring maintenance fee, on either side of the link.
• Internal time: Physicians, nurses and billers spend hours in design sessions, testing and training. A reduced schedule during go-live weeks is lost visit capacity, and it belongs in the budget.
• Yearly change: Code sets, quality measure specifications, certification criteria and payer rules change on their own schedules, and each change needs configuration or engineering time.

Bucket by bucket: where the money goes

Each bucket has its own cost drivers. Estimating them separately makes it clear which numbers are firm and which depend on decisions not yet made.

• 1. License or core build: For a commercial EHR, the drivers are user count by role, module list, hosting tier and contract length. For a custom build, they are the number of clinical workflows, the data model, role-based access design and the certification scope, if any.
• 2. Data migration: The drivers are the number of source systems, the clinical domains moved as coded data (problems, medications, allergies, immunizations, results), the volume of documents, duplicate patient records to resolve, and whether a read-only archive is needed for older charts.
• 3. Interfaces: The drivers are the count and type of connections: HL7 v2 ADT, ORM and ORU feeds through an interface engine, FHIR R4 APIs and SMART on FHIR launches, X12 270/271 eligibility and 837/835 claims, NCPDP SCRIPT e-prescribing and public health reporting.
• 4. Configuration and go-live: The drivers are note templates, order sets, decision support rules and billing edits per specialty, plus dress rehearsals, super-user training and on-site support in the first weeks of live use.
• 5. Run costs: The drivers are hosting, backup and disaster recovery, log storage, vulnerability scanning and penetration testing, interface monitoring, and the yearly updates to code sets, measures and API versions.

Buckets 2 and 3 are the hardest to estimate early, because they depend on systems outside the EHR. An inventory of those systems is the cheapest way to firm them up.

Which numbers should each vendor put in writing?

Ask every finalist for the same itemized list so the quotes can be compared line by line. A missing line is a cost you will pay later, either to that vendor or to someone else.

• Seats and modules: Price per user by role, the modules in the base price, and each add-on module priced on its own.
• Interfaces: Setup and yearly fees for each named connection, and who builds and tests the other side of each one.
• API terms: Any charge for API access, call volume, sandbox use or app approval, and the published rate card if one exists.
• Data in and data out: The cost of loading migrated data at go-live, and the format, timeline and fee for a full export when the contract ends.
• Implementation services: Vendor hours included for configuration, training and go-live support, and the hourly rate once they are used up.
• Price changes: The yearly increase cap, and what happens to pricing when users, sites or modules are added.

Which rules create fixed line items?

Some costs follow from federal rules, whichever product you choose. Plan for these as fixed lines rather than options.

• Read API, separate write budget: ASTP/ONC criterion 45 CFR 170.315(g)(10) requires certified EHRs to offer a standardized read API for patient and population services. Writing data back into the EHR needs the vendor's own write APIs or an HL7 v2 interface, so it is a separate line.
• Fees and information blocking: Under 45 CFR Part 171, fees that interfere with access to electronic health information can be information blocking unless an exception applies, such as the fees exception at 45 CFR 171.302. Ask vendors how their API and export fees fit it.
• Security risk analysis: The HIPAA Security Rule requires an accurate and thorough risk analysis at 45 CFR 164.308(a)(1)(ii)(A), and security measures must be reviewed and updated as needed under 45 CFR 164.306(e). Both take recurring staff or partner time.
• Accessibility: The HHS Section 504 rule at 45 CFR 84.84 adopts WCAG 2.1 Level AA for the web content and mobile apps of recipients of HHS funding. Compliance dates are 11 May 2027 for recipients with 15 or more employees and 10 May 2028 for smaller ones.
• SAFER Guides attestation: CMS Promoting Interoperability programs require an annual attestation to a SAFER Guides self-assessment, which takes clinical and IT time each year.

How do buying, extending and building change the buckets?

The three paths move cost between buckets rather than removing it. Compare them over five years, not on the first-year number.

• Buy a commercial EHR: Bucket 1 is a recurring license. Buckets 2 to 4 are front-loaded at go-live. Bucket 5 is shared with the vendor, which handles certification updates, while you keep interface monitoring and internal security work.
• Extend an existing EHR with SMART on FHIR: Bucket 1 stays as it is. You add build and hosting for the app, an interface or write API line if the app files data back, and run costs for app updates when the EHR changes versions.
• Build a custom EHR: Bucket 1 becomes engineering for discovery, data model, user interface and access control. Bucket 5 grows, because you own hosting, security operations and any certification work yourself.
• Mixed paths: Many organizations buy the core record and build around it. The budget then needs a clear boundary: which workflows the vendor covers, and which the custom layer owns.

How should you build a five-year cost model?

Build the model from inventories, not from vendor brochures. Each step below produces a document that someone can check.

• 1. Users and roles: Count physicians, advanced practice providers, nurses, medical assistants, front desk and billing staff, and note which roles need which modules.
• 2. Connected systems: List every lab, imaging system, pharmacy network, clearinghouse, registry, device and patient app, with the standard each uses: FHIR R4, HL7 v2, C-CDA or X12.
• 3. Migration scope: Pull a sample export from the current system, decide which domains move as coded data and which as documents, and price the archive for the rest.
• 4. One-time versus recurring: Put year-one build, migration and go-live costs in one column and years two to five license, hosting, interface upkeep and support in others.
• 5. Contract terms: Before signing, get written terms for API access and volume, sandbox access, SMART on FHIR app approval, and the format and fee for a full data export under the 45 CFR 170.315(b)(10) criterion.
• 6. Phased release: Price a first release that covers one complete clinical and billing loop at a pilot site, then price expansion from what the pilot shows.

Where EHR budgets overrun

• Choosing on seat price: A lower monthly fee is quickly offset if every lab interface, portal feature or API call has its own charge.
• No clinical cutoff for migration: Converting a decade of free-text history into coded fields adds engineering hours without helping care at the point of visit.
• Rebuilding commodity services: Custom EHR teams that build their own e-prescribing network, drug interaction content or clearinghouse take on certification work that existing networks already carry.
• Cutting rehearsal and training: Saving on dress rehearsals and super-user time tends to come back as charting backlogs and overtime after go-live.
• Ignoring exit terms: A contract that does not say how full records, documents and audit data come out at the end turns the next migration into a negotiation.
• Unmonitored interfaces: Stalled HL7 queues and rejected claims that nobody sees for days cost more in delayed revenue than the monitoring would have.

How Agnotic can help

The engineering buckets, migration and interfaces in particular, are where EHR budgets are hardest to estimate. Agnotic Technologies scopes and builds that work for the client: interface inventories and HL7 v2 or FHIR R4 integrations, validated data migrations, and SMART on FHIR apps that extend Epic, Oracle Health (Cerner) or athenahealth instead of replacing them.

Agnotic also reviews build-versus-buy options against a five-year model, so the decision rests on documented scope rather than on a first-year quote.

Sources

• ASTP/ONC: Standardized API for patient and population services, 45 CFR 170.315(g)(10)
• ASTP/ONC: Electronic health information export, 45 CFR 170.315(b)(10)
• 45 CFR 171.302: Fees exception (information blocking)
• 45 CFR 164.308: HIPAA administrative safeguards, including risk analysis
• 45 CFR Part 84 Subpart I: Web, mobile and kiosk accessibility (Section 504)
• Federal Register, 11 May 2026: Extension of Section 504 web and mobile accessibility compliance dates
• ASTP/ONC: SAFER Guides