EHR Implementers

EHR Implementers - eICR Creation, Validation, & Standards

What is an eICR document? What does it include? 

The electronic initial case report (eICR) is a consensus-based Health Level Seven International (HL7) standard. It was developed for use in electronic case reporting (eCR). It was constructed in the HL7 Clinical Document Architecture (CDA) almost entirely from Consolidated-Clinical Document Architecture (C-CDA) templates that are certified to already be used by electronic health records (EHRs) for other purposes. There is also a complete HL7 Fast Healthcare Interoperability Resources (FHIR) eICR specification and an updated CDA eICR standard (R3.0) that are in the process of being published.

The data in the eICR were identified by a Council of State and Territorial Epidemiologists (CSTE) task force as the “minimum necessary” data needed for public health case reporting. The CDA eICR R1.1 Implementation Guide was initially published in January 2017. There is also a complete HL7 FHIR eICR specification and an updated CDA eICR (will be R3.0) that are in the process of being published. 

  • 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, available for download on the HL7 website (external link)

How and when should an eICR document be created?

When specific patient encounter data match one of the trigger codes in the Electronic Reporting and Surveillance Distribution (eRSD) Reportable Condition Trigger Codes (RCTC) and the encounter timing is as specified in the eRSD, an eICR should be created and sent. An eICR can also be manually initiated by a clinician if they suspect the presence of a reportable condition. If manually initiated, the clinician should record the reason for sending the eICR for public health awareness. While an eICR can be created and sent directly from an EHR system, it can also be created in an EHR and sent through a designee of clinical care, such as a Health Information Network (HIN) or Exchange (HIE).

eICRS are securely received and processed on behalf of the provider organizations from which they originate. Using rules authored by each state and local public health agency’s head epidemiologist or their representative, the eICRs are then transmitted to appropriate public health agencies. 

eICRs are only maintained by the Association of Public Health Laboratories (APHL) Informatics Messaging Services (AIMS) long enough to complete routing to the public health agencies and address any errors in delivery. eICRs are not retained by APHL AIMS. eICRs are not sent to the Centers for Disease Control and Prevention (CDC), but state public health agencies may use some of the eICR data to send anonymized notifications of confirmed case reports to the CDC for nationwide statistics.

How to validate an eICR document?

Validation during eICR development

It is important while developing the eICR document to ensure it follows both Schema and Schematron validation specifications. APHL has implemented a specific online validation tool for this purpose. Users can upload eICR files without PHI to test validation with the AIMS Validator (external link). This validation tool is specific to the eICR and the eICR’s underlying CDA Schema. The tool produces very specific information to refine the creation of the eICR document. 

Validation is also performed on all incoming eICRs in production. Some of the validation information will also be placed in the Reportability Response (RR) that is returned to the submitting organization when production reports have issues that need to be addressed.

Additional XML support files (such as example files and the Schematron validation files) can be downloaded from this HL7 GForge link (external link). There are also some test eICRs that are available on the EHR Implementers - Test Packages page.

Validation in production on the AIMS platform

Within the production eCR workflow, validation also occurs on the eCR platform before the eICR is passed to the decision support service. This validation step allows for more detailed error and warning information in specific circumstances to be conveyed in the RR. 

  • RR “warnings” indicate that the eICR was received and processed, but that there is an issue to be addressed by an EHR administrator. Warnings may include that the EHR is using an outdated version of the eRSD and trigger codes, or that a minor issue exists in the relevant eICR.

  • RR “errors” indicate that the relevant eICR was not successfully processed, that the EHR administrator needs to determine what caused the issue (the validation error details are available in the RR to help diagnose the problem), and that the provider of care may need to be notified that required reporting has not been done.

Creation and management of eCR standards 

The eICR and RR were developed through the HL7 consensus-based standard development process. Participation included stakeholders from across the industry (clinical care, public health, EHR vendors). We encourage participation in the HL7 process for these standards in the HL7 Public Health Workgroup (external link).

Comments specifically on the eICR STU Implementation Guide can be made on the HL7 STU Comments site for the eICR (external link)

Comments specifically on the RR STU Implementation guide can be made on the HL7 STU Comments site for the RR (external link).

Other standards for eCR

While the CDA eICR STU 1.1 and RR STU 1.0 documents are currently the only eCR standards in use in production, there are new CDA versions and HL7 FHIR (Fast Healthcare Interoperability Resources) versions that have been balloted and will soon be published.

The eCR Now FHIR App uses the HL7 FHIR R4 to connect to EHRs. The app then produces the same CDA eICR STU 1.1 and receives the RR STU 1.0 documents that are in operations with “native” EHR implementations.

If your organization is interested in piloting FHIR standards or participating in FHIR Connectathons for eCR, contact us at eCR-Info@aimsplatform.org.