Clinical Decision Support Strategies for Electronic Case Reporting and its Open Source Connection

Noam H. Arzt, Ph.D.A key element of public health surveillance is the reporting of infectious and certain non-infectious conditions to state, local, and tribal public health agencies (PHA) around the United States. Historically, there have been a number of key challenges with the process of case reporting that is pervasive in the United States today. To help overcome some of these barriers, an effort has been underway to move the process of case reporting to electronic. A key component of the emerging electronic care reporting (eCR) strategy is the use of clinical decision support (CDS) to help clinical care organizations determine if a reportable condition is present in a patient's record. Multiple approaches have been identified for this CDS service, including a centralized model being implemented today, and several distributed options which will likely become equally viable. Given the size, diversity, and decentralized nature of healthcare enterprises, it is likely that all three approaches for CDS discussed in this article will be deployed simultaneously.

Introduction

A key element of public health surveillance is the reporting of infectious and certain non-infectious conditions to state, local, territorial, and tribal public health agencies (PHA) around the United States. The purpose of this reporting is to allow these PHAs to monitor, control, and prevent the occurrence and spread of diseases and conditions within the population. The Centers for Disease Control and Prevention (CDC) provides leadership and funding to assist states in collecting this information, and request notification of the occurrence of a national set of conditions to CDC.

Once a case is established and the patient is treated by the clinician, if indicated, additional steps may need to be taken by public health in conjunction with the clinician and the broader medical community. PHAs have established protocols for different conditions, which may involve contact tracing from the patient to determine if other individuals are affected by an infectious or environmental cause; prophylaxis such as targeted (or even mass) immunizations or medication administration (e.g., antibiotics) to a subset of the population in an area; and education to ensure that affected or potentially-affected patients are informed about the risks of any exposure or of the impact of subsequent behavior. Case reporting is the event that sets these interventions in motion.

Today, most case reporting is done manually. That is, when a clinician suspects that a reportable condition exists or may exist, a paper form provided by the PHA is completed and typically Faxed to the PHA for review. Often, forms are incomplete (or even illegible) and may require follow-up by the PHA to complete or understand. Data from these forms may be manually entered into one or more information systems at the PHA for case determination and follow-up or statistical tracking and analysis. Jurisdictional law or regulation determines who must do this reporting, how quickly after a patient encounter it must be reported, and for what diseases and conditions a report must be submitted. There are over 200 conditions reportable to various jurisdictions in the United States, with differing criteria and requirements among jurisdictions even for the reporting of the same diseases or conditions.

In addition to case reporting, a second parallel process is implemented in many jurisdictions: electronic laboratory reporting (ELR). Many jurisdictions require clinicians and/or laboratories to submit a variety of electronic test result records (and may include laboratory orders) to their PHA as part of the surveillance process. Jurisdictional law or regulation determines who must do this reporting, how quickly after a lab order or specimen processing it needs to be done, and for what diseases and conditions a lab report must be submitted.

Historically, there have been several key challenges with the process of case reporting that is pervasive in the United States today:

• Since case reporting is largely a manual process, the quality, timeliness, and completeness of case reports is widely variable.
• Each jurisdiction may have slightly different laws about which conditions require a case report and how quickly the reports need to be submitted.
• Some jurisdictions require a case report based on where the care was given; some require a case report based on where the patient lives, and some require both. It may be difficult for clinicians to understand when (and to whom) they need to report, especially when travel and mobility today may result in the patient living in one jurisdiction and receiving care in a different jurisdiction.
• The clinical guidelines surrounding how one determines that a reportable condition exists can be complicated and often vary between jurisdictions.
• Some jurisdictions have trouble matching case report data with ELR data, as demographic information contained in electronic laboratory reports is often incomplete and inaccurate, as is information found in paper case reports.
• In some cases, a report is required when a condition is suspected, not necessarily confirmed, and this represents a key note of urgency that is not always adequately met by current reporting.

Approach

To help overcome some of these barriers, the CDC in conjunction with the Council of State and Territorial Epidemiologists (CSTE), a number of interested PHAs, and a variety of vendor organizations, have been spearheading an effort to move the process of case reporting to electronic instead of manual. As electronic health record (EHR) use becomes more pervasive, and the quality and completeness of its data improves, electronic case reports can replace the manual, paper case reports currently in use. According to the CDC,

Electronic case reporting (eCR) is the automated identification and transmission of reportable health events from the electronic health record (EHR) to state and local public health departments. Because eCR uses a consensus set of trigger events and a standardized format, EHR vendors can incorporate automated case reporting into the medical record systems consistently across the nation, minimizing development time and simplifying disease reporting for providers. Because the EHR is the data source for case reports, eCR will improve the completeness of patient contact, clinical, and epidemiologic information to jump start case investigations.

