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 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.
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 published in January 2017, and there is an update planned for the May 2019 HL7 ballot cycle. An updated version will be made available by the end of 2019.
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 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 that delivery. eICRs are not then retained by APHL AIMS. eICRs are not sent to the Centers for Disease Control and Prevention (CDC), but states may use some of the eICR data to send anonymized notifications of confirmed case reports to the CDC to develop 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. The Association of Public Health Laboratories (APHL) has made a customized, online validation tool for this purpose. Users can upload eICR files to test validation on 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 healthcare when production reports have issues that need to be addressed.
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.
Validation in production on APHL Informatics Messaging Services (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 will allow 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 was processed, but that there is some issue to be addressed by an EHR system administrator. Such 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 errors should be 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 Reportability Response STU Implementation guide can be made on the HL7 STU Comments site for the Reportability Response (external link).
Other standards for eCR
While the CDA eICR and Reportability Response documents are currently the only eCR standards available for use in production, there are ongoing efforts to expand into Fast Healthcare Interoperability Resources (FHIR). An eCR FHIR Implementation Guide has been balloted and will soon be published. If your organization is interested in prototyping FHIR standards or participating in FHIR Connectathons for eCR, contact us at eCR-Info@aimsplatform.org.