Use Case and Functional Requirements Development for Interoperability
Public Health Reporting Initiative
Public Health Reporting
Initiative
Use Case: Provider-Initiated Report from EHR
System to Public Health Agency System
4/30/2012
This document reflects the Public Health Reporting Initiative Use Case as of April, 2012. This document
may be revised going forward based on Meaningful Use Stage 2 requirements and the ongoing and
future work of the initiative including functional requirements development, data modeling, and
implementation specification development. This document has been updated based on comments
received during both the internal and public comment review periods.
<<Date>>
1
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
Table of Contents
1.0
Preface and Introduction .................................................................................................................. 4
2.0
Initiative Overview ............................................................................................................................ 4
2.1
3.0
Initiative Challenge Statement...................................................................................................... 5
Use Case Scope ................................................................................................................................. 6
3.1
Background ................................................................................................................................... 6
3.2
In Scope ......................................................................................................................................... 7
3.3
Out of Scope.................................................................................................................................. 8
3.4
Stakeholders ................................................................................................................................. 9
4.0
Value Statement ............................................................................................................................. 10
5.0
Use Case Assumptions .................................................................................................................... 11
6.0
Pre-Conditions ................................................................................................................................ 12
7.0
Post Conditions ............................................................................................................................... 12
8.0
Actors and Roles ............................................................................................................................. 12
9.0
Triggers............................................................................................................................................ 13
10.0
Use Case Diagram ........................................................................................................................... 13
11.0
Scenario: EHR System Sends Report to Public Health Agency System ........................................... 14
11.1
User Story.................................................................................................................................... 14
11.1.1
Communicable Disease ....................................................................................................... 15
11.1.2
Chronic Disease ................................................................................................................... 15
11.1.3
Newborn / Child Health ...................................................................................................... 16
11.1.4
Adverse Events .................................................................................................................... 17
11.1.5
Infrastructure/Quality/Research......................................................................................... 18
11.2
Activity Diagram .......................................................................................................................... 18
11.2.1
Base Flow ............................................................................................................................ 19
11.2.2
Alternate Flow..................................................................................................................... 20
11.3
Functional Requirements ............................................................................................................ 22
11.3.1
12.0
Sequence Diagram .............................................................................................................. 22
Policy and Regulatory Issues ........................................................................................................... 22
Appendices.................................................................................................................................................. 24
Appendix A: User Stories........................................................................................................................ 24
<<Date>>
2
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
Communicable Disease Consolidated User Story (Reporting from EHR system) ............................... 24
Chronic Disease Consolidated User Story #1 ...................................................................................... 25
Chronic Disease Consolidated User Story #2 ...................................................................................... 27
Child Health Consolidated User Story – Birthing Facility .................................................................... 28
Child Health Consolidated User Story – Outpatient Setting ............................................................... 29
Adverse Events Consolidated User Story ............................................................................................ 30
Appendix B: Acronyms ........................................................................................................................... 31
Appendix C: Glossary of Terms .............................................................................................................. 31
List of Figures:
Figure 1: Use Case Diagram ....................................................................................................................... 13
Figure 2: Activity Diagram .......................................................................................................................... 19
Figure 3: Sequence Diagram ...................................................................................................................... 22
List of Tables:
Table 1: Key Stakeholders ........................................................................................................................... 10
Table 2: Actors and Roles ............................................................................................................................ 12
Table 3: Base Flow ...................................................................................................................................... 20
Table 4: Alternate Flow ............................................................................................................................... 21
<<Date>>
3
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
1.0 Preface and Introduction
To fully realize the benefits of health IT, the Office of the National Coordinator for Health Information
Technology (ONC), as part of the Standards and Interoperability (S&I) Framework is developing Use
Cases that define the interoperability requirements for high priority healthcare data exchange; maximize
efficiency, encourage rapid learning, and protect patients’ privacy in an interoperable environment.
These Use Cases address the requirements of a broad range of Communities of Interests including;
patients, their significant others and family members, providers, payers, vendors, standards
organizations, public health organizations, and Federal agencies.
These Use Cases describe:




The operational context for the data exchange
The stakeholders with an interest in the Use Case
The information flows that must be supported by the data exchange
The types of data and their specifications required in the data exchange
The Use Case is the foundation for identifying and specifying the standards required to support the data
exchange and developing reference implementations and tools to ensure consistent and reliable
adoption of the data exchange standards.
2.0 Initiative Overview
The Public Health Reporting Initiative (PHRI) is a community-led S&I Framework initiative focused on
harmonizing information exchange standards and creating implementation specifications for public
health1 reporting from healthcare providers to public health agencies. Our goal is to create a
harmonized specification that can be used to help reduce costs and reporting burden of healthcare
providers to public health agencies. The new specification can be used to promote health information
technology (HIT) adoption and facilitate electronic public health reporting from EHR systems. The PHRI
consolidated use case was derived using a representative sample of existing public health reporting
scenarios. These scenarios are grouped into reporting domains for Chronic Disease, Communicable
Disease, Child Health, and Adverse Events. This grouping approach will be used to identify common data
elements and reporting functional requirements to create an extensible EHR reporting specification that
could be more broadly applied to other public health reporting scenarios over time. For this use case,
“public health reporting” refers to information exchange between healthcare providers such as private
physician practices and hospitals to a public health agency. In particular, this use case will address
electronic transmission of EHR-generated or assisted healthcare provider reports, and receipt or
retrieval by the public health agency. Report content for this use case is based upon patient-level EHR
data that is extracted and/or reused to create compliant reports that meet reporting criteria of the
representative public health report types (domains) supported in the use case.
1
The term “public health,” as used in this document, refers to public health and patient safety programs.
<<Date>>
4
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
The Initiative recognizes the challenges of defining a single use case and harmonizing reporting
specifications for multiple public health reporting agencies and report types. To help address this
challenge, the Initiative solicited and examined many different user stories from stakeholder
participants, which represent requirements across several reporting programs. As previously described,
the resulting public health reporting domains for Child Health, Communicable Disease, Chronic Disease
and Adverse Events will be further refined to create a functional requirements specification for an
overall public health reporting scenario for sending an electronic report from a healthcare provider’s
EHR system to a public health agency.
In the short-term, the Initiative seeks to define criteria and requirements for improved data exchange
standards, specifications and validation rules for sending EHR-generated or assisted reports from a
healthcare provider to a public health agency. The long-term goals of the initiative include:




