How to test an electronic health record system

Direct answer

Shipped untested, an electronic health record system accepts a lab or consult order that lands in a queue nobody works, so the patient's test never happens, and delays a patient's record export to another provider, which can count as information blocking. 7 tests are mandatory here, each tied to a risk in the map below. After the release smoke check, start the risk tests with integration tests: every order type must reach its lab, pharmacy or specialty worklist, and an order with no valid target must be refused at entry.

7 mandatory testsfirst: integration tests

What counts as an electronic health record system

An electronic health record system here means the web, desktop and API product providers use for clinical records, orders and results during care. It counts when the system holds PHI, routes orders to departments or external systems, or is certified health IT. A patient portal that only exposes the record to patients is out of scope, and so is trial data capture software used by sponsors and study sites.

Adjacent product types not covered here

  • patient portal: A patient portal faces patients, so its risks are proxy access and lost messages, while the record system carries order routing and downtime during care.
  • clinical trial management software: Clinical trial software holds study data under audit trail and validation rules for sponsors, not orders and results used for treatment.
  • software as a medical device: Software as a medical device produces a dose or alarm itself, while the record system stores and routes the clinicians' own orders.

Risk map

4 risks attached to electronic health record system with evidence. Sorted by severity.
RiskGradeNoteEvidence
Physical or psychological harm to a user
user-harm
harmsecondaryA lab or consult order with no valid routing target is accepted on screen and lands in a queue nobody works, so the patient's test never happens, or an update takes the chart down during care and the downtime view does not show current medications and orders.
Fine or enforcement by a regulator
regulatory-penalty
legalprimaryA certified record system delays or refuses an export of a patient's electronic health information to another provider, which can count as information blocking.
Records silently wrong
data-corruption
datasecondaryA medication list or allergy sent to another site's record arrives with the wrong drug or no allergy, and the receiving pharmacist has no sign it changed.
Users or operators act on wrong numbers
wrong-decisions
trustsecondaryAfter go-live the quality and patient safety reports that accreditation depends on cannot be built from the new record data, and managers run the ward on gaps.

Mandatory tests (7)

  1. Step 1: release smoke tests

    Why:user-harm

    Done when: After each update, a test clinician opens a test patient's chart, places a lab order and sees it arrive in the lab worklist.

    Tool class: browser automation. Who usually runs it: QA engineer.

  2. Step 2: integration tests

    Why:user-harmdata-corruption

    Done when: Every order type placed in a test chart reaches its target lab, pharmacy or specialty worklist, and an order with no valid target is refused at entry with a message.

    Tool class: API client. Who usually runs it: developer.

  3. Step 3: end-to-end functional tests

    Why:user-harm

    Done when: A test patient goes from registration through orders, results, medication administration and discharge, and each step shows in the chart with the user and time.

    Tool class: browser automation. Who usually runs it: QA engineer.

  4. Step 4: regression suite

    Why:user-harm

    Done when: The regression set for ordering, results and medication workflows passes on each build before it reaches a live facility.

    Tool class: test management. Who usually runs it: QA engineer.

  5. Step 5: resilience and failure testing

    Why:user-harm

    Done when: With the main system taken offline in a test site, clinicians open the downtime view and read current medications, allergies and active orders for a test patient.

    Tool class: chaos tool. Who usually runs it: developer.

  6. Step 6: compliance checks

    Why:regulatory-penalty

    Done when: A reviewer confirms that a test patient's full electronic health information exports in the standard format on request and that the access audit log is reviewed on a set schedule.

    Tool class: test management. Who usually runs it: product manager.

  7. Step 7: data integrity and migration testing

    Why:data-corruptionwrong-decisions

    Done when: Medication lists and allergies for a sample of test patients match field for field between the sending and receiving records, and each required quality report produces a value.

    Tool class: data validation. Who usually runs it: developer.

