Products
Who We Serve
GENERAL INFORMATION
Developer Name: CareVue, a Division of Medsphere Systems Corporation
Product Name(s):
Version Number(s):
Product List (CHPL) ID(s):
ONC-ACB Certification ID:
Developer Real World Testing Page URL: https://www.medsphere.com/certifications/realworldtesting/carevue/
JUSTIFICATION FOR REAL WORLD TESTING APPROACH
At this time, CareVue is marketed to the small rural inpatient hospital systems. Therefore, the Real World Testing plan will apply to this care setting. We feel it is best to test functionality as a whole workflow rather than by individual measure as this is how it is utilized in the real world. Our Real World Testing approach will consist of five main components, Electronic exchange of information for Care Coordination and Patient Engagement, E-Prescribing, Clinical Quality Measures and Population Health, and Application Programming Interfaces.
Electronic exchange of information for Care Coordination and Patient Engagement
CareVue has developed functionality and created a best practice workflow around sending, receiving, reconciling, and exporting electronic health information. This workflow will allow us to test several certification criteria simultaneously. All criteria involving the Consolidated Clinical Documentation Architecture (C-CDA) documents will be tested, including 170.315(b)(1) Transitions of Care, 170.315(b)(2) Clinical Information Reconciliation and Incorporation, 170.315(b)(6), 170.315e(1) View, download, and transmit to 3rd party, Data Export and 170.315(h)(1) Direct Project.
Electronic Prescribing
CareVue has also developed functionality for e-prescribing. It is in our best interest to supply our users with the tools needed to provide fast and efficient mechanisms for patient care. We feel that it is vital to be able to monitor the transmissions of e- prescription activity flowing from the facility to the pharmacy. This plan incorporates the testing of 170.315(b)(3) e-Prescribing.
Clinical Quality Measures
To allow eligible hospitals to submit data related to their Clinical Quality Measures, we have developed functionality that enables users to create and export QRDA files and submit them. We also understand that QRDA files may only be created during 1st quarter of each calendar year due to when clients are submitting the data as part of their attestation, so it is anticipated that our Real World Testing Plans would be most active during Q1. This plan includes testing of 170.315(c)(1) record and export.
Population Health
As the product is targeted for inpatient hospital systems, in which a wide variety of patient ailments are seen and across multiple populations, we find it important to be able to transmit specific data to these external entities. Being able to efficiently transmit certain clinical information to external specialized registries is foundational to population health. This plan will also incorporate the testing of 170.315(f)(1) Transmission to immunization registries, and 170.315(f)(2), Transmission to public health agencies – Syndromic surveillance, 170.315(f)(3) Transmission to public health agencies – reportable laboratory tests and value/results and 170.315(f)(7) Transmission to public health agencies – health care surveys.
Application Programming Interfaces
CareVue has also developed Application Programming Interfaces to enable ways for our providers to communicate and transfer data to external systems. CareVue also will test multiple measures simultaneously around the criteria involving Application programming interfaces, including 170.315(g)(7) Application access- patient selection, 170.315(g)(8) Application access-data category request, and 170.315(g)(9) Application access – all data request.
STANDARDS UPDATES (INCLUDING STANDARDS VERSION ADVANCEMENT PROCESS (SVAP) AND UNITED STATES CORE DATA FOR INTEROPERABILITY (USCDI))
This product utilizes all standards associated with the 2015 certification methods.
| Standard (and version) | Not applicable |
| Date of ONC-ACB notification | Not applicable |
| Date of customer notification (SVAP only) | Not applicable |
| USCDI-updated certification criteria (and USCDI version) | None |
MEASURES USED IN OVERALL APPROACH
The following outlines our measures that have been identified to best demonstrate how our product is in and maintains conformance to multiple certification criteria.
Electronic exchange of information for Care Coordination and Patient Engagement
Measure 1 (Care Coordination Exchange Thresholds and Mechanisms)
As part of the Real World Testing requirements for 170.315(b)(1) Transitions of Care, 170.315(b)(2) Clinical Information Reconciliation and Incorporation, 170.315(b)(6), 170.315e(1) View, download, and transmit to 3rd party, Data Export and 170.315(h)(1) Direct Project, this measure will assess the sending and receiving of CCD-A documents, reconciling information received through the CCD-A, the methods of transmission for information shared between providers.
Metric 1 – This metric will determine the thresholds of the types of transport mechanism used to share transitions of care documents and EHI, as well as the success rate of transmission.
Associated certification criteria for the electronic exchange of information for Care Coordination and Patient Engagement in the ambulatory care setting include:
| Certification Criteria | Associated Criteria | Relied Upon Software |
| 170.315(b)(1) Transitions of Care | Send Transition of care/referral summaries | Surescripts Clinical Direct Messaging |
| Receive transition of care/referral summaries | ||
| 170.315(b)(2) Clinical Information Reconciliation and incorporation | Reconcile transition of care summary | N/A |
| 170.315(h)(1) Direct Project | Transmit summary using one of the methods of direct exchange | Surescripts Clinical Direct Messaging |
| 170.315(e)(1) View, download and transmit | Download ambulatory summary or inpatient summary using CCD Template | Patient Portal |
| Download of transition of care/referral summaries | ||
| Transmit to third party |
Rationale: The system includes three functionalities of interest transmitting, receiving, and reconciling electronic health information, while other documents can be shared through the patient portal either encrypted or unencrypted. This metric will provide CareVue with information on the types of transmissions that are used and the frequency of the individual usages. We feel that these findings could help us determine which methods are the most advantageous to our target base and help us identify those best practices that we can target those providers with low thresholds in order to reach out to them and provide them logic as to how to increase utilization.
Test Approach 1: De-identifiable data from system logs, will be extracted to produce analytic reports that will be reviewed to determine thresholds and statues of delivery used by the providers for transmitting and receiving transitions of care.
Expected Outcome(s): It is anticipated that providers and patients will be able to share their electronic health information using the various transmission methods provided with no limitations and in compliance with the certification criteria, including the technical standards and vocabulary code sets.
Transmission statuses will be tracked and trended over time to determine efficacy utilization rates.
Test Approach 2: Event type actions of download and transmit will be extracted from system logs to determine the frequency rate of patients downloading and transmitting documents.
Expected Outcome: It is expected that patients will be able to view, download and share their information as designed and previously certified. It is also anticipated that patients will be able to transmit using the transmission methods provided with no limitations. The event types within the activity log will be tracked and trended over time ensuring that baseline thresholds are maintained
Measure 2 (Data Export Trends)
This measure will capture the success/failure events related to exporting EHI for an individual patient as well as a batch of patients in real time and for a scheduled time. The associated certification criterion is:
| Certification Criteria | Associated Criteria | Relied Upon Software |
| 170.315(b)(6) Data Export | Create an export file (real time) single and batch | N/A |
Rationale: The export of EHI is another function that enables a way to share information with external organizations. The export is typically used when a particular patient requests for their medical records or to send a batch of CCD-A for patients seen during a specific time frame to an external source such as the patient portal.
Test Approach 1: System logs reviewed to trend error rates. We will also analyze the data to validate the proper utilization and determine if there are certain timeframes which cause system performance issues when scheduling them to run in batch. This will help us identify best practices related to this functionality.
Expected Outcome: It is expected that authorized users will be able to export data without limitations and in compliance with the certification criteria, including the technical standards and vocabulary code sets. Error rates and system performances will be tracked and trended over time.
Measure 3 (e-Prescribing)
This measure will capture the success rates of electronic prescriptions. We will look at prescription activity logs to determine the number of successful transmissions.
| Certification Criteria | Associated Criteria | Relied Upon Software |
| 170.315(b)(3) Electronic Prescribing | Create and transmit prescriptions electronically | NewCrop |
Rationale: The transmission of electronic prescriptions is a function within the application that enables providers to send prescriptions to the patient’s pharmacy of choice electronically. This allows for a quicker way for prescriptions to reach the pharmacy while alleviating call backs from the pharmacy.
Test Approach: Looking at system logs of prescription activity, we will perform data analytics on the success rate of activity on a quarterly basis.
Expected Outcome: It is anticipated that users will be able to transmit prescriptions electronically without limitations and in compliance with the certification criteria. We do anticipate some failures due to network connectivity issues so we would anticipate a 10% error rate and a 90% success rate.
Measure 4 (Transmission of HL7 messages)
This measure will capture the error rates of HL7 messages being transmitted. Specifically, we will extract the ORU and VXU message types to analyze error rates related to Immunization registries and labs and extract ADT messages to analyze error rates for public health agencies.
| Certification Criteria | Associated Criteria | Relied Upon Software |
| 170.315(f)(1) Transmission to Immunization Registries | Transmit VXU message to external entity | Mirth |
| 170.315(f)(2) Transmission to Public Health Agencies – Syndromic Surveillance | Transmit ADT message to public health agency. | Mirth |
| 170.315(f)(3) Transmission to Public Health Agencies – reportable laboratory tests and value/results | Transmit ORU message to external entity | Mirth |
| 170.315(f)(7) Transmission to Public Health Agencies – health care surveys | Transmit CDA for survey purposes | Mirth |
Rationale: CareVue allows clinicians the ability to transmit certain information to external entities using HL7 standards. These message types are transmitted through an HL7 engine and logged in the system. When immunization data, lab tests and results, surveys, or communicable disease data is captured within the system, these data elements are parsed into an HL7 message and transmitted to the respective external entity. This will provide an analytical view of the success rates of transmission.
Test Approach 1: For testing of 170.315(f)(1) Transmission to immunization registries, and 170.315(f)(2), Transmission to public health agencies – Syndromic surveillance, 170.315(f)(3) Transmission to public health agencies – reportable laboratory tests and value/results.
System logs will be used to extract certain message types related to immunization and syndromic surveillance activities. Success rates of VXU message types being delivered to immunization registries, ORU message types for lab tests and results as well as ADT messages being delivered to public health agencies will be reviewed and trended.
Expected Outcome(s): It is expected that clients will be able to transmit HL7 messages without limitations and in compliance with the certification criteria, including the technical standards and vocabulary code sets. We do anticipate some clients will experience some delay on first attempt due to network connectivity so we anticipate that 90% of messages will be successfully transmitted and the 10% error rate accounts for issues with network.
For testing and 170.315(f)(7) Transmission to public health agencies – health care surveys, we have two approaches.
Approach 1: In the event we have clients using this functionality, systems logs will be reviewed to determine numeric representation of the usage. Success rates and return rates will be evaluated.
Approach 2: in the event we do not have clients using this functionality, a quarterly test will be done using test environments to ensure the product is functioning as designed and previously certified. These quarterly tests will be logged, and errors will be researched and corrected.
Expected Outcome(s): It is expected with either approach that either external or internal test systems will be able to transmit surveys without limitations and in compliance with the certification criteria, including the technical standards and vocabulary code sets.
Measure 5(Export Data File)
This measure will capture the number of successful and unsuccessful events of exporting QRDA Cat 1 files.
| Certification Criteria | Associated Criteria | Relied Upon Software |
| 170.315(c)(1) – record and export | Export a QRDA Cat 1 file | N/A |
Rationale: CareVue gives clinicians the ability to create a QRDA Cat 1 file to submit to CMS for attestation given a particular reporting period. We feel that extracting the successful and unsuccessful events will give us a numeric representation as to what is happening in the real world.
Test Approach 1: (in the event we have an active client using the functionality) System logs will be used to extract data related to QRDA exports. Success rates of these types of exports will be trended over time. We do anticipate that most of these exports will occur during Q1 as this is when the clients will report to CMS.
Test Approach 2: (in the event we do not have an active client using this functionality, Internal test systems will be used to create and export a QRDA Cat 1 file. Internal system logs will be reviewed to analyze success rates of the export function.
Expected Outcome(s): It is expected in either case that both internal and external clients will be able to export QRDA Cat 1 files without limitations and in compliance with the certification criteria, including the technical standards and vocabulary code sets. We do anticipate that most of these exports will occur during Q1 as this is when the clients will report to CMS.
Measure 6 (API Requests)
This measure will capture the volume of API transactions across the measurement period.
| Certification Criteria | Associated Criteria | Relied Upon Software |
| 170.315(g)(7) Application Access- patient selection | API query for patient | N/A |
| 170.315(g)(8) Application Access – data category request | API query for data related to specific category for patient | N/A |
| 170.315(g)(9) Application Access – all data request | API query for all data related to patient | N/A |
Rationale: CareVue has developed API’s that can be used by external entities. These API’s can be used to ping the system to retrieve certain information based on a query for a single patient, requesting specific data categories for that patient or requesting all data for the selected patient.
Test Approach 1: (in the event we have an external system using the API’s) System logs will be used to capture the success rate of API transactions over time.
Expected Outcome(s): It is expected that external entities will be able to connect to the CareVue system without error using these API’s without limitation and in compliance with the certification criteria, including the technical standards and vocabulary code sets. These successful transaction thresholds will be used to demonstrate the utilization of the API in the real world over the testing year.
Test Approach 2: (in the event we do not have any external system using the API’s). Quarterly tests will be done in a test environment to ensure the API’s are functional. This will be done by using a test system to ping the host application for each level of access and the success/failure of the ping will be captured.
Expected Outcome(s): It is expected that the test system will be able to connect to the CareVue system without error using these API’s without limitation and in compliance with the certification criteria, including the technical standards and vocabulary code sets. We anticipate that the test system will be able to perform patient/data requests successfully during each quarter. At the end of the testing year, we anticipate having 4 successful events for each of the request types.
Care Setting(s)
CareVue is marketed to inpatient hospitals, therefore, only the inpatient setting will be used for Real World Testing.
SCHEDULE OF KEY MILESTONES
| Key Milestone | Date/Timeframe |
| Begin collection of data | March 2023 |
| Data Collection and Review | Quarterly |
| Certification Update to 170.315(b)(10) | Q3 |
| End of Real World Testing for all measures. | December, 2023 |
| Final data review and analytics, create results report | January 2024 |
| Submit Real World Testing Results Report to ACB | February 2024 |
ATTESTATION
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: | Nicki Anderson, Director, Compliance |
| Authorized Representative Email: | nicki.anderson@medsphere.com |
| Authorized Representative Phone: | 760.979.6531 |
| Authorized Representative Signature: | Nicki Anderson |
| Date: | October 26, 2022 |
© 2024 Medsphere Systems Corporation
