Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
Public Health Reporting
Initiative
Functional Requirements Description
9/25/2012
1
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
Table of Contents
1.0
2.0
2.1
3.0
3.1
3.2
3.3
3.4
3.5
4.0
5.0
5.1
5.2
5.3
6.0
7.0
7.1
7.2
8.0
9.0
Preface and Introduction .................................................................................................................. 2
Initiative Overview ............................................................................................................................ 3
Initiative Challenge Statement...................................................................................................... 4
Use Case Scope ................................................................................................................................. 5
Background ................................................................................................................................... 6
In Scope ......................................................................................................................................... 6
Out of Scope.................................................................................................................................. 7
Communities of Interest ............................................................................................................... 8
Actors and Roles ......................................................................................................................... 10
Public Health Reporting Workflow ................................................................................................. 11
Functional Requirements ................................................................................................................ 21
Information Interchange Requirements ..................................................................................... 21
System Requirements ................................................................................................................. 22
Triggers........................................................................................................................................ 23
Non-Functional Requirements ........................................................................................................ 24
Dependencies and Future Considerations ...................................................................................... 25
Dependencies.............................................................................................................................. 25
Additional Components and Considerations .............................................................................. 26
Dataset Requirements .................................................................................................................... 27
Standards Analysis .......................................................................................................................... 28
List of Figures:
Figure 1: Public Health Reporting Workflow ............................................................................................. 14
Figure 2: Public Health Reporting Workflow with Swimlanes .................................................................... 16
List of Tables:
Table 1: Public Health Reporting Communities of Interest ....................................................................... 10
Table 2: Public Health Reporting Actors and Roles.................................................................................... 11
Table 3: Details about Actions in the Public Health Reporting Workflow ................................................. 21
Table 4: Information Interchange Requirements ...................................................................................... 22
Table 5: Public Health Reporting General System Requirements.............................................................. 22
Table 6: Types of Non-Functional Requirements....................................................................................... 24
Table 7: Types of Dependencies ................................................................................................................. 26
Table 8: Additional Considerations ............................................................................................................. 27
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
2
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
Cases and associated functional requirements that define the requirements for health care data
exchange. The functional requirements document is used to specify requirements from a broad range of
stakeholders interested in a specific information exchange. Examples of stakeholders include but are
not limited to healthcare providers, EHR system vendors, public health organizations, and federal
agencies.
The functional requirements described in this document pertain to public health reporting data
exchange and help define:
•
•
•
•
The operational context for the data exchange
The stakeholders with an interest in specific user stories
The information flows that must be supported by the data exchange
The types of data and their required specifications for data exchange
The document provides the foundation for identifying and specifying the standards required to support
the data exchange, and facilitate development and/or identification of reference implementations and
tools needed to ensure consistent adoption and applicability of the data exchange standards across
user stories. This document is not intended to replace existing functional requirements or
implementation guides currently in use across the various public health reporting functions referenced
in this document.
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 for a
variety of reporting scenarios.
The PHRI consolidated use case was derived using a sample of existing public health reporting scenarios
submitted by Public Health Reporting Initiative members. Some of the user stories submitted for this
initiative reflect current workflows and information flows, but others represent a proposed future state.
For this use case, “public health reporting” refers to provider-initiated 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.
3
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
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.
This document will build upon the existing use case document to define the functional and nonfunctional requirements. In addition, this document references a data model and data element
mapping as outputs generated by harmonization of the user stories submitted under this initiative.
2.1
Initiative Challenge Statement
Much public health reporting currently relies on paper forms that are mailed, emailed or faxed; thus
necessitating manual data collection and transmission by providers, and/or manual data entry and
coding by the public health agency prior to initiating analysis or follow-up. There is relatively little
nationwide standardization of public health electronic information exchange, although standardization
does seem to be increasing. . 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 reduce the costs associated with the variability of building and maintaining disparate
specifications. In addition, as a complement to this reduction in costs, this initiative aims to simplify
data exchange and improve interoperability across reporting scenarios for both the senders and
receivers of public health reports. The anticipated healthcare benefit of a successful initiative is a more
standardized and efficient set of infrastructure requirements (standards, terminology, specifications and
tools) applicable to multiple types of provider-initiated public health reports which are typically
mandated by law or regulation. The anticipated public health benefit is more timely, reliable, secure,
standardized and efficient public health reporting which can be received and managed by a more
uniform infrastructure. Automated reporting to public health agencies will help streamline both
4
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
manual, paper-based operations and variable electronic requirements and should result in improved
efficiency. By receiving faster and more harmonized reports, public health agencies should 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 PHRI Use Case focuses on a provider-initiated report – a report sent from a provider (using an EHR
system) to a public health agency system containing 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. The report will include data elements automatically populated with
information from the patient’s record in the EHR; it may also include additional information manually
entered by healthcare personnel using the EHR interface. The basic reporting transactions covered by
this use case are:
•
•
•
•
Send report (EHR System)
Receive report (Public Health Agency System)
Send acknowledgement of report receipt (Public Health Agency System)
Receive acknowledgement of report receipt (EHR system)
The reporting transactions are described by two potential information flows between an EHR system
and a public health agency. The primary report flow (“basic flow”) is the transmission of a report
directly from the provider’s EHR system to the public health agency system. The alternate report flow is
the transmission of the report from the EHR system through an intermediary system, such as a Health
Information Exchange or Incident Reporting System, to a public health agency.
The Initiative recognizes that cases and reportable events may be identified through a variety of means,
including, but not limited to, provider recognition and/or automated EHR detection. The mechanism for
identifying such reportable events is out of scope for the Public Health Reporting Initiative – the scope
of the Initiative is identifying and defining required and optional data elements for an EHR system to
include in a provider-initiated report and sending it to a public health agency system.
Note that it is not the intent of this initiative to circumvent existing public health reporting infrastructure
or supercede existing widely-used implementation guides (such as those cited in Stages 1 or 2 of the
EHR Incentive Program - “Meaningful Use”). Those public health programs with existing information
exchange specifications that satisfy their requirements (e.g. immunization registry reporting; healthcare
acquired infection reporting) may continue to use existing implementation guides to support their
needs. At the same time, the Public Health Reporting Initiative has welcomed participation from
participants in such existing information exchange and recognizes that both new and established forms
of exchange may benefit from our efforts to develop harmonized reporting content and format.
5
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
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
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 Functional Requirements analysis:
2
Letter of June 16, 2011 from HITPC chairs to the National Coordinator for HIT.
6
•
•
•
•
•
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
Identifying and harmonizing the core reporting data elements required by public health agencies
shared by various types of reportable events
Identifying and harmonizing (to extent practical) additional data elements required by public
health agencies for specific types of reportable events (e.g., newborn hearing screening or
healthcare associated infections)
Defining a standard exchange format including structure and content (i.e., vocabulary)
Defining the requirements for limited bi-directional data exchange between EHR systems and
public health agency systems – sending the report, receiving the report, and transmitting an
acknowledgement of receipt
Identifying the content requirements to send reports from certified EHR systems (in a variety of
clinical settings where EHR data is used for reporting purposes – for example, inpatient,
outpatient, emergency room, urgent care, etc.) to public health agencies (Note: the initiative
recognizes that other report information (e.g., administrative, laboratory, pharmacy) may be
imported from separate systems into the EHR in order to complete a public health report;
however, the functional requirements for these systems, including the EHR interface
requirements, are not in scope for this use case)
3.3
Out of Scope
The following activities are out of scope for the PHRI Functional Requirements analysis:
•
•
•
•
•
•
•
•
Defining specifications and guidelines on reportable event criteria (e.g., defining reportable
conditions) – by law these specifications typically rest with states. This Initiative will enable
healthcare providers to submit a report based on jurisdictionally-defined laws and regulation,
but will not be responsible for actually creating those reporting criteria
Describing the precise processes for healthcare providers to add information into an EHR
manually or from an auxiliary (e.g., administrative, laboratory, pharmacy, etc.) system, or how
EHRs or providers recognize public health report “triggers”. It is expected that these details
would be defined by an implementation or demonstration project for a specific user story /
public health reporting scenario;
Describing the process for public health agencies to perform follow-up activities, including case
monitoring
Defining specifications and guidelines for reporting by other communications methods such as
telephone, web-based data entry, mailed, or faxed reports)
Describing any additional or extensive bi-directional communication between a public health
agency and a healthcare provider beyond the limited exchange supported by this use case (i.e.,
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
This Initiative acknowledges that all functions supported by current reporting programs are not
addressed in this document; the Initiative focuses on a common functional starting point – the presence
7
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
of key information in an EHR system that is needed to generate a public health report. The Initiative has
identified other use cases that may have similar actors and information requirements, but which are in
some ways distinct and out of scope for this initiative. These out-of-scope use cases include, but are not
limited to, the following:
•
•
•
Patient referral to a public health agency (e.g., tobacco quit-line) for services. In this scenario,
the initial public health report may not reflect all the necessary information for the referral or
transition of care or all requirements for the bidirectional exchange that would typically follow a
referral
A request for information initiated by a clinical provider about a patient (or set of patients) and
sent to a public health system (e.g., a request for a complete immunization history from a public
health Immunization Information System.. Again, the content and flow of information may have
requirements that go beyond those of simple provider-initiated public health reports.
Other Standards and Interoperability Initiatives (e.g. Transitions of Care and Query Health) are
alternate use cases that may (now or in the future) also be used to support public health
surveillance in addition to or as a replacement for Public Health Reporting, and may inform or
be informed by the PHRI content and format specifications.
However, it is likely that the harmonized data elements and specifications produced by this initiative
will also expedite the implementation of these alternate use cases. For example, data elements such as
the contact information for the subject of the report may support follow-up activities of public health
programs. Thus we welcome the participation of persons interested in these use cases in defining the
products of this Initiative. It is also possible that future phases of this initiative may address some
aspects of these other use cases, although they remain are out of scope for the current phase.
3.4
Communities of Interest
Member of Communities of Interest
Healthcare Provider
Public Health Agency
Description
Any supplier of a healthcare service; person or organization
that furnishes healthcare in the normal course of business.
Includes physicians and healthcare provider staff, as well as
ancillary healthcare 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.
8
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
Member of Communities of Interest
Description
Electronic Health Record (EHR) /
An EHR is an electronic record of health-related information
Electronic Medical Record (EMR) /
on an individual that conforms to nationally recognized
Personal Health Record (PHR)
interoperability standards and that can be created, managed,
Vendors and Suppliers
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 System
Vendors or suppliers of Public Health Information Systems Vendors/Suppliers
applications which may, among other things, receive public
health reports
Standards Development Organizations
Organizations key to identifying, balloting, approving, and
maintaining health information exchange standards, including
exchange, terminology, security, and transport protocols.
Health Information Exchange
Organizations (including state Designated Entities for Health
Organizations
Information Exchange, as well as other organizations
managing information exchange among different corporate
entities). Includes Regional Health Information Organizations
(RHIOs).
Intermediary Systems
Systems or organizations that support the transmission of
information from an EHR system and/or a public health
agency system. For the purposes of this document, an
intermediary system is any system that serves to transport
information to or from an EHR or public health agency
system.
Patient Safety Organization
A group, institution or association that improves medical care
by reducing medical errors
Quality improvement/measurement
A group of doctors and healthcare experts that evaluate and
organizations
seek to improve the care given to people. For
example, Quality Improvement Organizations (QIOs) 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.
Accountable Care Organization (ACO)
An ACO is an organization of health care providers that agrees
to be accountable for the quality, cost, and overall care of
Medicare beneficiaries who are enrolled in the traditional feefor-service program who are assigned to it
Laboratory
The laboratory performs laboratory analyses and produces
lab test results (typically as the filler of a lab order by a
licensed health professional).
9
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
Member of Communities of Interest
Description
Laboratory Information System (LIS) or An application to streamline the management of laboratory
Laboratory Information Management
processes including data collection, workflow management,
System (LIMS), Vendors/Suppliers
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: Public Health Reporting Communities of Interest
3.5
Actors and Roles
The table below describes the roles of the actors in the public health reporting workflow. More detail
about each action in the workflow is provided in later sections.
Actor
Healthcare Provider
EHR System (healthcare provider system)
Public Health Agency System
Role
• Deliver care to patient
• Enters information into EHR
• If applicable – suspect reportable event to begin
report generation process
• If applicable – send any immediately-required
public health reports
• If applicable – add information, sign, and/or
verify public health report prior to sending
• Collect, receive, and/or store patient-level data
• Support additional data entry (e.g. populate
data on an electronic form and allow healthcare
provider to add information)
• Generate public health report and make it
available for validation
• Validate public health report based on
implementation-specific business rules when
automation of validation is possible/allowable.
• 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
10
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
Actor
Role
Intermediary Systems, including Incident
If applicable:
Reporting Systems, Health Information
• Receive report from EHR system and send to
Exchange Systems, Health Information
public health agency system
Networks, etc.
• Receive acknowledgement from public health
agency system and send acknowledgement to
EHR system
Note: Intermediary System is a generic term used to
identify HIT systems or networks that are external to
the EHR system and are used to communicate
between EHR systems and public health agency
systems.
Supporting System (e.g., Testing Facility
If applicable:
System, Laboratory System)
• Transmit test results to the provider and/or
provider EHR system for a specific patient
Table 2: Public Health Reporting Actors and Roles
4.0
Public Health Reporting Workflow
The following diagrams and tables describe the public health reporting workflow, indicating the roles of
specific actors and whether or not an action is in scope, out of scope, or specific to a particular
implementation. The use case assumes that all information needed to complete a valid public health
report is made available to the EHR system to generate and send a report. The initiative recognizes that
the functions of generating, sending, receiving, and acknowledging a public health report are dependent
upon automated and/or manual process to incorporate relevant clinical, laboratory, and/or
administrative data within the EHR system. The functional requirements for these processes are not
within the scope of the initiative, however, the reporting workflow assumes that these functions will
become available and operational.
The first diagram, “Public Health Reporting Workflow,” illustrates the public health reporting workflow,
calling out actions that are implementation-specific, in scope, or out of scope. It includes paths to
accomodate the ‘basic flow’ – where a report is sent directly from an EHR system to a public health
agency system – and the ‘alternate flow’ – where the report is sent from and EHR system through an
intermediary system to the public health agency. It illustrates the transactions and decisions that are
required to create and send a provider-initiated report.
It is important to note that the following diagrams represent a generic flow of information and
operations based on a provider initiated report to a public health information system, with a simple
acknowledgement of receipt of the specific report. This is a result of considering a broad range of user
stories from across the spectrum of public health responsibilities. This representation of the information
flow does not represent critical components to several public health programs which rely on the
creation of case and patient records based on a care transition, those that are sourced from multiple
data sources, and / or those that require reconciliation / de-duplication of records. However, these
additional operations can and do impact the content requirements, format standards and information
11
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
exchange model. As such, when it comes to system design and implementation of a particular user
story (or set of user stories), these operations and interoperability requirements need to be accounted
for, and may affect information exchange requirements and standards for this initiative, or for
extensions of the use case built on this initiative.
12
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
13
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
Figure 1: Public Health Reporting Workflow
14
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
The second diagram, “Public Health Reporting Activity Flow,” includes the same actors and roles as the
first diagram, but is organized along swimlanes to clearly indicate the roles of each actor.
15
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
Figure 2: Public Health Reporting Workflow with Swimlanes
16
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
Additional details about the actions in the public health reporting workflow are presented in the
following table. Actions are not numbered as they are not necessarily sequential steps. Many of the
actions depicted in the workflow have implementation-specific functional requirements that are out of
the scope of the Public Health Reporting Initiative, but should be considered for an implementation.
Action
Additional Information
Healthcare Provider - Refers to the healthcare provider and/or associated staff (e.g., administrative
personnel, clinician, physician, nurses, etc.)
Note that defining the actions of the healthcare provider are out of scope for the Initiative.
Deliver care, order tests, treat
Describes the healthcare provider action at time of patient
patient, etc…
encounter. Specific action depends on provider workflow.
Enter information into patient’s
Information about the patient / patient encounter is entered
Electronic Health Record
into the specific record for that patient in the EHR system.
Suspect reportable event
The healthcare provider may suspect a reportable event based
on the patient encounter – this action is ‘optional’ and should
occur concurrently with the EHR system detection of a possible
reportable event.
Immediately sends report to public
If the EHR system (or provider, depending on specific triggers
health agency as jurisdictionally
and/or workflows) determines that public health must be
mandated.
immediately notified of the reportable event (based on
jurisdictional regulations), the healthcare provider is
responsible for transmitting the report. Note that depending
on workflow and regulations, this report may be a phone call
and/or may be an instruction to the EHR system to immediately
send the public health report. Depending on the mechanism of
transmission, the mechanism of receipt by the public health
agency may vary – for example, a health official could accept a
phone call report while a system would accept an electronic
report.
Add information, sign, and/or verify
If manual action by the healthcare provider is required, the
public health report
healthcare provider completes the required manual actions,
based on provider workflows and jurisdictional regulations, to
send the public health report.
EHR System – Refers to a healthcare provider’s Electronic Health Record System that manages electronic
health records for patients
Compiles / stores patient information Information may be manually entered into the EHR system or
(e.g., patient encounter information,
electronically provided from supporting systems. For example,
test results, transmission log)
a healthcare provider may enter patient notes into a patient’s
electronic health record. However, laboratory test results for a
patient may be transmitted to that patient’s electronic health
record from a supporting system. Defining the requirements
associated with this action are out of scope for the Initiative,
but should be considered when identifying data elements for
public health reporting.
Detect possible reportable event
Based on defined reporting criteria (dependent on jurisdictional
regulations), the EHR system (or, if applicable, the event
detection rules engine) identifies a possible reportable event
17
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
associated with a patient. Note that defining the specific
reporting criteria and business rules to identify reportable
events is out of scope of the Initiative.
Generate / assemble public health
A public health report is generated and populated based on
report
specific requirements (e.g., data elements, formats, etc.). The
actual mechanism to generate and assemble the information
(e.g., user interface) is out of scope of the Initiative, but
identifying the data elements that should be included in the
public health report is in scope.
Decision: Immediate report required? The EHR system or provider (depending on specific
implementation) determines if an immediate report to public
health is required, based on specific jurisdictional requirements.
If applicable, the EHR system notifies the healthcare provider
that an immediate report is required. Note that depending on
the implementation, an immediate report may be sent via
phone call or other method or from the EHR system at the
discretion of the healthcare provider. These actions are
accounted for in the public health reporting workflow, but out
of scope for the Initiative.
Decision: Manual action required?
The EHR system, based on provider-specific workflows,
determines if manual action to continue the public health
reporting process is required. Defining in detail these actions
and business rules are out of scope for the Initiative.
Generate / populate report for
If a manual action by the healthcare provider is required to
healthcare provider
continue the public health reporting process, the EHR system
generates/populates a report for the healthcare provider. Note
that depending on the implementation, this report may be
displayed through a user interface designed for the provider
(e.g., task list, worksheet, form, etc.). This report is not
necessarily in the same structure as the public health report,
but should be built using the same information. Defining the
mechanism to display this user interface is out of scope for the
Initiative.
Verify / validate public health report
The EHR system verifies / validates the public health report by
evaluating its compliance with the specific report requirements
and other implementation-specific business rules. Defining
these business rules is out of scope.
Decision: Verified/validated public
The EHR system determines if the public health report satisfies
health report?
the requirements or requires revisions. Note that if the report
fails the verification / validation step, it is returned to the
healthcare provider for revisions based on a workflow designed
by the provider. Defining the specific actions and business rules
associated with this step are out of scope.
Send public health report
If the public health report passes the verification / validation
step, the EHR system electronically sends the public health
report containing the appropriate information in the
appropriate format. The public health report may be sent
18
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
either directly to the public health agency or through an
intermediary system, such as an HIE. Defining the data element
and information exchange requirements associated with
sending the report are in scope for the Initiative.
Receive acknowledgement
The EHR system receives an acknowledgement that the public
health agency received the public health report. This
acknowledgement may be received directly from the public
health agency system or through an intermediary system, such
as an HIE. The acknowledgement is stored in the EHR system,
based on implementation-specific requirements. The actual
mechanism of receiving and/or storing the acknowledgement is
out of scope.
Public Health Agency System – Refers to a system at a public health agency designed to collect
information on a reportable event.
Receive public health report
The public health agency system receives the public health
report. Note that this report may come from the EHR system
directly or through an intermediary system. Additionally, the
public health agency system may receive a report directly from
a healthcare provider (via phone or other mechanism) if
jurisdictional regulations require an immediate report. Finally,
the public health agency system, as part of a separate
workflow, may receive a report from a supporting system, such
as a laboratory system, where jurisdictionally mandated.
Defining the data and structure of the public health report is in
scope for the Initiative.
Send initial acknowledgement
Once the public health agency has received a report, an
acknowledgement of receipt is sent to the sending system
(either HIE or EHR system). Note that this acknowledgement is
sent before any evaluation of the public health report is
performed by the public health agency. The acknowledgement
reflects only the fact that the public health agency received a
public health report from a sending system. The actual
mechanism of creating such an acknowledgement is out of
scope for the Initiatve.
Validate / verify report
The Public Health Agency will perform implementation-specific
procedures to verify / validate the report received from the EHR
system. Note that defining these procedures is out of scope for
the Initiative.
Decision: Valid report?
Based on public health agency business processes and
requirements, the public health agency system evaluates the
validity of the public health report. The outcome of this
decision has no impact on the sending of an initial
acknowledgement of receipt to the sending system, but may
lead to additional actions depending on the implementation.
Note that this action is out of scope for the Public Health
Reporting Initiative.
De-duplicate and merge records
Depending on public health agency business processes, any
19
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
record de-duplication and/or merging is performed. Note that
this action is out of scope for the Public Health Reporting
Initiative.
Decision: More data needed?
If a report is deemed valid by the public health agency system,
there may be an additional check to determine if more
information is needed to complete or follow-up on the report.
If more information is needed, the public health agency system
will notify the healthcare provider following implementationspecific workflows. If no additional information is needed, the
process is complete. Additionally, this decision has no impact
on the initial sending of an acknowledgement of receipt by a
public health agency system to a sending system. Note that this
action and decision are out of scope for the Public Health
Reporting Initiative.
Request information
If the Public Health Agency determines that the report is not
valid or requires more information, the Public Health Agency
system request additional information from the EHR system,
either directly or through an Intermediary System. Note that
this request is out of scope of the Initiative and depends on
implementation-specific requirements.
Send secondary acknowledgement
If the Public Health Agency determines that the report is valid
and requires no additional information, a ‘secondary
acknowledgement’ is sent to the EHR system, either directly or
through an Intermediary System. This ‘secondary
acknowledgement’ serves to notify the EHR system that report
processing from the Public Health Agency is complete and that
the report has been accepted – no further action is required
from the EHR system (or provider) at this time. Note that this
‘secondary acknowledgement’ is out of scope for the initiative
at this time, but should be considered during implementation.
Intermediary System – Refers to a system that enables the exchange of information between healthcare
providers and public health agencies (e.g., Health Information Exchange)
Receive public health report
The intermediary system receives the public health report from
the EHR system. Defining the mechanisms and involvement of
an intermediary system is out of scope for the Initiative, beyond
allowing for the use of such a system.
Send public health report
The intermediary system sends the public health report to the
public health agency system. Defining the mechanisms and
involvement of an intermediary system is out of scope for the
Initiative, beyond allowing for the use of such a system.
Receive acknowledgement
The intermediary system receives an acknowledgement back
from the public health agency system that the report was
received. Defining the mechanisms and involvement of an
intermediary system is out of scope for the Initiative, beyond
allowing for the use of such a system.
Send acknowledgement
The intermediary system, depending on implementation, may
send 2 separate acknowledgements to the EHR system:
20
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
• An acknowledgement that the report was received
from the EHR system (prior to sending to public health
agency system)
• An acknowledgement that the report was received by
the public health agency (after receiving the
acknowledgement from the public health agency)
Defining the mechanisms and involvement of an intermediary
system is out of scope for the Initiative, beyond allowing for the
use of such a system.
Supporting System – Refers to a system that provides additional information to the healthcare provider’s
EHR system about a patient. The actions of and transmissions from a supporting system are out of scope
for the Public Health Reporting Initiative; however, information from supporting systems may be
required to complete a public health report.
Conduct tests
The supporting system and/or associated staff conduct
appropriate tests as indicated by the healthcare provider.
Examples of tests include hearing screenings, laboratory tests,
etc. Note that the actions of supporting systems are out of
scope for the Public Health Reporting Initiative.
Send test results
The supporting system and/or associated staff send test results
to the healthcare provider. These test results are incorporated
into EHR system either by electronic submission or manual data
entry, depending on the provider-specific workflow. Note that
the actions of supporting systems are out of scope for the
Public Health Reporting Initiative.
Decision: Reportable event from test
Depending on jurisdictional regulations, a supporting system
site?
may send a report to a public health agency. Note that the
actions of supporting systems are out of scope for the Public
Health Reporting Initiative.
Table 3: Details about Actions in the Public Health Reporting Workflow
5.0
Functional Requirements
5.1
Information Interchange Requirements
Initiating
System
(describes
action)
(describes
action)
Receiving System
Send
Information
Interchange
Requirement Name
Public Health Report*
Electronic
Health Record
System
Public Health
Agency System
Alternate flow:
Electronic
Health Record
System
Receive
Public Health Agency System
Send
Acknowledgement
Receive
Send
Public Health Report
Receive
Electronic Health Record
System
Intermediary System
21
Alternate flow:
Intermediary
System
Alternate flow:
Public Health
Agency System
Alternate flow:
Intermediary
System
Send
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
Public Health Report
Receive
Public Health Agency System
Send
Acknowledgement
Receive
Electronic Health Record
System
Send
Acknowledgement
Receive
Electronic Health Record
System
Table 4: Information Interchange Requirements
5.2
System Requirements
System requirements provided in the table below refer to the base (direct transmission) and alternate
(transmission through intermediary system) flow requirements and reflect functions needed to support
various scenarios described in the use case. Note that reporting scenarios may or may not include fully
automated functions – for example, integration with a Clinical Decision Support system for managing
reporting criteria and/or triggers. However, the table includes information for both automated and
manual functions that are needed to support the use case.
System
Electronic Health Record System
Electronic Health Record System
Electronic Health Record System
Electronic Health Record System
Electronic Health Record System
Healthcare provider interface
EHR / Healthcare provider interface
EHR reporting module
Public health agency system
System Requirement
Interface with appropriate clinical, administrative,
laboratory, pharmacy or other systems to receive and
store relevant patient information needed to
generate compliant public health reports
Interface with a clinical decision support system to
receive, store and process public health reporting
criteria and/or triggers
Provide a user interface to support manual entry or
updates to public health reporting criteria or triggers
by healthcare providers or other staff.
Extract data (if outside the EHR system) and render
information needed to create a public health report
based on the appropriate jurisdictional reporting
criteria
Render a public health report for subsequent
validation, completion, verification and certification
Renders a report form for completion, verification,
and certification when necessary
Generates Public Health Report
Sends public health report to public health agency
receiving system; archives copy of report and data
exchange transmission; receive and archive Public
Health Agency system acknowedgements
Receives EHR public health report; generate and send
report receipt acknowledgements
Table 5: Public Health Reporting General System Requirements
22
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
5.3
Triggers
A public health event (such as a new diagnosis of tuberculosis) requiring a public health report is
typically defined by criteria established by local, state or federal statutes, regulations or guidelines.
These criteria may be unique to a specific public health agency or surveillance program, and are
essentially defined by the business requirements of public health surveillance and intervention. Some
reportable events may not even involve a diagnosis, for example, childhood blood lead tests or newborn
hearing examinations may be reportable whether or not they are abnormal. Report creation is
dependent upon healthcare provider discovery or identification of a possible public health event of
interest and comparison of that potential event with criteria. Today in most cases, this a manual
process. Event discovery or detection is a result of data from direct patient care encounters or
assessments of other health information, such as results from laboratory test or diagnostic procedures.
However, depending upon the reporting criteria, IT automation can be applied to the event detection or
discovery process such that direct healthcare provider interaction or intervention is reduced or not
required to initiate the reporting process. For example, a single laboratory test result, a single diagnosis
code, or a combination of demographic and diagnostic elements may algorithmically trigger recognition
of a reportable event by an EHR or by a supporting application.
In the context of this use case, the term “trigger” is used to convey automation of one or more event
discovery or detection parameters based upon jurisdictionally defined reporting criteria. Automated
detection and initiation of the reporting process can be programmatically defined in a computer system
(EHR) or supporting application (such as an EHR services platform, or ESP). The initiation of the
reporting process can be triggered by the presence of information contained in the EHR that meets the
jurisdictionally defined reporting criteria that is used to determine if a report should be sent to a public
health agency. Automated triggers are created or programmed using the reporting criteria and can be
based upon several factors that include but are not limited to:
•
•
•
•
Mandated reporting criteria specified by jurisdictional (e.g., federal, state, local or territorial)
legislation, statute or regulation.
Surveillance criteria for voluntary reporting specified by an organization (e.g., public health
agency, healthcare provider, quality improvement organization, registry, etc.)
Criteria may include observations or assessments made by healthcare providers or other staff,
whether or not they are documented within the EHR. For example, the suspicion of certain
diseases alone may constitute a reportable condition, whether or not it is written as a diagnosis
in the EHR.
The presence of specific data or documentation, or a combination of items, within an EHR that
meets the reporting criteria.
As EHR public health reporting functions are designed and piloted, implementers will have to consider
these factors, as well as the clinical workflow, clinical / administrative policies, and report validation /
certification processes. Some implementations may depend upon manual processes to initiate and
execute public health reporting, while others may be partially or fully automated based on the functions
23
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
available within a specific EHR product or supporting application like a public health trigger recognition
system (e.g., ESP at Harvard) or a clinical decision support system.
6.0
Non-Functional Requirements
Non-functional Requirements are those requirements that reflect required operational needs, rather
than functional information flow operations. Non-functional requirements are generally
implementation-specific and may vary based on healthcare provider workflow, report type, etc.
These requirements include, but are not limited to, the following:
Type
Quality
Constraints
Workflow
Timeliness
Transmission Mode
Consent policies
Description
Requirements for quality, reliability, performance,
usability, supportability, and/or implementation.
Requirements related to security, accessibility,
jurisdictional reporting requirements and
operations, operations, interfaces, and other legal
constraints.
Requirements related to implementation-specific
workflows (e.g., how a healthcare provider adds
information to or signs a public health report
generated by the EHR system)
Requirements related to the timeliness of
reporting
Requirements related to the batching of reports
vs. the submission of a single report
Most types of public health reports are mandated
without patient consent (e.g., the report of a
communicable disease). Others may depend on
consent, often depending on jurisdictional laws
(for example, some immunization registries or
developmental disability registries only collect
information with consent). Especially when
intermediary systems are involved, consent
policies need to correspond to public health legal
requirements. For example, an HIE that only
exchanges information by consent would not be
suitable for most public health reporting.
Table 6: Types of Non-Functional Requirements
Non-functional requirements may vary based upon the specific public health agency or program’s
policies. For example, timeframe for reporting, (e.g., within 24 hours of event discovery), may have
operational implications for human and system actors supporting the specific reporting scenarios
expected that pilot implementations will provide a greater level of detail concerning the non functional
requirements relevant to their EHR systems, which includes internal IT infrastructure considerations and
24
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
any manual business processes that are needed to facilitate or augment report generation, validation,
completion, verification, certification and transmission.
7.0
Dependencies and Future Considerations
7.1
Dependencies
As a secondary user of clinical information, public health programs rely on the security, accessibility,
reliability, consistency, and quality of information from providers and other information sources that are
not under direct management or regulation of public health agencies. As such, there are several
business processes, policy and technical dependencies that must be understood by report senders and
receivers to both enable specific public health reporting exchanges, and to help promote the long term
sustainability of nationwide public health information exchanges.
These dependencies include, but are not limited to, the following:
Type
Certification
Value Set maintenance and provisioning
Health Information Standards Bodies and
Processes
Healthcare Provider and Public Health Agency
Processes, Procedures, and Tools
Description
As the functional and data requirements for
certified electronic health record systems and
modules evolve, there may be downsteam impacts
and opportunities for public health agencies,
including the availability of specific data elements
that enable and are required for reporting
purposes.
Agreed upon vocabulary value sets associated with
public health reporting data elements must be
maintained. These value sets are critical for EHR /
clinical setting data sources, intermediaries (e.g
health information exchanges), and public health
agency receivers for data validation and
translation. Nationwide and local governance and
technical infrastructure are necessary to enable
implementation, adoption, and sustainability.
Public health reporting will rely on standardized
information exchange format and content
standards. These base standards rely on balloting
and consensus processes to promote industry
acceptance and adoption. Current and future
public health reporting specifications may be
dependent on these bodies and their associated
consensus building, maintenance, and distribution
processes.
In order to realize the full potential of the PHRI
specification, it is recognized that short and long
term commitments from vendors is needed. This
involves providing software tools and/or other
25
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
services that can be used to augment or replace
existing processes used to create and send public
health reports. This also implies reciprocal
commitments from healthcare providers and
public health agencies to adopt and use the PHRI
specification. To facilitate this, there is a specific
need to evaluate impacts to augment current
infrastructure and processes to interoperate (or
map) with/to the PHRI specification
Table 7: Types of Dependencies
7.2
Additional Components and Considerations
Public health reporting relies on a number of operations that are outside the scope of the functional
requirements and information exchange descriptions captured in this document. Capturing additional
components of the overall public health business process and system flows will be important both in the
specific design and exchange serving a specific public health program / jurisdiction. This includes the
sustainability / extensibilty of public health reporting requirements as the public health programs,
policies, systems and infrastructure change over time. These important components and considerations
include, but are not limited to:
Type
Reporting criteria
Reportable event filters and templates
Description
Provider-initiated public health reports rely on
specific criteria associated with jurisdictional /
program policies, public health case definitions,
data availability, provider expertise, and other
factors. These report criteria may change over
time or between jurisdictions, and the technical
systems will require a means to understand which
criteria apply and when criteria change (e.g. when
a new reportable event is added, which
sometimes occurs emergently during an outbreak).
Both public health agencies and healthcare
providers need to consider how information about
criteria are made available, updated and how
notification of change is accomplished. When
automated report triggering is used, how might
systems operating such algorithms receive and
implement different criteria across jurisdictions or
over time? A public health reportable condition
knowledge base may help facilitate up-to-date
access.
As information exchange specifications for each
public health report are developed and
maintained, reporting templates and filters may be
made available to system senders and receivers, to
facilitate and accelerate reporting. A public health
reportable event knowledge base may help
26
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
promote their availability to affected stakeholders.
Security / Trust
Reporting to a public health agency will require a
level of trust between the agency and the
reporting party. As security, accessibility, and
privacy policies and infrastructure are developed,
it will be important that public health reporting
specifications account for these needs. An
important component of this trust is accounting
for program jurisdiction in both the data content
and associated data use accessibility requirements,
including requirements for authentication,
authorization, non-repudiation, and attestation of
the report (via electronic signature or other
mechanism).
Validation / data management processes
There are multiple types of validation processes
involved in a public health reporting process,
including message / report format conformance,
data / content verification, error handling, and
case de-duplication and record merging. The
requirements for these processes vary between
the policies, capacities, and needs of particular
programs and jurisdictions. Implementations of
specific public health reporting exchanges in
specific jurisdictions should follow the guidance,
recommendations, and best practices advocated
by various stakeholders, which may include
professional associations, patient advocacy
groups, and/or sponsoring federal, state, and local
agency programs.
Table 8: Additional Considerations
8.0
Dataset Requirements
The PHRI will identify the data elements along with associated value sets and related guidelines that
have been provided by each domain and/or across domains.3 This task will result in a PHRI Data
Harmonization Profile that will help promote normalized field definitions, vocabulary bindings, and
content requirements to facilitate the analysis of base content exchange (e.g. HL7 2.x, HL7 Clinical
Document Architecture and terminology standards and future standards development harmonization
tasks). This document is available on the Public Health Reporting Initiative wiki, here:
http://wiki.siframework.org/PHRI+-+Data+%26Terminology+Harmonization+Sub-Workgroup.
As described in the Data Harmonization Profile, the data elements for public health reporting can be
broken down into 3 classifications:
3
Note that the data elements and Data Harmonization Profile have not yet been completed or consensus
approved. Once completed, a separate consensus process will determine acceptance and this footnote will be
deleted.
27
Functional Requirements Description
Public Health Reporting Initiative
Consensus Approved
• Core Common Data Elements – harmonized data elements that are widely shared across several
report types. Expect EHR systems to be able to produce these data elements but public health
systems may choose to receive these elements at their discretion. Identifying and harmonizing
core common data elements are the primary focus of the Data Harmonization Profile.
• Report Type Specific Data Elements – harmonized data elements (although variance is allowed
where necessary) that are broadly required across public health for a specific report type (e.g., a
communicable disease case report, a birth record report, etc.). Special effort is taken to
harmonize elements between different report types, but this is a secondary effort of the PHRI at
this time. Where possible, report type data elements are detailed and harmonized, but future
companion documents and phases of the Public Health Reporting Initiative may be required to
cover data elements for various types of reports.
• Implementation Specific Data Elements – additional, relatively unique, or non-harmonized data
elements required by a particular jurisdiction or public health program (e.g., a TB report in
California). Defining these elements is out of scope for the Data Harmonization Profile and the
Public Health Reporting Initiative at this time.
Specific public health reporting scenarios, either ‘report type-specific’ or ‘implementation-specific’, will
provide their own requirements for optionality but can take advantage of harmonized value sets and
terminology.
9.0
Standards Analysis
In the standards analysis phase, the PHRI will analyze the data harmonization profile, as well as review
relevant existing implementation guides, against the requirements described in the functional
requirements documents. This will help the initiative determine the best data exchange specification
and selection of appropriate data elements, terminologies and value sets. It is possible that different
public health reporting user stories and report types will require different specifications as a result of
this analysis. Our approach will identify a uniform set of “common core data elements” valid for many
different types of public health reports, and “extension data elements” that include unique needs for a
particular type of public health report. This information can be used by EHR and other software
vendors and public health agency system support teams to determine gaps and opportunities for
enhancing existing products, tools, services and infrastructure to support testing and adoption of the
PHRI specifications.
28