Recommended and optional tests

  • exploratory testingrecommended

    Becomes mandatory when a new facility or specialty goes live with order sets not seen before.

  • contract testsrecommended

    Becomes mandatory when a lab, pharmacy or second record system consumes the system's interfaces on its own release schedule.

  • accessibility testingrecommended

    Becomes mandatory when the system is sold to a federal agency or a public body that requires Section 508 conformance.

  • performance and load testingrecommended

    Becomes mandatory when evidence shows chart load times slowing clinicians at shift change or during go-live.

  • security scanningrecommended

    Becomes mandatory when the risk "Personal or sensitive data exposed" is attached to this product type with verified evidence (see the methodology).

  • penetration testingrecommended

    Becomes mandatory when the risk "Personal or sensitive data exposed" is attached to this product type with verified evidence (see the methodology).

  • device and browser compatibilityrecommended

    Becomes mandatory when facilities run the client on browser or operating system versions the team does not use.

  • unit testsoptional

    May help on dose calculation, unit conversion and date logic in medication modules.

Not needed and why

  • localization testing

    Not needed while the system runs in one language and one country's coding systems. Becomes recommended when a second country or language is sold.

  • offline and poor-network testing

    Not needed while the system runs on facility networks with a separate downtime view. Becomes recommended when a mobile or home-visit client stores charts on the device.

Order of work

First release

  1. release smoke tests: Open a test patient's chart after the update, place a lab order and confirm it appears in the lab worklist.
  2. integration tests: Place every order type in a test chart and confirm each reaches its lab, pharmacy or specialty worklist, then place an order with no valid target and confirm entry is refused with a message.
  3. end-to-end functional tests: Take a test patient from registration through orders, results, medication administration and discharge, and check each step shows in the chart with the user and time.
  4. regression suite: Run the ordering, results and medication regression set on each build before it reaches a live facility.
  5. resilience and failure testing: Take the main system offline in a test site and confirm clinicians read current medications, allergies and active orders from the downtime view.
  6. compliance checks: Export a test patient's full electronic health information in the standard format on request and confirm the access audit log has a set review schedule.
  7. data integrity and migration testing: Compare medication lists and allergies field by field between sending and receiving records for a sample of test patients, and run each required quality report.

Ongoing cadence

Tools

Listed alphabetically inside each test type, filtered to the tests above and to the platforms of electronic health record system (web, desktop, api). Not recommendations.

40 tools shown

release smoke tests

  • TestRailTest case and run management. webiosandroidapicommercial
  • XrayTest management inside Jira. webiosandroidapicommercial

integration tests

  • Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
  • JestJavaScript test runner with mocking and snapshots. webapiopen-source
  • JUnitTest framework for the JVM. apiandroidopen-source
  • PostmanAPI client with collections and scripted assertions. apifreemium
  • pytestTest framework for Python with fixtures and plugins. apiopen-source
  • VitestTest runner for Vite-based JavaScript and TypeScript projects. webapiopen-source

end-to-end functional tests

  • ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
  • BrowserStackCloud of real devices and browsers. webiosandroidcommercial
  • CypressBrowser-based end-to-end testing with a visual runner. webfreemium
  • DeepEvalUnit-style evaluation for LLM applications. apiopen-source
  • LambdaTestCloud browser and device grid. webiosandroidcommercial
  • PercyVisual review of UI changes. webcommercial
  • PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
  • PostmanAPI client with collections and scripted assertions. apifreemium
  • PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
  • Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
  • SeleniumWebDriver-based browser automation. webopen-source

regression suite

  • CypressBrowser-based end-to-end testing with a visual runner. webfreemium
  • DeepEvalUnit-style evaluation for LLM applications. apiopen-source
  • PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
  • PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
  • TestRailTest case and run management. webiosandroidapicommercial
  • XrayTest management inside Jira. webiosandroidapicommercial

resilience and failure testing

  • Chaos MeshFault injection for Kubernetes. apiopen-source
  • GremlinManaged fault injection. apicommercial
  • ToxiproxyTCP proxy for simulating network failures. apiopen-source

data integrity and migration testing

  • dbt testsTests on warehouse models inside dbt. apiopen-source
  • Great ExpectationsData validation with declarative expectations. apiopen-source

contract tests

  • PactConsumer-driven contract testing with a broker. apiopen-source
  • PostmanAPI client with collections and scripted assertions. apifreemium
  • SchemathesisProperty-based testing from OpenAPI and GraphQL schemas. apiopen-source

accessibility testing

  • axe-coreAccessibility rules engine for automated checks. webopen-source
  • LighthouseAudits for accessibility and performance in Chrome. webopen-source
  • Pa11yCommand-line accessibility testing. webopen-source

