Data Export Use Cases

Data Export Use Cases Drummond Group

One of the most important criteria of the ONC 2015 Edition is the Data Export (170.315(b)(6)). This requirement satisfies the definition of 2015 Edition Base EHR and the CEHRT, and b.6 is a necessary criterion for participation in the MIPS and Meaningful Use Quality Payment Program.
ONC also has emphasized its value in providing a valuable means of achieving data sharing and interoperability. With the CMS MIPS Quality Payment Program now requiring clinicians to attest to preventing health information blocking, a robust and usable Data Export functionality is essential to the modern health IT system. However, many developers do not fully understand the ramifications and use cases of this important criterion.

Use cases

Data Export is just that: exporting patient data from a health IT system to be shared with other clinicians and health care entities. The criterion requirements address how the data is to be selected and exported. Beyond passing the ONC criteria for certification, Data Export enables sharing of patient health data. Some of the use cases of Data Export are:
Connecting to a clinical registry to assist in disease tracking and improvement of quality of care through benchmarking and other analysis. Clinician works with a specialized registry to analyze patient data.
Feeding a data warehouse to complete its Quality Reporting for MIPS. The certified health IT captures all the demographic and clinical information necessary for quality reporting, then exports the patient data as C-CDA files to be delivered to the QCDR or Qualified Registry.
Interfacing with HIE to support an ACO. Many clinicians work with an accountable care organization (ACO) to participate in an advanced alternative payment model (APM) through the CMS Quality Payment Program. Large volumes of data are often necessary to help clinician groups achieve their APM goals.

Additional guidance

When developers understand how a criterion can support its customers, they can better develop their health IT system. Drummond Group has a more detailed whitepaper on understanding and implementing Data Export, including a breakdown of the requirements and expanded use-case examples. This material, along with FAQs, whitepapers and access to our world-class test proctors, is available to developers who fully enroll for 2015 Edition Testing and Certification. Sign up now at www.drummondgroup.com.
 
 

Data Export Design Considerations (expanded whitepaper)

One of the most important criteria of the ONC 2015 Edition is the Data Export (170.315(b)(6)). This requirement satisfies the definition of 2015 Edition Base EHR and the CEHRT, and b.6 is a necessary criterion for participation in the MIPS and Meaningful Use Quality Payment Program.
ONC has emphasized its value in providing a valuable means of achieving data sharing and interoperability. With the CMS MIPS Quality Payment Program now requiring clinicians to attest that they do not engage in health information blocking, a robust and usable Data Export functionality is essential to the modern health IT system. However, many developers do not fully understand the ramifications and use cases of this important criterion.
This whitepaper provides an overview of the requirements of this criterion and also illustrates how it can be used in modern health IT workflows and use cases. Though ONC regulations provide the outline of the features necessary to implement Data Export, quality design and viable usability cannot be achieved simply by following a test procedure. This requires an understanding of intended customer use cases.
The examples provided here are for illustrative purposes and should not be consider mandatory for ONC certification, nor can the examples be a substitute for feedback from existing customers on their specific needs. However, this whitepaper can help in understanding the purpose and use of Data Export to assist developers in creating a quality health IT system.

Checklist of criteria requirements

The Drummond Group’s overview sheets provide an excellent look at the requirements of this criterion, including references to the necessary standards and ONC background on this criterion from the preamble section of the 2015 Edition Final Rule, but the criterion requirements are listed below:

  • Clinical content, patient(s) selection, and document structure.
    • Creates export summaries as C-CDA vs 2.1 CCD documents containing the Common Clinical Data Set (CCDS) and other required elements.
    • Capability of exporting a single patient summary or multiple patient summaries or all patient summaries.
    • Selection of summaries to export can be configured with start and end date and time range.
      • Attributes or data elements (e.g., encounter dates, effectiveTime elements within C-CDA sections, etc.) used in identifying summaries fall within the range.
  • Specific choice of data elements to use in timeframe selection is not explicitly defined and left to the developers.
  • Export time of selected and identified summaries can be configured.
    • On-demand to export now in the present.
    • Scheduled for a future date and time.
      • For example, export the selected summaries tomorrow at 2:00 AM
    • Recurring on a relative date and time.
      • For example, all encounters seen in last 7 days every Sunday night at 11.
    • Export of summaries can be downloaded or accessed at a storage location defined and easily accessible by the user.
      • For example, exported and saved to a folder on local drive of user’s computer.
    • High level of user access and control.
      • Capability of exporting on demand without developer assistance.
      • Access to export capability limited to administrators or specific set of identified users.
    • Security and performance features apply.
      • User access control and access time-out.
      • Auditing and audit log.
      • Integrity – hashing of the C-CDAs or exported file.
      • Standard QMS and Accessibility-centered design criteria apply.

