EHR Real World Testing Plan 2022
Professional Imaging PI EMR v2.0
Real World Testing Plan - 2022
Justification for Real World Testing Approach
The overall approach for our Real World Testing includes extraction and analysis of data on ongoing activity and simulated testing where there is no ongoing use of relevant certified functionality.
The PI EMR v2.0 Certified Health IT Module is self-developed. It is not available for sale. It is only used by Professional Imaging LLC and its affiliates. As a self-developer with a very narrow practice scope, resources for implementing RWT must, by necessity, be limited to mitigate negative financial impact.
The care setting in which this module is used is an ambulatory interaction with Nursing Facilities. For some of the criteria covered in the Real World Testing plan, testing will be conducted using simulated environments utilizing a pass/fail metric due to the absence of real world use. The affected criteria in this regard are those related to Care Coordination, Public Health, Application Program Interfaces and Electronic Exchange. As there is no ongoing activity in these cases, it is not possible to measure ongoing compliance.
The circumstances for this are as follows:
· As yet, no Nursing Facilities have requested use of the interoperability functionality being tested. This is due to the fact that Nursing Facilities are not required to use an EHR as doing so is not seen as a benefit.
· No Nursing Facility, patient, patient representative or providing clinician has ever requested access to our API.
· We are either unqualified for or unable to (due to unavailability of agencies prepared to receive the data) perform the activities covered by criteria related to Transmission to public health Agencies.
In the cases mentioned above, our Real World Testing approach measures success through demonstrating conformance and interoperability through simulated testing. Testing will be conducted to confirm and document that each data point transmitted and received is accurate and complete as required by the relevant certification criteria.
For certified functionality that we do have ongoing activity, the records of that activity will be analyzed regarding the successful transmission and receipt of relevant information. Documentation of that analysis will be provided.
The RWT plan may also utilize data transfer with an affiliate practice. The affiliate practice, which provides the same type of specialized service as Professional Imaging, has been selected due to their ongoing relationship with our practice and their availability for this testing.
Where applicable, several certification criteria may be tested simultaneously.
ANTICIPATED PLAN UPDATES: We are currently working on integrating an ONC certified EHR from an outside vendor to work in conjunction with PI EMR 2.0. One of the goals of this effort is to replace modules related to interoperability in PI EMR 2.0 with the corresponding modules in the outside vendor's EHR. This process is occurring much more quickly than originally anticipated. It now appears very likely that we will complete this transition by January 1, 2022. The modules that are being replaced include all of those being tested in our RWT plan. Thus, our RWT plan may not be applicable for 2022 as we will be relying on the outside vendor's CEHRT. Of course, in the event any of the functions covered by our RWT plan need to remain operational beyond 1/1/2022, we will conduct testing and reporting for those functions per this plan.
Criteria to be Tested
· § 170.315(b)(1) Transitions of care
· § 170.315(b)(2) Clinical information reconciliation and incorporation
· § 170.315(c)(1) Record and export
· § 170.315(c)(2) Import and calculate
· § 170.315(c)(3) Report
· § 170.315(e)(1) View, download, and transmit to 3rd party.
· § 170.315(f)(2) Syndromic surveillance
· § 170.315(f)(7) Health care surveys
· § 170.315(g)(7) Application access— patient selection R
· § 170.315(g)(8) Application access— data category request
· § 170.315(g)(9) Application access— all data request
· § 170.315(h)(1) Direct Project
Schedule of Key Milestones
· 1Q-2022: Begin communication with affiliate practice to schedule participation in real-world testing.
· 2Q-3Q 2022: During the 2nd and 3rd quarter, real world testing will be scheduled and performed. It is expected that a preparatory call will be made with the affiliate practice to prepare them for testing activities. Capture and analysis of data relevant to functionality will be conducted. Test results will be documented and ultimately used to build the test report. If any non-compliances are observed, we will notify the ONC-ACB of the findings and make the necessary changes required.
· 4Q-2022: During the last quarter of the year, the CY 2023 real-world test plan will be completed according to ONC and ONC-ACB requirements and expectations. The test plan will be prepared and submitted per the deadline requirements.
· February 2023: Document our CY 2022 test results into our RWT Test Report and submit to our ONC-ACB.
Care Coordination
The following outlines the measure that has been identified to best demonstrate conformance to the certification criteria concerning Care Coordination (170.315(b)(1) and 170.315(b)(2)).
Measure Description
The metric used for testing functionality covered by these criteria is the successful secure transmission, receipt, re-incorporation and data verification of the required transition of care documentation.
Measure Justification
The stated metric was selected as it provides full testing of the functionality.
Expected Outcome
The expected outcome is that the data transmitted will be identical with that of the data received. This will be confirmed by the reconciliation process covered under (b)(2) and the received data is successfully imported and applied to the target patient.
Test Methodology
· Step 1: Generate a CCDA R2.1 file for a test patient containing problems, medications and allergies at an affiliate practice. Transmit the generated file over a secure network to the primary practice using PI EMR v2.0 and use the PI EMR v2.0 patient reconciliation process to import the patient and all problems, medications and allergies for the patient.
· Step 2: Generate a second CCDA R2.1 file for the same patient at the affiliate practice and include new and modified problems, new and modified medications and new and modified allergies. Then transmit the generated file over a secure network to the primary practice and use the PI EMR v2.0 patient reconciliation process to import the revised problems, medications and allergies.
Clinical Quality Measures
The following outlines the measure that has been identified to best demonstrate conformance to multiple certification criteria concerning Critical Quality Measures (170.315(c)(1), 170.315(c)(2) and 170.315(c)(3).
Measure Description
This measure is tracking and counting how many eCQM quality measures were successfully reported on by the EHR Module to CMS during their submission period for our MIPS Quality reporting.
Measure Justification
This measure will provide a count and list of electronic clinical quality measures (eCQMs) which are calculated and submitted to CMS for MIPS. Clinical quality measures are only transmitted for MIPS submissions. Because CQM criteria, 315(c)(1)-(c)(3), all work collectively together in the eCQM functionality of the EHR Module, this measurement is used for all three.
Expected Outcome
The measurement will count and list of CQMs submitted to CMS for MIPs during 2022. We will report on the number CQMs successfully reported on to CMS which reveals compliance to the associated criteria listed above. A successful measure submission indicates compliance to the underlying ONC criteria. It will show that the EHR can do calculations on the CQM and that they are accepted by CMS. Successfully completing this measure also confirms general understanding of the EHR functional operations for this EHR Module and an overall support for the user experience while not completing this measure may indicate lack of understanding or possibly lack of use or need for this functionality. We will use the measure result to establish a historic baseline of expected interoperability use so it can be used in subsequent real world testing efforts.
Test Methodology
Analysis of use logs associated with transmission of CQM data to CMS for MIPS. In addition, for QRDA category I data, we will import the data sent to CMS (using PI EMR v2.0) to a test database and confirm that all intended patient data has been successfully transmitted.
Patient Engagement
The following outlines the measure that has been identified to best demonstrate conformance to the certification criteria concerning Patient Engagement (170.315(e)(1)).
Measure Description
This use case is tracking and counting how patients are given access to their portal account over the course of the reporting period.
Measure Justification
This use case measure will provide a numeric value to indicate both the how often this interoperability feature is being used as well as its compliance to the requirement. An increment to this measure indicates that the EHR can create a new patient portal account and give the patient access to it. A survey can often provide more information on the impact and value of an interoperability element than a standard software test evaluation. The patient portal is intended to support patient engagement with their health records and the ability to transmit their patient data as a C-CDA or human readable copy.
Expected Outcome
We will get reporting values on patient portal access as well as patients use of the portal’s interoperability features. Measure #1: Report the number of new patient accounts created over a three (3) month period. The measurement will produce numeric results over a given interval. We will utilize various reports and audit logs to determine our measure count. A successful measure increment indicates compliance to the underlying ONC criteria.
Testing Methodology: Analysis of use logs for Patient Portal for viewing, downloading and transmission of patient data.
Public Health –
The following outlines the measure that has been identified to best demonstrate conformance to the certification criteria concerning Transmission to Public Health Agencies (170.315(f)(2) and 170.315(f)(7).
Measure Description
The metric used for testing functionality covered by these criteria is the successful secure transmission, receipt, verification and processing of the required public health data.
Measure Justification
The stated metric was selected as it provides full testing of the functionality.
Expected Outcome
The expected outcome is that the data transmitted will be identical with that of the data received and the data will be successfully processed by the receiving entity. This will be confirmed by the validation websites.
Test Methodology -
· f2: Generate NIST HL7v2 Syndromic Surveillance xml files for a representative sample of synthetic patient data based on our actual patient cases. This process may produce as many as 30 synthetic patient files. Confirm the accuracy and completion of these test files then use the NIST HL7v2 Syndromic Surveillance validation website for validation.
· f7: generate a NHCS xml survey file for a representative sample of synthetic patient data based on our actual patient cases. This process may produce as many as 30 synthetic patient files. Confirm the accuracy and completion of these test files, then use the NHCS validation website to validate the generated xml test files.
Application Programming Interfaces
The following outlines the measure that has been identified to best demonstrate conformance to the certification criteria concerning APIs (170.315(g)(7), 170.315(g)(8) and 170.315(g)(9).
Measure Description
The metric used for testing functionality covered by these criteria is the successful secure retrieval and verification of the applicable data by a simulated patient.
Measure Justification
The stated metric was selected as it provides full testing of the functionality.
Expected Outcome
The expected outcome is that the data received by the simulated patient will be identical with that of the data transmitted. This will be confirmed by the comparison between the data sets.
Testing Methodolgy -
A test application will be created that implements the PI EMR v2.0 API protocol. This application will be used to access the PI EMR v2.0 API and download test patient data file for a representative sample of synthetic patient data based on our actual patient cases. Files will be downloaded both by 1) data category, and 2) as an entire CCDA R2.1 file. This process may produce as many as 30 synthetic patient files. The respective downloaded files will then be reviewed for accuracy and completion.
Electronic Exchange
The following outlines the measure that has been identified to best demonstrate conformance to the certification criteria concerning Electronic Exchange (170.315(h)(1)).
Measure Description
The metric used for testing functionality covered by these criteria is the successful secure retrieval and verification of the applicable data for a simulated patient.
Measure Justification
The stated metric was selected as it provides full testing of the functionality.
Expected Outcome
The expected outcome is that the data received by the simulated patient will be identical with that of the data transmitted. This will be confirmed by the comparison between the data sets.
Testing Methodolgy -
Send 2 Direct messages to a test Direct address, one message with an attachment and one with no attachment. Then we will recover the Direct message replies to these messages, again one with an attachment and one with no attachment. This will be done by sending the message to a HISP provider test address then verifying the contents of the received messages on the HISP provider user website match our EHR.
Authorized Representative Name: Michael Goforth
Authorized Representative Email: mike@proimagetx.com
Authorized Representative Phone: 360-359-3690
Authorized Representative Signature:
Date: October 5, 2021