Real World Testing is an annual requirement in the ONC 21st Century Cures Act Final Rule under which certified health IT developers publicly document how their software actually performs in live clinical settings — not in a lab. The plans and results are posted on the Certified Health IT Product List, which means you can read your shortlisted vendor's own account of how its product behaves in production before you sign anything. It is one of the few genuinely independent, public, free artifacts available to an EHR buyer. It is also, as of 2026, partially suspended by an ONC enforcement discretion notice, which is exactly the kind of detail worth knowing before you go looking for a document that may not be there.
What Real World Testing is
ONC describes it plainly. Real World Testing is “an annual requirement outlined in the ONC 21st Century Cures Act Final Rule for all health IT developers participating in the ONC Health IT Certification Program.” It is a Condition and Maintenance of Certification requirement, which means it is part of what a developer must keep doing to keep its certification — not a one-time hurdle cleared at launch.
The stated purpose is “for Certified Health IT Developers to demonstrate interoperability and functionality of their certified health IT in real world settings and scenarios, rather than in a controlled test environment with an ONC-Authorized Testing Lab.”
The mechanism is observation. ONC: Real World Testing “verifies that deployed Certified Health IT continues to perform as intended by conducting and measuring observations of interoperability and data exchange. These observations are described in a public and transparent way through Real World Testing plans and reported as Real World Testing results.”
Two documents, then. A plan saying what the developer intends to measure, and a results report saying what it found.
Why it is different from certification testing
This distinction is the entire value of the artifact, and it maps onto a frustration most EHR buyers already have.
Certification testing happens in a controlled environment with an ONC-Authorized Testing Laboratory. A product demonstrates that it can do the thing, under conditions arranged for it to succeed. That is a real and useful bar, and it is also the bar that produces the familiar experience of buying certified software and then discovering that the certified capability behaves differently once it meets your actual referral partners, your actual lab, and your actual data.
Real World Testing is aimed squarely at that gap. It asks the developer to observe and measure the capability in deployment and to publish what it saw. The word ONC uses is continues — verifying that deployed certified health IT continues to perform as intended. It is a statement about sustained behavior, not about a demonstration.
Where to find it
The Certified Health IT Product List, at chpl.healthit.gov. ONC calls it “a comprehensive and authoritative listing of successfully tested and certified health IT modules.”
The publication schedule ONC states:
| Document | Public on the CHPL by |
|---|---|
| Real World Testing plan | December 15, annually |
| Real World Testing results | March 15 of the subsequent year |
ONC adds that certified health IT developers should consult their ONC-Authorized Certification Body about deadlines for submitting their plans and results. The ONC-ACB is the body that certifies the module and receives the submissions; the CHPL is where the public sees them.
For a buyer the workflow is simple: look up the product on the CHPL, and read what the developer wrote about its own product for a regulator. It is a different genre from a sales deck, and it reads like one.
What changed: ONC's enforcement discretion
This is the part that will save you a confused afternoon, and it is current as of ONC's Real World Testing page, last updated April 9, 2026.
Specifically, per ONC:
- For calendar year 2025, a developer “is not expected to submit an annual Real World Testing plan to its ONC-Authorized Certification Body (ONC-ACB) for the 2026 Real World Testing year.”
- For calendar year 2026, ONC “only expects a developer with a Health IT Module(s) certified to the (g)(7) through (10) certification criteria, as of August 31, 2024, to submit a CY 2025 Real World Testing results report to its ONC-ACB by March 2026.”
- Duration: the enforcement discretion “will be in effect immediately, and will remain in effect until December 31, 2026, or until the Department of Health and Human Services completes deregulatory action, whichever comes first.”
What that means for you as a buyer, stated carefully:
- A missing 2026 plan is not evidence of a bad vendor. If you go to the CHPL and find no current plan, the most likely explanation is the enforcement discretion, not negligence. Do not score a vendor down for it.
- Historical plans and results still exist and are still informative. The requirement has been running for several years. Prior-year documents remain the best public record of how the product behaved in the field.
- The narrowed 2026 results expectation is worth knowing precisely. It applies to developers with modules certified to the API criteria at (g)(7) through (10) as of August 31, 2024. If your shortlisted vendor is in that group, a CY 2025 results report was expected by March 2026 and it is fair to ask about it.
- This is a moving target with a stated end. ONC has tied it to December 31, 2026 or the completion of deregulatory action. Anyone quoting the pre-2025 rules as current, or treating the requirement as permanently gone, is working from a stale reading. Check the ONC page rather than an article — including this one.
Which criteria it covers
Real World Testing does not apply to every certification criterion. ONC publishes the list, and it is worth knowing because it tells you which capabilities the regime is designed to keep honest:
- Care coordination — transitions of care; clinical information reconciliation and incorporation; electronic prescribing; real-time prescription benefit; security tags for summary of care, send and receive; care plan; electronic health information export; decision support interventions.
- Clinical quality measures — record and export; import and calculate; report.
- Patient engagement — view, download, and transmit to 3rd party.
- Public health — transmission to immunization registries; syndromic surveillance; reportable laboratory tests and values; cancer registries; electronic case reporting; antimicrobial use and resistance reporting; health care surveys.
- Application programming interfaces — application access for patient selection; all data request; standardized API for patient and population services; and the provider prior authorization API criteria.
- Electronic exchange — Direct Project; Direct Project with Edge Protocol and XDR/XDM.
- Modular API capabilities — workflow triggers for decision support interventions (client); subscriptions (client).
Notice the pattern: these are overwhelmingly the criteria where the software has to talk to something outside itself. That is exactly where lab conditions are least representative and where a buyer is most likely to be disappointed. It is a sensibly drawn list.
The flip side is the caveat: a capability that matters enormously to you — documentation ergonomics, scheduling, billing workflow — is likely nowhere in a Real World Testing plan. Its absence from the plan says nothing about the product.
How to read a plan or results report as a buyer
These documents are written for a certification body, which is good for you: nobody was trying to sell anything when they wrote them.
- Check the care settings. A plan describes where the developer observed the product. If a product was measured only in settings unlike yours, its results are less transferable to your practice.
- Look for the measures, not the adjectives. The requirement is about “conducting and measuring observations.” A report with numbers in it is doing the job. A report of reassurance is not.
- Read the exceptions and the known issues. This is the highest-value section in the document and the one you will never see in a demo. A developer documenting where exchange failed is telling you what the product's hard edges are.
- Compare across your shortlist. Because the format is standardized — ONC publishes plan and results report templates — two vendors' documents are more comparable to each other than any two sales decks will ever be.
- Match it to your actual exchange partners. If your referral network runs on a particular pathway, look for observations on that pathway specifically.
What it does not tell you
Being fair to the artifact means being clear about its limits.
The developer chooses its own measures and writes its own report. This is self-reported data submitted to a certification body, not an independent audit conducted by ONC. It is more accountable than marketing and less rigorous than an inspection, and it should be read as the former with the latter's absence in mind.
It also covers only the certified capabilities on ONC's applicable-criteria list. It is silent on usability, on support responsiveness, on uptime, on price, and on whether your clinicians will tolerate the note templates. Those questions need other methods.
And right now, under the enforcement discretion, the most recent documents may simply not exist. That is a gap in your evidence, not a finding about a vendor.
The bottom line
Real World Testing is a free, public, standardized, regulator-directed account of how a certified EHR behaves outside the lab. For the interoperability capabilities that decide whether your practice can actually exchange data with the people it needs to exchange data with, it is the best public evidence available, and remarkably few buyers ever open it.
Go to the CHPL, look up your shortlist, and read the last few years of plans and results. Then ask the vendor about the gaps you find. Just do it knowing that the 2026 picture is thinner than prior years by design, and that the thinness is ONC's decision rather than your vendor's.
Common questions
What is Real World Testing for certified EHRs?
Real World Testing is an annual requirement in the ONC 21st Century Cures Act Final Rule for health IT developers participating in the ONC Health IT Certification Program. It is a Condition and Maintenance of Certification requirement. Its purpose is for certified health IT developers to demonstrate the interoperability and functionality of their certified health IT in real world settings and scenarios, rather than in a controlled test environment with an ONC-Authorized Testing Laboratory. ONC describes it as verifying that deployed certified health IT continues to perform as intended by conducting and measuring observations of interoperability and data exchange.
Where can I find a vendor's Real World Testing plan and results?
On the Certified Health IT Product List at chpl.healthit.gov. ONC states that to comply with the requirements, Real World Testing plans should be made publicly available on the CHPL annually on December 15, and results should be publicly available on the CHPL on March 15 of the subsequent year. Developers are directed to consult their ONC-Authorized Certification Body about submission deadlines. The CHPL is the authoritative public listing of certified health IT modules, so it is the right place to check a claim rather than taking a vendor's word for it.
Has ONC changed the Real World Testing requirements?
Yes. ONC is exercising enforcement discretion on certain Real World Testing requirements in accordance with Executive Order 14192, Unleashing Prosperity Through Deregulation, to reduce regulatory burden for certified health IT developers. For calendar year 2025, a developer is not expected to submit an annual Real World Testing plan to its ONC-Authorized Certification Body for the 2026 Real World Testing year. For calendar year 2026, ONC only expects a developer with Health IT Modules certified to the (g)(7) through (10) certification criteria, as of August 31, 2024, to submit a CY 2025 Real World Testing results report to its ONC-ACB by March 2026. ONC states the enforcement discretion is in effect immediately and remains in effect until December 31, 2026, or until HHS completes deregulatory action, whichever comes first.
Does Real World Testing apply to every certification criterion?
No. ONC publishes a specific list of applicable criteria. It spans care coordination criteria such as transitions of care and electronic prescribing, clinical quality measures criteria, the view download and transmit to 3rd party criterion, public health criteria such as immunization registry and syndromic surveillance transmission, application programming interface criteria including the standardized API for patient and population services, electronic exchange criteria such as Direct Project, and modular API capabilities. Criteria outside that list are not subject to the Real World Testing requirement, so a product can be certified without every one of its capabilities appearing in a Real World Testing plan.