This page is part of the electronic Case Reporting (eCR) (v2.1.2: STU 2) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions
The Electronic Case Reporting (eCR) standards; the electronic Initial Case Report (eICR) and the Reportability Response (RR), support two broad approaches to eCR.
One of the approaches also uses the Reportable Condition Knowledge Management System (RCKMS) on the AIMS platform to report to Public Health Agencies (PHAs) and one does not. The two approaches are:
In some jurisdictions, HIEs and/or Health Information Networks may also be employed to securely move data between organizations including to and from a shared services platform.
Prominent among these purposes is to implement public health reporting rules that cannot currently be readily distributed to healthcare. The rules ensure that public health agencies only get the data they are authorized to receive by state laws.
Without more complex reporting rules that are distributable to, and executable in, healthcare most PHAs will not use approach #1. Hence, these approaches are principally represented by either "Remote Rules" or "Local Rules" in the following diagram.
FHIR enables several capabilities for eCR. Because reportable events occur in healthcare without PHA knowledge and because PHAs do not have the authority to receive these data until they are deemed reportable, eCR utilizes an unsolicited push transaction, FHIR messaging, and flexibility in multi-network transport to report data to state and local agencies. There is also a transaction for "electronic Reporting & Surveillance Distribution (eRSD)." The eRSD includes Reportable Condition Trigger Code (RCTC) trigger code value sets and other reporting guidance from public health to healthcare to support reporting from EHRs.
The eRSD transaction needs to be able to help orchestrate this reporting which may span a broad spectrum from trigger codes in an EHR all the way to a healthcare-based API connected rules engine that is external to the EHR but operating inside of healthcare or at a healthcare Business Associate. To achieve this orchestration the eRSD resource needs to guide the Triggering, Rule Processing, Clinical Feedback, Creation of eICR, Routing and Sending components of eCR and interactions between them. For some time, much of the eRSD transaction will provide structure to eCR as human consumable guidance. The most immediately machine processable components are the included trigger code value sets.
When distributable rules can be processed in most healthcare settings, there may be needs to distribute the rules, the trigger codes, and links to relevant on-line condition-specific information. The eRSD transaction can enable these distributions going forward as well as provide details for how critical elements, like report timing, of the reporting process should be implemented. It will also allow for a connection to separate efforts to develop clinical guidelines for public health conditions. Reporting and guidelines should utilize the same infrastructure and approaches where possible to minimize demands on EHRs.
eICRs shared from EHR interface are not definitively reportable. There are complex rules that also need to also be implemented to ensure that case reports meet state laws for submission. Examples of some of these rules follow.
Rule Number |
Rule Description |
Data needed for rule to determine reportability |
Rule 1 |
Pediatric influenza mortality reporting |
age and condition |
Rule 2 |
Staph Aureus with Vancomycin MIC > 4μg/ml |
condition and drug sensitivity |
Rule 3 |
Respiratory Syncytial Virus associated deaths in laboratory confirmed cases less than five years of age |
condition, cause of death, and age |