Reduce variability in data exchange standards supported by different public health agency
systems covering the same or different jurisdictions
Increase interoperability and data exchange from healthcare providers to public health agencies
Reduce the burden on senders to create and manage different data exchanges based upon the
use of the same or similar source clinical or administrative data
Reduce the burden on public health agencies to receive, extract, translate, load, and analyze
information contained in healthcare provider reports.
Future Use Cases that could be developed include exchanges between Health Information Exchanges
(HIEs) and public health laboratories, exchanges between state, local or federal public health agencies,
and exchanges for events of public health interest involving non-human subjects.
2.1
Initiative Challenge Statement
Much public health reporting currently relies on paper forms that are mailed, emailed or faxed; thus
necessitating manual data entry and coding by the public health agency prior to initiating analysis or
follow-up. There is relatively little, but increasing nationwide standardization of public health electronic
information exchange. Even when reporting is performed electronically, there are multiple regulatory
or statutory requirements and implementation specifications that cover different reporting activities.
Varied reporting requirements and methods impose burdens on both healthcare providers and public
health agencies to support multiple formats and manage competing requirements defined by mandated
or voluntary reporting programs. Additionally, multiple data exchange standards used for public health
reporting (e.g., HL7 Versions 2.x and 3 messages and HL7 Clinical Document Architecture (CDA))
introduce additional variability across reporting programs because of differences in data standards
adoption and implementation timelines, data elements, terminology and metadata. The need to
accommodate and manage these variations and extensibility of existing data exchanges increases the
costs and barriers for reporting, data sharing and data reuse for both the senders and receivers of public
health reports.
The PHRI aims to address some of these issues by identifying common reporting requirements, e.g., data
elements, terminology, report generation workflow and infrastructure that can be used to help refine
<<Date>>
5
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
and recommend standards and implementation specifications. These specifications can be used to help
streamline electronic reporting from EHRs to public health, and also help identify needed changes to
regulatory and statutory policies that further complicate or hinder broader EHR adoption and reuse of
EHR data for downstream uses such as public health reporting. Successful completion of this initiative
will help reduce or eliminate redundant reporting standards, specifications and create a framework for
leveraging solutions that can accommodate a broader range of reporting scenarios. Additionally, the
initiative hopes to highlight gaps and issues that can be used as a future catalyst for addressing various
discrepancies or overlaps in federal, state and local regulations that confuse reporters or inadvertently
create standards adoption burdens on healthcare providers. The anticipated public health benefit of a
successful initiative is a more timely, reliable, secure, standardized and efficient public health reporting
infrastructure (standards, terminology, specifications and tools) for healthcare providers. Public health
agencies may be able to improve their public health surveillance and risk/harm mitigation activities,
which should result in reductions in preventable disease, disability and death.
3.0 Use Case Scope
The scope of this Use Case is limited to the use of a healthcare provider’s EHR system for reporting
patient-level events of public health interest to a public health agency. This Use Case focuses on a
provider-initiated report – a report sent from a provider (using an EHR system) to a public health agency
system with information about a particular public health event. The report (at a minimum) will contain
specific information about what occurred and the relevant patient-level information. For example, a
report about a patient’s health condition or disease (suspected or confirmed) by a healthcare provider
to authorized local, state, or federal public health agencies. The common dataset for this use case is
derived from the core data elements described across all reporting domains (e.g., communicable
disease, chronic disease, child health, adverse events) that are needed to meet the reporting criteria for
the public health agency programs represented in this phase of work. In the context of this initiative’s
use case, the reporting process is facilitated by the healthcare provider’s EHR and assumes that the EHR
system contains or is used to create all relevant information (e.g., demographic, clinical, laboratory,
pharmacy, etc.) to create and send a report to a public health agency.
The reporting scenario for this use case describes two potential information flows from the EHR system
to the public health agency. The primary report flow involves the transmission of a report directly from
the provider’s EHR system to the public health agency system. The alternate report flow involves the
transmission of the report from the EHR system to an intermediary system such as a Health Information
Exchange or similar intermediary (e.g., Incident Reporting System) to a public health agency.
The functional requirements supported by this use case support the active reporting process initiated by
the healthcare provider, and are consistent with established state, local or federal mandates.
3.1
Background
On February 17, 2009, the President signed the American Recovery and Reinvestment Act of 2009
(ARRA). This statute includes the Health Information Technology for Economic and Clinical Health Act of
<<Date>>
6
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
2009 (the HITECH Act) that set forth a plan for advancing the Meaningful Use (MU) of health information
technology (HIT) to improve quality of care and establish a foundation for healthcare reform. Two
Federal Advisory Committees, Health IT Policy and Health IT Standards have been established under this
legislation. In 2010 these Committees identified three types of public health reporting that were
adopted for MU Stage 1 of the HITECH-funded Centers for Medicare and Medicaid Services (CMS)
Incentive Program:

Capability to submit electronic syndromic surveillance data to public health agencies and actual
transmission according to applicable law and practice.

Capability to submit electronic data to immunization registries of Immunization Information
Systems and actual submission in accordance with applicable law and practice.

Capability to submit electronic data on reportable (as required by state or local law) lab results
to public health agencies and actual submission in accordance with applicable law and practice.
Both Committees recognize that these three types of public health reporting represent just a few of the
many types of ongoing information exchange between healthcare providers and public health agencies,
and that creating a unique implementation specification for each would impose long-term burdens on
healthcare providers and agencies alike. Both have suggested that simpler approaches to managing
public health reporting be considered for future stages of Meaningful Use2.
ONC manages the S&I Framework to leverage existing and new HIT standards and tools, and to
harmonize and implement standards specifications (implementation specifications) in order to promote
electronic health information exchange interoperability nationwide. In 2011, several S&I Framework
Initiatives were established to provide clarification in HIT standards selected for MU and guide
standards-based products and certification including the Laboratory Results Interface (LRI) Workgroup
and its Public Health Laboratory Reporting Workgroup. The Public Health Laboratory Reporting
Workgroup recognized that additional information is needed for prompt assessment and response to
reportable diseases beyond that contained in the MU Stage 1 implementation specification for
laboratory result reporting. Similar types of information are needed for other kinds of public health
reports. During the ONC S&I Framework face-to-face meeting in Washington DC, June 14-15, 2011 the
LRI Public Health Workgroup proposed establishing the Public Health Reporting Initiative within the ONC
S&I Framework to better understand public health reporting needs and define standards-based
interoperability specifications.
3.2
In Scope
The following activities are in scope for the PHRI Use Case.


2
Describing the stakeholders and actors for each public health reporting User Story
Identifying and harmonizing the core reporting data elements required by public health agencies
for reportable events
Letter of June 16, 2011 from HITPC chairs to the National Coordinator for HIT.
<<Date>>
7
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative




3.3
Defining a standard exchange format including structure and content (i.e., vocabulary)
Defining the requirements for limited bi-directional3 exchange – sending the report, receiving
the report, and acknowledging receipt
Identifying the requirements to send reports from certified EHR systems (in all clinical settings
where EHR data is used for reporting purposes – inpatient, outpatient, emergency room, urgent
care, etc.) to public health agencies (Note: reports may include administrative, laboratory,
pharmacy and/or other information imported from separate systems into the EHR)
Supporting all relevant federal, state, and local regulations to the best extent possible when
creating the harmonized standards and specifications
Out of Scope
The following activities are out of scope for the PHRI Use Case.








