PH+Reporting+User+Story+-+Model

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

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

In defining user stories for the Public Health Reporting Initiative, we have identified elements that are common to all types of public health reporting, as well as dependencies between stories and actors. To avoid confusion, we have felt that a top level structure would greatly assist in managing user stories for the public health initiative. This is the Public Health Reporting Initiative User Story Model. In this section, we provide a high level overview and structure for public health reporting user stories. As this is not a user story per se, we will not follow the template as closely.
 * 1.1 Introduction**

A public health official or epidemiologist may see a dramatic difference between adverse events reporting, biosurveillance, and immunizations reporting. Clearly, the paper-based processes they are based on are quite different, and many currently proposed electronic solutions have retained the “siloed” business models of their paper analogs.. However, when we apply Meaningful Use to retrieve data rom electronic health records, each report is reduced to stream of 0s and 1s and transmitted on communications channel to a Public Health Agency (PHA), and creating multiple architectures based on specific types of reporting does not seem logical.. To avoid duplication of effort, or worse yet, contradictory user stories, it is important to identify the common elements of user stories, and manage them separately. This will allow the developers of user stories for specific types of reporting to focus their specific challenges, and not worry about the more mundane concerns of establishing a connection, responding to faulty submissions, authentication, etc.
 * 1.2 User Story Narrative**
 * 1.2.1 Goal**

The creation of a generalized model and architecture for all types of public health reporting addresses the initial charge of the S&I PHRI was to “develop and implement a standardized approach to electronic public health reporting from EHR systems to local, state and federal public health programs that addresses the needs of various public health programs.”

We have developed a high level use case model to capture the relationship between potential actors and use stories for this initiative, as is illustrated in Exhibit 1. The two main participants and their relationship in this exhibit is explained below -
 * 1.2.2 High Level Model**
 * 1) Actors - The human stick figures are actors participating in the use case model.
 * 2) User Story – The oval shaped figure are user stories
 * 3) Association – The actors involved in the user story are indicated by a straight line showing their association with the user story.

The actors, user stories and their association in the model are depicted below in the use case model. The user stories that we have submitted along with this model are indicated in blue.

**Exhibit 1: Use Case Model for Public Health Reporting Initiative.**

In this section the role of the actors and what they are playing in the reporting user stories (particularly under meaningful use) are explained.
 * 1.2.3 Actors:**

The actors are listed when they are either at the source of data, beneficiaries of data, or responsible for some aspect of the workflow. The actors on the left side of the diagram are all located at the source of the report.
 * Patient: The patient is included as a source of data, but will only play a more active role if HIPAA and patient consent needs to be modeled or if it becomes necessary to re-identify the patient.
 * Admissions Specialist: Captures the majority of admission information and discharge information.
 * Provider: Doctor or similar caregiver responsible for diagnoses, notes, etc. In some cases, such as reporting of Health Quality data, it may be necessary to either maintain the provider’s consent for reports where the provider identifier is visible.
 * Quality POC: One or more people responsible for the data quality of a given report.
 * Admin: Someone with either elevated technical capability and access rights, or someone with decision making authority within the source organization.
 * PH Officer: Source Liaison to the state/local public health departments.

Note: In many cases, once the reporting connection is established, the actions may not be triggered knowingly by an actor. The actions will be triggered within the EHR by either a timer (e.g., report every 12 hours), or a data event (end of a patient encounter). For example, in a biosurveillance report, the patient, the admissions specialist and provider are all providing/entering the data used as part of their normal care delivery process, but they do not manually send the report.