Two related efforts are in progress to help further the effort of electronic case reporting:

1) Reportable Conditions Knowledge Management System (RCKMS): The CDC, through the Council of State and Territorial Epidemiologists (CSTE), has funded a project to develop an Authoring Tool tailored to eCR that allows jurisdictions to author rules that determine whether a patient's encounter is reportable for certain conditions. In addition, the RCKMS software includes a Decision Support Service (DSS) to which the authored rules are deployed. The DSS runs the deployed rules against a patient record and determines if the patient's encounter is reportable for which condition(s) and to which jurisdiction(s). Work on RCKMS began in late 2014.

2) Digital Bridge Initiative: A foundation-funded coordinating effort, the Digital Bridge Initiative has been working to provide structure and governance around a national planning and implementation effort. Launched in 2016 and funded by the Robert Wood Johnson and de Beaumont Foundations, Digital Bridge provides oversight and governance to the national eCR implementation.

The workflow for eCR is displayed in the following diagram (care of Digital Bridge):

Figure 1 – Electronic Case Reporting Workflow

This workflow covers the activities of healthcare providers, central decision support services, and public health agencies in the identification of a suspected reportable condition, to determine whether (and how) a condition is actually reportable, to the submission of the initial report. In addition, this workflow includes the ongoing management of reporting criteria by public health agencies and the maintenance of those criteria in the decision support service.

Clinical Decision Support (CDS)

A key component of the emerging eCR strategy in the United States is the use of RCKMS, which provides clinical decision support (CDS) for eCR and is shown in the center of Figure 1. An electronic health record (EHR) system submits clinical data for an individual patient to RCKMS via a standards-based transaction. The clinical data is submitted as an Electronic Initial Case Report (eICR), which is a balloted Health Level Seven (HL7) implementation guide that follows the Consolidated Clinical Document Architecture (C-CDA) standard developed and balloted within HL7.

RCKMS answers several key questions:

• Does the clinical data represent an event reportable to one or more public health agencies?
• If so, which condition(s) is reportable?
• To which public health authority(ies) is the condition(s) reportable?

The response is returned to the EHR system as a standards-based message called the Reportability Response (RR), also balloted through HL7. This response is then displayed to the reporter, incorporated into the EHR, and/or used to provide information about other actions for the clinician to follow-up based on the content of the response. For positive responses, the Reportability Response document is also sent to the identified public health agency (PHA).

The clinical knowledge and rules used by RCKMS are referred to as reporting specifications. Reporting specifications are rules that describe the criteria that when met, a person is considered reportable to a PHA for a particular condition. The reporting specifications are derived from position statements developed nationally by epidemiologists coordinated by the Council of State and Territorial Epidemiologists (CSTE). According to CSTE, "Position statements allow CSTE members to standardize surveillance case definitions, maintain the Nationally Notifiable Condition List, and address policy issues that could affect state or local law, rules or regulations." The CSTE Position Statement Archive contains a searchable site of approved positions statement, both current and past.

Through the RCKMS project, CSTE works to refine the logic in its position statement text and codify this logic in a structured and standardized display within spreadsheets. Rules are then derived from the spreadsheets and necessary value sets are identified to support them. Finally, the rules are entered into the RCKMS Authoring Tool for each condition. Within the Authoring Tool, a user can deploy the reporting specifications to the rules engine, whereupon the rules are converted into executable rules using the Drools Business Rules Management Systems as an executable representation of the rules for use by RCKMS. More details on Drools can be found here.

Because each jurisdiction's rules may vary, the rules are entered and implemented through the RCKMS Authoring Tool. The Authoring Tool has been developed to manage the complex rules required for eCR, as well as the workflow to manage the rules in a distributed fashion by state and local public health agencies. The Authoring Tool supports multiple levels of authoring and authorization required to manage the review and approval of rules.

A jurisdiction begins with a set of default national rules ("out of the box") for the supported conditions. They can either accept the default rules as their own or modify the rules to meet their own requirements. This is done through the Reporting Specifications Module within RCKMS. The module provides a user-friendly interface that allows jurisdictions to view the criteria details and adjust the reporting specifications for their own needs, without requiring any knowledge of the underlying Drools rules language used to execute the rules.

The value sets used by the rules are pulled from the National Library of Medicine's (NLM) Value Set Authority Center (VSAC). The value sets are developed and maintained by the RCKMS Team in conjunction with the rules and criteria. Currently, CDS knowledge artifacts have been authored for 74 nationally notifiable reportable conditions. The initial Digital Bridge pilot implementations of eCR, two of which went into production in Fall 2018, used an initial five reportable conditions (a sixth was added shortly thereafter).

RCKMS is currently being deployed as a single, central, national service on the AIMS (APHL Informatics Messaging Service) platform, which is operated and maintained by the Association of Public Health Laboratories (APHL). The AIMS platform connects directly with reporters and provides a routing and validation service for incoming and outgoing messages.

