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.
- 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.
Although the eRSD is in HL7 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 (HL7 FHIR eCR 2.1) includes an updated version of the eRSD specification (eRSD R2). The eRSD R1 will continue to be available for some time. The eRSD R2 will eventually also have a second FHIR bundle that will convey rules for local implementation that are intended to refine eICR transmissions and further minimize network traffic.
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.
Lab Orders (LOINC)
An eICR will be triggered when a laboratory order is placed where the lab order matches a value within the eRSD “Lab_Order_Test_Name” value set.
Note: Because this trigger handles reporting on suspicion of a condition to meet related laws, this triggering should occur before lab results are available.
Diagnoses & Suspected Diagnoses (SNOMED, ICD-10 CM)
An eICR will be triggered when a diagnosis is recorded in the EHR that matches a value within the eRSD “Diagnosis_Problem” value set. The EHR data could be in problem lists or diagnosis fields.
An eICR will also be triggered when a suspected diagnosis is recorded in the EHR that matches a value in the eRSD “Suspected_Disorder” value set. The suspected diagnosis triggering may be used to replace lab order triggering for EHRs that cannot do lab order triggering.
Lab Results (SNOMED)
An eICR will be triggered when a laboratory result is received by the EHR where the laboratory result matches a value within the eRSD “Organism_Substance” value set.
Lab Result Test Name (LOINC)
An eICR will be triggered when a laboratory result is received by the EHR where the laboratory test name matches a value within the eRSD “Lab_Observation_Test_Name” value set.
Medication (for version 3.X eICRs only)
(CVX, RXNORM, SNOMED)
An eICR can be triggered when a medication is administered or prescribed and matches a value within the eRSD “Medication” value set.
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.
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 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 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.
A reference version of the full RCTC trigger code list can be found here (this spreadsheet is not intended for operational use, rather it is a complete, historic version of the RCTC value sets as an example):
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 (this file is not intended for operational use):
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 (this file is not intended for operational use):
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 Support Team eCR-Info@aimsplatform.org