PH+Reporting+User+Story+-+Quality+Reporting

include component="page" wikiName="siframework" page="PHRI Header" =User Story: Quality Reporting=

Contact Info:
John Page (john.page@agilex.com, phone: 703.889.3977) -- Agilex Aleena Dhar (aleena.dhar@agilex.com, phone: 703.889.3187) -- Agilex

Date Received:
11/18/2011

We are submitting the Quality Reporting User Story for consideration by the ONC S&I Framework Public Health Reporting Initiative (PHRI). Although the CMS is providing guidance in Meaningful Use for automated reporting of health quality measures from EHRs on a national level, there is less guidance for how such measures should be shared with state and local level. This user story attempts to provide a more formalized description of how Health Quality Measure data can be shared with state and local Public Health Agencies (PHAs).
 * 1.1 Introduction**

In the process of identifying the potential user stories, the need to create a high level use case model is realized that would help in describing the PHRI problem space in depth, and manage user stories that might be common to all reporting activities. These user stories have been submitted in a separate document entitled PHRI User Story Model, which has been submitted as a separate document. We have also provided a table of acronyms at the end of the document. We apologize for any unintentional errors we have introduced in our effort to create these user stories, and welcome any suggestions for their improvement.

The 44 quality measures defined for Stage 1 Meaningful Use form part of a more ambitious effort by the CMS and National Quality Forum (NQF) to automate the reporting of health quality measures from EHRs. Automated reporting will reduce the resources needed for care delivery organizations, and also reduce the bias introduced by manual interpretation. Health Quality reporting offers several benefits to public health, including tracking the application of best practices, encouraging savings through preventive care, and avoidance of costly and avoidable conditions. Currently, the primary recipient and beneficiary of quality reporting will be the CMS. Although States may specify how they can receive health quality data as part of their State Medicaid HIT Plans (SMHPs), there is little guidance for the states to identify how they can collect or use this data, and, based on an informal survey of several SMHPs, many are not prepared to receive it. The goal of this user story is to specify a standardized state/local health quality reporting capability so that State and local PHAs may be able to pool resources and share common capabilities, and create a “catcher’s mitt” so that they can better benefit from Health Quality reporting under Stage 2 Meaningful Use.
 * 1.2 User Story Narrative**
 * 1.2.1 Goal**

The abstract model illustrated in Exhibit-1 depicts reporting of standardized health quality measures from a source (a provider, practice, facility) to a PHA.
 * 1.2.2 Abstract Model**

**Exhibit-1: Health Quality Measure Reporting Abstract Model**

//Pre-Conditions://
 * 1.2.3 Description of Data Reporting Events, Actors and Triggers**
 * The State Medicaid HIT Plan (SMHP) has identified at least one recipient PHA for receiving the reports’
 * Registration User Story has been completed that has defined the reporting relationship between the care provider and the PHA receiving the data, included the type, mode, and frequency of reporting, the appropriate encryption strategy is in place, and that any necessary data use agreements are in place.

//Assumptions://
 * The scope of this user story only addressed Health Quality Measures that have been approved under the current state of Meaningful Use.
 * The EHRs at the provider facility have been certified and meet the reporting requirements for automated quality reporting.
 * The strategy for WHERE the data is to be sent, and how to be shared by all PHAs in the State should be defined in the State Medicaid HIT Plan

//Primary Actors:// Since the reports will be sent on a chronologically triggered process, these actors will not be consciously initiating the health quality report. The true “actor” initiating the activity is either the EHR or a reporting system integrated with the EHR. || PHA Analyst || Agents at the PHA responsible for interpreting and acting upon the data. ||
 * **Actors** || **Description** ||
 * Patient Admissions Specialist Provider || The patient, admissions specialist, and care providers at the source are listed as actors here since they are providing much of the information that is used to calculate health quality measures.
 * PHA Official

//Events and Triggers:// Reporting is to be triggered chronologically, based on the reporting frequency established in the Registration user story. Many of the measures tend to require that an encounter has been completed in order to be effective.

The PHAs would benefit from a standardized capability to “catch” the reports, and convert them to a format that would be readily assimilated into a database or analysis program. While this capability may no

