Electronic Case Reporting (eCR) with Mirth Connect: Building the CDC-Mandated Pipeline

Electronic Case Reporting (eCR) is the CDC's program for automating the reporting of notifiable conditions — over 1,500 reportable conditions including COVID-19, hepatitis, Lyme disease, and influenza — from EHRs to state and local public health agencies. The mandate is in the CARES Act. The technical standard is an eICR (electronic Initial Case Report) transmitted as a FHIR R4 document. Mirth Connect is the most common integration engine for assembling and routing eICR documents. This guide covers the complete pipeline. For TEFCA context, see our TEFCA and information blocking guide.

New to Mirth? Start with our Mirth Connect guide: what it is, how it works, and when it fits.

The Three-Component eCR Architecture

eCR workflows have three components: (1) The EHR (trigger source) provides clinical data — diagnoses, lab results, patient demographics. (2) The RCKMS (Reportable Conditions Knowledge Management System), operated by APHL, evaluates the clinical data against condition-specific trigger criteria and returns a reportability determination. (3) Mirth assembles the eICR FHIR Bundle and submits it to the AIMS Platform for routing to the appropriate state and local health departments.

Teams that want this built rather than researched can work with our Mirth Connect integration team.

RCKMS Rule Evaluation from Mirth

// Call RCKMS Reportability Response API
var rkcmsUrl = 'https://rckms.aimsplatform.org/v1/decision';
var httpClient = Packages.org.apache.commons.httpclient.HttpClient();
var post = new Packages.org.apache.commons.httpclient.methods.PostMethod(rkcmsUrl);
post.setRequestBody(encounterFHIRJson);
post.setRequestHeader('Content-Type', 'application/fhir+json');
post.setRequestHeader('Authorization', 'Bearer ' + globalMap.get('rkcms_token'));
httpClient.executeMethod(post);

var response = JSON.parse(post.getResponseBodyAsString());
var reportability = response.extension.find(function(e) {
    return e.url.indexOf('reportability-information-extension') !== -1;
});

if (!reportability || reportability.valueCode === 'NOREPORT') {
    channelMap.put('suppress_ecr', 'true');
} else {
    channelMap.put('suppress_ecr', 'false');
    channelMap.put('reportable_condition', response.reasonCode[0].text);
}

eICR FHIR Composition: Required Sections

The eICR is a FHIR R4 Composition containing these required sections per the HL7 US eCR Implementation Guide:

• Patient Demographics — Patient resource with identifiers (required always)
• Problem List — Conditions with ICD-10 trigger codes (required — primary trigger source)
• Results — Lab values that triggered the report (required — secondary trigger source)
• Medications — Active medications at time of report (required always)
• Chief Complaint / Reason for Visit — Encounter reason text (required always)
• Travel History — Recent travel when clinically relevant (conditional)
• Social History — Occupation, living situation for epidemiological context (required)
• Plan of Treatment — Isolation orders, referrals, treatment planned (required always)

For C-CDA to FHIR conversion patterns used when extracting the eICR sections from EHR C-CDA output, see our dedicated C-CDA guide.

AIMS Platform Submission

var aimsUrl = 'https://aims.aimsplatform.org/ecr/fhir/Bundle';
var post = new Packages.org.apache.commons.httpclient.methods.PostMethod(aimsUrl);
post.setRequestBody(JSON.stringify(eicrBundle));
post.setRequestHeader('Content-Type', 'application/fhir+json');
post.setRequestHeader('Authorization', 'Bearer ' + globalMap.get('aims_token'));
httpClient.executeMethod(post);

var statusCode = post.getStatusCode();
if (statusCode === 200 || statusCode === 201) {
    var responseId = JSON.parse(post.getResponseBodyAsString()).id;
    channelMap.put('ecr_submission_id', responseId);
    logger.info('eCR submitted: ' + responseId);
} else {
    logger.error('eCR submission failed: ' + statusCode);
    channelMap.put('ecr_error', post.getResponseBodyAsString());
}

For security configuration of the AIMS HTTPS connection including certificate management in Mirth, see our Mirth Connect security guide.

Managing Trigger Condition Lists

RCKMS trigger conditions update regularly. Maintain the trigger condition list in a database table that can be updated without channel redeployment. Load into globalMap at channel startup. Pre-filter messages in the source filter — check the patient's active diagnoses against the trigger list before calling RCKMS to avoid unnecessary API calls for clearly non-reportable encounters.

Further Reading

• TEFCA & Information Blocking: Integration Engine Guide
• C-CDA Processing with Mirth Connect
• Turning HL7 v2 into Modern FHIR APIs
• Healthcare Interoperability Standards: FHIR, HL7, X12
• Mirth Connect NCPDP SCRIPT e-Prescribing