PH+Reporting+User+Story+-+Public+Health+Data+Quality+Assurance

include component="page" wikiName="siframework" page="PHRI Header" =User Story: Public Health Data Quality Assurance=

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 Public Health Data Quality Assurance User Story for consideration by the ONC S&I Framework Public Health Reporting Initiative (PHRI). The PH Data Quality Assurance User Story addresses the need for a common approach to supporting data quality across the full range of reporting that may occur (e.g., immunizations, registries, biosurveillance, adverse events reporting, quality reporting, etc.), rather than leave each user story to define its own solution. This story will be presented at a fairly high level, and does encompass several types of activities which may need to be decomposed into separate user stories.
 * 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 usefulness and effectiveness of all public health reporting transactions are dependent on the quality of data being reported, particularly in cases such as biosurveillance where that data transmission is frequent, and time sensitive. For data to be accepted as actionable by Public Health Agency (PHA) needs to have a trust relationship, based on tested components, and the processes for all of the actors involved need to be well documented. Testing and validation needs to be applied both prior to “going live” as well as ongoing process.
 * 1.2 User Story Narrative**
 * 1.2.1 Goal**

One of the primary goals of the PH Reporting Initiative is to harmonize common activities across different types of reporting. A common data quality framework would not only support more consistency, but also reduce the effort needed in developing user stories for each type of reporting.

The abstract model depicts the PH Data Quality Assurance user story where the actors are the participants directly involved in the user story.
 * 1.2.2 Abstract Model**

**Fig 1: PH Data Quality Assurance Abstract Model**

//Pre-Conditions:// The Reporting agreement parameters are addressed in the Reporting Registration User Story that is submitted separately. The reporting agreement will need to specify:
 * 1.2.3 Description of Data Reporting Events, Actors and Triggers**
 * Types of reports being sent
 * Anticipated frequency of reporting
 * Contact information for issue resolution

//Primary Actors:// This user story expands any user stories that support a type of public health reporting. It will add agents for: //Events and Triggers:// There are several different activities that will likely be included under the umbrella of Data Quality, each with their own triggers.
 * **Actors** || **Description** ||
 * Source Quality POC || One or more people at the source responsible for the quality of data. If there is more than one, the source may wish to qualify each one- for example, there can be a technical POC, domain experts for biosurveillance, quality reporting, etc. ||
 * PHA Quality POC || One or more people at the PHA responsible for quality of received data, and how it is processed and interpreted. If multiple agents are defined, they may have different areas of responsibility, such as described for the Source POC ||
 * Pre-production Testing: Performing a one-time test of data transmission before the report feed goes live.
 * Pre-Submission Validation: The EHR at the source could perform basic data validation prior to sending the report to make sure that the transmission is syntactically compliant, and that all data elements provided are in the allowable ranges. Any errors would be communicated to the Source Quality POC. The agreement between the source and the PHA should determine if a message known to be erroneous should be sent.
 * Receipt Validation: Similar syntax and allowable value checking can be done at the PHA as well. In addition, the PHA needs to also identify “legal”, but problematic values, such as obvious coding errors. (Such as the confusion of Crimean Hemorrhagic Fever for Congestive Heart Failure). The PHA Quality POC will also be necessary for identifying failures for a source to transmit data within the agreed timeframes.
 * Updates and Correction: This activity addresses how a source may update or resubmit an erroneous or incomplete submission.
 * Data Quality Report Summaries: To support the determination of Medicare and Medicaid Incentive payments, it may be necessary to generate summary reports of PH reporting for a given time period, as well as the results of any validation checking.
 * Escalation: Process by which a PHA may engage a source as a result of persistent data quality problems.

//Use by Public Health:// This user story will be indirectly support all Public Health Reporting use cases that address any type of reporting.

The data and standards being exchanged will vary to a large degree on the specific types of reporting, and the specifications for each type of exchange. However, there are some more general standards and protocols which could be applicable.
 * 1.2.4 Data (and Standards)**
 * For NwHIN Exchange-based transactions the Document Submission and Administrative Transactions may be applicable. (Note, the latter is asynchronous, and does not return any acknowledgement)
 * For Direct, these may be handled through the IHE XDR and XDM specifications.
 * PHIN MS may be applicable for transactions using the PHIN.
 * Validation of any XML-Based submissions could be specified in Schematron.

This user story will likely be developed in parallel with those specific to different types of reporting.
 * 1.2.5 Other Information**

The November 2010 findings from the Public Health Quality Forum address data quality as a pressing need, but do not offer guidance at a tactical level. Should there be interest in further refining this user story, we will reach out to representatives the PHQF, the National Quality Forum, and the CMS Office of Clinical Standards and Quality.
 * 1.3 Stakeholder Commitment**

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 - Public Health Data Quality Assurance - 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"