The actors on the right side of the diagram represent people at one or more state/local PHAs, or else the state’s HIT officer. They include:
 * PHA Analyst: An analyst or epidemiologist who is primary responsible for analysis of reported data
 * PHA Quality POC: Person at the PHA primarily responsible to oversee the quality of received data, and reach out to sources who are either not reporting or are repeatedly sending faulty data.
 * PHA Admin: A person at the PHA that either has elevated technical skills and access privileges, or has the ability to represent the PHA and make binding decisions.
 * PHA PH Official: The person at the PHA who is empowered to reach out to sources to act upon the data in the reports, such as to investigate a potential outbreak, or suggest an educational outreach to regional providers to promote best practices.
 * State HIT Officer: A person who is, among other things, responsible for planning and operating the Medicaid Meaningful use incentives for public health reporting.

The use case model created consists of number of user stories. The stories we have submitted to the work group in separate documents are depicted in blue. Other user stories which have either been submitted by others, are will likely be part of a finished model are depicted in grey. Although it is understood that the workgroup would like to focus the ignition scope on a small group of relevant user stories, there is a substantial benefit in maintaining a collection of potential user stories and how they fit together in the larger picture. In this document, we will provide a high level description of each user story.
 * 1.2.3 User Stories**

The user stories can be divided into three broad categories: Reporting, Shared Capabilities, and Collaborations.

//1. Reporting User Stories:// In this approach the user story for each type of reporting is an extension of a “generic” or “base” Reporting user story that incorporates all the common elements in the reports. It addresses the elements in establishing and operating a reporting feed between a source and a PHA. Below is a representative sample of the reports which “extends” the Reporting user story. (Note that this is an attempt to address some of the reports and their elements currently and by no means complete)
 * Syndromic Surveillance Using ED and UC EHR Data.: This user story addresses the submission of a patient level “Minimum Data Set” of surveillance data to a PHA, as recommended by the International Society of Disease Surveillance (ISDS). This feed allows deep mining of data, as well as a maximal flexibility of a PHA in analyzing the data. We anticipate that this user story will be submitted to the PHRI by representatives of the ISDS.
 * Syndromic Measures: This user story addresses the simple aggregate measures of the prevalence of syndromes such as Influenza-Like-Illness (ILI) and Gastrointestinal Illness directly from the source entity. The aim of this story is to provide a lightweight, consistent, and near-real time situation awareness measure of a very limited set of public health threats. This story is meant to operate in parallel with the Surveillance Data feed user Story, and to complement it. A more detailed description of this user story has been submitted in Syndromic Measure User Story document.
 * Health Quality Measures: This user story expands the currently envisioned reporting of Health Quality Measures under Meaningful Use to address how this data will be made available to state and local PHAs. A more detailed description of this user story has been submitted in Quality Reporting to PHAs User Story document.
 * Notifiable (Reportable) Conditions: This user story would presumably cover the mandating reporting of certain health conditions to the appropriate PHA. This capability is already included in Stage 1 meaningful use, but it may be desirable to revisit it. A user story has already been submitted to the workgroup..
 * Immunizations: Data about administered immunizations is sent to an immunization repository, and is accessed by PHAs. A user story has already been submitted to the workgroup.
 * Vital Statistics: Vital statistics data is updated electronically when possible, lessoning the amount of time and effort needed to enter the data, as well as access it. A user story has already been submitted to the workgroup by some other interested party.
 * Adverse Events: Reporting of any negative outcomes or events that may be associated with a medication or vaccine. At present, no user story has been defined.

As a note, it may be helpful to incorporate the reporting of Healthcare Acquired-Infections (HAI) under the more generalized case of Health Quality Measure Reporting, as there is a large degree of overlap between the current HAI specifications and the quality reporting specifications being endorsed by the CMS and National Quality Forum.