Defining specifications and guidelines on reportable event criteria (e.g., defining reportable
conditions) – this Initiative will enable healthcare providers to submit a report based on
jurisdictionally defined laws and regulation, but will not be responsible for defining the reporting
criteria.
Describing the process for healthcare providers to add information into an EHR or auxiliary
system
Describing the process for public health agencies to perform follow-up activities, including case
monitoring
Defining specifications and guidelines for reporting by means other than the transmission of an
electronic message or document (e.g., telephone voice, manual web-entry and mailed or faxed
information)
Describing any additional or extensive bi-directional communication between a public health
agency and a healthcare provider beyond the sending of a public health report and the
acknowledgement of receipt of that report
Identifying transport protocols
Identifying security requirements, methodologies, procedures, and/or protocols
Identifying information and data stewardship practices and policies
The Initiative acknowledges that there are several exchanges described in various user stories that are
not explicitly harmonized for phase of work. The following exchanges will be considered for future
harmonization with this use case:
 Queries to electronic health records for surveillance or research purposes;
 Transactions between EHRs and other ancillary systems such as Laboratory Information Systems
or Incident Reporting Systems
3
Note that further bi-directional communication (e.g., a follow-up for additional information by the public health
agency system) is out of scope for this use case, but may be considered by future phases of the Public Health
Reporting Initiative.
<<Date>>
8
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
3.4
Stakeholders
The key stakeholder groups interested in this Use Case and the associated standards and
implementation specifications are included in the table below.
Stakeholders
Healthcare Provider
Public Health Agency
Electronic Health Record (EHR) /
Electronic Medical Record (EMR) /
Personal Health Record (PHR)
Vendors and Suppliers
Public Health Information System
Vendors/Suppliers
Standards Development Organizations
Health Information Exchange
Organizations
Patient Safety Organization
Quality improvement/measurement
organizations
Laboratory
<<Date>>
Description
Any supplier of a healthcare service; person or organization
that furnishes, bills, or is paid for healthcare in the normal
course of business. Includes physicians and healthcare
provider staff, as well as ancillary healthcare personnel (e.g.,
lab personnel)
An entity under the jurisdiction of the U.S. Department of
Health and Human Services, tribal organization, State level
and/or city/county level administration that serves a public
health function.
An EHR is an electronic record of health-related information
on an individual that conforms to nationally recognized
interoperability standards and that can be created, managed,
and consulted by authorized providers and staff across more
than one health care organization. An EMR is an electronic
record of health-related information on an individual that can
be created, gathered, managed, and consulted by authorized
providers and staff within one health care organization. A
PHR is an electronic record of health-related information on
an individual that conforms to nationally recognized
interoperability standards and that can be drawn from
multiple sources while being managed, shared, and controlled
by the individual. A vendor or supplier is a
company/consortium that provides products and/or services.
Public health Information Systems: applications which may,
among other things, receive Public health Reports
Organizations key to identifying, balloting, approving, and
maintaining health information exchange standards, including
exchange, terminology, security, and transport protocols.
Organizations (including state Designated Entities for Health
Information Exchange, as well as other organizations
managing information exchange among different corporate
entities). Includes Regional Health Information Organizations
(RHIOs).
A group, institution or association that improves medical care
by reducing medical errors
A group of doctors and healthcare experts to check on and
improve the care given to people. For example, QIO’s are key
stakeholders in Hospital Acquired Infection reporting and in a
range of care and transitions of care issues including the
reporting and control of healthcare associated infections.
The laboratory is a producer of lab test results (filler of a lab
order).
9
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
Stakeholders
Laboratory Information System (LIS),
Vendors/Suppliers
Description
An application to streamline the management of laboratory
processes including data collection, workflow management,
and report generation. May provide an automatic interface
to laboratory analytical instruments to transfer verified
results to nurse stations, chart carts, and remote physician
offices.
Table 1: Key Stakeholders
4.0 Value Statement
Public health agencies rely on health information captured and/or generated during healthcare
processes and interactions with individual patients to save lives and reduce disability and illness by
identifying threats (such as outbreaks, epidemics and adverse trends like obesity); by assuring
interventions (like infection control, prophylactic or therapeutic treatment, environmental intervention,
and public risk communication); and monitoring outcomes to evaluate the effectiveness of both public
health and medical prevention efforts. Collectively these information-dependent functions are referred
to as public health surveillance.
Historically, public health reports are submitted manually by phone, mail, fax and more recently, typing
into internet forms. Because clinical information is increasingly stored and managed in Electronic
Health Records, public health agencies have an opportunity and obligation to adapt their reporting
methods and infrastructure to leverage EHR data for public health use. Electronic reporting of
structured EHR data can help reduce or eliminate some of the manual processes involved in creating,
sending, receiving, and analyzing public health reports. By leveraging emerging EHR technology,
healthcare providers improve the speed, accuracy and completeness of reporting, and help enable
improvements in public health agency response and mitigation of important public health events.
The value of the Public Health Reporting Initiative will be to help facilitate HIT adoption and lower
barriers of manual reporting methods by creating and promoting the use of a consensus-based standard
and specification to support automated reporting of public health events from certified EHR systems.
The initiative will leverage standardized health information models to support implementable, highvalue user stories, based on available, shareable and standardized information from EHRs. The
Initiative’s artifacts may be leveraged to facilitate further extension of interoperable data exchanges to
support other public health-related activities. To the extent that the Initiative can develop and
successfully demonstrate the use of a practical specification in time for consideration for Stage 3 of
Meaningful Use, it is anticipated that certified EHR systems will support and be capable of limited, bidirectional public health reporting using a harmonized implementation specification to support a variety
of public health reporting scenarios and programs.
While outside the scope of this Initiative and Use Case document, it is important to note the need for
effective integration of public health reporting into the evolving HIT landscape, and this will require that
public, private and academic organizations work together to understand and improve the overall
<<Date>>
10
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
workflows and responses associated with multi-dimensional public health information exchange,
including public health reporting. It is anticipated that as the Public Health Reporting Initiative evolves
over time, there will be critical multi-stakeholder and multi-disciplinary assessments of the baseline
standards, specifications and processes to help establish a longer term roadmap for addressing broader
policy, workflow and IT burdens that affect overall improvements in public health programmatic
outcomes.
5.0 Use Case Assumptions










Patient-level clinical information is entered, imported, or accessed by a healthcare provider
using an EHR System interface.
Broadly-acceptable security and transport protocols, patient identification methodology, privacy
and security procedures, coding, vocabulary, and normalization standards exist and are in use by
the EHR system and Public Health Agency system.
The healthcare provider (EHR) system contains all relevant information (e.g., demographic,
clinical, laboratory, pharmacy, etc.). The EHR has or has to enable access to all needed data
(electronic population of information is preferred, but information may be manually entered for
legal purposes) to generate a complete and accurate public health report in accordance with the
appropriate public health reporting domain requirements described in the new PHRI
specification.
Appropriate data and information stewardship practices are adopted by exchange partners.
Established network and policy infrastructure will exist to enable consistent, appropriate, and
accurate information exchange across healthcare provider systems, data repositories and
locator services.
Electronic Health Record Systems may be a single stand-alone system or based upon a
component-based architecture where the EHR interfaces with other systems that are used to
help populate or transmit the report to public health.
The public health agency system is in place and capable of receiving the report in a standardized
structured format. Public health agency information systems receive the public health report.
These information systems may be a single stand-alone system or composed of a componentbased architecture that is used to receive and process the report for review and/or analysis.
There are variations in requirements for reporting across local, state, tribal, and territorial
boundaries, as well as voluntary versus mandatory requirements.
The healthcare provider will locate or select the appropriate reporting criteria and has made
provisions to electronically program or integrate the criteria into the EHR reporting process
The reporting system is capable of sending the report to a public health agency in a standardized
structured format.
The HIE, if used, is responsible to pass the acknowledgement from the Public Health Agency
system to the EHR system; the HIE may send separate acknowledgements, but these are not
considered the authoritative acknowledgement.
<<Date>>
11
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
6.0 Pre-Conditions
At least one of the following has occurred:



The criteria for public health reporting have been met, including collecting all data and meeting
all reportable event criteria and triggers
The EHR system populates/generates a report using the all appropriate information (e.g., data
elements and terminology) for the report type
The report is verified or certified based upon the appropriate healthcare provider process and is
released for transmission to the public health agency
7.0 Post Conditions



The public health agency information system has received the report and sent
acknowledgement of receipt to the EHR system
The sending healthcare provider EHR system has received acknowledgement of receipt of the
report
A record of a report sent from the EHR to the public health agency is stored in a log
8.0 Actors and Roles
Actor
EHR System (healthcare provider system)
Public Health Agency System
Intermediary Systems, including Incident
Reporting Systems, Health Information
Exchange Systems, Health Information
Networks, etc. that are used as
intermediaries to communicate between
EHR systems and Public Health Agency
systems
Role
 Collect, receive, and/or store patient-level data
 Supports additional data entry (e.g. populate
data on an electronic form)
 Generate public health report and make it
available for validation
 Send report to public health agency either
directly or through an intermediary
 Receive acknowledgement either directly or
through an intermediary
 Receive report from EHR system or intermediary
 Generate acknowledgement from public health
agency
 Send acknowledgement to EHR system either
directly or through an intermediary
If applicable:
 Receive report from EHR system and send to
public health agency system
 Receive acknowledgement from public health
agency system and send acknowledgement to
EHR system
Table 2: Actors and Roles
<<Date>>
12
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
9.0 Triggers
For the purpose of this document, the term, “trigger” is meant to convey the specified reporting criteria
that is used to determine if a public health report should be sent to a public health agency, as
jurisdictionally defined. The criteria can be based upon several factors that include but are not limited
to:



Reporting criteria as specified by jurisdictional (e.g., federal, state, local or territorial) legislation,
statute or regulation.
Surveillance criteria as specified by an organization (e.g., public health agency, healthcare
provider, quality improvement organization, registry, etc.)
Patient observations or other healthcare-related assessments made by healthcare providers or
other staff
EHR reporting triggers, including validation/certification processes will be further specified and
documented in the Use Case Functional Requirements Document.
10.0 Use Case Diagram
Figure 1: Use Case Diagram
<<Date>>
13
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
11.0 Scenario: EHR System Sends Report to Public Health Agency
System
In this scenario, an Electronic Health Record System sends a report to a public health agency information
system based on a set of reporting criteria that are used to identify a public health event. This report
may be sent directly by the EHR system or through an HIE or similar intermediary sending system.
The high level EHR reporting process flow begins with the identification of an event of a possible
reportable public health event. When the event meets the pre-specified reporting criteria, the EHR
system renders or generates an electronic public health report. When the report has been verified, the
EHR system sends the report to the public health agency system and updates a log to reflect the
submission. The public health agency system receives the electronic report and sends an
acknowledgement of receipt to the sending EHR system. The EHR system receives the
acknowledgement.
More specifically, the EHR reporting process includes the following high-level steps:







The Public Health Agency determines the appropriate reporting criteria for a public health event.
The healthcare provider or provider EHR determines how the criteria will be implemented with the
EHR system infrastructure. As applicable, the reporting criteria are integrated into the provider’s
patient care process or programmed into the EHR system.
Once the EHR reporting criteria have been met, the EHR system prepares the public health report
and allows for healthcare provider completion, verification, and certification (where necessary)
Once the report is verified and/or certified for submission (where necessary), the EHR system
generates the electronic public health report
The EHR system sends the public health report to the public health agency system (or, if applicable,
the intermediary system) and updates the log to reflect transmission
The public health agency system receives the electronic report (either directly from the EHR system
or from the intermediary system)
The public health agency sends an acknowledgement of receipt to the sending EHR system, either
directly or through the intermediary system
The EHR system receives the acknowledgement
The User Stories that follow have been consolidated and generalized from over 30 individual user story
submissions. The User Stories below describe this scenario for selected public health domains –
communicable disease, chronic disease, child health, and adverse events.
11.1 User Story
The User Stories below are meant to be representative across the selected domains. These User Stories
have been generalized from submissions received from stakeholder members of the Public Health
Reporting Initiative.
It is important to note that these consolidated user stories and supporting information in Appendix A
provide a high-level description of public health reporting processes for the specific domains. There are
<<Date>>
14
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
public health reporting user stories that present more complexities in specific reporting requirements.
These types of requirements may be captured in the analysis of functional requirements, data elements
and value sets for specific reporting implementations and/or examined during later stages of this
initiative.
11.1.1 Communicable Disease
A patient is admitted to a hospital / medical facility or comes to a healthcare provider’s office. The
healthcare provider performs a clinical examination and evaluates the medical history of the patient. At
this point, the healthcare provider may:


Send a report to public health if the healthcare provider assessment indicates that the patient
presents with clinically significant findings or otherwise meets the criteria for a legally mandated
reportable condition (e.g., meets the criteria for legally mandated reportable condition and does
not require laboratory confirmation to report)
Order a diagnostic test, if the healthcare provider cannot rule out a reportable condition and the
patient’s clinical presentation does not met reporting criteria without diagnostic testing. Upon
receipt of test results, the healthcare provider re-examines diagnostic criteria and, if reporting
criteria are met, sends a report to the public health agency including diagnostic test results.
The public health agency information system receives the report and sends electronic acknowledgement
of receipt to the EHR system.
It is important to note that this consolidated user story and supporting Appendix A provide a high-level
description of public health communicable disease reporting processes. There are public health
reporting user stories (e.g. Healthcare Associated Infection reporting) that present more complexities in
specific reporting requirements, including the reporting of numerator and denominators for the specific
conditions. These types of requirements may be captured in the analysis of functional requirements for
specific reporting implementations.
11.1.2 Chronic Disease
A patient comes to a healthcare provider with symptoms of a disease or for a checkup. The healthcare
provider completes a clinical examination and assesses medical history. The healthcare provider reports
to a public health agency, depending on the reporting criteria. The healthcare provider orders laboratory
(clinical or pathology) and/or any diagnostic tests. Diagnostic tests are performed and/or laboratory
performs ordered tests on received specimens. The laboratory sends the results to the healthcare
provider. The healthcare provider re-examines clinical findings and/or diagnostic/lab results and
diagnoses a reportable condition. The EHR system sends the report to a public health agency
information system, depending on the reporting criteria. The healthcare provider treats the patient,
including a counseling session, if applicable. (Note: patient discharge data and/or hospital billing data
are combined into the EHR, if applicable.) The EHR system sends the report to a public health agency
information system, depending on the reporting criteria. The public health agency information system
receives the report and sends electronic acknowledgement of receipt to the EHR system.
<<Date>>
15
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
11.1.3 Newborn / Child Health
Newborn / Child Health reporting can be described through two user stories – each uses different data
elements and has different public health reporting criteria. It is important to note that these
consolidated user stories and supporting Appendix A provide high-level descriptions of public health
newborn and child health reporting processes. There are public health reporting user stories that
present more complexities in specific reporting requirements. These types of requirements may be
captured in the analysis of functional requirements, data elements and value sets for specific reporting
implementations.
Newborn
A child is delivered. The Newborn’s Electronic Health Record is established in the Birthing Facility EHR.
The establishment of the Newborn record in the EHR serves as a trigger event for well child care to
automate notifications with standing orders to conduct required newborn assessments and procedures
within 24-48 hours of birth (prior to discharge) such as hearing screening, metabolic testing, initial birth
defect assessment, Hepatitis B vaccination and other procedures. Consent for procedure and Consent
for information exchange is obtained from the caregiver. The required newborn assessment/test is
conducted; and the Hepatitis B vaccine is administered by the birthing facility staff. Information about
assessment/ test/vaccination is entered into the EHR. The birthing facility EHR pre-populates the Facility
Worksheet with the information needed by the vital statistics jurisdiction for the birth certificate or
report of fetal death. According to jurisdiction-specific laws, Public Health Reports on hearing screening
test results, initial birth defect assessment, and Hepatitis B vaccination are generated in Birthing Facility
EHR. The provider collects additional information needed for these reports and enters that information
in the Reports. The provider reviews, electronically signs and submits the Reports via health information
exchange (HIE) or directly to the Public Health Authority according to jurisdiction-specific laws. The
Public Health Authority information systems (early hearing detection and intervention information
system, birth defect registry, immunization registry) receive the Report and sends electronic
acknowledgement of receipt to the EHR system via HIE or directly.
The laboratory specimen for newborn metabolic testing is collected within 24-48 hours of birth (prior to
discharge). Data related to specimen and patient demographic is pre-populated on the test order form
from the Birthing Facility EHR. The provider reviews, certifies and submits the test order via health
information exchange (HIE) or directly to the laboratory. Specimen is sent to the laboratory. Laboratory
sends electronic acknowledgement of receipt of the test order to the Birthing Facility EHR via HIE or
directly. Laboratory conducts the metabolic test following jurisdiction-specific rules for metabolic
screening. Depending on jurisdictional workflows, test result reports from the Laboratory Information
Management System (LIMS) or other entities are sent to the EHR system or the Public Health Authority
information system (e.g., genetics information system). The Public Health Authority information system
<<Date>>
16
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
receives the Report from either LIMS or the provider EHR system and then sends electronic
acknowledgement of receipt; transmission of information is performed via HIE or directly.4
Child Health
A child with a caregiver comes to a provider for a well-child visit. The provider EHR queries HIE for
information on the child and uploads appropriate information into EHR. EHR calculates that the child is
due for a procedure (e.g., immunization, hearing test and others) and generates the notification to the
provider with the standing order. Consent for procedure and Consent for information exchange is
obtained from the caregiver. The provider and/or staff performs the appropriate procedure (or refers to
a specialist) and enters information into the EHR.
According to jurisdiction-specific laws, Public Health Reports on the procedure are generated in the
provider EHR. The provider collects additional information needed for these reports and enters that
information in the Reports. The provider reviews, electronically signs and submits the Reports via health
information exchange (HIE) or directly to the Public Health Authority according to jurisdiction-specific
laws. The Public Health Authority information systems (early hearing detection and intervention
information system, birth defect registry, immunization information system) receive the Report and
sends electronic acknowledgement of receipt to the EHR system via HIE or directly.
11.1.4 Adverse Events
A patient receives healthcare services (e.g. administered medication or vaccine, surgical or diagnostic
procedure) and the appropriate information (e.g., vital signs, lab results, medical product information,
etc.) is entered or uploaded into the EHR system. Note that EHR data entry or upload may or may not
be an automated process. When an adverse event occurs and determined to meet appropriate
reporting criteria, the EHR system renders or generates an adverse event report. When necessary, the
healthcare provider or other staff validates or certifies the accuracy and completeness of the report.
When necessary, the healthcare provider or other staff enters additional information into the report.
Upon successful verification and/or certification, the EHR system generates the adverse event report
and sends it to the public health agency system or when appropriate, to another intermediate system
(e.g., HIE, registry or incident reporting system).
If applicable, the intermediate system sends the report to the public health agency information system.
The public health agency or intermediate system receives the report and sends an electronic
acknowledgement of receipt to the EHR system.
It is important to note that this consolidated user story and supporting Appendix A provide a high-level
description of public health adverse event reporting process. There are public health reporting user
stories (e.g. Healthcare Associated Infection reporting) that present more complexities in specific
reporting scenarios, for example, mandatory versus voluntary reporting requirements, and reporting of
numerators and denominators for the specific conditions. These requirements are further clarified and
4
Note: direct reporting for a laboratory (or LIMS) to public health is out of scope for this phase of the Public
Health Reporting Initiative. It may be considered in future versions.
<<Date>>
17
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
captured during the analysis and discussion of detailed functional requirements for the use case, taking
into account existing reporting processes and implementations.
11.1.5 Infrastructure/Quality/Research
The user stories in the Infrastructure, Quality, and Research domain may have elements that are
applicable throughout other stories submitted to this initiative. These user stories may be used/re-used
by other stories in functional requirements and data modeling discussions. Infrastructure, Quality, and
Research user stories are generally focused on quality reporting, administrative data reporting, and
infrastructure.
11.2 Activity Diagram
The sections below describe the high-level public health reporting activity flow. The diagram depicts
both the primary and alternate reporting scenarios, where the report can be sent either directly from an
EHR system to a public health agency system, or can be sent through an HIE or other intermediary
system (e.g., incident reporting system or patient safety organization). The primary reporting flow (i.e.,
base flow) – the submission of a report from an EHR system directly to a public health agency – is
depicted in the activity flow below in white boxes and black arrows. The alternate reporting flow – the
submission of a report through intermediary system such as an HIE or Incident Reporting System – is
depicted in the activity flow below using grey boxes and grey arrows. Both flows are further described
in the following sections.
<<Date>>
18
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
Electronic Health
Record System
Intermediary
System
Public Health
Agency System
(1)
Generates and
Sends report
(2)
Receives report
(1a)
Receives report
(1b)
Sends report
(4)
Receives
acknowledgement
of receipt
(3)
Sends
acknowledgement
of receipt
(3a)
Receives
acknowledgement
of receipt
(3b)
Sends
acknowledgement
of receipt
Figure 2: Activity Diagram
11.2.1 Base Flow
The base flow (primary reporting flow) describes the submission of a report to a public health agency
directly from a healthcare provider EHR system. This flow assumes that an event of public health
interest has been identified and meets pre-specified reporting criteria. Note that additional system
interactions and acknowledgements will be described in additional documents, including the functional
requirements and implementation specification.
Step
#
Actor
<<Date>>
Role
Event/Description
Inputs
Outputs
19
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
Step
#
1
2
3
4
Actor
Role
Event/Description
EHR
System
Generate and
Send Report
EHR System
generates public
health report and
sends to public
health agency system
(Note: healthcare
provider may
verify/certify report
prior to send)
Public
Health
Agency
System
Public
Health
Agency
System
EHR
System
Receive
Report
Public Health Agency
System receives
report
Send
Acknowledge
ment
Public Health Agency
System sends
acknowledgement of
receipt of report
EHR System receives
acknowledgement of
receipt
Receive
Acknowledge
ment
Inputs
Public health
reporting criteria;
report
generated/sent
when
patient/healthcare
data meets
reporting criteria
and appropriate
report validation
and certification
processes are
complete.
Receipt of public
health report
Receipt of public
health report
Acknowledgement
of receipt of public
health report
Outputs
Public health report,
including at a
minimum all
required data
elements that meet
the specified report
type, in
standardized
structured format
Program-specific
outputs (out of
scope for this
document)
Acknowledgement
of receipt of public
health report
END
Table 3: Base Flow
11.2.2 Alternate Flow
In the alternate flow, a healthcare provider sends the report through an intermediary system (e.g., HIE,
Incident Reporting System, Patient Safety Organization) to a public health agency. Note that there are
various considerations for the HIE or other intermediaries, including possible requirements for routenot-read; privacy/security controls, including appropriate encryption of data; and the potential for the
intermediary to generate a report based on data received in various systems. The full elaboration of
these requirements is out of scope for the use case, and can be elaborated in the development of
Functional and Information Exchange Requirements.
Step
#
Actor
<<Date>>
Role
Event/Description
Inputs
Outputs
20
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
Step
#
1
Actor
Role
Event/Description
Inputs
EHR System
Generate
and Send
Report
EHR System
generates public
health report and
sends to Public
Health Agency
System (Note:
healthcare provider
may verify/certify
report prior to send)
1a
Intermediary
System
Receive
Report
HIE System receives
report
1b
Intermediary
System
Send
Report
HIE System sends
report to Public
Health Agency
System
Receipt of public
health report
2
Public Health
Agency
System
Receive
Report
Public Health Agency
System receives
report
Receipt of public
health report
3
Public Health
Agency
System
Send
Acknowle
dgement
Receipt of public
health report
3a
Intermediary
System
Receive
Acknowle
dgement
3b
Intermediary
System
Send
Acknowle
dgement
4
EHR System
Receive
Acknowle
dgement
Public Health Agency
System sends
acknowledgement of
receipt of report to
HIE system
HIE System receives
acknowledgement of
receipt from Public
Health Agency
System
HIE System sends
acknowledgement of
receipt to EHR
system
Healthcare provider
receives
acknowledgement of
receipt from HIE
system
Public health
reporting criteria;
report
generated/sent
when
patient/healthcare
data meets
reporting criteria
and appropriate
report validation
and certification
processes are
complete.
Receipt of public
health report
Outputs
Public health report,
including at a
minimum all
required data
elements that meet
the specified report
type, in
standardized
structured format
Public health report
in standardized
structured format.
Public health report
in standardized
structured format
Program-specific
outputs (out of
scope for this
document)
Acknowledgement
of receipt of public
health report
Acknowledgement
of receipt of public
health report
Acknowledgement
of receipt of public
health report
Acknowledgement
of receipt of public
health report
Acknowledgement
of receipt of public
health report
Acknowledgement
of receipt of public
health report
END
Table 4: Alternate Flow
<<Date>>
21
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
11.3 Functional Requirements
The functional requirements for this use case, which includes the data elements, terminology and data
exchange standards requirements will be provided in a separate Functional Requirements Document.
11.3.1 Sequence Diagram
The sequence diagram below depicts the system interactions between the EHR system, Intermediary
System or Network and the Public Health Agency. Both the primary and alternate reporting flows are
represented. Healthcare providers may send reports directly to a public health agency system or
through an intermediary system or network.
Electronic Health Record System
Intermediary System
Public Health Agency System
Send Initial Case/Event Notification
Send Initial Case/Event Notification
Send Initial Case/Event Notification
Send Acknowledgement
Send Acknowledgement
Send Acknowledgement
Figure 3: Sequence Diagram
12.0 Policy and Regulatory Issues
The primary policy issue at hand is the intention to converge the public health reporting rules into a
single standard. Some hope to have a solution that fits all needs, even as others recognize the inherent
differences between local laws and policies that may have disparate requirements. For example, one
jurisdiction may not be able to request date of birth and store age in their system instead, whereas
another may in fact be required by law to collect date of birth. The Public health reporting criteria are
based on specific jurisdictional or public health agency requirements and may vary from condition-tocondition or jurisdiction-to-jurisdiction.
Reporting to public health agencies is most often governed by state statutes, regulations and policies
that are different than what governs other types of health information exchange. While Health
Insurance Portability and Accountability Act (HIPAA) regulations are the primary determinant of privacy
protections for most health information exchange (or statutes in states that exceed HIPAA regulations),
<<Date>>
22
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
reporting to public health agencies is generally exempt from HIPAA regulations, governed instead by a
patchwork of state statutes, regulations and policies. However, as was learned in the multiyear Health
Information Security and Privacy Collaborative, interpretation and implementation of even national
regulations such as HIPAA can vary considerably within the same state. So, inconsistent regulations and
policies around health information exchange, including public health reporting, appear to be a given in
this country. This can certainly be seen as a reflection of the level of care and caution being exercised
around privacy protections and health information exchange, which is entirely appropriate. Earning
ongoing public trust in health information exchange, including public health reporting, is critical to
achieving the HITECH and broader e-health goals in this country.
However, the public health community is increasingly questioning whether the degree of interjurisdictional variation in privacy protections and especially reporting regulations are necessary. This use
case provides an opportunity to explore areas of similarities and differences in reporting requirements
that could contribute to greater harmonization over time. However, it is important to keep in mind that
state statutes and regulations are only changed through often lengthy and complex public processes and
occur on a state-by-state basis. Federal preemption of state privacy laws and regulations is highly
unlikely (except for periodically establishing the floor as was done with HIPAA). Harmonizing other
policies, such as establishing core data elements for particular public health domains, is much more
under the control of the professional domains, and so amendable to cross-domain harmonization.
<<Date>>
23
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
Appendices
Appendix A: User Stories
The Initiative received user stories from the community and worked with the community to consolidate
the submissions around five general Public health domains – communicable disease; chronic disease;
child health; adverse events; and infrastructure, quality, and research. Each domain-area consolidated
user story is presented below, with the following elements:







User story names – the names of the individual user stories that contributed
Actors – the actors involved in the consolidated story
Flow of events – the high level flow of events across the consolidated user story
Information exchange artifacts – identifies the data/content that the report should contain (e.g.,
paper form content or dataset/class)
Pre-conditions – the system(s) that creates/sends reports
Post-conditions – the system(s) that receives reports
Preferred timing – desired frequency of reporting (if applicable)
Communicable Disease Consolidated User Story (Reporting from EHR system)
User Story
Names:
Provider-Initiated Report from the EHR system
(Communicable Diseases)
Actors:
Patient, Healthcare Provider (Hospital, Physician’s office),
Laboratory, Public Health Agency
Flow of Events: 1.
2.
3.
4.
5.
Patient was admitted to a hospital, emergency room
(ER), or came to a provider’s office
Provider provided clinical examination and assessed
medical history
a. [trigger: all Emergency Department records
sent] If provider assessment indicates that
Patient has symptoms that should be reported
through Syndromic Surveillance (SS) system, a
SS repot was sent to public health agency.
Electronic confirmation was sent from public
health agency system to provider.
b. [trigger: clinically significant symptoms of
reportable communicable disease – sent
before lab results are obtained] If patient’s
symptoms require a specific communicable
disease public health report without waiting for
laboratory results, a preliminary report was
sent to public health agency.
Provider orders lab tests.
Laboratory performs ordered tests on received
specimens. Laboratory sends results to Provider and
public health agency (if needed)
Provider re-examines clinical findings and lab results; he
sends a communicable disease preliminary report to a
public health agency (some reports require clinical and
<<Date>>
Information Exchange Artifacts







Provider information
Ordering facility
Patient information
Patient employment
Clinical information
Laboratory test order/result
Additional epidemiologic data
24
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
6.
7.
lab component)
Electronic message validated by public health agency
information system.
Electronic confirmation sent from public health agency
to provider.
Sending
System(s):
EHR System, Health Information Exchange (HIE)
Receiving
System(s):
Public Health Agency Information Systems
Preferred
Timing:
It is important to note that the above description provides a basic description of communicable disease
reporting processes. There are public health reporting user stories (e.g. Healthcare Associated Infection
reporting to CDC’s National Healthcare Safety Network) that present more complexities in specific
reporting requirements, including the reporting of numerator and denominators for the specific
conditions. These types of requirements may be captured in the analysis of functional requirements,
data elements and value sets for specific reporting implementations.
Chronic Disease Consolidated User Story #1
User Story
Names:
cancer, occupational health, future flow for National Center
for Health Statistics (NCHS), genetic counseling
Actors:
Patient, Healthcare Provider/Physician, Laboratory, Public
Health Agency
Flow of Events: 1.
2.
3.
4.
5.
6.
7.
Patient comes to Physician at specific healthcare facility
with symptoms of a disease or for a check up
Physician provides clinical examination and assesses
medical history.
Physician orders lab (clinical or pathology) and any
diagnostic tests.
Physician discontinues, changes, and/or orders new
medications and/or services and/or
consultations/referrals
Any other diagnostic tests are performed and
Laboratory performs ordered tests on received
specimens.
Laboratory send results to Physician [and Public Health
Agency for reportable conditions]
Physician re-examines clinical findings/diagnostic results
and lab results and diagnoses reportable condition,
treats patient, including discontinues, changes and/or
orders new medications and/or services and/or
consultations/referrals and/or new lab tests based on
previous results
<<Date>>
Information Exchange Artifacts














