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