Potential use cases

Below are three possible use cases for the data export capabilities in a modern health IT environment. The use cases are meant only to illustrate the goals and intent of this criterion.

Connecting to clinical registry

To assist in disease tracking and improvement of quality of care through benchmarking and other analysis, a clinician works with a specialized registry to analyze patient data.
The clinician uses the registry as needed and configures exports based on specific dates. Clinician configures the health IT to export patient summaries based on a specific start date and end date of encounters and other patient engagement. The summaries are exported by the clinician at the time of operation and stored on the secure repository in the practice setting. The clinician then uploads the patient data to the specialized registry for analysis and benchmarking.

Feeding QCDR /data warehouse for Quality Reporting

To compete its Quality Reporting for MIPS, a developer works with a Qualified Clinical Data Registry (QCDR) or Qualified Registry to report quality reporting. The certified health IT captures all the demographic and clinical information necessary for quality reporting, then exports the patient data as C-CDA files to be delivered to the QCDR or Qualified Registry.
Let’s say the clinician has a performance period of a full calendar year but wants to evaluate results every month on the past three months. Health IT is configured to export the patient records for encounters from the past three months on the first Tuesday of each month at 12 a.m. EST.
Using these data export capabilities, the health IT exports this data to a shared directory system that the QCDR or Qualified Registry system can access and obtain the C-CDA files for process and quality analytics.
After the end of the calendar year performance period, the clinician configures the health IT to export all patient data involving encounters from January 1 to December 31 of the past year. The file are exported to the same shared folder for the QCDR or Qualified Registry to access, calculate, and then report to CMS.
By using this method, the eligible clinician can also meet the CMS definition of end-to-end electronic reporting within the MIPS program to qualify for the reporting bonus.

Interfacing with HIE to support an ACO

Clinician is working with an accountable care organization (ACO) in an advanced alternative payment model (APM) through the CMS Quality Payment Program. To support the efforts and initiatives of the Advanced APM, the clinician needs to submit C-CDA files each day to the health information exchange (HIE) utilized by the ACO.
Clinician configures the health IT to export patient summaries for patient encounters from that day every night at 11:00 EST. The summaries are exported and then delivered to the HIE via Direct or another transport exchange mechanism each evening.

Major challenge points

Any and all design decisions to implement Data Export criterion are left to the developer. Though the points below are not normative testing requirements, some areas of consideration in implementing this criterion are as follows:

  1. Patient selection methodsIdentifying a single patient to export is easy, and selecting all patients in the system to export is not very difficult. Providing a robust means for selecting specific sets of patients based on date-time elements is more challenging. Developers should consider thoughtful design to how to best select patients, especially with time frame constraints and a recurring export feature.
    One idea for implementation is to use the patient list selection functionality from the old 2014 Edition criterion of Patient List Creation (§ 170.314(a)(14)). Though this criterion is no longer part of the 2015 Edition scheme, its functionality of using date and time to identify various patients can be leveraged and adjusted to align with the timeframe selection feature of Data Export. Also, a developer could leverage some of this same patient filtering capabilities to the CQM-Filter criterion ((§ 170.315(c)(4)), which is needed for some ACO efforts.
  1. System performanceThe execution of creating and exporting a vast number of patient records is not a light use of computing resources. Software architects should consider how having to create a large number of C-CDA patient records will affect performance.
    Developers are permitted to put some reasonable technical constraints on this export capability in light of overall performance, for example, exporting of patient counts over 5,000 is done only at off-hours (e.g., 2 a.m.). However, any limitation would need to be disclosed on the mandatory disclosures for certification. Also, developers should discuss this with their test proctors in advance before adding specific limitations.
  1. Usefulness of the designAs alluded to previously, MIPS requires clinicians to attest that they supported health information exchange and prevented information blocking to the extent under their control. Thus, clinicians need to be able to get the clinical patient data they need from their system to share it with other health care professionals and organizations or run the risk of being forfeit to MIPS positive payment adjustments.
    Because of that, clinicians need a Data Export feature that is usable for their real-world needs. The use cases provided in this whitepaper are intended to illustrate clinical use cases, but developers should ultimately seek feedback from their users to properly design this capability.

 
 

Privacy Preferences

When you visit our website, it may store information through your browser from specific services, usually in the form of cookies. Here you can change your Privacy preferences. It is worth noting that blocking some types of cookies may impact your experience on our website and the services we are able to offer.

Click to enable/disable Google Analytics tracking code.
Click to enable/disable Google Fonts.
Click to enable/disable Google Maps.
Click to enable/disable video embeds.
Our website uses cookies, some from third-party services. Define your Privacy Preferences and/or agree to our use of cookies.