performance and load testing

  • ArtilleryLoad testing with YAML scenarios. apiwebfreemium
  • GatlingLoad testing with Scala, Java or Kotlin scenarios. apiwebfreemium
  • JMeterLoad testing tool from the Apache Foundation. apiwebopen-source
  • k6Load testing scripted in JavaScript. apiwebopen-source
  • LighthouseAudits for accessibility and performance in Chrome. webopen-source
  • LocustLoad testing scripted in Python. apiwebopen-source

security scanning

  • Burp SuiteProxy and scanner for web application security testing. webapifreemium
  • GarakProbing LLM applications for prompt injection and leakage. apiopen-source
  • mitmproxyInteractive HTTPS proxy. iosandroidwebapiopen-source
  • OWASP ZAPDynamic application security scanner. webapiopen-source
  • SchemathesisProperty-based testing from OpenAPI and GraphQL schemas. apiopen-source
  • SemgrepStatic analysis with custom rules. apiwebiosandroidfreemium
  • SnykDependency and code vulnerability scanning. apiwebiosandroidfreemium
  • TrivyScanner for containers, dependencies and configuration. apiopen-source

penetration testing

  • Burp SuiteProxy and scanner for web application security testing. webapifreemium

device and browser compatibility

  • ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
  • BrowserStackCloud of real devices and browsers. webiosandroidcommercial
  • LambdaTestCloud browser and device grid. webiosandroidcommercial
  • PercyVisual review of UI changes. webcommercial
  • PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
  • Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
  • SeleniumWebDriver-based browser automation. webopen-source

What to send to the person who will test

Send the checklist and the brief below. The printable checklist for electronic health record system has the same 7 items with checkboxes.

Download the checklistMarkdownCSVBrief (Markdown)

Acceptance criteria wording

A release of the electronic health record system is accepted when every order type placed in a test chart reaches its target worklist and an order with no valid target is refused at entry. Medication lists and allergies match field for field between sending and receiving records, and each required quality report produces a value. With the main system offline, the downtime view shows current medications, allergies and active orders for a test patient.

Brief

# Test brief: electronic health record system

Product type: electronic health record system. Clinical records, orders and results used by providers.
Risk map and evidence: https://howtotestaproduct.com/how-to-test/ehr-system/
Printable checklist: https://howtotestaproduct.com/checklists/ehr-system/

Run these 7 mandatory tests in this order. A test is done only when its done condition is true on the build you will release.

1. release smoke tests (risks: user-harm). Tool class: browser automation. Usually run by: QA engineer.
   Done when: After each update, a test clinician opens a test patient's chart, places a lab order and sees it arrive in the lab worklist.
2. integration tests (risks: user-harm, data-corruption). Tool class: API client. Usually run by: developer.
   Done when: Every order type placed in a test chart reaches its target lab, pharmacy or specialty worklist, and an order with no valid target is refused at entry with a message.
3. end-to-end functional tests (risks: user-harm). Tool class: browser automation. Usually run by: QA engineer.
   Done when: A test patient goes from registration through orders, results, medication administration and discharge, and each step shows in the chart with the user and time.
4. regression suite (risks: user-harm). Tool class: test management. Usually run by: QA engineer.
   Done when: The regression set for ordering, results and medication workflows passes on each build before it reaches a live facility.
5. resilience and failure testing (risks: user-harm). Tool class: chaos tool. Usually run by: developer.
   Done when: With the main system taken offline in a test site, clinicians open the downtime view and read current medications, allergies and active orders for a test patient.
6. compliance checks (risks: regulatory-penalty). Tool class: test management. Usually run by: product manager.
   Done when: A reviewer confirms that a test patient's full electronic health information exports in the standard format on request and that the access audit log is reviewed on a set schedule.
7. data integrity and migration testing (risks: data-corruption, wrong-decisions). Tool class: data validation. Usually run by: developer.
   Done when: Medication lists and allergies for a sample of test patients match field for field between the sending and receiving records, and each required quality report produces a value.

Acceptance criteria wording:
A release of the electronic health record system is accepted when every order type placed in a test chart reaches its target worklist and an order with no valid target is refused at entry. Medication lists and allergies match field for field between sending and receiving records, and each required quality report produces a value. With the main system offline, the downtime view shows current medications, allergies and active orders for a test patient.

Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file).

