EHR and EMR testing services

What actually breaks in an EHR?

Data that goes missing without raising anything. An EHR is where an encounter becomes a record that other people rely on afterwards, so the failures that matter in this class of product are the quiet ones: an allergy that arrived on an inbound message and never reached the chart, a corrected laboratory result that sits beside the original instead of replacing it, a note saved by two clinicians in the same minute where one version wins and neither of them is told. Each of those produces a screen that looks right. The defect is visible only by comparing what was sent with what a clinician can now read, which is a comparison a feature test never makes.

The second family of failures is about the record of the record. Reading a chart is itself an event the system is required to capture, so a build can pass every functional check while the entry that proves who opened the chart is missing, or is written under the service account of the integration engine rather than under the person who clicked. Nothing in the product misbehaves. The evidence is simply not there when someone asks for it, and by then the release that lost it is months old.

The third is context. A records system is worked in several windows at once, with a patient selected in one place and an order written in another, and the binding between the two is held partly by the application and partly by the clinician's attention. When that binding slips, the order is valid, the audit trail is complete, and the entry lands on the wrong person. This is the failure mode behind the usability evidence the certification programme asks for at section 170.315(g)(3), Safety-enhanced design, which requires at least ten test participants and a report that ties each task back to the criterion it belongs to.

Which rules does a record system answer to?

More than one at once, and they do not share a vocabulary. A hospital records system in the United States sits inside three separate regimes, and evidence produced for one of them does not transfer to another without a mapping written by hand.

Provisions of 45 CFR parts 170, 164 and 162 that bind an EHR, each set against what it requires of the record system.

Where the obligation sits	What it binds in an EHR
45 CFR 170.102, Base EHR	The criteria a Health IT Module has to hold before it counts as a Base EHR at all
45 CFR 170.315(d), thirteen privacy and security criteria	Auditable events, audit reports, amendments, automatic access time-out, emergency access, integrity, accounting of disclosures and the rest of the certification security set
45 CFR 164.312, HIPAA technical safeguards	Access control, audit controls, integrity, authentication and transmission security over the same data, judged by a different reader
45 CFR 162.1000(a)	Which release of a code set decides whether a stored diagnosis is valid
45 CFR 170.315(b)(3), electronic prescribing	The transactions a prescription has to be written in, and the unit and decimal rules the field has to enforce

The privacy and security block is the one that surprises a team reading only the HIPAA text. section 170.315(d) runs from (d)(1) through (d)(13) with no gaps, and several of its criteria have no HIPAA counterpart at all: (d)(4) Amendments, (d)(11) Accounting of disclosures and (d)(12) Encrypt authentication credentials are certification requirements drawn up for a records system rather than restatements of a safeguard. The reverse also holds, which is why ONC certification testing requirements and HIPAA testing requirements for software are read side by side when the scope is set, and why a coverage matrix that shows which check answers which criterion is worth building before any of it is run.

Two prescribing rules sit inside the same criterion and are cheap to test. section 170.315(b)(3)(ii)(E) limits a user to prescribing oral liquid medications in metric standard units of mL rather than cc, and (F) requires a zero to be inserted before the decimal point for amounts under one, and forbids a trailing zero after it. Both are properties of a text field, and neither appears in any requirement a product manager writes.

What does an EHR suite have to exercise that a generic one does not?

Five paths, and each of them exists because the record has to survive being questioned later rather than because a user asked for it.

The clinical content itself is the part a functional suite covers well and a regulatory reader looks at last. What separates an EHR test plan from a general application test plan is that every one of the five paths above produces a document rather than a screen, and the document is what gets read in an investigation.

Where do the interface defects concentrate?

At the boundary, because a records system is almost never alone. Registration arrives from one application, results from another, orders leave for a third, and a patient-facing API answers on top of all of it. Each of those is a place where two teams agreed on a specification and one of them tested it.

On the messaging side, the trap is coverage that looks complete. HL7 v2 shares a message structure between trigger events, so ADT_A01 carries A01, A04, A08 and A13, and a suite that exercises the structure once has exercised one of the four events routed through it. Local Z-segments make it worse in the other direction: both applications depend on a field that appears in neither specification, so the traffic works every day in production and fails the first validation run against a profile. The acknowledgement path is usually the thinnest part of a suite, because MSH-15 and MSH-16 are left empty and nothing ever exercises the rejection codes the receiver can return. What ties all three together is where the assertion is made: an interface engine that accepted a message has proved nothing about the chart, so the end of the test is a field a clinician can see. How to test an EHR integration sets out that scope.