Provider Info
Demographic patient info
Diagnosis
Payer information
Encounter information
Medical history
Family history
Procedures
Results of testing (lab and otherwise)
Risk factors
Exposure information
Occupational information
Employer information
Medications
25
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
8.
9.
10.
11.
12.
13.
Physician completes counseling session, if applicable
IT personnel combines EHR patient discharge data with
Hospital billing data, if applicable
Physician/EHR system sends report to a Public Health
Agency for reportable conditions
Electronic report validated by Public Health Agency
information system
EHR system sends a CCD/CCR electronic ‘snapshot’ of
the episode of care to Health Information Exchange
agency
Electronic confirmation/acknowledgement was sent
from Public Health Agency to Provider
Sending
System(s):
EHR System
Receiving
System(s):
Public Health Agency Information Systems
Preferred
Timing:
Varies currently – prefer real time
<<Date>>
26
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
Chronic Disease Consolidated User Story #2
User Story
Names:
Quality, NCHS current flow, Cardiovascular Disease (CVD)
Actors:
Patient, Healthcare Provider/Physician/healthcare facility,
billing staff, PH authority
Flow of Events: 1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Patient admitted to specific healthcare facility
Billing creates Public Health report based on status
Physician provides clinical examination and assesses
medical history.
Physician orders lab (clinical or pathology) and any
diagnostic tests.
Nursing or ancillary staff takes samples and sends them
to Laboratory.
Physician discontinues, changes, and/or orders new
medications and/or services and/or
consultations/referrals
Any other diagnostic tests are performed and
Laboratory performs ordered tests on received
specimens.
Laboratory send results to Physician [and Public Health
Agency for reportable conditions]
Physician re-examines clinical findings/diagnostic results
and lab results and diagnoses reportable condition,
treats patient, including discontinues, changes, and/or
orders new medications, and/or services, and/or
consultations/referrals, and/or new lab tests based on
previous results
Patient is discharged from specific healthcare facility
Billing system or clearing house sends report/discharge
claim records to a Public Health Agency
Electronic report validated by Public Health Agency
/information system
Electronic confirmation/acknowledgement was sent
from Public Health Agency to Provider
Information Exchange Artifacts