//Use by Public Health:// At the basest level, the states have a need to determine which care providers have been reporting this data to determine Medicaid incentive payments. However, many state and local PHAs have a keen interest in harnessing this data for their own public health initiatives. Of the 44 current measures, and the 113 eMeasures defined to date, many are applicable to public health initiatives at the state and local level. Data reported on preventive care measures for cardiovascular risks, such as use of aspirin therapy, blood pressure and cholesterol screening and control will be of use to state cardiovascular health programs, and grants from the Prevention and Public Health Fund. Measures on counseling for tobacco cessation would be useful in supporting local programs for reducing tobacco use. Weight assessment and counseling also addresses a large source of preventable conditions. Prenatal care screening and childhood immunization status is also important to prevent costly and unfortunate conditions. While the CMS has the primary interest of rewarding best practices and evidence based care as the macro level, state and local PHAs may further benefit from the data at the tactical level, but identifying those regions where the application of best practices is not as consistent, and also to target those regions with higher concentrations of populations at risk.

Health measure reporting is fairly well standardized. Measures will conform to the eMeasures defined by the CMS and NQF, and will be specified in the Health Quality Measure Format.
 * 1.2.4 Data (and Standards)**

The transmission of the measures will, according to current CMS guidance, use the Quality Reporting Document Architecture (QRDA) specification. One issue that would need to be resolved is whether or not the data sent outside the source’s firewall would be at the patient level or the aggregate level. The Category 1 level of the specification (patient level data) has been balloted by HL7, but is undergoing minor revision. The Category 3 level of the specification, for reporting aggregate data, is not fully fleshed out, but is currently being modified. Based on experience with provider organizations, and the initial responses to the CMS’s interim rule for quality reporting, there may be some resistance by providers to sending patient-level data, so it may be necessary to support both types of reporting.

Risks/Concerns
 * State and local PHAs have already voiced concern that they may not be able to support feeds in either HL7 2.x or CDA-based documents. The user story will need to address a transform to a tabular (e.g. .csv) or relational representation so that the PHAs can access and use the data effectively.
 * Another potential concern is the inclusion (or grouping by) provider IDs. While provider identities are not covered by HIPAA, and are required by CMS for their Pay for Performance programs, we have found this to be a potentially contentious issue in sharing the measure data with state/local health agencies.

The quality measures themselves have been developed with oversight from the CMS and NQF, and have also been analyzed by the CDC. The current status of the QRDA document specification and balloting under HL7 has already been described earlier. The primary goal of this user story is not to modify or supersede any of these specifications, but rather to further define the necessary workflows needed to ensure that State and Local PHAs may also benefit.
 * 1.2.5 Other Information**
 * 1.3 Stakeholder Commitment**

Should interest be expressed to develop this user story further, we will reach out to the National Quality Forum, the Public Health Quality Forum, the CMS Office of Clinical Standards and Quality, AHRQ, and representative state programs for quality measure reporting.

Any comments/questions may be directed to:
 * 1.4 Contact Information**

John Page Agilex 703-889-3977 John.page@agilex.com

Aleena Dhar Agilex 703-889-3187 Aleena.dhar@agilex.com

QRDA -- Quality Reporting Document Architecture NQF -- National Quality Forum MU -- Meaningful Use CDC -- Centers for Disease Control and Prevention CMS -- Centers for Medicare & Medicaid Services ONC -- Office of the National Coordinator S&I -- Standards and Implementation PH -- Public Health PHA -- Public Health Agencies PHRI -- Public Health Reporting Initiative EHR -- Electronic Health Record HQMF -- Health Quality Measure Format STST -- Surveillance Technical Steering Team HAIR -- Health Acquired Infection Report MDS -- Minimum Data Set ISDS -- International Society of Disease Surveillance NwHIN -- Nationwide Health Information Network POC -- Point of Contact OID -- Object Identifier DURSA -- Data Use and Reciprocal Support Agreement BA -- Business Agreement IRB -- Institutional Review Board PKI -- Public Key Infrastructure HL7 -- Health Level 7 CDA -- Clinical Document Architecture HIPAA -- Health Insurance Portability and Accountability Act HIT -- Health Information Technology SMHP -- State Medicaid HIT Plan XML -- eXtensible Markup Language ER -- Emergency Room IHE -- Integrating the Health Enterprise XDR -- Cross-Enterprise Document Reliable Exchange XDM -- Cross-Enterprise Document Media Exchange PHIN -- Public Health Information Network PHIN MS -- Public Health Information Network Messaging System
 * 1.5 Acronyms**

Supporting Files:

 * **Description** || **File** ||
 * This document contains the initial draft user story submission. || [[file:Initial Draft Submission - Quality Reporting - November 18 2011.docx]] ||  ||

Comments:
Please comment on this User Story using the "Discussion" tab at the top of the screen.

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