2. //Shared User Stories:// The “generic” or “base” Reporting user story also “includes” two user stories that address common concerns for all reporting user stories. As a result every type of reporting would need to include these two user stories. These two stories contain shared elements the should be common to all of the reporting user stories.
 * Registration: The registration user story addresses ALL of the necessary activities that need to take place prior to sending the first report. This includes:
 * Setting up necessary DURSAs and Business Agreements,
 * Establishing an encrypted communications channel
 * Agreeing on the parameters for each type of report (what types of reports, what level of granularity, and how frequently are they expected)
 * Identification of metadata for the facility, including points of contacts for quality control issues and follow-up investigations.
 * //Note that it will also be necessary to repeat this story when a new type of reporting is added or existing data needs to be refreshed. A more detailed description of this user story has been submitted in Registration for PH Reporting User Story document.//
 * Data Quality: This user story specifies the different activities by the actors in order to monitor the data quality of the feed. These activities include:
 * The electronic validation of a report by the EHR prior to submission.
 * PHA notifying a Source in response to faulty transmission.
 * Resolving any anomalies (such as Crimean Hemorrhagic Fever entered instead of Congestive Heart Failure) that, while conforming, are likely data entry errors.
 * The process for submitting updated, corrected reports.
 * Identify and responding to the absence of expected reports. (For example, if a surveillance system does not get expected reports from a source, it does not conclude that the population treated is in extraordinarily good health.)
 * Escalation of continued data quality issues with a given feed.
 * //A more detailed description of this user story has been in PH Data Quality User Story document.//

3. //Collaboration User Stories//. The scope of the PHRI addresses bi-directional communications between PHAs at different levels and care providers. Although the workgroup has wisely recommended to focus the first detailed user stories on the initial submission of data, we feel that it is important to at least identify and track likely user stories that will reflect bi-directional communications. There is a tremendous degree of risk in not attempting an initial description of workflow that includes these later user stories. How can we be sure we have all of the appropriate data elements they will be needed “downstream” if we have not characterized follow up user stories? For example, in an immunization or adverse event report, lot numbers would not be required until a potential health event has been identified. In surveillance situations, it may be necessary to re-identify pseudonymized patient data as part of an outbreak response and management activity. If these needs are not anticipated, any specification for the initial submission will be flawed. If this is to be realized under meaningful use, it will likely take two years to correct omissions.

It is for that reason that we have identified the following high level user stories to support bi-directional communication between PHAs and Sources after a report is submitted.
 * Reach Back: There may be points where the PHA may wish to reach out to the Source to follow up on the contents of a report. For example, in a biosurveillance, it may be necessary to request additional information to confirm if an outbreak is occurring, or in a very serious situation, re-identify patients that presenting a given syndrome. In an adverse events scenario, it would be necessary to identify exposed patients by tracking lot numbers. In other cases, lower scores in quality metrics could prompt outreach and education to the caregivers in a particular region. At present, there is no current user story defined.
 * Notification: A notification system would allow PHAs and Sources to share alerts. Ideally, a recipient could define a “subscription” to alerts so that they could be filtered by origin, type, severity, and confidence level. At present, there is no current user story defined.
 * Incentive Determination: The first year of Meaningful Use has not required that a source needed to demonstrate that it had been sending public health reports at a given frequency and duration. This will soon be changing, as it will soon be necessary to determine if a source has actually been transmitting a report to meet the required duration and frequency. While this is already a challenge for the CMS in determining Medicare incentive payments, this is even a greater challenge for the HIT Coordinators in each state in determining Medicaid Incentive payments. The State HIT coordinators are tasked with developing a means to track and verify public health reporting. A standardized specification would allow states to pool resources to develop a shareable solution. At present, there is not current user story defined.

This discussion is at a higher level than individual user stories, and a comprehensive mapping of existing standards, vetting by stakeholder groups, etc. is best realized at the individual user story level.
 * 1.3 Standards, Stakeholder Commitment, etc.**

We would suggest that this model and approach be submitted to the S&I for consideration under Use Case simplification and/or Cross Initiative functions, as the scope of this initiative broad enough to qualify under both, and many of these issues require architectural input, as opposed to public health domain expert. This effort may benefit from the injection of cross-domain and architecture support that may be difficult to obtain in a purely community-based effort.

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 - PH Reporting User Story Model - 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"