888.455.0855
Menu
InPracSys Real World Test Plans and Results Reports
Plan ReportID Number: 20241114ips
Developer Name: InPracSys
Product Name(s): InPracSys EHR
Version Number(s): 9.0
Product List (CHPL) ID(s): 15.05.05.2762.INPS.01.00.1.191206
Developer Real World Testing Page URL: https://inpracsys.com/rwt/
Real world testing will begin using 1 representative clinic that agrees to all criteria that are included in the requirement list for RWT. If some criteria or criterion remain unused by the testing clinic, InPracSys will perform that part of the test at InPracSys Lab.
Clinic’s real data will be used for performing each test using queries and dynamically presented as counts of successes and failure or screen available to authorized users. The data presented will also be benchmarked against InPracSys internal benchmark for expected results and acceptable failure rates to ensure continued success. All failures will be documented and used for process improvement and/or training of clinic staff.
All tests will be carefully aligned to meet criteria’s requirements and technical outcomes.
Should, for any reason, the clinic has not used one or more functions, for their own reasons, e.g. Transmission to Public health agencies, we plan on running the tests manually a few times during the calendar year(s) to ensure continuing functionality thru the year(s) of the unused functions.
There are no voluntary SVAP standards updates.
Measurement/Metric | Description |
Transitions of Care – Create | Using data query, Count of referral summaries created, during the measurement period |
Transitions of Care – Conformance | Use CMS validator API to Automatically test a Random sampling of messages created during the measurement period to ensure at a minimum that messages meet the Release, content and PT matching criteria |
Transitions of Care Receive | Using data query, Count of referral summaries received during the measurement period grouped by status (valid/invalid) AND “grouped by” containing XDM package |
Transitions of Care Display | Using data query, count of referral summaries received and successfully displayed, during the measurement period |
Transitions of Care Display section order | Using data query, count of referral summaries displayed where the display order was changed by the user |
Clinical information reconciliation and incorporation | Using data query, Count of reconciliations, during the measurement period, where the auto-matched PT flag is set to true, and occurred from the side-by-side display page |
Electronic prescribing | Count of prescriptions successfully transmitted, during the measurement period, where the units are in mL and where the Qty is set to 0.XX where XX is any numeric value |
Health Information Export | Enable a user to timely create an export file(s) with all of a patient’s electronic health information |
Clinical quality measures (CQMs) – record and export | Using data query, count of patients, in measurement period, where the criteria is met or where the patients fall in exclusions, with coded exclusion reason, for all certified CQMs, and where data was successfully exported |
VDT – View | Using data query count of patients who viewed their data including complete common clinical data set, lab reports and Dx reports, containing provider name/contact, in human readable format, for one or more date ranges during the measurement period. |
VDT – download and Transmit | Using data query count of patients who downloaded or transmitted their data including complete common clinical data set, lab reports and Dx reports containing provider name/contact, for one or more date ranges, during the measurement period. |
VDT – Activity Logging | Using data query generate a list of top 10 patients/reps who, during the measurement period, viewed, downloaded, and/or transmitted their data including the user (patient/rep) who performed the action and NTP timestamp when the action was performed |
Creation of syndromic surveillance messages | Using data query, count of Syndromic Surveillance messages created by staff as needed, per HL7 2.5.1 standard, during the measurement period. |
Transmission to public health agencies
| Using data query count eligible cases when a trigger is matched in accordance with provision (f)(5)(ii), where the Health IT Module created a case report with only the required subset of data elements, during the measurement period |
Application access — patient selection (Success) | Using data queries, count the number of successful requests for patient data, where the request resulted in successful generation of a token and data exchange, during the measurement period |
Application access — patient selection (failure) | Using data queries, count the number of failed requests for patient data during the measurement period, where a successful token was not issued and no data was exchanged. |
Application access — all data request
| Using data queries count of data requests specifying all categories. requested during the measurement period, where the request resulted in successful generation of a token and subsequent data exchange. |
Standardized API for patient and population services | Using standardized API technology well documented used for data response, supported search operations, secure connections with authentication and authorization and with authorization revocation |
Direct Project – Stored addresses
| Using data query, count the direct addresses entered and stored in the health IT module, grouped by binding (domain/Address) and hosting (DNS and LDAP), during the measurement period |
Direct Project – Wrapped message success | Using data query, count the wrapped messages successfully transmitted to third parties during the measurement period |
Measurement/Metric | Associated Certification Criteria | Relied on |
Transitions of Care – Create | 170.315(b)(1) Transitions of Care | EMR Direct |
Transitions of Care – Conformance | 170.315(b)(1) Transitions of Care | EMR Direct |
Transitions of Care Receive | 170.315(b)(1) Transitions of Care | EMR Direct |
Transitions of Care Display | 170.315(b)(1) Transitions of Care | EMR Direct |
Transitions of Care Display section order | 170.315(b)(1) Transitions of Care | EMR Direct |
Clinical information reconciliation and incorporation | 170.315 (b)(2) Clinical information reconciliation and incorporation | EMR Direct |
Electronic prescribing | 170.315 (b)(3) Electronic prescribing | Dosespot |
Health Information Export | 170.315(b)(10) Electronic Health Information export | NA |
Clinical quality measures (CQMs) — record and export | 170.315(c)(1) Clinical quality measures (CQMs) — record and export | NA |
VDT- View | 170.315(e)(1) View, download, and transmit to 3rd party | NA |
VDT- download and transmit | 170.315(e)(1) View, download, and transmit to 3rd party | NA |
VDT – Activity Logging | 170.315(e)(1) View, download, and transmit to 3rd party | NA |
Creation of syndromic surveillance messages | 170.315(f)(2) Transmission to public health agencies — syndromic surveillance | NA |
Transmission to public health agencies | 170.315(f)(5) Transmission to public health agencies — electronic case reporting | NA |
Application access — patient selection Success | 170.315(g)(7) Application access — patient selection | NA |
Application access — patient selection failed | 170.315(g)(7) Application access — patient selection | NA |
Application access — all data request | 170.315(g)(9) Application access — all data request | NA |
Standardized API for patient and population services | 170.315(g)(10) Standardized API for Patient and Population Services (Cures update) | NA |
Direct Project – Stored addresses | 170.315(h)(1) Direct Project | EMR Direct |
Direct Project – Wrapped message success | 170.315(h)(1) Direct Project
| EMR Direct |
Measurement/Metric | Justification |
Transitions of Care – Create | Counts of valid documents created during the measurement period, demonstrates that the Health IT is working as expected and certified |
Transitions of Care – Conformance | Counts of conforming documents created during the measurement period, demonstrates that the Health IT is working as expected and certified |
Transitions of Care Receive | Counts of invalid and /or valid documents received during the measurement period, demonstrates the ability of the IT to detect valid/invalid documents |
Transitions of Care Display | Counts of documents demonstrates the ability of the IT to handle display |
Transitions of Care Display section order | Our technology is able to save the display preferences of the application. Counting the number of times this activity took place, during the measurement period demonstrates functionality. |
Clinical information reconciliation and incorporation | Our technology automatically matches the patient to the ToC and has the user verify the match and sets the auto-match flag true. Counting cases that the flag is set to true, and the page the action was performed on, during the measurement period, demonstrates that the product is working as expected. |
Electronic prescribing | Getting counts of prescriptions, during the measurement period, that were successfully received by the service provider and not rejected, that contained units in mL as well as quantity, demonstrates this function. |
Health Information Export | Enable a user to timely create an export file(s) with all of a single patient’s electronic health information stored in the EHR. |
Clinical quality measures (CQMs) — record and export
| Reports of patients by the CQM including status (Met, Unmet and Exclusion, with reason medical, Patient, System) demonstrates that the Health IT is working as expected and certified for this function. |
VDT – View | Counts of occurrence(s) during the measurement period demonstrate that the function is working as expected for viewing data. |
VDT – download and Transmit | Counts of occurrence(s) during the measurement period demonstrate that the function is working as expected for downloading or transmitting data |
VDT – Activity Logging | Counts of occurrence(s) during the measurement period demonstrate that NTP time stamp and user activity logging is working. |
Creation of syndromic surveillance messages | Since our technology validates messages on creation, getting counts demonstrates that the function is working. |
Transmission to public health agencies | Counts of eligible cases generated and transmitted during the measurement period illustrates that this function is working. |
Application access — patient selection Success
| If we receive, validate the request, issue a token that is used subsequently for data exchange, we demonstrate that this function is working and our documentation is on point. |
Application access — patient selection failed
| If we receive, validate the request, do not issue a token if the request is not to syntax, we demonstrate that this function is working and documentation is on point, but the requester made an error. |
Application access — all data request | If we receive, validate the request, issue a token that is used subsequently for data exchange, we demonstrate that this function is working and documentation is on point. |
Standardized API for patient and population services | On receiving requests through search under a secure connection, we authenticate and check pt authorization by token received in an API |
Direct Project – Stored addresses | Storing direct addresses to the database during the measurement period demonstrates this function |
Direct Project – Wrapped message success | Counting wrapped messages transmitted during the measurement period demonstrates this function |
Care Setting | Justification |
Ambulatory Medical Clinic | Ambulatory Medical Clinic (Urology Clinics) |
| Measurement/Metric | Expected Outcomes |
| Transitions of Care as – Create | EMR will be queried, using SQL, for messages created successfully with no errors |
| Transitions of Care – Conformance | EMR will be queried, using SQL, for messages created successfully with no errors and conforming to the requirements |
| Transitions of Care Receive | EMR will be queried, using SQL, to ensure that the messages are successfully received, reconciled and data incorporated with no errors |
| Transitions of Care Display | EMR will be queried, using SQL, to ensure that the messages are successfully received and displayed |
| Transitions of Care Display section order | EMR will be queried, using SQL, to ensure that the messages are successfully received, order of sections displayed with no errors |
| Clinical information reconciliation and incorporation | EMR will be queried, using SQL, to ensure that the messages are successfully reconciled, and data incorporated with no errors. |
| Electronic prescribing | EMR will be queried, using SQL, to ensure that the prescriptions in the measure were successfully transmitted and acknowledged by the recipient service provider. |
| Electronic Health Information Export | EMR will be queried, using SQL, to ensure that Data is successfully exported and a file is created for a selected patient with all of the patient health information |
| Clinical quality measures (CQMs) — record and export | EMR will be queried, using SQL, to ensure that Data is successfully exported and error free. |
| VDT – View | EMR will be queried, using SQL, to ensure that Data is successfully viewed and error free |
| VDT – Download and Transmit | EMR will be queried, using SQL, to ensure that Data is successfully downloaded or transmitted and error free |
| VDT – Activity Logging | EMR will be queried, using SQL, to ensure that Data is viewed, successfully downloaded or transmitted, contains user and timestamp. |
| Creation of syndromic surveillance messages | EMR will be queried, using SQL, to ensure that messages are successfully created to HL7 2.5.1 standard and there were no errors. |
| Transmission to public health agencies | EMR will be queried, using SQL, to ensure that messages are successfully transmitted without errors. |
| Application access — patient selection Success | EMR will be queried, using SQL, to ensure that greater than 99% of the requests made per Health IT’s documentation, resulted in the successful issue of a token and patient selection succeeded. |
| Application access — patient selection failed | EMR will be queried, using SQL, to ensure that greater than 99% of the requests made per Health IT’s documentation, resulted in successful issue of a token and patient selection failed. |
| Application access — all data request | EMR will be queried, using SQL, to ensure that greater than 99% of the requests made per Health IT’s documentation, resulted in successful issue of a token and exchange of data for the requested parameters. |
| Standardized API for patient and population services | Respond to requests for a single/multiple patient’s data or as a data group according to the standard adopted and consistent with the search criteria Enable an application to register with the Health IT Module’s “authorization server”. Establish a secure and trusted connection. Authentication and Authorization must happen for the patient, EMR will be queried, using SQL, to ensure authentication and authorization success. |
| Direct Project – Stored addresses | EMR will be queried, using SQL, to ensure that greater than one each of address and domain bound Direct addresses are stored without errors. |
| Direct Project – Wrapped message success | EMR will be queried, using SQL, to ensure that messages are successfully sent to third parties. |
For each key milestone, describe when Real World Testing will begin in specific care settings and the date/timeframe during which data will be collected.
Key Milestone | Care Setting | Date/Timeframe |
Complete RWT Development | Ambulatory Medical Clinic | Oct 30 2024 |
Test RWT plan | Ambulatory Medical Clinic | Dec 15 2025 |
Implement RWT Plan | Ambulatory Medical Clinic | Jan 5 2025 |
Report Results to SLI | Ambulatory Medical Clinic | Jan 15 2026 |
This Real World Testing plan is complete with all required elements, including measures that address all certification criteria and care settings. All information in this plan is up to date and fully addresses the health IT developer’s Real World Testing requirements.
Authorized Representative Name: Ashu Kataria
Authorized Representative Email:Ashu.Kataria@inpracsys.com
Authorized Representative Phone: 612-455-6789
Authorized Representative Signature: Digitally Signed Ashu Kataria for InPracSys
Date: 11/12/2024
Under the ONC Health IT Certification Program (Program), health IT developers are required to conduct Real World Testing of their certified health IT (45 CFR 170.405). The Office of the National Coordinator for Health Information Technology (ONC) issues Real World Testing resources to clarify health IT developers’ responsibilities for conducting Real World Testing, to identify topics and specific elements of Real World Testing that ONC considers a priority, and to assist health IT developers in developing their Real World Testing plans.
Plan ReportID Number: 20231201ips
Developer Name: InPracSys
Product Name(s): InPracSys EHR
Version Number(s): 9.0
Certified Health IT: Yes
Product List (CHPL) ID(s): 15.05.05.2762.INPS.01.00.1.191206
Developer Real World Testing Page URL: https://inpracsys.com/rwt/
Real world testing will begin using 1 representative clinic that agrees to all criteria that are included in the requirement list for RWT. If some criteria or criterion remain unused by the testing clinic, InPracSys will perform that part of the test at InPracSys Lab.
Clinic’s real data will be used for performing each test using queries and dynamically presented as counts of successes and failure or screen available to authorized users. The data presented will also be benchmarked against InPracSys internal benchmark for expected results and acceptable failure rates to ensure continued success. All failures will be documented and used for process improvement and/or training of clinic staff.
All tests will be carefully aligned to meet criteria’s requirements and technical outcomes.
If, for any reason, the test clinic has not used one or more functions, for their own reasons, e.g., Transmission to Public health agencies, we plan on running the tests manually a few times during the calendar year(s) to ensure continuing functionality thru the year(s) of the unused functions.
| Standard (and version) | USCDI v1 |
| Updated certification criteria and associated product | b1, b2, e1, f5, g9 |
| Health IT Module CHPL ID | 15.05.05.2762.INPS.01.00.1.191206 |
| Method used for standard update | Cures Update |
| Date of ONC-ACB notification | 12/29/2022 |
| Date of customer notification (SVAP only) | NA |
| Conformance measure |
|
| USCDI-updated certification criteria (and USCDI version) | USCDI version 1 – b1, b2, e1, f5, g9 |
Each plan must include at least one measurement/metric that addresses each applicable certification criterion in the Health IT Module’s scope of certification. Describe the method for measuring how the approach(es) chosen meet the intent and purpose of Real World Testing.
For each measurement/metric, describe the elements below:
Describe the measure(s) that will be used to support the overall approach to Real World Testing.
| Measurement/Metric | Description |
| Transitions of Care as CCDA – Create | Using data query, Count of C-CDA referral summaries created, formatted to release 2.1, during the measurement period |
| Transitions of Care CCDA – Conformance | Use CMS validator API to Automatically test a Random sampling of messages created during the measurement period to ensure at a minimum that messages meet the Release, content and PT matching criteria |
| Transitions of Care CCDA Receive | Using data query, Count of C-CDA referral summaries received during the measurement period grouped by status (valid/invalid) AND “grouped by” containing XDM package |
| Transitions of Care CCDA Display | Using data query, count of referral summaries received and successfully displayed, during the measurement period, “grouped by” CCD release (1.1, 1.2) |
| Transitions of Care CCDA Display section order | Using data query, count of referral summaries displayed where the display order was changed by the user |
| Clinical information reconciliation and incorporation | Using data query, Count of reconciliations, during the measurement period, where the auto-matched PT flag is set to true, and occurred from the side-by-side display page |
| Electronic prescribing | Count of prescriptions successfully transmitted, during the measurement period, where the units are in mL and where the Qty is set to 0.XX where XX is any numeric value |
| Health Information Export | Enable a user to timely create an export file(s) with all of a patient’s electronic health information |
| Clinical quality measures (CQMs) – record and export | Using data query, count of patients, in measurement period, where the criteria is met or where the patients fall in exclusions, with coded exclusion reason, for all certified CQMs, and where data was successfully exported |
| VDT – View | Using data query count of patients who viewed their data including complete common clinical data set, lab reports and Dx reports, containing provider name/contact, in human readable format, for one or more date ranges during the measurement period. |
| VDT – download and Transmit | Using data query count of patients who downloaded or transmitted their data including complete common clinical data set, lab reports and Dx reports containing provider name/contact, for one or more date ranges, during the measurement period. |
| VDT – Activity Logging | Using data query generate a list of top 10 patients/reps who, during the measurement period, viewed, downloaded, and/or transmitted their data including the user (patient/rep) who performed the action and NTP timestamp when the action was performed |
| Creation of syndromic surveillance messages | Using data query, count of Syndromic Surveillance messages created by staff as needed, per HL7 2.5.1 standard, during the measurement period. |
Transmission to public health agencies
| Using data query count eligible cases when a trigger is matched in accordance with provision (f)(5)(ii), where the Health IT Module created a case report with only the required subset of CCDS data elements, during the measurement period |
Application access — patient selection (Success)
| Using data queries, count the number of successful requests for patient data, where the request resulted in successful generation of a token and data exchange, during the measurement period |
| Application access — patient selection (failure) | Using data queries, count the number of failed requests for patient data during the measurement period, where a successful token was not issued and no data was exchanged. |
Application access — all data request
| Using data queries count of data requests specifying all categories. requested during the measurement period, where the request resulted in successful generation of a token and subsequent data exchange. |
| Standardized API for patient and population services | Using standardized API technology well documented used for data response, supported search operations, secure connections with authentication and authorization and with authorization revocation. |
Direct Project – Stored addresses
| Using data query, count the direct addresses entered and stored in the health IT module, grouped by binding (domain/Address) and hosting (DNS and LDAP), during the measurement period |
| Direct Project – Wrapped message success | Using data query, count the wrapped messages successfully transmitted to third parties during the measurement period |
List certification criteria associated with the measure and Update criteria.
| Measurement/Metric | Associated Certification Criteria | Relied Upon |
| Transitions of Care as CCDA – Create | 170.315(b)(1) Transitions of Care | EMR Direct |
| Transitions of Care CCDA – Conformance | 170.315(b)(1) Transitions of Care | EMR Direct |
| Transitions of Care CCDA Receive | 170.315(b)(1) Transitions of Care | EMR Direct |
| Transitions of Care CCDA Display | 170.315(b)(1) Transitions of Care | EMR Direct |
| Transitions of Care CCDA Display section order | 170.315(b)(1) Transitions of Care | EMR Direct |
| Clinical information reconciliation and incorporation | 170.315 (b)(2) Clinical information reconciliation and incorporation | EMR Direct |
| Electronic prescribing | 170.315 (b)(3) Electronic prescribing | Dosespot |
| Health Information Export | 170.315(b)(10) Electronic Health Information export | NA |
| Clinical quality measures (CQMs) — record and export | 170.315(c)(1) Clinical quality measures (CQMs) — record and export | NA |
| VDT- View | 170.315(e)(1) View, download, and transmit to 3rd party | NA |
| VDT- download and transmit | 170.315(e)(1) View, download, and transmit to 3rd party | NA |
| VDT – Activity Logging | 170.315(e)(1) View, download, and transmit to 3rd party | NA |
| Creation of syndromic surveillance messages | 170.315(f)(2) Transmission to public health agencies — syndromic surveillance | NA |
| Transmission to public health agencies | 170.315(f)(5) Transmission to public health agencies — electronic case reporting | NA |
| Application access — patient selection Success | 170.315(g)(7) Application access — patient selection | NA |
| Application access — patient selection failed | 170.315(g)(7) Application access — patient selection | NA |
| Application access — all data request | 170.315(g)(9) Application access — all data request | NA |
| Standardized API for patient and population services | 170.315(g)(10) Standardized API for Patient and Population Services | NA |
| Direct Project – Stored addresses | 170.315(h)(1) Direct Project | EMR Direct |
| Direct Project – Wrapped message success | 170.315(h)(1) Direct Project | EMR Direct |
Provide an explanation for the measurement/metric selected to conduct Real World Testing
| Measurement/Metric | Justification |
| Transitions of Care as CCDA – Create | Counts of valid CCDAs created during the measurement period, demonstrates that the Health IT is working as expected and certified to create CCDs |
| Transitions of Care CCDA – Conformance | Counts of conforming CCDAs created during the measurement period, demonstrates that the Health IT is working as expected and certified |
| Transitions of Care CCDA Receive | Counts of invalid and /or valid CCDA received during the measurement period, demonstrates the ability of the IT to detect valid/invalid CCDA |
| Transitions of Care CCDA Display | Counts of CCDAs grouped by R1.1 and R2.1 demonstrates the ability of the IT to handle both releases |
| Transitions of Care CCDA Display section order | Our technology is able to save the display preferences of the application. Counting the number of times this activity took place, during the measurement period demonstrates functionality |
| Clinical information reconciliation and incorporation | Our technology automatically matches the patient to the ToC and has the user verify the match and sets the auto-match flag true. Counting cases that the flag is set to true, and the page the action was performed on, during the measurement period, demonstrates that the product is working as expected.
|
| Electronic prescribing | Getting counts of prescriptions, during the measurement period, that were successfully received by the service provider and not rejected, that contained units in mL as well as quantity, demonstrates this function.
|
| Health Information Export | Enable a user to timely create an export file(s) with all of a single patient’s electronic health information stored in the EHR |
Clinical quality measures (CQMs) — record and export
| Reports of patients by the CQM including status (Met, Unmet and Exclusion, with reason medical, Patient, System) demonstrates that the Health IT is working as expected and certified for this function. |
| VDT – View | Counts of occurrence(s) during the measurement period demonstrate that the function is working as expected for viewing data. |
| VDT – download and Transmit | Counts of occurrence(s) during the measurement period demonstrate that the function is working as expected for downloading or transmitting data. |
| VDT – Activity Logging | Counts of occurrence(s) during the measurement period demonstrate that NTP time stamp and user activity logging is working. |
| Creation of syndromic surveillance messages | Since our technology validates messages on creation, getting counts demonstrates that the function is working. |
| Transmission to public health agencies | Counts of eligible cases generated and transmitted during the measurement period illustrates that this function is working. |
| Application access — patient selection Success | If we receive, validate the request, issue a token that is used subsequently for data exchange, we demonstrate that this function is working and our documentation is on point. |
| Application access — patient selection failed | If we receive, validate the request, do not issue a token if the request is not to syntax, we demonstrate that this function is working and documentation is on point, but the requester made an error. |
| Application access — all data request | If we receive, validate the request, issue a token that is used subsequently for data exchange, we demonstrate that this function is working and documentation is on point. |
| Standardized API for patient and population services | On receiving requests through search under a secure connection, we authenticate and check pt authorization by token received in an API |
| Direct Project – Stored addresses | Storing direct addresses to the database during the measurement period demonstrates this function. |
| Direct Project – Wrapped message success | Counting wrapped messages transmitted during the measurement period demonstrates this function. |
Care Setting | Justification |
Ambulatory Medical Clinic | Ambulatory Medical Clinic (Urology Clinics) |
| Measurement/Metric | Expected Outcomes |
| Transitions of Care as CCDA – Create | That CCDA messages created conform to B(1) requirements |
| Transitions of Care CCDA – Conformance | CCDA messages created conform to B(1) requirements, with no errors, which exceeds our benchmark of 99%. |
| Transitions of Care CCDA Receive | That the CCDA messages were successfully received, reconciled and data incorporated with no errors |
| Transitions of Care CCDA Display | That the CCDA messages were successfully received and displayed |
| Transitions of Care CCDA Display section order | That the CCDA messages were successfully received, order of sections displayed with no errors |
| Clinical information reconciliation and incorporation | That the CCDA messages were successfully reconciled, and data incorporated with no errors. |
| Electronic prescribing | The prescriptions in the measure were successfully transmitted and acknowledged by the recipient service provider. |
| Electronic Health Information Export | Data was successfully exported and a file was created for a selected patient with all of the patient health information |
| Clinical quality measures (CQMs) — record and export | Data was successfully exported and error free. |
| VDT – View | Data was successfully viewed and error free |
| VDT – Download and Transmit | Data was successfully downloaded or transmitted and error free |
| VDT – Activity Logging | Data viewed, successfully downloaded or transmitted, contains user and timestamp |
| Creation of syndromic surveillance messages | Messages were successful created to HL7 2.5.1 standard and there were no errors |
| Transmission to public health agencies | Messages were successfully transmitted without errors |
| Application access — patient selection Success | Greater than 99% of the requests made per Health IT’s documentation, resulted in successful issue of a token |
| Application access — patient selection failed | Greater than 99% of the requests made per Health IT’s documentation, resulted in successful issue of a token |
| V 1Application access — all data request | Greater than 99% of the requests made per Health IT’s documentation, resulted in successful issue of a token and exchange of data for the requested parameters. |
| Standardized API for patient and population services | Respond to requests for a single/multiple patient’s data or as a data group according to the standard adopted and consistent with the search criteria Enable an application to register with the Health IT Module’s “authorization server”. Establish a secure and trusted connection. Authentication and Authorization must happen for the patient. |
| Direct Project – Stored addresses | Greater than one each of address and domain bound Direct addresses are stored without errors |
| Direct Project – Wrapped message success | Messages are successfully sent to third parties |
For each key milestone, describe when Real World Testing will begin in specific care settings and the date/timeframe during which data will be collected.
Key Milestone | Care Setting | Date/Timeframe |
Complete RWT Development
| Ambulatory Medical Clinic
| Oct 30 2023 |
Test RWT plan | Ambulatory Medical Clinic | Dec 15 2023 |
Implement RWT Plan | Ambulatory Medical Clinic | Jan 5 2024 |
Report Results to SLI | Ambulatory Medical Clinic | Jan 15 2025 |
This Real World Testing plan is complete with all required elements, including measures that address all certification criteria and care settings. All information in this plan is up to date and fully addresses the health IT developer’s Real World Testing requirements.
Authorized Representative Name: Ashu Kataria
Authorized Representative Email:Ashu.Kataria@inpracsys.com
Authorized Representative Phone: 612-455-6789
Authorized Representative Signature: Digitally Signed Ashu Kataria for InPracSys
Date: 11/29/2023
Under the ONC Health IT Certification Program (Program), health IT developers are required to conduct Real World Testing of their certified health IT (45 CFR 170.405). The Office of the National Coordinator for Health Information Technology (ONC) issues Real World Testing resources to clarify health IT developers’ responsibilities for conducting Real World Testing, to identify topics and specific elements of Real World Testing that ONC considers a priority, and to assist health IT developers in developing their Real World Testing plans.
Plan ReportID Number: [For ONC-Authorized Certification Body use only]
Developer Name: InPracSys
Product Name(s): InPracSys EHR
Version Number(s): 9.0
Certified Health IT: Yes
Product List (CHPL) ID(s): 15.05.05.2762.INPS.01.00.1.191206
Developer Real World Testing Page URL: https://inpracsys.com/rwt/
As we did in 2022, We plan on beginning real work testing using the same representative clinic’s data, that agreed to all criteria that are included in the requirement list for RWT. If some criteria or criterion remain unused by the testing clinic, InPracSys will perform that part of the test at InPracSys Lab.
The tests will be performed on real data using data queries and presented as counts of successes and failure on screens available to authorized users. The data presented will also be benchmarked against InPracSys internal benchmark for expected results and acceptable failure rates to ensure continuing success. All failures will be documented and used for process improvement and/or training of clinic staff.
All tests will be carefully aligned to meet criteria’s requirements and technical outcomes. E.g., B(1) can the IT detect valid vs invalid ToC referral summaries.
If, for any reason, the test clinic has not used one or more functions, for their own reasons, e.g., Transmission to Public health agencies, we plan on running the tests manually a few times during the calendar year(s) to ensure continuing functionality thru the year(s) of the unused functions.
Standard (and version) | All Standards are the 2015 Versions |
Updated certification criteria and associated product | NA |
Health IT Module CHPL ID | NA |
Method used for standard update | NA |
Date of ONC-ACB notification | NA |
Date of customer notification (SVAP only) | NA |
Conformance measure | NA |
USCDI-updated certification criteria (and USCDI version) | NA |
Each plan must include at least one measurement/metric that addresses each applicable certification criterion in the Health IT Module’s scope of certification. Describe the method for measuring how the approach(es) chosen meet the intent and purpose of Real World Testing.
For each measurement/metric, describe the elements below:
Describe the measure(s) that will be used to support the overall approach to Real World Testing.
Measurement/Metric | Description |
Transitions of Care as CCDA – Create | Using data query, Count of C-CDA referral summaries created, formatted to release 2.1, during the measurement period |
Transitions of Care CCDA – Conformance | Use CMS validator API to Automatically test a Random sampling of messages created during the measurement period to ensure at a minimum that messages meet the Release, content and PT matching criteria |
Transitions of Care CCDA Receive | Using data query, Count of C-CDA referral summaries received during the measurement period grouped by status (valid/invalid) AND “grouped by” containing XDM package |
Transitions of Care CCDA Display | Using data query, count of referral summaries received and successfully displayed, during the measurement period, “grouped by” CCD release (1.1, 1.2) |
Transitions of Care CCDA Display section order | Using data query, count of referral summaries displayed where the display order was changed by the user |
Clinical information reconciliation and incorporation | Using data query, Count of reconciliations, during the measurement period, where the auto-matched PT flag is set to true, and occurred from the side-by-side display page |
Electronic prescribing | Count of prescriptions successfully transmitted, during the measurement period, where the units are in mL and where the Qty is set to 0.XX where XX is any numeric value |
Data export | Using data query, Count of summaries created by the user where a user entered single date or date range and destination locations are saved in database in the appropriate fields, during the measurement period. |
Clinical quality measures (CQMs) – record and export | Using data query, count of patients, in measurement period, where the criteria is met or where the patients fall in exclusions, with coded exclusion reason, for all certified CQMs, and where data was successfully exported |
VDT – View | Using data query count of patients who viewed their data including complete common clinical data set, lab reports and Dx reports, containing provider name/contact, in human readable format, for one or more date ranges during the measurement period. |
VDT – download and Transmit | Using data query count of patients who downloaded or transmitted their data including complete common clinical data set, lab reports and Dx reports containing provider name/contact, for one or more date ranges, during the measurement period. |
VDT – Activity Logging | Using data query generate a list of top 10 patients/reps who, during the measurement period, viewed, downloaded, and/or transmitted their data including the user (patient/rep) who performed the action and NTP timestamp when the action was performed |
Creation of syndromic surveillance messages | Using data query, count of Syndromic Surveillance messages created by staff as needed, per HL7 2.5.1 standard, during the measurement period. |
Transmission to public health agencies
| Using data query count eligible cases when a trigger is matched in accordance with provision (f)(5)(ii), where the Health IT Module created a case report with only the required subset of CCDS data elements, during the measurement period |
Direct Project – Stored addresses
| Using data query, count the direct addresses entered and stored in the health IT module, grouped by binding (domain/Address) and hosting (DNS and LDAP), during the measurement period |
Direct Project – Wrapped message success | Using data query, count the wrapped messages successfully transmitted to third parties during the measurement period |
List certification criteria associated with the measure and Update criteria.
Measurement/Metric | Associated Certification Criteria | Relied Upon |
Transitions of Care as CCDA – Create | 170.315(b)(1) Transitions of Care | EMR Direct |
Transitions of Care CCDA – Conformance | 170.315(b)(1) Transitions of Care | EMR Direct |
Transitions of Care CCDA Receive | 170.315(b)(1) Transitions of Care | EMR Direct |
Transitions of Care CCDA Display | 170.315(b)(1) Transitions of Care | EMR Direct |
Transitions of Care CCDA Display section order | 170.315(b)(1) Transitions of Care | EMR Direct |
Clinical information reconciliation and incorporation | 170.315 (b)(2) Clinical information reconciliation and incorporation | EMR Direct |
Electronic prescribing | 170.315 (b)(3) Electronic prescribing | Dosespot |
Data export | 170.315 (b)(6) Data export | EMR Direct |
Clinical quality measures (CQMs) — record and export | 170.315(c)(1) Clinical quality measures (CQMs) — record and export | None |
VDT- View | 170.315(e)(1) View, download, and transmit to 3rd party | None |
download and transmit | 170.315(e)(1) View, download, and transmit to 3rd party | None |
Activity Logging | 170.315(e)(1) View, download, and transmit to 3rd party | None |
Creation of syndromic surveillance to required standard | 170.315(f)(2) Transmission to public health agencies — syndromic surveillance | None |
Transmission to public health agencies — electronic case reporting | 170.315(f)(5) Transmission to public health agencies — electronic case reporting | None |
Application access — patient selection Success | 170.315(g)(7) Application access — patient selection | None |
Application access — patient selection failed | 170.315(g)(7) Application access — patient selection | None |
Application access — all data request | 170.315(g)(9) Application access — all data request | None |
Direct Project – Stored addresses | 170.315(h)(1) Direct Project | EMR Direct |
Direct Project – Wrapped message success | 170.315(h)(1) Direct Project | EMR Direct |
Provide an explanation for the measurement/metric selected to conduct Real World Testing
Measurement/Metric | Justification |
Transitions of Care as CCDA – Create | Counts of valid CCDAs created during the measurement period, demonstrates that the Health IT is working as expected and certified to create CCDs |
Transitions of Care CCDA – Conformance | Counts of conforming CCDAs created during the measurement period, demonstrates that the Health IT is working as expected and certified |
Transitions of Care CCDA Receive | Counts of invalid and /or valid CCDA received during the measurement period, demonstrates the ability of the IT to detect valid/invalid CCDA |
Transitions of Care CCDA Display | Counts of CCDAs grouped by R1.1 and R2.1 demonstrates the ability of the IT to handle both releases |
Transitions of Care CCDA Display section order | Our technology is able to save the display preferences of the application. Counting the number of times this activity took place, during the measurement period demonstrates functionality |
Clinical information reconciliation and incorporation | Our technology automatically matches the patient to the ToC and has the user verify the match and sets the auto-match flag true. Counting cases that the flag is set to true, and the page the action was performed on, during the measurement period, demonstrates that the product is working as expected.
|
Electronic prescribing | Getting counts of prescriptions, during the measurement period, that were successfully received by the service provider and not rejected, that contained units in mL as well as quantity, demonstrates this function.
|
Data export | Our application allows the user to choose the instances, date range and location of the destination of the export. Therefore reporting counts of summaries created, grouped by date range and destination demonstrates this function. |
Clinical quality measures (CQMs) — record and export
| Reports of patients by the CQM including status (Met, Unmet and Exclusion, with reason medical, Patient, System) demonstrates that the Health IT is working as expected and certified for this function. |
VDT – View | Counts of occurrence(s) during the measurement period demonstrate that the function is working as expected for viewing data. |
VDT – download and Transmit | Counts of occurrence(s) during the measurement period demonstrate that the function is working as expected for downloading or transmitting data |
VDT – Activity Logging | Counts of occurrence(s) during the measurement period demonstrate that NTP time stamp and user activity logging is working. |
Creation of syndromic surveillance to required standard | Since our technology validates messages on creation, getting counts demonstrates that the function is working. |
Transmission to public health agencies — electronic case reporting | Counts of eligible cases generated and transmitted during the measurement period illustrates that this function is working. |
Direct Project – Stored addresses | Storing direct addresses to the database during the measurement period demonstrates this function |
Direct Project – Wrapped message success | Counting wrapped messages transmitted during the measurement period demonstrates this function |
Care Setting | Justification |
Ambulatory Medical Clinic | Ambulatory Medical Clinic (Urology Clinics) |
Measurement/Metric | Expected Outcomes |
Transitions of Care as CCDA – Create | CCDA messages were successfully created with no errors, which exceeds our benchmark of 99%. |
Transitions of Care CCDA – Conformance | CCDA messages created conform to B(1) requirements, with no errors, which exceeds our benchmark of 99%. |
Transitions of Care CCDA Receive | the CCDA messages were successfully received, reconciled and data incorporated with no errors exceeding our benchmark of 99%. |
Transitions of Care CCDA Display | the CCDA messages were successfully received and displayed. There were no errors, which exceeds our benchmark of 99%. |
Transitions of Care CCDA Display section order | the CCDA messages were successfully received, order of sections displayed with no errors, which exceeds our benchmark of 99%. |
Clinical information reconciliation and incorporation | That the CCDA messages were successfully reconciled, and data incorporated with no errors, exceeding our benchmark of 99%. |
Electronic prescribing | The prescriptions in the measure were successfully transmitted and acknowledged by the recipient service provider, with no errors, which exceeds our benchmark of 99%. |
Data export | That summaries were successfully exported and transmitted without errors, and final destination recorded. Our benchmark of 99% was exceeded. |
Clinical quality measures (CQMs) — record and export | Data was successfully exported and error free. Our benchmark of 99% was exceeded. |
VDT – View | Data was successfully viewed and error free. Our benchmark of 99% was exceeded. |
VDT – Download and Transmit | Data was successfully downloaded or transmitted and error free. Our benchmark of 99% was exceeded. |
VDT – Activity Logging | Data viewed, successfully downloaded or transmitted, contains user and timestamp. There we re no errors. Our benchmark of 99% was exceeded. |
Creation of syndromic surveillance to required standard | Messages were successful created to HL7 2.5.1 standard and there were no errors. Our benchmark of 99% was exceeded. |
Transmission to public health agencies — electronic case reporting | Messages were successfully transmitted without errors, exceeding our benchmark of 99%. |
Direct Project – Stored addresses | Greater than one each of address and domain bound Direct addresses are stored without errors, Our benchmark of 99% was exceeded. |
Direct Project – Wrapped message success | Messages are successfully sent to third parties without errors. Our benchmark of 99% was exceeded. |
For each key milestone, describe when Real World Testing will begin in specific care settings and the date/timeframe during which data will be collected.
Key Milestone | Care Setting | Date/Timeframe |
Complete RWT Development
| Ambulatory Medical Clinic
| Nov 30 2022 |
Test RWT plan | Ambulatory Medical Clinic | Dec 15 2022 |
Implement RWT Plan | Ambulatory Medical Clinic | Jan 2 2023 |
Report Results to SLI | Ambulatory Medical Clinic | Jan 6 2024 |
The Real World Testing plan must include the following attestation signed by the health IT developer authorized representative.
Note: The plan must be approved by a health IT developer authorized representative capable of binding the health IT developer for execution of the plan and include the representative’s contact information.[i]
This Real World Testing plan is complete with all required elements, including measures that address all certification criteria and care settings. All information in this plan is up to date and fully addresses the health IT developer’s Real World Testing requirements.
Authorized Representative Name: Ashu Kataria
Authorized Representative Email: Ashu.Kataria@inpracsys.com
Authorized Representative Phone: 612-455-6789
Authorized Representative Signature: Ashu Kataria
Date: 12/12/2022
Under the ONC Health IT Certification Program (Program), health IT developers are required to conduct Real World Testing of their certified health IT (45 CFR 170.405). The Office of the National Coordinator for Health Information Technology (ONC) issues Real World Testing resources to clarify health IT developers’ responsibilities for conducting Real World Testing, to identify topics and specific elements of Real World Testing that ONC considers a priority, and to assist health IT developers in developing their Real World Testing plans.
Plan ReportID Number: [For ONC-Authorized Certification Body use only]
Developer Name: InPracSys
Product Name(s): InPracSys EHR
Version Number(s): 9.0
Certified Health IT: Yes
Product List (CHPL) ID(s): 15.05.05.2762.INPS.01.00.1.191206
Developer Real World Testing Page URL: https://inpracsys.com/rwt/
As we did in 2022, We plan on beginning real work testing using the same representative clinic’s data, that agreed to all criteria that are included in the requirement list for RWT. If some criteria or criterion remain unused by the testing clinic, InPracSys will perform that part of the test at InPracSys Lab.
The tests will be performed on real data using data queries and presented as counts of successes and failure on screens available to authorized users. The data presented will also be benchmarked against InPracSys internal benchmark for expected results and acceptable failure rates to ensure continuing success. All failures will be documented and used for process improvement and/or training of clinic staff.
All tests will be carefully aligned to meet criteria’s requirements and technical outcomes. E.g., B(1) can the IT detect valid vs invalid ToC referral summaries.
If, for any reason, the test clinic has not used one or more functions, for their own reasons, e.g., Transmission to Public health agencies, we plan on running the tests manually a few times during the calendar year(s) to ensure continuing functionality thru the year(s) of the unused functions.
Standard (and version) | All Standards are the 2015 Versions |
Updated certification criteria and associated product | NA |
Health IT Module CHPL ID | NA |
Method used for standard update | NA |
Date of ONC-ACB notification | NA |
Date of customer notification (SVAP only) | NA |
Conformance measure | NA |
USCDI-updated certification criteria (and USCDI version) | NA |
Each plan must include at least one measurement/metric that addresses each applicable certification criterion in the Health IT Module’s scope of certification. Describe the method for measuring how the approach(es) chosen meet the intent and purpose of Real World Testing.
For each measurement/metric, describe the elements below:
Describe the measure(s) that will be used to support the overall approach to Real World Testing.
Measurement/Metric | Description |
Transitions of Care as CCDA – Create | Using data query, Count of C-CDA referral summaries created, formatted to release 2.1, during the measurement period |
Transitions of Care CCDA – Conformance | Use CMS validator API to Automatically test a Random sampling of messages created during the measurement period to ensure at a minimum that messages meet the Release, content and PT matching criteria |
Transitions of Care CCDA Receive | Using data query, Count of C-CDA referral summaries received during the measurement period grouped by status (valid/invalid) AND “grouped by” containing XDM package |
Transitions of Care CCDA Display | Using data query, count of referral summaries received and successfully displayed, during the measurement period, “grouped by” CCD release (1.1, 1.2) |
Transitions of Care CCDA Display section order | Using data query, count of referral summaries displayed where the display order was changed by the user |
Clinical information reconciliation and incorporation | Using data query, Count of reconciliations, during the measurement period, where the auto-matched PT flag is set to true, and occurred from the side-by-side display page |
Electronic prescribing | Count of prescriptions successfully transmitted, during the measurement period, where the units are in mL and where the Qty is set to 0.XX where XX is any numeric value |
Data export | Using data query, Count of summaries created by the user where a user entered single date or date range and destination locations are saved in database in the appropriate fields, during the measurement period. |
Clinical quality measures (CQMs) – record and export | Using data query, count of patients, in measurement period, where the criteria is met or where the patients fall in exclusions, with coded exclusion reason, for all certified CQMs, and where data was successfully exported |
VDT – View | Using data query count of patients who viewed their data including complete common clinical data set, lab reports and Dx reports, containing provider name/contact, in human readable format, for one or more date ranges during the measurement period. |
VDT – download and Transmit | Using data query count of patients who downloaded or transmitted their data including complete common clinical data set, lab reports and Dx reports containing provider name/contact, for one or more date ranges, during the measurement period. |
VDT – Activity Logging | Using data query generate a list of top 10 patients/reps who, during the measurement period, viewed, downloaded, and/or transmitted their data including the user (patient/rep) who performed the action and NTP timestamp when the action was performed |
Creation of syndromic surveillance messages | Using data query, count of Syndromic Surveillance messages created by staff as needed, per HL7 2.5.1 standard, during the measurement period. |
Transmission to public health agencies
| Using data query count eligible cases when a trigger is matched in accordance with provision (f)(5)(ii), where the Health IT Module created a case report with only the required subset of CCDS data elements, during the measurement period |
Direct Project – Stored addresses
| Using data query, count the direct addresses entered and stored in the health IT module, grouped by binding (domain/Address) and hosting (DNS and LDAP), during the measurement period |
Direct Project – Wrapped message success | Using data query, count the wrapped messages successfully transmitted to third parties during the measurement period |
List certification criteria associated with the measure and if updated to the 2015 Edition Cures Update criteria.
Measurement/Metric | Associated Certification Criteria | Relied Upon |
Transitions of Care as CCDA – Create | 170.315(b)(1) Transitions of Care | EMR Direct |
Transitions of Care CCDA – Conformance | 170.315(b)(1) Transitions of Care | EMR Direct |
Transitions of Care CCDA Receive | 170.315(b)(1) Transitions of Care | EMR Direct |
Transitions of Care CCDA Display | 170.315(b)(1) Transitions of Care | EMR Direct |
Transitions of Care CCDA Display section order | 170.315(b)(1) Transitions of Care | EMR Direct |
Clinical information reconciliation and incorporation | 170.315 (b)(2) Clinical information reconciliation and incorporation | EMR Direct |
Electronic prescribing | 170.315 (b)(3) Electronic prescribing | Dosespot |
Data export | 170.315 (b)(6) Data export | EMR Direct |
Clinical quality measures (CQMs) — record and export | 170.315(c)(1) Clinical quality measures (CQMs) — record and export | None |
VDT- View | 170.315(e)(1) View, download, and transmit to 3rd party | None |
download and transmit | 170.315(e)(1) View, download, and transmit to 3rd party | None |
Activity Logging | 170.315(e)(1) View, download, and transmit to 3rd party | None |
Creation of syndromic surveillance to required standard | 170.315(f)(2) Transmission to public health agencies — syndromic surveillance | None |
Transmission to public health agencies — electronic case reporting | 170.315(f)(5) Transmission to public health agencies — electronic case reporting | None |
Application access — patient selection Success | 170.315(g)(7) Application access — patient selection | None |
Application access — patient selection failed | 170.315(g)(7) Application access — patient selection | None |
Application access — all data request | 170.315(g)(9) Application access — all data request | None |
Direct Project – Stored addresses | 170.315(h)(1) Direct Project | EMR Direct |
Direct Project – Wrapped message success | 170.315(h)(1) Direct Project | EMR Direct |
Provide an explanation for the measurement/metric selected to conduct Real World Testing
Measurement/Metric | Justification |
Transitions of Care as CCDA – Create | Counts of valid CCDAs created during the measurement period, demonstrates that the Health IT is working as expected and certified to create CCDs |
Transitions of Care CCDA – Conformance | Counts of conforming CCDAs created during the measurement period, demonstrates that the Health IT is working as expected and certified |
Transitions of Care CCDA Receive | Counts of invalid and /or valid CCDA received during the measurement period, demonstrates the ability of the IT to detect valid/invalid CCDA |
Transitions of Care CCDA Display | Counts of CCDAs grouped by R1.1 and R2.1 demonstrates the ability of the IT to handle both releases |
Transitions of Care CCDA Display section order | Our technology is able to save the display preferences of the application. Counting the number of times this activity took place, during the measurement period demonstrates functionality |
Clinical information reconciliation and incorporation | Our technology automatically matches the patient to the ToC and has the user verify the match and sets the auto-match flag true. Counting cases that the flag is set to true, and the page the action was performed on, during the measurement period, demonstrates that the product is working as expected.
|
Electronic prescribing | Getting counts of prescriptions, during the measurement period, that were successfully received by the service provider and not rejected, that contained units in mL as well as quantity, demonstrates this function.
|
Data export | Our application allows the user to choose the instances, date range and location of the destination of the export. Therefore reporting counts of summaries created, grouped by date range and destination demonstrates this function. |
Clinical quality measures (CQMs) — record and export
| Reports of patients by the CQM including status (Met, Unmet and Exclusion, with reason medical, Patient, System) demonstrates that the Health IT is working as expected and certified for this function. |
VDT – View | Counts of occurrence(s) during the measurement period demonstrate that the function is working as expected for viewing data. |
VDT – download and Transmit | Counts of occurrence(s) during the measurement period demonstrate that the function is working as expected for downloading or transmitting data |
VDT – Activity Logging | Counts of occurrence(s) during the measurement period demonstrate that NTP time stamp and user activity logging is working. |
Creation of syndromic surveillance to required standard | Since our technology validates messages on creation, getting counts demonstrates that the function is working. |
Transmission to public health agencies — electronic case reporting | Counts of eligible cases generated and transmitted during the measurement period illustrates that this function is working. |
Direct Project – Stored addresses | Storing direct addresses to the database during the measurement period demonstrates this function |
Direct Project – Wrapped message success | Counting wrapped messages transmitted during the measurement period demonstrates this function |
Care Setting | Justification |
Ambulatory Medical Clinic | Ambulatory Medical Clinic (Urology Clinics) |
Measurement/Metric | Expected Outcomes |
Transitions of Care as CCDA – Create | CCDA messages were successfully created with no errors, which exceeds our benchmark of 99%. |
Transitions of Care CCDA – Conformance | CCDA messages created conform to B(1) requirements, with no errors, which exceeds our benchmark of 99%. |
Transitions of Care CCDA Receive | the CCDA messages were successfully received, reconciled and data incorporated with no errors exceeding our benchmark of 99%. |
Transitions of Care CCDA Display | the CCDA messages were successfully received and displayed. There were no errors, which exceeds our benchmark of 99%. |
Transitions of Care CCDA Display section order | the CCDA messages were successfully received, order of sections displayed with no errors, which exceeds our benchmark of 99%. |
Clinical information reconciliation and incorporation | That the CCDA messages were successfully reconciled, and data incorporated with no errors, exceeding our benchmark of 99%. |
Electronic prescribing | The prescriptions in the measure were successfully transmitted and acknowledged by the recipient service provider, with no errors, which exceeds our benchmark of 99%. |
Data export | That summaries were successfully exported and transmitted without errors, and final destination recorded. Our benchmark of 99% was exceeded. |
Clinical quality measures (CQMs) — record and export | Data was successfully exported and error free. Our benchmark of 99% was exceeded. |
VDT – View | Data was successfully viewed and error free. Our benchmark of 99% was exceeded. |
VDT – Download and Transmit | Data was successfully downloaded or transmitted and error free. Our benchmark of 99% was exceeded. |
VDT – Activity Logging | Data viewed, successfully downloaded or transmitted, contains user and timestamp. There we re no errors. Our benchmark of 99% was exceeded. |
Creation of syndromic surveillance to required standard | Messages were successful created to HL7 2.5.1 standard and there were no errors. Our benchmark of 99% was exceeded. |
Transmission to public health agencies — electronic case reporting | Messages were successfully transmitted without errors, exceeding our benchmark of 99%. |
Direct Project – Stored addresses | Greater than one each of address and domain bound Direct addresses are stored without errors, Our benchmark of 99% was exceeded. |
Direct Project – Wrapped message success | Messages are successfully sent to third parties without errors. Our benchmark of 99% was exceeded. |
For each key milestone, describe when Real World Testing will begin in specific care settings and the date/timeframe during which data will be collected.
Key Milestone | Care Setting | Date/Timeframe |
Complete RWT Development
| Ambulatory Medical Clinic
| Nov 30 2022 |
Test RWT plan | Ambulatory Medical Clinic | Dec 15 2022 |
Implement RWT Plan | Ambulatory Medical Clinic | Jan 2 2023 |
Report Results to SLI | Ambulatory Medical Clinic | Jan 6 2024 |
The Real World Testing plan must include the following attestation signed by the health IT developer authorized representative.
Note: The plan must be approved by a health IT developer authorized representative capable of binding the health IT developer for execution of the plan and include the representative’s contact information.[i]
This Real World Testing plan is complete with all required elements, including measures that address all certification criteria and care settings. All information in this plan is up to date and fully addresses the health IT developer’s Real World Testing requirements.
Authorized Representative Name: Ashu Kataria
Authorized Representative Email: Ashu.Kataria@inpracsys.com
Authorized Representative Phone: 612-455-6789
Authorized Representative Signature: Ashu Kataria
Date: 12/12/2022
Under the ONC Health IT Certification Program (Program), health IT developers are required to conduct Real World Testing of their certified health IT (45 CFR 170.405). The Office of the National Coordinator for Health Information Technology (ONC) issues Real World Testing resources to clarify health IT developers’ responsibilities for conducting Real World Testing, to identify topics and specific elements of Real World Testing that ONC considers a priority, and to assist health IT developers in developing their Real World Testing plans.
Plan Report ID Number: 20211025inp
Developer Name: InPracSys
Product Name(s): InPracSys EHR
Version Number(s): 9.0
Product List (CHPL) ID(s): 15.05.05.2762.INPS.01.00.1.191206
Developer Real World Testing Page URL: https://www.inpracsys.com/rwt/
Provide an explanation for the overall approach to Real World Testing, including an outline of the approach and how data will be used to demonstrate successful Real World Testing .
All measures should reasonably align with the elements within a Real World Testing plan, the scope of the certification, the types of settings in which the certified health IT is marketed, and other factors relevant to the implementation of the certified Health IT Module(s). The justification should reflect how each element within the plan is relevant to the developer’s overall strategy for meeting the Real World Testing Condition and Maintenance of Certification requirements.
Note: A single Real World Testing plan may address multiple products and certification criteria for multiple care settings.
We plan on beginning real work testing using 1 representative clinic that agrees to all criteria that are included in the requirement list for RWT. If some criteria or criterion remain unused by the testing clinic, InPracSys will perform that part of the test at InPracSys Lab.
The tests will be performed on real data using data queries and dynamically presented as counts of successes and failure or screen available to authorized users. The data presented will also be benchmarked against InPracSys internal benchmark for expected results and acceptable failure rates to ensure continuing success. All failures will be documented and used for process improvement and/or training of clinic staff.
All tests will be carefully aligned to meet criteria’s requirements and technical outcomes. E.g., B(1) can the IT detect valid vs invalid ToC referral summaries.
If, for any reason, the test clinic has not used one or more functions, for their own reasons, e.g. Transmission to Public health agencies, we plan on running the tests manually a few times during the calendar year(s) to ensure continuing functionality thru the year(s) of the unused functions.
Both required and voluntary standards updates must be addressed in the Real World Testing plan. Real World Testing plans must include all certified health IT updated to newer versions of standards prior to August 31 of the year in which the updates were made.
Describe approach(es) for demonstrating conformance to all certification requirements using each standard to which the health IT is certified. List each version of a given standard separately. For each version of a standard submit the following:
| Standard (and Version) | All Standards are the 2015 Versions |
| Updated certification criteria and associated product | N/A |
| Health IT Module CHP ID | N/A |
| Method used for standard update | N/A |
| Date of ONC-ACB notification | N/A |
| Date of customer notification (SVAP only) | N/A |
| Conformance measure | N/A |
| USCDI-updated certification criteria (and USCDI version) | N/A |
Each plan must include at least one measurement/metric that addresses each applicable certification criterion in the Health IT Module’s scope of certification. Describe the method for measuring how the approach(es) chosen meet the intent and purpose of Real World Testing.
For each measurement/metric, describe the elements below:
| Measurement/Metric | Description |
| Transitions of Care as CCDA – Create | Using data query, Count of C-CDA referral summaries created, formatted to release 2.1, during the measurement period |
| Transitions of Care CCDA – Conformance | Use CMS validator API to Automatically test a Random sampling of messages created during the measurement period to ensure at a minimum that messages meet the Release, content and PT matching criteria |
| Transitions of Care CCDA Receive | Using data query, Count of C-CDA referral summaries received during the measurement period grouped by status (valid/invalid) AND “grouped by” containing XDM package |
| Transitions of Care CCDA Display | Using data query, count of referral summaries received and successfully displayed, during the measurement period, “grouped by” CCD release (1.1, 1.2) |
| Transitions of Care CCDA Display section order | Using data query, count of referral summaries displayed where the display order was changed by the user |
| Clinical information reconciliation and incorporation | Using data query, Count of reconciliations, during the measurement period, where the auto-matched PT flag is set to true, and occurred from the side-by-side display page |
| Electronic prescribing | Count of prescriptions successfully transmitted, during the measurement period, where the units are in mL and where the Qty is set to 0.XX where XX is any numeric value |
| Data export | Using data query, Count of summaries created by the user where a user entered single date or date range and destination locations are saved in database in the appropriate fields, during the measurement period. |
| Clinical quality measures (CQMs) – record and export | Using data query, count of patients, in measurement period, where the criteria is met or where the patients fall in exclusions, with coded exclusion reason, for all certified CQMs, and where data was successfully exported |
| VDT – View | Using data query count of patients who viewed their data including complete common clinical data set, lab reports and Dx reports, containing provider name/contact, in human readable format, for one or more date ranges during the measurement period. |
| VDT – download and Transmit | Using data query count of patients who downloaded or transmitted their data including complete common clinical data set, lab reports and Dx reports containing provider name/contact, for one or more date ranges, during the measurement period. |
| VDT – Activity Logging | Using data query generate a list of top 10 patients/reps who, during the measurement period, viewed, downloaded, and/or transmitted their data including the user (patient/rep) who performed the action and NTP timestamp when the action was performed |
| Creation of syndromic surveillance messages | Using data query, count of Syndromic Surveillance messages created by staff as needed, per HL7 2.5.1 standard, during the measurement period. |
| Transmission to public health agencies | Using data query count eligible cases when a trigger is matched in accordance with provision (f)(5)(ii), where the Health IT Module created a case report with only the required subset of CCDS data elements, during the measurement period |
| Application access — patient selection (Success) | Using data queries, count the number of successful requests for patient data, where the request resulted in successful generation of a token and data exchange, during the measurement period |
| Application access — patient selection (failure) | Using data queries, count the number of failed requests for patient data during the measurement period, where a successful token was not issued and no data was exchanged. |
| Application access — data category request | Using data queries count individual data categories requested, during the measurement period, where the request resulted in successful generation of a token and subsequent data exchange |
| Application access — all data request | Using data queries count of data requests specifying all categories. requested during the measurement period, where the request resulted in successful generation of a token and subsequent data exchange. |
| Direct Project – Stored addresses | Using data query, count the direct addresses entered and stored in the health IT module, grouped by binding (domain/Address) and hosting (DNS and LDAP), during the measurement period |
| Direct Project – Wrapped message success | Using data query, count the wrapped messages successfully transmitted to third parties during the measurement period |
| Measurement/Metric | Associated Certification Criteria |
| Transitions of Care as CCDA – Create | 170.315(b)(1) Transitions of Care |
| Transitions of Care CCDA – Conformance | 170.315(b)(1) Transitions of Care |
| Transitions of Care CCDA Receive | 170.315(b)(1) Transitions of Care |
| Transitions of Care CCDA Display | 170.315(b)(1) Transitions of Care |
| Transitions of Care CCDA Display section order | 170.315(b)(1) Transitions of Care |
| Clinical information reconciliation and incorporation | 170.315 (b)(2) Clinical information reconciliation and incorporation |
| Electronic prescribing | 170.315 (b)(3) Electronic prescribing |
| Data export | 170.315 (b)(6) Data export |
| Clinical quality measures (CQMs) — record and export | 170.315(c)(1) Clinical quality measures (CQMs) — record and export |
| VDT- View | 170.315(e)(1) View, download, and transmit to 3rd party |
| VDT- download and transmit | 170.315(e)(1) View, download, and transmit to 3rd party |
| VDT – Activity Logging | 170.315(e)(1) View, download, and transmit to 3rd party |
| Creation of syndromic surveillance messages | 170.315(f)(2) Transmission to public health agencies — syndromic surveillance |
| Transmission to public health agencies | 170.315(f)(5) Transmission to public health agencies — electronic case reporting |
| Application access — patient selection Success | 170.315(g)(7) Application access — patient selection |
| Application access — patient selection failed | 170.315(g)(7) Application access — patient selection |
| Application access — data category request | 170.315(g)(8) Application access — data category request |
| Application access — all data request | 170.315(g)(9) Application access — all data request |
| Direct Project – Stored addresses | 170.315(h)(1) Direct Project |
| Direct Project – Wrapped message success | 170.315(h)(1) Direct Project |
| Measurement/Metric | Justification |
| Transitions of Care as CCDA – Create | Counts of valid CCDAs created during the measurement period, demonstrates that the Health IT is working as expected and certified to create CCDs |
| Transitions of Care CCDA – Conformance | Counts of conforming CCDAs created during the measurement period, demonstrates that the Health IT is working as expected and certified |
| Transitions of Care CCDA Receive | Counts of invalid and /or valid CCDA received during the measurement period, demonstrates the ability of the IT to detect valid/invalid CCDA |
| Transitions of Care CCDA Display | Counts of CCDAs grouped by R1.1 and R2.1 demonstrates the ability of the IT to handle both releases |
| Transitions of Care CCDA Display section order | Our technology is able to save the display preferences of the application. Counting the number of times this activity took place, during the measurement period demonstrates functionality |
| Clinical information reconciliation and incorporation | Our technology automatically matches the patient to the ToC and has the user verify the match and sets the auto-match flag true. Counting cases that the flag is set to true, and the page the action was performed on, during the measurement period, demonstrates that the product is working as expected. |
| Electronic prescribing | Getting counts of prescriptions, during the measurement period, that were successfully received by the service provider and not rejected, that contained units in mL as well as quantity, demonstrates this function. |
| Data export | Our application allows the user to choose the instances, date range and location of the destination of the export. Therefore reporting counts of summaries created, grouped by date range and destination demonstrates this function. |
| Clinical quality measures (CQMs) — record and export | Reports of patients by the CQM including status (Met, Unmet and Exclusion, with reason medical, Patient, System) demonstrates that the Health IT is working as expected and certified for this function. |
| VDT – View | Counts of occurrence(s) during the measurement period demonstrate that the function is working as expected for viewing data. |
| VDT – download and Transmit | Counts of occurrence(s) during the measurement period demonstrate that the function is working as expected for downloading or transmitting data |
| VDT – Activity Logging | Counts of occurrence(s) during the measurement period demonstrate that NTP time stamp and user activity logging is working. |
| Creation of syndromic surveillance messages | Since our technology validates messages on creation, getting counts demonstrates that the function is working. |
| Transmission to public health agencies | Counts of eligible cases generated and transmitted during the measurement period illustrates that this function is working. |
| Application access — patient selection Success | If we receive, validate the request, issue a token that is used subsequently for data exchange, we demonstrate that this function is working and our documentation is on point. |
| Application access — patient selection failed | If we receive, validate the request, do not issue a token if the request is not to syntax, we demonstrate that this function is working and documentation is on point, but the requester made an error. |
| Application access — data category request | If we receive, validate the request, issue a token that is used subsequently for data exchange, we demonstrate that this function is working and documentation is on point. |
| Application access — all data request | If we receive, validate the request, issue a token that is used subsequently for data exchange, we demonstrate that this function is working and documentation is on point. |
| Direct Project – Stored addresses | Storing direct addresses to the database during the measurement period demonstrates this function |
| Direct Project – Wrapped message success | Counting wrapped messages transmitted during the measurement period demonstrates this function |
| Care Setting | Justification |
| Ambulatory Medical Clinic | Ambulatory Medical Clinic (Urology Clinics) Note: Our application is specific to the practice of Urology |
| Measurement/Metric | Expected Outcomes |
| Transitions of Care as CCDA – Create | That CCDA messages were successfully created with no errors |
| Transitions of Care CCDA – Conformance | That CCDA messages created conform to B(1) requirements |
| Transitions of Care CCDA Receive | That the CCDA messages were successfully received, reconciled and data incorporated with no errors |
| Transitions of Care CCDA Display | That the CCDA messages were successfully received and displayed |
| Transitions of Care CCDA Display section order | That the CCDA messages were successfully received, order of sections displayed with no errors |
| Clinical information reconciliation and incorporation | That the CCDA messages were successfully reconciled, and data incorporated with no errors. |
| Electronic prescribing | The prescriptions in the measure were successfully transmitted and acknowledged by the recipient service provider. |
| Data export | That summaries were successfully exported and transmitted without errors, and final destination recorded. |
| Clinical quality measures (CQMs) — record and export | Data was successfully exported and error free. |
| VDT – View | Data was successfully viewed and error free |
| VDT – Download and Transmit | Data was successfully downloaded or transmitted and error free |
| VDT – Activity Logging | Data viewed, successfully downloaded or transmitted, contains user and timestamp |
| Creation of syndromic surveillance messages | Messages were successful created to HL7 2.5.1 standard and there were no errors |
| Transmission to public health agencies | Messages were successfully transmitted without errors |
| Application access — patient selection Success | Greater than 99% of the requests made per Health IT’s documentation, resulted in successful issue of a token |
| Application access — patient selection failed | Greater than 99% of the requests made per Health IT’s documentation, resulted in successful issue of a token |
| Application access — data category request | Greater than 99% of the requests made per Health IT’s documentation, resulted in successful issue of a token and exchange of data for the requested parameters. |
| Application access — all data request | Greater than 99% of the requests made per Health IT’s documentation, resulted in successful issue of a token and exchange of data for the requested parameters. |
| Direct Project – Stored addresses | Greater than one each of address and domain bound Direct addresses are stored without errors |
| Direct Project – Wrapped message success | Messages are successfully sent to third parties |
| Key Milestone | Care Setting | Date/Timeframe |
| Complete RWT Development | Ambulatory Medical Clinic | Nov 30 2021 |
| Test RWT plan | Ambulatory Medical Clinic | Dec 15 2021 |
| Implement RWT Plan | Ambulatory Medical Clinic | Jan 2 2022 |
| Report Results to SLI | Ambulatory Medical Clinic | Jan 6 2023 |
The Real World Testing plan must include the following attestation signed by the health IT developer authorized representative.
Note: The plan must be approved by a health IT developer authorized representative capable of binding the health IT developer for execution of the plan and include the representative’s contact information.
This Real World Testing plan is complete with all required elements, including measures that address all certification criteria and care settings. All information in this plan is up to date and fully addresses the health IT developer’s Real World Testing requirements.
Authorized Representative Name: Ashu Kataria
Authorized Representative Email: Ashu.Kataria@inpracsys.com
Authorized Representative Phone: 612-455-6789
Authorized Representative Signature: Digitally Signed Ashu Kataria for InPracSys
Date: 10/8/2021
A state-of-the-art, innovative and complete healthcare IT solution designed to help clinics excel.
This Health IT Module is compliant with the ONC Certification Criteria for Health IT and has been certified by an ONC-ACB in accordance with the applicable certification criteria adopted by the Secretary of Health and Human Services. This certification does not represent an endorsement by the U.S. Department of Health and Human Services.
Additional cost information can be found here.
© 2024 InPracSys. All rights reserved
Find out how our intuitive, easily customizable EHR can seamlessly integrate into your ideal workflow.
Easy, affordable and completely customizable, InPracSys EHR was built with your practice in mind.
InPracSys' intuitive billing feature allows your team to submit claims efficiently, saving you both time and money.
Find out how you can embed Meaningful Use 2 into your workflow with InPracSys.
Take a moment to complete this questionnaire, so we may tailor our demo to address your specific needs.