Public Health Reporting Initiative Functional Requirements Description

Transcription

1 Public Health Reporting Initiative Functional Requirements Description 9/25/2012 1

2 Table of Contents 1.0 Preface and Introduction Initiative Overview Initiative Challenge Statement Use Case Scope Background In Scope Out of Scope Communities of Interest Actors and Roles Public Health Reporting Workflow Functional Requirements Information Interchange Requirements System Requirements Triggers Non-Functional Requirements Dependencies and Future Considerations Dependencies Additional Components and Considerations Dataset Requirements Standards Analysis List of Figures: Figure 1: Public Health Reporting Workflow Figure 2: Public Health Reporting Workflow with Swimlanes List of Tables: Table 1: Public Health Reporting Communities of Interest Table 2: Public Health Reporting Actors and Roles Table 3: Details about Actions in the Public Health Reporting Workflow Table 4: Information Interchange Requirements Table 5: Public Health Reporting General System Requirements Table 6: Types of Non-Functional Requirements Table 7: Types of Dependencies Table 8: Additional Considerations 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

3 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 (PHRI) is a community-led S&I Framework initiative focused on harmonizing information exchange standards and creating implementation specifications for public health 1 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 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

4 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, ed 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

5 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 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 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

6 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 Use 2. 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 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

7 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

8 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 Description Healthcare Provider 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. Public Health Agency 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

9 Member of Communities of Interest Electronic Health Record (EHR)/ Electronic Medical Record (EMR)/ Personal Health Record (PHR) Vendors and Suppliers Public Health Information System Vendors/Suppliers Functional Requirements Description Description 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. Vendors or suppliers of Public Health Information Systems - 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 Intermediary Systems Patient Safety Organization Quality improvement/measurement organizations Accountable Care Organization (ACO) Laboratory 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). 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. A group, institution or association that improves medical care by reducing medical errors A group of doctors and healthcare experts that evaluate and 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. 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 The laboratory performs laboratory analyses and produces lab test results (typically as the filler of a lab order by a licensed health professional). 9

10 Member of Communities of Interest Laboratory Information System (LIS) or Laboratory Information Management System (LIMS), Vendors/Suppliers Functional Requirements Description 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: 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 Role Healthcare Provider 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 EHR System (healthcare provider system) 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 Public Health Agency System 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

11 Actor Intermediary Systems, including Incident Reporting Systems, Health Information Exchange Systems, Health Information Networks, etc. Supporting System (e.g., Testing Facility System, Laboratory System) Functional Requirements Description Role 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 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. If applicable: 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

12 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

13 13

14 Figure 1: Public Health Reporting Workflow 14

15 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

16 Figure 2: Public Health Reporting Workflow with Swimlanes 16

17 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, 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 (e.g., patient encounter information, test results, transmission log) Detect possible reportable event Information may be manually entered into the EHR system or electronically provided from supporting systems. For example, 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. 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

18 Generate / assemble public health report Functional Requirements Description 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. A public health report is generated and populated based on 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? Generate / populate report for healthcare provider 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. If a manual action by the healthcare provider is required to 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 health report? Send public health report The EHR system determines if the public health report satisfies 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. 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

19 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 Send initial acknowledgement Validate / verify report Decision: Valid report? De-duplicate and merge records 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. 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. 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. 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. Depending on public health agency business processes, any 19

20 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 Send public health report Receive acknowledgement Send acknowledgement 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. 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. 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. The intermediary system, depending on implementation, may send 2 separate acknowledgements to the EHR system: 20

21 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 ; however, information from supporting systems may be required to complete a public health report. Conduct tests Send test results Decision: Reportable event from test site? 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. 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. Depending on jurisdictional regulations, a supporting system 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 Electronic Health Record System Public Health Agency System Alternate flow: Electronic Health Record System (describes action) Information Interchange Requirement Name (describes action) Receiving System Send Public Health Report* Receive Public Health Agency System Send Acknowledgement Receive Electronic Health Record System Send Public Health Report Receive Intermediary System 21

22 Alternate flow: Intermediary System Alternate flow: Public Health Agency System Alternate flow: Intermediary System Functional Requirements Description Send 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 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 Public health agency system Receives EHR public health report; generate and send report receipt acknowledgements Table 5: Public Health Reporting General System Requirements 22

23 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

24 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: Quality Constraints Workflow Timeliness Transmission Mode Consent policies Type 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