2022 Real World Testing: CareVue

CareVue

GENERAL INFORMATION

Developer Name: CareVue, a Division of Medsphere Systems Corporation

Plan Report ID Number: RWTP-0000250

Product Name(s):  

  • CareVue
  • OpenVista CareVue

Version Number(s):

  • CareVue v.2.1
  • OpenVista CareVue v.2

Product List (CHPL) ID(s):

  • CareVue – 15.04.04.2806.Open.02.01.1.210401
  • OpenVista CareVue – 15.04.04.2806.Open.02.00.1.171108       

ONC-ACB Certification ID:

  • CareVue – 15.04.04.2806.Open.02.01.1.210401
  • OpenVista CareVue – 15.04.04.2806.Open.02.00.1.171108

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 notificationNot 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 CriteriaRequirement
170.315(b)(1) Transitions of care Send transition of care/referral summaries
Receive transition of care/referral summaries
170.315(b)(2) Clinical Information Reconciliation and incorporation         Reconcile transition of care summary
170.315(h)(1) Direct Project Transmit summary using one of the methods of direct exchange
170.315(e)(1) View, download and transmitDownload ambulatory summary or inpatient summary using CCD Template
Download of transition of care/referral summaries
Transmit to third party
Transmit transition of care/referral summaries

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 CriteriaRequirement
170.315(b)(6) Data Export        Create an export file (real time) single and batch  
Create an export file (scheduled) single and batch

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 CriteriaRequirement
170.315(b)(3) Electronic Prescribing        Create and transmit prescriptions electronically  

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 CriteriaRequirement
170.315(f)(1) Transmission to Immunization RegistriesTransmit VXU message to external entity
170.315(f)(2) Transmission to Public Health Agencies – Syndromic Surveillance        Transmit ADT message to public health agency.
170.315(f)(3) Transmission to Public Health Agencies – reportable laboratory tests and value/resultsTransmit ORU message to external entity
170.315(f)(7) Transmission to Public Health Agencies – health care surveysTransmit CDA for survey purposes

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 CriteriaRequirement
170.315(c)(1) – record and exportExport a QRDA Cat 1 file

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 CriteriaRequirement
170.315(g)(7) Application Access- patient selectionAPI query for patient
170.315(g)(8) Application Access – data category request        API query for data related to specific category for patient
170.315(g)(9) Application Access – all data request API query for all data related to patient

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 MilestoneDate/Timeframe
Deployment of code allowing ability to capture additional information in system logs.    Feb 2022
Begin collection of data laid out by plan for all measures excluding e-prescribing      March 2022
Begin collection of data of e-prescribing measure      July 2022
Deployment of code allowing ability to capture additional information in system logs needed for the e-prescribing measure only.    July 2022
Data Collection and ReviewQuarterly
Certification Update to Cures Test MethodsQ3
End of Real World Testing for all measures.December 2022
Final data review and analytics, create results reportJanuary 2023
Submit Real World Testing Results Report to ACBJanuary 2023

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:  November 4, 2021