Public Health Agencies - Understanding eCR Standards
Using eICR documents - Implement functionality to receive, process, and use eICR in surveillance systems at public health agencies
The electronic initial case report (eICR) is termed “initial” because the report may be the first report made to public health from the clinical provider, containing just enough pertinent data for public health agencies (PHAs) to initiate an investigation or other appropriate public health activities as necessary. The eICR will convey initial data to a PHA that will support all reportable conditions and be used by all jurisdictions to ease integration by electronic health record (EHR) companies and clinical care organizations so they can support this critical public health function. Full case classification is carried out at the PHA. Common data elements for the eICR were identified by a task force of the Council of State and Territorial Epidemiologists (CSTE). The data for the eICR are drawn from those supported in certified EHRs and are considered critical for reporting or the initiation of a public health investigation.
In some circumstances, the eICR will be all that is needed to support public health reporting. Having electronic case reports on reportable conditions sent from EHRs and received by PHAs represents a significant accomplishment of interoperability between healthcare and public health. The eICR may lead to the reporting of additional data or follow-up by the PHA to confirm reportability; provide condition-specific or public health jurisdiction-specific case data; and/or support public health investigation, contact tracing, and/or countermeasure administration.
The eICR is a Health Level Seven International (HL7) Clinical Document Architecture (CDA) balloted standard for reporting to public health. The 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 is available for download on the HL7 website (external link).
CDA documents are designed to be easily human readable in addition to machine processable. Stylesheets to view the eICRs can be downloaded using this GForge document download (file download).
Additional informative XML support files (such as example files and the Schematron validation files) can be downloaded from this GForge link (external link). See the “_readme.txt” file included in the STU document download for more details.
Using RR documents - Implement functionality to receive and use RR, if desired
For some time, clinical care providers have expressed the concern that they do not receive the information they want from public health for all of the information they provide to public health. Therefore, the primary audience for the Reportability Response (RR) document is healthcare providers/reporters. Its purpose is to communicate back information on the status of reportable conditions in their jurisdiction(s) with succinct next steps they should take relative to these conditions and their patients.
The RR can also be used by healthcare organizations to support multiple roles and workflows, for differing levels of public health urgency:
There are times when a healthcare provider, such as the clinician of record, needs information regarding legally mandated reporting requirements on important public health conditions for which they may have just submitted a report.
Frequently, clinical support staff or infection control practitioners (ICPs) are responsible for following up on reportable conditions and ensuring that all reporting is accomplished, as well as implementing relevant transmission mitigation procedures within their healthcare facility.
EHR system administrators need confirmation that eICRs have been properly shared with public health and, if errors or reporting problems occur, that they are rapidly resolved.
The RR is designed to have one RR created for each eICR and to be shared with the clinical care organization that created the eICR. The RR can also be shared with the PHA(s) that has relevant reporting requirements (a responsible PHA) and wants to use it to monitor the reporting process and know what has been conveyed to clinical care organizations and other PHAs.
PHAs will also want, at times, to receive and visualize RRs. The narrative section of the RR will likely be of most interest to PHAs. It will show the conditions and their respective reportability determinations for each relevant PHA(s). RRs also contain codes that can be used to deliver eICRs to appropriate disease/condition programs inside of the PHA. Also in the RR is information about the reporting criteria that the eICR matched if it was determined reportable.
Also available is the eICR Validation Output if there are issues identified during validation.
The RR is an HL7 CDA balloted standard for the communication back to healthcare of reports from public health. The HL7 CDA® R2 Implementation Guide: Reportability Response, Release 1, STU Release 1.0 - US Realm is available for download on the HL7 website (external link).
A stylesheet is available to illustrate the desired format of the rendered RR CDA document. It can be downloaded with this GForge document download (file download).
Additional informative XML support files (such as example files and the Schematron validation files) can be downloaded from this GForge link (external link). Please see the “_readme.txt” file included in the STU document download for more details.
Reportable Conditions Trigger Codes
The Reportable Conditions Trigger Codes (RCTC) is a list of codes related to reportable diseases that can be easily matched against relevant patient record data. These trigger code value sets are distributed through the Electronic Reporting and Surveillance Distribution (eRSD) (For more information on the eRSD, visit the EHR Implementers - Triggering page). These trigger codes are intended to be matched against recorded diagnoses, problems recorded, lab test names when the test names identify a possible reportable condition, and lab results. There are also circumstances when conditions are reportable when suspected and where matching at the time of lab orders may be necessary.
These trigger codes are defined based on the reporting criteria authored in the Reportable Conditions Knowledge Management System (RCKMS) and are meant to represent all conditions across all jurisdictions. This then allows for the next level of adjudication within RCKMS based on authored specifications from the jurisdictional level to determine actual reportability.
See the EHR Implementers - Triggering page for details on accessing the latest version of the eRSD and trigger codes.
If you identify any codes that you believe should be part of the RCTC, but are not included, contact RCKMS by submitting a ticket through the RCKMS Ticket System (external link).