EHR Implementers

EHR Implementers - EHR Triggering

Triggering of eICRs

Triggering is the set of actions in an electronic health record (EHR) that initiates the creation of an electronic initial case report (eICR) and leads to its transmission (directly or indirectly) to the Association of Public Health Laboratories (APHL) Informatics Messaging Services (AIMS) platform. When certain data in the EHR are recorded or updated, they are checked against a series of codes that have been distributed to the EHR. If there are matches, there is one (or more) reportable condition that need to be processed for confirmation. If the timing parameters for reporting have been met, then the eICR should be “triggered” and transmitted to the AIMS platform. This should all be done automatically, behind the scenes, and without disrupting healthcare providers’ workflows.

Triggering is based on reporting parameters and trigger code value sets in XML or JSON format that are distributed through the Electronic Reporting and Surveillance Distribution (eRSD) system. The eRSD contains these value sets, (also sometimes referred to as the included Reportable Conditions Trigger Codes (RCTC)). The trigger codes in the eRSD are developed by the Council of State and Territorial Epidemiologists (CSTE), Centers for Disease Control and Prevention (CDC), and APHL. EHR implementers can register and “subscribe” to the eRSD service at no cost to receive notification of routine and emergent updates. Each update will include an effective start date, which is the date the set of codes should be implemented and in use by reporters. For routine scheduled releases, this will typically be four to six months from the release date (see schedule below). Emergent eRSD releases should be implemented as soon as possible to meet pressing public health emergency needs.

eRSD - Electronic Reporting and Surveillance Distribution (external link) includes:

• Trigger code value sets
• Triggering timing parameters
• Other metadata about the triggering process

To access the eRSD, follow these steps:

• If you have not registered, click the registration link (external link) and follow the instructions.
• Once you have established an account, you will receive notifications of routine and emergent updates. You will also be able to download the eRSD.

eRSD specifications and standards

Although the eRSD is in Health Level Seven International (HL7) Fast Healthcare Interoperability Resources (FHIR®) format, the eRSD’s XML or JSON distribution can be used by EHRs that have not yet implemented FHIR.

The latest version of the HL7 FHIR eCR standards, FHIR eCR 2.1 (HL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR) - US Realm 2.1.2 - STU 2.1.2 US), includes an updated version of the eRSD specification.

There are currently three versions of the eRSD available. eRSD Versions 1 and 2 include the queries necessary for producing CDA eICR R1.1 documents (HL7 CDA® R2 Implementation Guide: Public Health Case Report Release 2: the Electronic Initial Case Report (eICR) Release 1, STU Release 1.1 - US Realm).

While eRSD Version 3 also includes the queries necessary for producing CDA eICR R1.1 documents, it has been introduced to facilitate producing CDA eICR R3.1 documents (HL7 CDA® R2 Implementation Guide: Public Health Case Report Release 2: the Electronic Initial Case Report (eICR) Release 1, STU Release 1.1 - US Realm). Version 3 is for users of the eCR Now FHIR App release 3.X and greater as well as for EHR companies developing custom eCR solutions.

How the eRSD is used to trigger an eICR

