PH+Reporting+User+Story+-+Registration+for+Public+Health+Reporting

include component="page" wikiName="siframework" page="PHRI Header" =User Story: Registration for Public Health 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 Registration for Public Health Reporting User Story for consideration by the ONC S&I Framework Public Health Reporting Initiative (PHRI). The Registration for Public Health Reporting user story is not meant to stand by itself, but rather it captures the activity needed to initiate a reporting relationship between a provider, practice or facility (known hereafter as the Source), and a public health agency, hereafter known as the PHA. Ideally, this will be used as a prerequisite for user stories for reporting immunizations, quality measures, notifiable (reportable) conditions, adverse events, biosurveillance, or any other type of public health reporting.
 * 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.

Experience with the NwHIN has shown the establishing the relationship between the sender and receiver is a non-trivial task which can, among other things, create major schedule delays. The registration user story aims to help the parties ensure a basic connection, establish the appropriate exchange agreements, define the agreed parameters for reporting, and the necessary metadata and contact information needed to support continued reporting.
 * 1.2 User Story Narrative**
 * 1.2.1 Goal**

The abstract model depicts the Registration for Public Health Reporting user story where the actors are the participants directly involved in the user story.
 * 1.2.2 Abstract Model**

**Fig 1: Registration for PH Reporting Abstract Model**

//Primary Actors:// //Events and Triggers:// __Initial Registration__ An initial registration occurs when the first reporting relationship is set up between the source and the PHA. The following activities are included in the user story:
 * 1.2.3 Description of Data Reporting Events, Actors and Triggers**
 * **Actors** || **Description** ||
 * Source Admin || A person who either has elevated technical capabilities and access rights, or a person with decision making authority. In reality, this may be more than one person. ||
 * PHA Admin || A similar role for the PHA. ||
 * Determine if the data to be reported will be aggregate data, or patient level data. If the latter, it will need to be further determined if it the data is classified under HIPAA as Protected Health Information, a Limited Data Set, or de-identified data.
 * Establish a DURSA or BA between the source and PHA. The DURSA or BA needs to:
 * Specify how data received from the source can be shared with other PHAs
 * Assert that the source has secured consent, as required, from patients, providers, and any other parties that may have jurisdiction over the data.
 * Assert that any IRB or Privacy Board with jurisdiction over the data has provided its consent.
 * Establish the communications channel. The data may be submitted via a variety of means, including NwHIN Exchange, the Direct Project, or another acceptable means. A viable encryption strategy needs to be specified if any PHI is to be transmitted.
 * Define the Parameters of the Reporting Agreement: Specify the type and frequency of reports, and the degree to which optional fields will be supported in the specification, as applicable.
 * Capture metadata which can support multiple user stories, such as facility location, points of contact for data quality issues, etc.

__Maintenance__
 * 1) Modification of Registration - Whenever a new type of reporting is added, it will be necessary to update the registration.
 * 2) Periodic Refresh - It is recommended to update the registration annually on order to ensure that the contact information is current.

//Use by Public Health:// This user story does not stand on its own, but rather establishes the perquisites for any reporting relationship. Its primary benefits is that it explicitly addresses the prerequisites in reporting that can lead to delays of weeks or months in setting up a connection, and captures much of the data the is needed to monitor and maintain reporting relationships over time.

The NwHIN DURSA can be used as a starting point in defining a DURSA or BA.
 * 1.2.4 Data (and Standards)**

Facility Metadata can include data elements such as: The applicable standards and specifications will also depend highly on the communication channel used, in addition to the workflow. For example, for NwHIN Exchange, it would be necessary to request an Object Identifier (OID) from HL7, and obtain the proper PKI certificate. For the Direct Project, it may depend on whether or not an intermediate Health Service Provider is being used. The path and standards for each channel will need to be better defined to create an efficient onboarding process.
 * Facility Name
 * Facility Location / Address
 * Unique Facility Identifier
 * Umbrella Organization, if applicable
 * Facility Type or Specialty
 * Data Quality POCs
 * Administrative POCs
 * PH Liaison POC

This user story will likely be developed and expanded over time as user stories are developed for each type of reporting. The aim is to capture any common requirements and activities in this story so they can be better managed.
 * 1.2.5 Other Information**

This user story has not been vetted by any major body, but is based in part on an onboarding process developed to support the NwHIN.
 * 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 - Registration for PH 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"