Licence: CC BY 4.0.

For founders: what to forward and what to ask back. For product managers: turning this page into tickets.

Questions about testing an electronic health record system

What testing does an electronic health record system need?

7 mandatory tests cover the 4 risks in the map: orders lost in unworked queues, medication and allergy changes in exchange, delayed record exports, and quality reports that cannot be built after go-live. They run as release smoke, integration, end-to-end, regression, resilience, compliance and data integrity tests. Security scanning and penetration testing are recommended until a data exposure risk is attached with verified evidence.

What is the minimum testing for an electronic health record system at MVP stage?

Once clinicians use the system during care, the minimum is the 7 mandatory tests, each tied to a risk in the map. Order routing, downtime and record export checks apply from the first live facility. The data integrity test applies once records are migrated, exchanged with another system or used for quality reporting.

Which tests in a vendor test plan for an electronic health record system are not needed?

Localization and offline tests are marked not needed. The system runs in one language and one country's coding systems, and runs on facility networks with a separate downtime view. Offline testing becomes recommended when a mobile or home-visit client stores charts on the device.

How is the audit trail tested in an electronic health record system?

The end-to-end test takes a test patient from registration to discharge and checks that each step shows in the chart with the user and time. The compliance check confirms the access audit log is reviewed on a set schedule. The recommended penetration test requires a logged break-the-glass reason when a user without a care relationship opens a record.

What should I send to the person who will test an electronic health record system?

Send the 7 mandatory tests with their done conditions, a test facility with test patients, and the list of order types with their target worklists. Include the downtime view procedure for the resilience test and the required quality reports the data integrity test must produce.

Evidence

  1. ev-0076regulatorsecondary

    The New Electronic Health Record's Unknown Queue Caused Multiple Events of Patient Harm, U.S. Department of Veterans Affairs, Office of Inspector General

    Government inspection report: clinician orders the EHR could not route went to a queue no one monitored, and patients were harmed. Supports user-harm for EHR systems, where an order that never reaches the lab or specialty service produces no error on screen.

    published 2022-07-14 · verified 2026-10-07

  2. ev-0078regulatorsecondary

    VA Needs to Strengthen Controls to Address Electronic Health Record System Major Performance Incidents, U.S. Department of Veterans Affairs, Office of Inspector General

    The OIG found that VA and Oracle Health did not have adequate controls in place to prevent system changes from causing major incidents, to respond to those incidents when they did occur, and to mitigate their impact.

    Government audit of EHR outages, degradations and incomplete functionality caused by system changes, plus downtime viewers that did not suit every facility. Supports user-harm for EHR systems, where clinicians lose the chart during care after an update.

    published 2024-09-23 · verified 2026-10-07

  3. ev-0081regulatorprimary

    Enforcement Alert, Assistant Secretary for Technology Policy / Office of the National Coordinator for Health IT

    Information blocking enforcement alert: developers of certified health IT that interfere with access, exchange or use of electronic health information face civil money penalties from OIG. Supports regulatory-penalty for EHR systems and for patient portals that sit on certified health IT and must release records to patients and other systems.

    published 2025-09-04 · verified 2026-10-07

  4. ev-0077regulatorsecondary

    Electronic Health Record Modernization Caused Pharmacy-Related Patient Safety Issues Nationally and at the VA Central Ohio Healthcare System in Columbus, U.S. Department of Veterans Affairs, Office of Inspector General

    Government inspection report: a software coding error sent inaccurate medication and allergy information from new EHR sites to legacy EHR sites. Supports data-corruption for EHR systems that exchange medication lists and allergies with another record system.

    published 2024-03-21 · verified 2026-10-07

  5. ev-0079regulatorsecondary

    Deficits with Metrics Following Implementation of the New Electronic Health Record at the Mann-Grandstaff VA Medical Center in Spokane, Washington, U.S. Department of Veterans Affairs, Office of Inspector General

    One year after go-live, gaps existed between required and available metrics using new EHR data.

    Government inspection report: after an EHR go-live, quality, patient safety and accreditation metrics could not be produced from the new data. Supports wrong-decisions for EHR systems whose reports feed quality and safety oversight.

    published 2022-06-01 · verified 2026-10-07

Disclaimer

This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.