On the API side the trap is the opposite: a claim that cannot be failed. FHIR conformance is claimed only for the functionality the served CapabilityStatement declares, so a contract clause reading "supports FHIR" gives a tester no assertion to write. Must Support is the sharpest case of it. R4 flags no element itself and leaves the meaning of support to whoever wrote the profile, so until that author has written down whether support means storing an element, showing it to a user, or acting on it, the criterion has no pass and no fail. Two checks are worth running early on an EHR API: compare the CapabilityStatement the server returns against the endpoints that actually answer, and stop reading the HTTP status from a validation call, since the operation returns success whether or not the resource was valid.

Coded content is the third boundary, and it moves on a calendar the product does not control. A diagnosis is stored once and read for years, so a system that validates against whichever code file is loaded today will reject records that were correct when they were written. ICD-10 code mapping testing requirements sets out the structural rules a validator has to encode; the part that concerns an EHR specifically is that the date of service has to reach the validation call, and that a description copied into a chart at the time of coding can drift from the current one while the code stays valid. All three boundaries are covered by healthcare interoperability testing.

What happens when the record moves in or out?

A migration is a one-way door. Once the source system is decommissioned, the only copy of what a clinician wrote is the one that landed, and a comparison against the original is no longer available to anyone. That changes what the testing has to produce: reconciliation evidence built while both systems are still standing, rather than a defect list gathered afterwards.

The failure that does the most damage is a mapping written as one to one. Code sets are remapped over time, and one current code can stand behind several earlier ones, so a load that stops at the first match discards the others and reports success. Nothing in a row count shows it. It surfaces years later, in a re-coded historical dataset that a clinician reads as fact, which is why the reconciliation is built around clinical meaning instead of record totals. Free text attachments, superseded results and deleted or amended entries each need their own rule, agreed before the load rather than discovered during it.

Migration testing on a records system is therefore scoped from the source query to the rendered chart, and the reconciliation artefacts are the deliverable. Healthcare data migration testing covers how that comparison is structured while both systems are still available.

Where does EHR testing go wrong?

• The suite asserts on the screen and never on the log, so the audit evidence for 164.312(b) and for 170.315(d)(2), (d)(3) and (d)(10) is first read during an investigation.
• Emergency access is written up in a policy and never run against a build, so its behaviour is first observed during the incident it was built for.
• Access control is exercised for human roles only, while the integration accounts and background jobs hold standing access nobody reviews.
• One HL7 message structure is tested and the trigger events sharing it are recorded as covered.
• The FHIR CapabilityStatement is written by hand, drifts from the deployed configuration, and nothing compares the two.
• The current code file is loaded once per environment, so historical records are judged against a release that did not exist when they were written.
• A correction overwrites the value it corrects, so the record shows the current state and no trace of the state it replaced.
• The certification scope is priced from the criteria the team asked for, before section 170.550(g) and (h) attach the dependent ones.
• Migration is verified by comparing row counts, so a mapping that dropped the second and third predecessor of a code passes.
• Test environments are seeded from a production copy, which puts real patient data under a set of controls that environment never inherited.

What do we run against an EHR?

Work starts from the record rather than from the feature list: what enters the chart, from where, who is allowed to read it, what happens when it is corrected, and what evidence each of those events leaves behind. From that map the suite splits into the interface layer, which is tested against a profile or a CapabilityStatement rather than against a prose specification, and the record layer, which is tested by reading the log and the export back out of the system.

Test data is the first decision rather than the last. Registration and results feeds carry patient identifiers, so an EHR suite either runs on generated records or runs under terms agreed in advance. Which of the two applies is decided at the start, under how we work with protected health information. The same question decides whether a defect can be reproduced against a production copy or has to be recreated synthetically.

The certification decision belongs to an ONC-Authorized Certification Body and the compliance position belongs to the organisation that ships the product. What testing produces is the evidence underneath both: a coverage matrix from criterion to check to result, validation reports per interface, audit trail evidence tied to named builds, and reconciliation records for anything that moved.