Provider Info
Demographic patient info
Diagnosis
Payer information
Case details (clinical symptoms etc.)
Procedures
Results of testing (lab and otherwise)
Risk factors
Exposure information
Occupational information
Employer information
Medications
Sending
System(s):
Billing system within the EHR System
Receiving
System(s):
Public Health Agency Information Systems
Preferred
Timing:
For CVD: Admit – 5 days after admit and 24 hours after billing code assigned
For NCHS: Discharge – preferred quarterly (accepted monthly or 24 hours)
For Quality: patient encounter is completed - quarterly
<<Date>>
27
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
Child Health Consolidated User Story – Birthing Facility
User Story
Names:
Vital Records, Hearing, Immunization, Birth Defects,
Metabolic Screening
Actors:
Newborn, Caregiver, Provider, Hospital staff, Public Health
Program Staff
Flow of Events: 1. Child is delivered.
2. Provider conducts initial physical exam and assessment
for birth defects. If live birth, follow steps 3-9. If fetal
death, follow steps 7-9.
3. Newborn is due for <immunization, hearing test,
metabolic test, other newborn tests, birth registration,
etc.> Provider obtains consent for procedure and
information exchange from caregiver.
4. Provider orders an <immunization, hearing test,
metabolic test, additional birth defect testing, etc.>
5. Hospital staff administers <immunization> and conducts
<hearing test> and collects <blood specimen> and
conducts <birth defect testing>
6. Hospital staff enter data on the <immunization, hearing
test, birth defects, lab order> into the EHR. EHR
generates public health report
7. EHR system pre-populates information to the Birth/Fetal
Death Facility Worksheet
8. Hospital staff and provider review/electronically signs the
Birth/Fetal Death Facility Worksheet and public health
report
9. Public health report is electronically sent on
<immunization, hearing test, metabolic test order, birth
defect, birth registration/fetal death registration, etc.> to
the appropriate public health information systems as
jurisdictionally defined directly or via HIE
10. Public Health Authority information system (IS)
<Immunization IS, Early Hearing Detection & Intervention
(EHDI) IS, Metabolic IS, Birth Defect IS, Vital Records IS>
receives notification of report availability
11. Public health authority staff reviews the report and
create public health IS record on a child in <Immunization
IS, EHDI IS, Genetic IS, Birth Defect IS, Vital Records IS>
12. Public health IS sends Acknowledgement of Receipt of
the Report to EHR system directly or via HIE.
Information Exchange Artifacts
1&2 Demographics, Antepartum Record, Prenatal
record, Labor & Delivery Record, Postpartum
record, Newborn EHR
3. Consent for procedure as jurisdictionally defined
(not for birth registration) and Consent for
information exchange
4. Test Order or Standing Order
5. Immun. Record, Test Results, Birth Defect Record
6. Immun. Record, Hearing Test Results, Birth Defect
Record, Birth Record, Lab Order
7&8. Birth/Fetal Death Facility Worksheet
9. Public health report <immunization, hearing test,
metabolic test order, birth defect, birth
registration/fetal death registration, etc.>
10. Notification of Report Availability
11. Updated public health record
12. Acknowledgement of receipt
Sending
Systems:
EHR System, Health Information Exchange (HIE), other Intermediary System
Receiving
Systems:
Public Health Information Systems <Immunization IS, EHDI IS, Birth Defect IS, Vital Records IS, Genetic Testing IS,
etc.>
Preferred
Timing:
Daily updates
<<Date>>
28
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
Child Health Consolidated User Story – Outpatient Setting
User Story
Names:
Child Health <Immunization, EHDI>
Actors:
Child, Pediatrician, Provider, Specialist, Public Health
program staff
Flow of Events: 1. Child with caregiver comes to pediatrician for a well-child
care visit (general check-up) and he/she is due for
<immunization, hearing test, etc.> Provider obtains
consent for procedure and information exchange from
caregiver.
2. Physician orders <immunization> or refers to an
Audiologist <hearing test> or a Specialist <other tests>
3. Provider administers an immunization; Audiologist
conducts hearing test
4. Provider/Audiologist enter data on the <immunization,
hearing test> into the EHR
5. EHR system generates public health report
6. Provider review/electronically signs the public health
report
7. Public health report is electronically sent on
<immunization, hearing test> to the appropriate public
health information systems as jurisdictionally defined
directly or via HIE
8. Public Health Authority information system (IS)
<Immunization IS, Early Hearing Detection & Intervention
(EHDI) IS > receives notification of report availability
9. Public health authority staff reviews the report and
updates the public health IS record on a child in
<Immunization IS, EHDI IS>
10. Public health IS sends Acknowledgement of Receipt of
the Report to EHR system directly or via HIE.
Sending
Systems:
EHR System, Health Information Exchange (HIE)
Receiving
Systems:
Public Health Information System <Immunization IS, EHDI IS>
Preferred
Timing:
Daily updates
<<Date>>
Information Exchange Artifacts
1. Demographics, Consent for procedure as
jurisdictionally defined and Consent for information
exchange
2. Test Order, Referral
3. Immunization Record. Test Results
4. Test Results
5,6 & 7 Public health report
8. Notification of Report Availability
9. Updated public health record
10. Acknowledgement of receipt
29
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
Adverse Events Consolidated User Story
User Story
Names:
Actors:
Healthcare Provider Reporting; Agency for Healthcare
Research and Quality (AHRQ) Common Formats; American
Immunization Registry Association (AIRA); Food and Drug
Administration (FDA) Adverse Event Reporting; CDC’s
National Healthcare Safety Network (NHSN)
Information Exchange Artifacts
Patient, Healthcare Provider (HCP), Immunization Registry,
Public Health / Patient Safety Organization
Flow of Events: 1.
2.
3.
4.
5.
6.
7.
Surveillance parameters are programmed into an EHR
system based on specific jurisdictional or Public Health
Agency requirements (e.g., Liver function test, or
serious adverse event)
A patient receives healthcare services and information
is uploaded to the HCP EHR (e.g., vital signs, lab results,
etc.) via manual data entry, HCP PDA-device or other
EHR data interface
When the surveillance criteria is met, an adverse event
report form is automatically rendered for HCP review
Report form is auto populated with appropriate patient
and event information based upon jurisdictional or
Public Health Agency requirements
HCP validates completeness of report and make
adjustments as necessary (e.g., add reporter’s
comments)
HCP local system (EHR system or Incident Reporting
System) sends report to Public Health Agency
Public Health Agency sends acknowledgement to HCP
local system that report was received





Patient Demographics
Relevant Medical History and Lab: pre-existing
conditions, diseases, tests, procedures
Adverse Event Information: date, time, adverse
event description and patient outcome
Product Information: suspect and concomitant
medications, medical devices, other therapies,
dates of use, indication, dose, strength, name,
identifiers, etc. (Reference specific FDA
reporting form, AHRQ Common Format
Template, NHSN Implementation Guide and
Immunization information system
implementation guide)
Reporter Information: name, address,
telephone/email, and facility contact
information
Note: Data categories are unique to the specific
program and datasets/data elements are available
for reference.
Sending
System(s):
RSS System, Laboratory information system, EHR System, Incident Reporting System
Receiving
System(s):
Public Health Agency Information Systems or Patient Safety Organization’s Information System
Preferred
Timing:
Varies depending on jurisdictional or Public Health Agency requirements.
<<Date>>
30
Use Case Development and Functional Requirements for Interoperability
Public Health Reporting Intiative
Appendix B: Acronyms
Acronyms used in the document are identified in the table below.
Term
Agency for Healthcare Research and Quality
American Immunization Registry Association
American Recovery and Reinvestment Act of 2009
Centers for Medicare and Medicaid Services
Early Hearing Detection and Intervention
Electronic Health Record
Electronic Medical Record
Emergency Room
Food and Drug Administration
Health Information Exchange
Health information technology
Health Information Technology for Economic and
Clinical Health Act of 2009
Health Insurance Portability and Accountability Act
Healthcare Provider
Information System
Laboratory Information System
Laboratory Results Interface Workgroup
Meaningful Use
Office of the National Coordinator for Health
Information Technology
Personal Health Record
Public Health Laboratory Reporting Workgroup
Public Health Reporting Initiative
Standards & Interoperability Framework
Acronym
AHRQ
AIRA
ARRA
CMS
EHDI
EHR
EMR
ER
FDA
HIE
HIT
HITECH Act
HIPAA
HCP
IS
LIS
LRI Workgroup
MU
ONC
PHR
LRI Public Health Workgroup
PHRI
S&I Framework
Appendix C: Glossary of Terms
A glossary of terms has been developed for the Public Health Reporting Initiative. These terms and their
definitions are available as a word document through the S&I Framework wiki. A more extensive excel
spreadsheet detailing these terms, their definitions, and reference sources is also available. Visit
http://wiki.siframework.org/PHRI+-+Definitions+Sub-Working+Group to access these resources.
<<Date>>
31