888.455.0855

TESTING

InPracSys Real World Test Plan

Background & Instructions

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.

GENERAL INFORMATION

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/

JUSTIFICATION FOR REAL WORLD TESTING APPROACH

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.

STANDARDS UPDATES (INCLUDING STANDARDS VERSION ADVANCEMENT PROCESS (SVAP) AND UNITED STATES CORE DATA FOR INTEROPERABILITY (USCDI))

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

MEASURES USED IN OVERALL APPROACH

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:

Description of Measurement/Metric

Measurement/MetricDescription
Transitions of Care as CCDA – CreateUsing data query, Count of C-CDA referral summaries created, formatted to release 2.1, during the measurement period
Transitions of Care CCDA – ConformanceUse 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 ReceiveUsing 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 DisplayUsing 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 orderUsing data query, count of referral summaries displayed where the display order was changed by the user
Clinical information reconciliation and incorporationUsing 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 prescribingCount 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 exportUsing 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 exportUsing 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 – ViewUsing 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 TransmitUsing 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 LoggingUsing 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 messagesUsing 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 agenciesUsing 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 requestUsing 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 requestUsing 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 addressesUsing 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 successUsing data query, count the wrapped messages successfully transmitted to third parties during the measurement period

Associated Certification Criteria

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

JUSTIFICATION FOR SELECTED MEASUREMENT/METRIC

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(s)

Care Setting Justification
Ambulatory Medical Clinic Ambulatory Medical Clinic (Urology Clinics) Note: Our application is specific to the practice of Urology

Expected Outcomes

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

Schedule of Key Milestones

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

ATTESTATION

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

Find out how our intuitive, easily customizable EHR can seamlessly integrate into your ideal workflow.

InPracSys EHR

Easy, affordable and completely customizable, InPracSys EHR was built with your practice in mind.

InPracSys Billing

InPracSys' intuitive billing feature allows your team to submit claims efficiently, saving you both time and money.

Meaningful Use

Find out how you can embed Meaningful Use 2 into your workflow with InPracSys.