This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

QRDA Use Cases White Paper

From HL7Wiki
Jump to navigation Jump to search

Back to the CQI Work Group Wiki

Overview

This group is focused on publishing guidance that describes the use of QRDA files for data exchange of quality information, as opposed to their original use for measure reporting.

Please view the documents on this google doc and please feel free to edit and add. We are in need of two example QRDAs that are described at the end of the "Whitepaper" document. The final product is the document "QRDA Data Exchange Whitepaper" but the supporting notes and docs are also included. Use the link below to read and download the document. The text has also been pasted below as of 11/13/2015 for convenience but please make changes to the google docs themselves.

https://drive.google.com/folderview?id=0B9vJFxyie9tSYmsySm1iRndsN28&usp=sharing

Meeting Times

  • The ballot has been submitted for the January 2016 ballot cycle. Remember to sign up to comment on the ballot by December 3, 2015
  • No further calls are scheduled at this time

Minutes of QRDA Use Cases White Paper

==Current Version== to access editable version please use googledocs link above

QRDA Exchange Whitepaper

Goals The ONC 2015 Health IT Certification Program Final Rule defines certification criteria for clinical quality measures record/export and clinical quality measure import/calculate requires exchange of QRDA documents between entities other than reporting end points. The current QRDA Category I Implementation Guide Volume 1 provides guidance on what a QRDA document should contain when being submitted to the reporting endpoint. While this guidance doesn’t prohibit other use cases, it doesn't help the industry move forward in a standard way. As other use cases gain importance (based on industry needs or regulation), there are situations where systems need to communicate information using QRDA documents but the requirements defining how the documents are created can vary with each exchange. Information from this white paper will help the workgroup determine guidance on how QRDA documents should be constructed in order to meet some of these common use cases, and if the QRDA IG should be updated to reflect the recommendations.

Examples of Quality Data Exchange Include examples of the different use cases, and if they deviated from the base guidance. 1. Registry example 2. Reporting endpoints 3. The Joint Commission IG 4. Others?

Proposed Changes to Guidance In the base QRDA guide, there are recommendations on when documents should be created and what data should be included in these documents, in section 7.2 QDM-Based QRDA Category I Construction Rules. These can be overridden by a program wanting to receive documents. The main use for QRDA documents so far has been to reporting end points, and the recommendations fit within this use case. In the case of including multiple sources of quality data, such as when QRDA documents are imported, following the guidance as directed could lead to a different quality result than if the result were calculated with all quality data about the patient.

Generate a QRDA for Which Patients? (Justin) The base recommendation (section 7.2.2 of QRDA R1 DSTU 3) of the QRDA R. A document should be sent when you have any quality data about the patient. It should include all measures you have data for. It might be possible to filter out measures that the receiving end doesn’t care about.

What Data Should be Included (Justin) In the recommendation from section 7.2.3, QRDA describes how the data in the document should follow the “smoking gun” approach.

A QRDA document created for the intent of import should include all data that could be used to calculate a measure. In practice, this would be more of a naïve dump of data, or “anti-smoking gun”. This would override the smoking gun guidance. What time periods of data should this document include when sent throughout the year? Should this be a full reporting year, or a partial year? Duration of QRDA Reporting Period (Julia) Most measure reports have a defined measurement period, often a year; however, in using QRDA for data exchange we expect that the duration of data sent and received will vary. In the QRDA, reporting timing is referenced in the “Reporting Parameters Section” (5.2).

Out of Scope There are other use cases of quality data exchange where QRDA could be enhanced or additional guidance could be provided. Currently these were considered, but were considered out, but were not included for various reasons. Documents with delta updates This problem is much more complex. For example, there is no way to say that you want to delete a data element from a previously sent document.

QRDA Header Changes At the current time, there are no sections or labels that identify a complete measure report and/or differentiate a complete report from a partial one or overburdened one. It may be possible in the future that the community identifies a need for a label that indicates the document is intended for exchange and not direct reporting. However, at the current time, there is not an identified clear need to add discretely which guidance was followed when generating a QRDA document.

Information not relevant to measures QRDA is still inherently a quality measure document. In the cases of certain registries, non-measure level information was also included. Guidance on this is not included, because this is mainly dependent would be dependent on agreements between the two systems, and there is not a general way everyone would want to format these templates.

Messages asking for QRDA This paper does not go into detail as to how to make queries based upon specific measures; however, we do not specify here as to what method the query is communicated. The messaging about the query is not described in QRDA itself, but the QRDA is the response to the query. It may be possible to send documents using formats like Direct, assuming it was communicated which patients to include and on what measures information is being requested. Other than using Direct, it is unclear how one might structure targeted queries of this type. IHE’s XDSb profile may be able to be used for this context; however, at the current time, we choose not to specify a method for transmitting queries. It may also be adequate to use direct contact with provider offices to specify the patient identifiers and scope. Some users may choose to push measure data over to other systems based on a patient relationship with the provider, which may not require a query. For example, registries may accept all relevant data from providers at a specific time frame or when the patient is seen. The measure context would still need to be established at the outset. When reporting information related to one or more measures in response to a query, it is expected that all of those measures which are supported by the system would be referenced in the Measure Section (5.1) even if no information is available. If the measure information requested is not supported; however, then that measure should not be referenced in the Measure Section.

Sample QRDAs for Data Exchange

Provider use case: Patient is going to transfer her primary care to another provider across town and both want to transfer her quality data on all measures to the new provider. This file would therefore contain as much available information as is relevant to a set of measures.


Partial measure information: Patient saw a provider while out of town but has returned and wants to bring back her quality data to another provider. It is only partial measure information but is relevant to at least one measure.