An eICR is “triggered” or generated and sent to the AIMS platform for confirmation of reportability when a diagnosis, a suspected diagnosis (or a laboratory order for conditions reportable based on suspicion, a laboratory test name, a laboratory result code, or a medication is matched to one of the specific trigger code sets in the eRSD. There are six primary triggering scenarios that EHRs need to account for by matching data recorded in the EHR against the trigger codes within the eRSD.

The “Lab_Order_Test_Name” and “Suspected_Disorder” value sets are both intended to meet public health needs for the reporting of a certain set of conditions when they are only suspected. “Suspected_Disorder” trigger codes are all SNOMED “suspicion of” diagnosis codes and are recorded in the eICR diagnosis template.

eRSD Preparation and Maintenance

It is important to implement the latest version of the eRSD within EHRs, as doing otherwise may adversely impact public health reporting, resulting in reports of public health interest going undetected and not being sent to public health. The eRSD includes value sets that will continue to evolve with additional codes and conditions reportable to public health. It may also include new codes for rapid implementation in a public health emergency setting. It is important to be able to accommodate routine and emergent eRSD updates.

In some cases, a healthcare provider may use local codes that are not specified in the eRSD. Most major labs deliver results to EHRs with the nationally accepted SNOMED and LOINC terminologies. Not all EHRs record these values on receipt. EHRs using local codes may need to map those codes into the nationally accepted SNOMED and LOINC terminologies to trigger properly. This mapping may be unique to individual healthcare providers, and it is encouraged that the healthcare provider and EHR implementer work collaboratively to determine this need.

Trigger Timing

Because of variability in accumulation of data at the start of a patient encounter, the EHR implementer should implement a time-based delay in generating and sending the first encounter eICR to allow time for required data to be captured within the patient chart. This will ensure the eICR is better populated before sending and will reduce the number of case reports that are sent for a single patient encounter. 

Full triggering timing can be described using the suggested parameters below from the eRSD:

Parameter A – The time from the start of the patient encounter to when the first eICR is constructed and sent. This eICR should include multiple triggers if they are identified.

• Example - 1 hour after the encounter begins, EHR data matches a code in the eRSD diagnosis data trigger code set and other EHR data matches a code in the eRSD lab result trigger code set. Both of these trigger codes should be recorded in the appropriate eICR trigger code template and the eICR should be transmitted out.

Parameter B - The time period from a previous trigger code check to subsequent checking for new trigger code matches in a longer encounter. New trigger code matches do not include matches on an eRSD trigger code that have already been used to generate an eICR for that encounter.

• Example - 12-24 hours after there was a trigger code match, the EHR data is checked against the eRSD trigger code sets again. If a new match is found (not a match against the same eRSD trigger code as had been already matched in that encounter) then a new eICR is generated that includes all of the new trigger codes that have been matched.

Parameter C - The time period from the send of previous eICRs to the send of an updated eICR during a longer encounter.

• Example - 72 hours after a previous eICR was sent, there have been no new trigger code matches, but a new eICR is created and transmitted because there had been a match in the encounter previously and there is a need for public health to receive updated data about the patient.

Parameter D – The time period after the encounter ends through which trigger code checks and eICR updates should still occur.

• Example - For 72 hours after the encounter ends, trigger code checks and / or updated eICR transmissions should still occur.

Parameter E – The reporting duration for the encounter. While an encounter is in progress and within a limited reporting duration, reportability will continue to be checked. Once the encounter has extended beyond that duration, it will only be reported in response to an ‘encounter-modified’ trigger.

• Example – For 1 week after the encounter begins and while it is still in progress, continue to check for suspected reportability. Otherwise, once the encounter has extended beyond 1 week, check for reportability and report only if the encounter has been modified.

In this diagram parameter “A” is 1 hour, parameter “B” is 12-24 hours, parameter “C” is 72 hours, parameter “D” is 72 hours, and parameter “E” is 1 week. These specific values may eventually change and are a part of the eRSD payload.

The eRSD and the Reportable Condition Trigger Code (RCTC) Value Sets

The eRSD is an electronically consumable representation of the information necessary for health care organizations (HCOs) to do electronic case reporting (eCR). Because it can be important to rapidly update information in a public health emergency, HCOs should implement the eRSD so they can rapidly download and import the eRSD content.

The eRSD is composed of trigger codes and trigger timing information for triggering in its main bundle. The second version of the eRSD has a second bundle composed of rules that can be used to reduce reporting network traffic.

The main components of the eRSD are the Reportable Condition Trigger Code (RCTC) value sets developed as part of the Reportable Condition Knowledge Management System (RCKMS) project. The RCTC are maintained by the Council of State and Territorial Epidemiologists (CSTE) in the NLM Value Set Authority Center (VSAC) and are distributed through the eRSD.

Reference Version of the RCTC Value Set:

Reportable Conditions Trigger Codes Value Set for Electronic Case Reporting. RCTC OID: 2.16.840.1.114222.4.11.7508, Release March 29, 2022. 

The RCTC value sets are maintained by the Council of State and Territorial Epidemiologists (CSTE) in the NLM Value Set Authority Center (VSAC).  The reference version of the value set published March 29, 2022 is available at: https://ecr.aimsplatform.org/cms/resources/blocks/reference-rctc-3-22.xlsx

The eRSD service that delivers the RCTC and other critical case reporting data can be accessed through the eRSD Service (external link). An example of the version 1 eRSD can be found here:

        eRSD version 1 example (single bundle - large zip file)

The eRSD represents the trigger codes in XML or JSON format so that it can be rapidly and conveniently consumed by EHR systems. An example of the RCTC value set for suspect conditions can be found here:

        Suspect Conditions Value Set Example (file download)

The eRSD registration system found at this site is intended to ensure users are aware of emergent and routine updates to the eRSD. It does allow for automated download of eRSDs using a token system, but such automated downloads should be performed in accordance with emergency update timing to ensure timely implementation.

For any questions or feedback regarding the eRSD, please contact the eCR Team via the eCR service desk.