Figure 2 - Electronic Case Reporting Information Flow

The provider submits patient data related to a suspected event as an HL7 Electronic Initial Case Report (eICR), a document template for creating an HL7 Version 3 Clinical Document Architecture (CDA) document, to the AIMS platform via one of several supported data transport mechanisms. After pre-processing, the eICR is converted into an HL7 Virtual Medical Record (vMR) file for submission to the RCKMS Clinical Decision Support web service. The RCKMS rules themselves are deployed as Drools executable rules to the rules engine, OpenCDS, a general-purpose open source CDS engine, where they are executed. RCKMS returns decision support data to AIMS which constructs an HL7 Reportability Response (RR) for transmission back to the provider and to the PHA.

The eCR approach meets the "5 Rights" framework of delivering CDS, namely:

Development and Maintenance of CDS Rules

In order to develop and maintain the rules for the Reporting Specifications, for over five years the project has been developing and improving the RCKMS Authoring Tool. The Authoring Tool has been built upon a pre-existing, open source CDS Authoring Tool (CAT) framework, a software foundation that is used across other projects and other domains. RCKMS has two main purposes: First, it allows users to use a default set of pre-written rules and value sets for their reporting specifications consistent with the national guidance (CSTE Position Statements), and to modify those rules for a particular jurisdiction. The jurisdiction can control how and when new rules are deployed to the RCKMS Decision Support Service. The Authoring Tool's user interface is specifically designed to support the concepts necessary for the implementation of the reporting specifications in a structured presentation that public health officials expect to see and can easily use. For example, the screen depicted in Figure 3 from the Authoring Tool shows the criteria, logic sets, reporting timeframe, and reporting rules that have been defined for a particular condition in a jurisdiction:

Figure 3 – CDS Authoring Tool Reporting Specification Screen

Second, the tool allows jurisdictions to manage a multi-layer workflow that may be required for the distributed authoring and approval of rules before they are deployed in the RCKMS Decision Support Service. It also supports versioning of rules to assist in the orderly testing and migration from one version of the reporting specification to another.

The Authoring Tool has three core modules:

After reporting specifications are authored, at the push of a button jurisdictions can deploy the rules to the RCKMS OpenCDS-based CDS Service.

Multiple Approaches for CDS

The EHR interacts with the central CDS service and benefits from its recommendations. There are distinct advantages to using a central CDS service at this time. First, most EHRs have not yet invested sufficiently in the development of local CDS services sufficient for eCR functionality. Second, RCKMS is being deployed on a scalable infrastructure that allows for efficient operation of the CDS service without replication. Third, the reporting specifications are maintained in a central, authoritative location and executed from that location to ensure consistent CDS decisions are made appropriate to each jurisdiction and across jurisdictions.

Despite the benefits of a centralized CDS model for eCR, there are some distinct disadvantages that come to light, especially as EHRs and interoperability standards mature and become more established. Decentralized models of CDS for eCR have been contemplated to overcome some of these disadvantages and leverage local CDS capabilities as they become available over the next several years:

1. End-to-end performance on a central CDS service may be less than optimal as it is dependent on network performance between the EHR and the central service (in both directions). Network reliability can be compromised at every step along the way - the local network, the Internet, and the network where the central CDS service is deployed. Potential network latency can be introduced which may not block a transaction, but may slow it sufficiently as to cause a transmission failure.
2. Some clinical organizations may not choose to have something as crucial as a CDS service operated by a third party outside of their infrastructure, security, and control.
3. Legal issues may also develop: while the submission of a case report is usually mandated by law and covered by the public health exclusion in HIPAA, the submission of clinical data for a suspected case that turns out to be negative may not be covered under jurisdictional law or HIPAA public health exclusions. The current national deployment of RCKMS mitigates this concern by establishing a business associate (BA) relationship between APHL, the central RCKMS deployment vendor, and participating provider organizations. But as hundreds, thousands, and even tens of thousands of potential provider organizations participating in this project is contemplated, the BA strategy may become difficult to manage.

Two distributed CDS scenarios for decentralized eCR models have been identified.

In the first scenario, the Decision Support Service component of the RCKMS software is installed within a clinical organization and executed locally. Ostensibly, the clinical organization can control its local network environment and ensure high-quality operations and performance. This option will likely bring some associated costs as it will require the proper training to install and operate the RCKMS Decision Support Service on an ongoing basis (note that RCKMS is an open source product released under the LGPL v3 license so no license fee is required). Also, there must be a mechanism to distribute updates to the reporting specifications and supporting artifacts, such as value sets for local implementation. This model is not currently supported by the Digital Bridge project or the RCKMS project, but can be implemented with additional software augmentation by RCKMS.

