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 already certified to be used by electronic health records (EHRs) for other purposes.
The AIMS platform currently processes documents using both HL7 CDA eICR standards listed below (and available for download on the HL7 website).
- The initial 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 (eICR R1.1), published in January 2017.
- The HL7 CDA® R2 Implementation Guide: Public Health Case Report, Release 2: the Electronic Initial Case Report (eICR), Release 2, STU Release 3.1 - US Realm (eICR R3.1), published in July 2022.
There is also a complete HL7 Fast Healthcare Interoperability Resources (FHIR) eICR specification that will be supported on the platform in the future.
If your organization is interested in piloting FHIR standards or participating in FHIR Connectathons for eCR, contact the eCR Team via the eCR service desk.
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 a multi-condition, multi-jurisdiction public health case report.
- The eICR Data Needs workbook (file download) is intended for use by EHR Implementers and healthcare teams to facilitate eCR onboarding. It does not take the place of any HL7 implementation guides relevant to the eCR use case but is a useful companion artifact.
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. Public health jurisdictions may choose for AIMS to send anonymized data to CDC on their behalf.
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, stylesheets and the Schematron validation files) can be downloaded by clicking the green code button at this GitHub 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.
Other standards for eCR
The AIMS platform generates the HL7 CDA® R2 Implementation Guide: Reportability Response, Release 1, STU Release 1.1 - US Realm (RR R1.1), available for download on the HL7 website (external link). For more information on RRs, see Reportability Response Receipt and Use.
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). Participation in the HL7 process for these standards is encouraged in the HL7 Public Health Workgroup (external link).
Comments or feedback on HL7 eCR standards can be submitted through the HL7 CDA Specifications Feedback Jira site (external link).
The eCR Now FHIR App
The eCR Now FHIR App is open source and freely available for EHR industry partners to integrate with their products. It provides eCR capabilities for any EHR product and fulfills certification for eCR. It uses the HL7 FHIR R4 API to connect to EHRs to:
- identify when a patient has a condition that should be reported, and
- construct an eICR to send to public health.
