QRDA+Category+3+Analysis+-+Query+Health

include component="page" wikiName="siframework" page="Query Health Header" toc =Introduction=

The purpose of this Quality Reporting Document Architecture (QRDA) Category 3 analysis was to look at the possibilities surrounding QRDA Category 3 documents and how they might be used in the context of the S&I Framework Query Health initiative. For this specific analysis, we reviewed QRDA Category 3 fit to support query and results expression, as as interface with a common clinical information model.



Assumptions
Several assumptions underlie this analysis:
 * This analysis is limited to a hypothetical view of how the query of a QRDA Category 3 document might work; a more complete analysis will be based on the agreed upon Query Health User Stories.
 * QRDA Category 1 and Category 2 are not considered.
 * The CIM developed in support of using QRDA would NOT be a RIM-based model.

Scope
The specific request being analyzed in the context of the Query Health Initiative is:
 * What are the potential strengths and limitations of using QRDA Category 3 for results reporting?
 * What other standards should be analyzed beyond QRDA?

The guiding principle within this scope was the concept of "sending questions to the data". Thus, if the data is stored in a QRDA Category 3 document, how is it pushed into a specific store and then how can the data be queried. Additional standards are covered at the end of this document for the purposes of possible analysis in addition to QRDA. Each will require deeper analysis to be conducted. =Initial Conclusions= __**The initial conclusion in evaluating QRDA Category 3 as a possible query mechanism for Query Health is that it would work within the context of the possible use case defined in the Query Health charter:**__

Generalized Query & Result using a Quality Measure __**Because each of these user stories would be expressing information in a measure set(s), it is possible to query this information from a QRDA document.**__ =What is QRDA?= The QRDA is an electronic format that shares a common set of data types and model and vocabulary with electronic health records that use the CDA to express clinical documents. As such, it creates CDA-based XML documents that can be parsed and reviewed. There are 3 categories of QRDA documents to consider, but for the purpose of this hypothetical analysis, only Category 3 is considered, consistent with the unique set of requirements for the Query Health initiative.

A QRDA Category III report is an aggregate quality report. Each report contains calculated summary data for one or more measures for a specified population of patients within a particular health system over a specific period of time. Whereas a QRDA Category I report contain data for individual patients, a QRDA Category III report only contains calculated data (e.g., number of meeting numerator criteria, number of meeting denominator criteria) on the population.

