Open Test Method Development Pilot Program

ONC’s Open Test Method Development Pilot Program builds on our continued commitment to collaborate with health IT stakeholders and to enhance stakeholder engagement in ONC’s Health IT Certification Program. This pilot program is open to all stakeholders willing to contribute their expertise towards the development of the test methods that could ultimately be used by accredited testing laboratories (ATLs) for health IT testing. This pilot program is designed to provide stakeholders with an expanded opportunity to apply their in-the-field experience to test method development (including test procedures, test data, and test tools) to support improvements to the nation’s health care system.

The pilot program will be limited to two 2014 Edition EHR certification criteria and, at its conclusion, will be evaluated for feasibility, efficiency, and scalability relative to future certification criteria editions.

The pilot program will follow the process below and aims to complete the development of two test methods by October 31, 2014


If you have questions about the Open Test Development Pilot Program Email Us

Guidelines
  1. It is acceptable to contribute to only a portion of this test method, e.g. only the test data.
  2. The test method should meet only the requirements of the Final Rule (45 CFR Part 170, September 4, 2012) for the certification criteria.   Conversely, no requirements should be added.
  3. The test procedure should align with the test data and vice versa.
  4. There may or may not be a need for a conformance tool for the test method.
  5. Referenced standards are called out by the Final Rule and cannot be ignored or changed.
  6. Concentrate on the “what” and not the “how.”   That is, do not try to lead the tester through the process in a step-by-step or prescriptive manner.
  7. Do not tie the test method to a particular clinical practice workflow.  (Note:  If you are proposing a test scenario involving multiple unit tests, then clinical practice workflow must be described.  However, do not make the workflow overly specific, thereby making it plausible in only a very restricted and prescribed environment.)
  8. Provide enough detail so that a determination of pass/fail can be made.  That is, make a clear statement of the expected outcome for each step (or group of steps).

  9. There is a distinction between certification criteria that EHR technology must meet to be certified and meaningful use objectives and measures that EPs, EHs, and CAHs must meet.  Certification is granted for meeting adopted certification criteria not meaningful use objectives.

Definitions

Derived Test Requirements - describes a specific portion of the certification criterion which will be addressed in the test procedure. To provide traceability, each is denoted using the following form: DTR [FR certification criterion number] – [Sequence number]

Required Vendor Information - describes the information needed from the Vendor in order to perform the test procedure. To provide traceability, each is denoted using the following form: VE [FR certification criterion number] – [Sequence number] 

Required Test Procedure – describes the test activities required to be performed by the Tester. To provide traceability, each is denoted using the following form: TE [FR certification criterion number] – [Sequence number]

Inspection Guide – provides additional guidance to the Tester on how to evaluate conformance to the certification criterion. To provide traceability, each is denoted using the following form: IN [FR certification criterion number] – [Sequence number]

Test Story – an English language description of a clinical situation that gives context to the test data.  It can describe the patient-physician interactions or the physician-lab interactions, for instance.  They may be very simple and short or long and complex.

Test Method Template

 

 

  • No labels