The second distributed CDS scenario for eCR involves the distribution of the reporting specification rules without the software. In this scenario, local EHR implementations would consume the reporting specifications and utilize them in a CDS capability within their EHR. This scenario builds upon emerging EHR capabilities and reduces the dependence on centrally-deployed (or even centrally-provided) RCKMS software. The most complete version of this distributed set of reporting specifications might be a set of HL7 FHIR (Fast Healthcare Interoperability Resources) resources, which would include the reporting specifications and associated value sets packaged for incorporation by a local EHR CDS system. FHIR is HL7's next-generation standard for health data interoperability. It is often used in conjunction with SMART, an open technology platform that allows applications to be created by third parties and run within an EHR. Use of standard methods to represent the reporting specification is critical to ensure that clinical content can be leveraged by EHR implementations.

It cannot be stressed enough that in all scenarios - centralized and distributed - there must be a centralized and uniform authoring of the reporting specifications and value sets. Since the specifications themselves originate from public health through a centralized process, it must be administered nationally through a well-established process. It is also essential that all sites have all the rules available to them, since there may be multiple jurisdictions whose rules and reporting is required, since the determination of jurisdiction(s) is based on where a patient lives and where they receive care.

Enabling Distributed Models

This second scenario for distributed models represents the most forward-thinking, standards-based alternative for making this clinical knowledge widely available as EHR CDS capabilities improve. To enable a distributed CDS option for eCR, the following additional capabilities need to be supported by the tools:

• The reporting specification logic for eCR should be developed in Health Level 7 (HL7) Clinical Quality Language (CQL) format since this is the emerging standard for expressing CDS logic in a platform and system independent way. CQL is being positioned as a technology-agnostic way for representing clinical logic and rules in Decision Support Services, and the Clinical Reasoning Standards (or its successor) to represent the actions that are to be taken based on the clinical evaluation. Implementing CQL will have the best chance for distribution of electronic case reporting logic to EHRs and other clinical systems. The rules in RCKMS are currently represented in Drools.
• If CQL is adopted more broadly in the healthcare community, the Authoring Tool used to manage the clinical content will be modified to support it.
• A set of FHIR resources that include the CQL-based Reporting Specification logic, clinical reasoning actions that result from that logic, and associated value sets will need to be developed.
• CQL-based reporting specification logic and the new FHIR- and CQL-based artifacts should be deployed into an accessible repository where it can be easily maintained and downloaded by potential sites and vendors for use. The Agency for Health Research Quality (AHRQ) CDS Connect repository is one such national site for distribution to EHR vendors and clinical sites.
• The Authoring Tool should be modified to automatically publish revised versions of the CDS artifacts to the CDS Connect repository for distribution to EHR vendors and clinical sites.
• The project should continue to generate and distribute rules for new conditions as they are prioritized by CDC and CSTE and customized by jurisdictions around the country.

These features should enable EHR vendors and clinical sites to incorporate the CDS artifacts in their local systems without dependence on a centrally-hosted version of the RCKMS Decision Support Service.

Conclusion

Electronic case reporting is still in its infancy in the United States. Given the size, diversity and decentralized nature of the healthcare enterprise, it is likely that all three scenarios for CDS discussed in this article will be deployed simultaneously for some time to come. Less robust clinical organizations may rely on a centralized service even with possible network limitations. More capable organizations may begin to deploy "cloned" services using the RCKMS software in environments they control with fewer networking challenges. Over time, these organizations may develop or acquire CDS services of their own that can absorb clinical knowledge and rules articulated in standards-based CQL and use those rules within the software. It is imperative that all three of these strategies be funded and supported to allow the broadest possible deployment of eCR over the next few years. All three strategies rely on a common base of clinical knowledge that can be managed consistently for maximum leverage and reuse.

The eCR initiative uses a number of existing and emerging Health Level 7 (HL7) standards. The project may choose to use CQL format to represent the CDS logic. In addition, the project can facilitate and enable the implementation of this CDS functionality within EHRs by expressing the clinical logic and associated value sets as a set of FHIR resources that can be more easily deployed within a local environment. The structure and capabilities of the Authoring Tool make it very amenable to modification for export of the CDS logic into CQL, and the export of clinical reasoning actions and associated value sets into FHIR resources. Clinical sites that wish to display more immediate results to clinicians will be able to use tools such as CDS Hooks (an enabling technology for clinical decision support using FHIR) and SMART to create user-facing applications and alerts with case reporting determinations and instructions.

HLN Consulting, LLC 4/30/2019

[1] https://www.cste.org/page/PSLanding

[2] Campbell, Robert James. "The Five Rights of Clinical Decision Support: CDS Tools Helpful for Meeting Meaningful Use" Journal of AHIMA 84, no.10 (October 2013): 42-47 (web version updated February 2016).