Public Health Agencies

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) vendors and clinical care organizations so they can support this critical public health function. Full case classification is carried out at the public health agency.  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 will represent 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 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 here on the HL7 Website.

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 link.

Additional informative XML support files (such as example files and the Schematron validation files) can be downloaded from this GForge link. Please 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 RR document is healthcare providers/reporters and 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 public health agency(s). RRs also contain codes that can be used to deliver eICRs to appropriate disease/condition programs inside of the public health agency.  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 a HL7 CDA balloted standard for the communication back to healthcare reports from public health. The HL7 CDA® R2 Implementation Guide: Reportability Response, Release 1, STU Release 1.0 - US Realm, available for download on the HL7 Website here.

A stylesheet is available to illustrate the desired format of the rendered Reportability Response CDA document. It can be downloaded with this GForge link.

Additional informative XML support files (such as example files and the Schematron validation files) can be downloaded from this GForge 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 (RCTC) are distributed through the Electronic Reporting and Surveillance Distribution (eRSD) (For more information on the eRSD, please 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 name identifies a possible reportable condition and lab results. There are also circumstances when conditions are reportable when suspected, 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.

The latest version of the eRSD, including trigger codes, is available for distribution on the EHR Implementers - Triggering page.

If you identify any codes that you believe should be part of the RCTC but are not included, please contact RCKMS by submitting a ticket through the RCKMS Ticketing system.

RCTC Scope