Measure Set Usage
Measure sets can be created that would be queried by an EHR to produce answers to specific questions generated from a clinician. By using measure sets, it would avoid duplicate collection of raw clinical data for a patient for individual quality measures (known as eMeasures) as some of the quality measures require similar type of clinical data. The Measure set used would simply be a collection of measures stored within the QRDA document, and associated patient data. It is important to note that the assumption used in this analysis is that the measure set might not just contain measure-specific data, such as eMeasures, but might contain specific aggregated data (such as other CDA Documents that store data associated with the measure set. This would allow for a broader set of data to be available for query.

Because the QRDA is based off of CDA, the information contained in CDA-level documentation can be queried directly. Whereas a QRDA Category I and a QRDA Category II report contain data for individual patients, a QRDA Category III report only contains calculated data (e.g., number of meeting numerator criteria, number of meeting denominator criteria) on the population that is being queried. This appears to fit quite closely with the intent of the Query Health initiative, as this removes the burden of calculation from the requester who is sending the query. =Current Pilots= The New York eHealth Collaborative has done pilot work using Category 3 that can be further studied and leveraged in case of possible usage by the Query Health initiative of QRDA. This pilot work cannot be studied in the timeframe of this analysis but will be looked at closely in the context of the Harmonization phase of the S&I Framework. An example of how the Universal Public Health Node (UPHN) works regarding distributed queries is shown below. This sequence diagram outlines a similar method to that described in the Query Health charter:



Additional distributed query pilots, such as i2b2/SHRINE, PopMedNet/ESP, and DARTNet, will also need to be analyzed in the context of QRDA. These implementations do not use explictly defined standards like QRDA but have created their own level of mapping and data model representation. =Possible QRDA Approach to Query Health=

In analyzing QRDA as a possible option for the Query Health Use Case, a possible approach was laid out whereby QRDA could be analyzed through some type of testing mechanism, to further validate this approach. The approach used was to create a set of possible workflows using QRDA, based on information already contained in the Query Health charter. The workflow would then be applied to a UML component diagram (similar to the one used in the Query Health charter and shown above). This could then be analyzed for possible strengths and limitations of the QRDA approach.

Data Push Workflow
This workflow covers the concept of an EMR "data push", which in the case of QRDA would be a QRDA Category 3 document:
 * Create a standard XML definition for Query Health - creates a measure set within a QRDA document (HQMF as an example for the creation of an eMeasure). Each instantiation of the measure document will include vocabulary and where in the EHR these things can be found
 * Present query to hybrid (clinical information system, administrative system, human, data warehouse …) – so EHR can create a query (e.g., SQL) to an EHR. The "hybrid" in this case is data from other Query Health "nodes" that are needed to provide the information that would populate the measure set. **This step in the workflow is key because any distributed query would suffer from a problem in that the processing entity has to have enough data to answer the query sent; otherwise, other queries would have to be sent to other Query Health nodes to collect this data.**
 * Define what the content needs to be in each measure set- derived from the hybrid information system
 * The standard XML definition for the measure set would use the same terminology and EHR context as the content described for Query Health XML definition
 * Create QRDA Category 3 document
 * Instantiate a measure set (in measure-specific document). This might also include patient-level data relevant to the measure in the document (all denominator, numerator, exclusion/inclusion criteria data elements)
 * Run Schematron against QRDA to validate the QRDA contents (assume Patient-level and/or aggregate)

Query Workflow
For the actual query to occur of the QRDA measure set, some mechanism would have to exist that would allow for the querying of the data directly. There are two possibilities that could be considered (and that will be discussed during the Harmonization phase of the S&I Framework)
 * CIM Object representation of the QRDA Category 3 document would be queried. The CIM Object would be tied to specific sections of a CDA document at the template, section, and entry level and the data elements within the CIM could potentially be queried. This option would require further testing and analysis as the TOC CIM has just neared completion and is entering a pilot phase. The CIM in this case would have to be some mechanism that maps the standardized patient record (such as that within a CCD) to allow for standardized services to query and return results to authorized users. The TOC CIM is reusable in this instance.
 * Direct query of the QRDA document would need to occur. This could be done using the IHE QED profile. Query Existing Data (QED) is one of the integration profiles that support dynamic queries for clinical data. QED defines a use-case in which a clinical consumer system queries a clinical source system for clinical information. QED defines different types of queries that are all patient centric. A clinical consumer system might request various types of clinical data for a specific patient, including vital signs, allergies, medications, immunizations, diagnostic results, procedures, and visit history. A QED profile leverages HL7 domain standards for the content model, and it leverages the common HL7 messaging formats for conveying both query and result. The response is composed of clinical statements, such as CDA snippets, that describe clinical data according to the query's parameters

High Level View
This high level view takes the diagram defined in the Query Health charter and expands it out further to detail how a possible distributed query might work using QRDA.

What this approach would imply is that the following would be needed to support QRDA:
 * QRDA Category 3 documents generated to support measure sets
 * Some processing entity that would store the QRDA document (the Query Health node)
 * A common way to query the QRDA document (IHE QED is one possible profile)
 * A CIM that overlays the processing entity's data store and allows for possible querying of the CIM to gather the underlying data.

__**All these outputs are possible using the QRDA Category 3 approach and based on an analysis of strengths and limitations (shown below), QRDA should be considered as a possible standard for the S&I Framework Query Health initiative.**__ =Strengths of QRDA Approach= There are several apparent strengths of this approach: =Limitations of QRDA Approach= =Other Standards to Consider= This level of high-level analysis is limited to just QRDA. Additional analysis of this type will be conducted prior to the start of the Harmonization phase of the S&I Framework for the following standards: Data Model || As a basis for building out the Query Health CIM || need to be defined || of measure sets ||
 * Existing Transitions of Care (TOC) Clinical Information Model (CIM) draws from CDA and can serve as a reference to developing CIM objects for Query Health. Each of the TOC CIM Objects are aligned to specific CDA sections and templates. A similar approach could be adopted for a QRDA document since it is CDA-based.
 * A QRDA document is essentially a XML document, which could be rendered on any web browser using the standard style sheet supplied by the CDA R2 standard. Thus, additional options for representing QRDA data (for example, pulling it from web pages) is possible. This may be necessary to support the population of measure sets from Query Health nodes.
 * If an EHR can generate a CCD, it should be able to interpret formal eMeasure criteria within the Measure Set section of a QRDA document.
 * The future use of Templated CDA would be supported, to allow for the EHR interface to be defined such that it can be queried and such that it can report out directly.
 * Many of the data elements in a QRDA document will require judgment calls with respect to whether EHR-available data are useful and sufficient to express the intent of the element and the context intended by the QRDA document developer. This is where the importance of some type of Clinical Information Model (CIM) will become apparent.
 * Some of the data elements in measure sets will not have clear EHR or electronic codified data concepts. To accommodate such items, we would need to allow for the EHR to use some type of profile to fill data. The proposal might be to allow EHRs to auto fill what is possible and enable human filling of information not in codified standard form. This would still allow for the development of measure sets that could be queried. A possibility here is the IHE RFD profile to auto-fill data in the EHR.
 * The information exchanged may be vastly different among various specialties and/or regions, and a format like QRDA has not been tested on this scale. These regions and specialties would need to agree to some core vs. optional measure set to support the idea of using QRDA documents for common measure sets.
 * The workflows may be vastly different among various specialties and/or regions, thus precluding a common set of transactions as defined in the Query Health charter. Note that this is a specific problem for all possible standards under consideration in the Query Health initiative.
 * **Standard Name** || **Level of Analysis** ||
 * OMOP Common
 * IHE QED || Ability to directly query QRDA documents ||
 * IHE RFD || Ability to support QRDA by allowing for some level of automated EHR data population ||
 * SDMX || Another possible way to aggregate and query data (the query mechanism would
 * HQMF || Used to capture measures in electronic format, and would form the basis for development
 * hQuery || JSON based method to store an array of CCD data, and a mechanism to query it rapidly. ||

include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"