Challenge
The response is stored as a file nobody opens
Agnotic approach
Responses are filed into the chart as a document with a task or inbox item for the role your policy names.
Integrations / Electronic Case Reporting
Electronic Case Reporting Integration for EHRs and Health IT
A reportable diagnosis is charted, but the case report never leaves the EHR, or it leaves and the response from public health is never filed. Agnotic Technologies builds the EHR side of electronic case reporting: trigger matching, eICR creation, routing and the reportability response back in the chart.
RCTC trigger matchingeICR in FHIR or CDAReportability response filingCertification evidence
Trusted by global innovators
What is electronic case reporting integration?
Electronic case reporting integration is the EHR work that spots a possibly reportable encounter from trigger codes, builds an electronic initial case report (eICR) in HL7 FHIR or CDA, sends it to public health and files the reportability response back to the chart. Agnotic Technologies builds and tests this for EHR vendors and provider IT teams.
The buyer is usually one of two teams: a health IT developer that needs its product to meet the certification criterion, or a hospital or clinic group that has to show active engagement with its public health agency.
What happens after the report arrives, such as person matching and case follow-up at the health department, is covered on our public health software page.
Flow and failure points
Where can a case report fail between the encounter and public health?
eCR has six hand-offs, and each one can fail without anyone noticing. This is the flow we build, with the check that catches each failure.
| Step | What happens | What can fail | Check that catches it |
|---|---|---|---|
| 1. Encounter is documented | Diagnoses, lab orders and results are recorded in the EHR | The finding sits in free text or a local code that no trigger can match | Code mapping review of local lab and problem list codes against standard terminologies |
| 2. Trigger match | Encounter codes are compared with the Reportable Conditions Trigger Codes value set | An old copy of the value set is still loaded, so newer trigger codes are missed | Value set version stored with every match, and an alert when a newer release is available |
| 3. eICR created | The case report is built in FHIR or CDA from the encounter data | Required sections are empty or the document fails validation | Schema and profile validation before sending, with failures queued for review |
| 4. Routed | The eICR is sent to the shared routing platform or straight to the agency | Transport errors, expired certificates or a silent connection | Delivery acknowledgment tracked per report, with an alert when one is overdue |
| 5. Reportability response returned | Public health rules decide whether the case is reportable and to which jurisdiction | The response never arrives, or arrives for an encounter the EHR cannot match | Correlation on the eICR document ID, and a list of reports with no response |
| 6. Response filed | The response is attached to the patient record and shown to the care team | It is stored but no clinician sees the follow-up instructions | Filing rules that place it in the chart and notify the right role |
A report that fails silently looks the same as a case that was never reportable, so every step keeps its own status.
Trigger matching
How are trigger codes matched inside the EHR?
Matching starts with the Reportable Conditions Trigger Codes (RCTC) value set: diagnosis, lab order, lab result and organism codes that suggest a condition may be reportable. A match does not mean the case is reportable. That decision is made by public health rules after the report is sent.
We load the value set as versioned data, not as hard-coded lists, so an update is a data release rather than a code change. Each eICR records which trigger and which value set version caused it.
Matching runs on the events that carry the codes: encounter diagnoses, problem list changes, lab orders and lab results. Results that arrive days after discharge still trigger, so a report can follow the encounter it belongs to.
Documents and profiles
Which eCR documents does the EHR send and receive?
The criterion accepts the FHIR or CDA family. Most builds pick one for eICR and use the matching reportability response format.
| Code | Name | Typical use |
|---|---|---|
| eICR (FHIR) | Electronic initial case report, HL7 FHIR eCR IG | Sent by the EHR when a trigger matches; built from encounter, patient and provider data |
| eICR (CDA) | Electronic initial case report, HL7 CDA R2 eICR IG | The same report as a CDA document, often chosen where CDA tooling already exists |
| RR (FHIR) | Reportability response profile, HL7 FHIR eCR IG | Returned to the EHR: reportable or not, the jurisdictions and the follow-up guidance |
| RR (CDA) | Reportability response, HL7 CDA RR IG | The CDA form of the response, paired with a CDA eICR |
| eRSD | Electronic reporting and surveillance distribution | Distributes trigger codes and reporting rules in FHIR, so the value set can be loaded as data |
| RCTC | Reportable Conditions Trigger Codes value set | The codes the EHR matches against before it creates an eICR |
Reportability responses
What goes wrong when the reportability response comes back?
Sending the eICR is half the job. The response is where most builds stop short.
Challenge
One encounter triggers several reports
Agnotic approach
Reports are linked to the encounter and the trigger, so updates replace the earlier report instead of creating a second case.
Challenge
The case is reportable in more than one jurisdiction
Agnotic approach
The response lists each jurisdiction, and the chart shows every one of them rather than the first.
Challenge
Responses stop arriving after a certificate or endpoint change
Agnotic approach
A daily list of reports with no response goes to the integration owner before anyone has to ask.
Evidence
What evidence does each team need from eCR?
The same build serves two different obligations. The records it keeps should match the one you carry.
01
Health IT developer
Example: Certification to the electronic case reporting criterion for an EHR or Health IT Module
Approach: Test cases for trigger consumption, eICR creation in the chosen standard, response processing and transmission, with sample documents kept per release.
02
Eligible hospital or CAH
Example: Active engagement with the public health agency under the Promoting Interoperability measure
Approach: Registration and onboarding records with the agency, production send logs and response counts per reporting period.
03
Claiming an exclusion
Example: No reportable conditions treated, or no agency ready to receive eCR in the required standards
Approach: The agency's readiness status and your diagnosis data kept with the attestation, so the exclusion can be shown later.
Security
How is patient data protected along the eCR path?
A case report carries identifiable clinical data to an outside party, so the path is built and logged like any other PHI interface.
Encrypted transport
Reports travel over authenticated, encrypted connections, with certificates tracked before they expire.
Logged per report
Every eICR sent and every response received is logged with time, destination and status.
Alerts without payloads
Monitoring uses document IDs and status codes, so alerts never copy clinical content.
BAA before production
Agnotic signs a business associate agreement before touching production clinical data.
Who it is for
Who builds electronic case reporting with us?
Teams on the sending side of eCR.
EHR and Health IT Module developers
Products that need the criterion for certification and a supportable eCR feature for customers.
Hospitals and CAHs
IT teams completing onboarding with their public health agency and keeping evidence for attestation.
Clinic groups and urgent care networks
Practices on several EHR instances that need one consistent reporting path.
Lab and specialty system vendors
Systems that hold the results that trigger reports and feed them into the EHR on time.
Integration teams after an EHR change
Rebuilding trigger matching and response filing when the old system is retired.
Compliance-First Healthcare App Development Services Backed by Global Standards
01
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
02
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
03
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
04
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
05
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
06
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
07
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
08
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
09
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Facts and sources
Which rules and standards define eCR?
Short facts the build is designed around, each linked to its primary source.
To meet the standards-based electronic case reporting criterion, a Health IT Module must consume the Reportable Conditions Trigger Codes value set, create a case report with the eICR profile of the HL7 FHIR eCR IG or the HL7 CDA eICR IG, receive and process the reportability response, and transmit the case report electronically.
Source: 45 CFR 170.315(f)(5)(ii) (eCFR)ONC adopts four electronic case reporting standards: the HL7 FHIR eCR IG 2.1.0 (STU 2), the HL7 CDA eICR IG Release 2 (STU Release 3.1), the HL7 CDA Reportability Response IG (STU Release 1.1) and the Reportable Conditions Trigger Codes value set.
Source: 45 CFR 170.205(t) (eCFR)The HL7 FHIR eCR implementation guide (US Realm, version 2.1.2, based on FHIR 4.0.1) defines transactions and profiles for the electronic initial case report (eICR), the reportability response (RR) and the electronic reporting and surveillance distribution (eRSD).
Source: HL7 FHIR Implementation Guide: Electronic Case Reporting (eCR), US RealmThe Promoting Interoperability electronic case reporting measure asks an eligible hospital or CAH to be in active engagement with a public health agency to submit case reporting of reportable conditions. Exclusions include a jurisdiction where no agency can receive eCR in the required standards.
Source: 42 CFR 495.24 (eCFR)
How we work
How does an eCR integration project run?
Three stages, starting from your EHR's current data.
1.
Scoping call
We review your EHR, the standard you will send, your agency's onboarding status and where trigger codes live today.
Data first
2.
First release
Trigger matching, eICR creation and validation in a test environment, then transmission and response filing.
Fixed scope
3.
Production and upkeep
Go-live with your agency, the no-response report and value set updates on a schedule.
Ongoing
Frequently Asked Questions
Either meets the criterion, as long as the reportability response uses the matching family. FHIR suits products that already expose FHIR resources; CDA suits teams with mature CDA document tooling. We pick with you based on what your EHR already produces well.
No. A match only means the encounter may be reportable. Public health decision rules make the call after the eICR is received, and the reportability response tells the EHR the outcome for each jurisdiction.
No. Electronic lab reporting sends reportable lab results from the lab, while eCR sends a case report built from the clinical encounter. Promoting Interoperability lists them as separate measures, and many hospitals run both.
Yes. We work from the EHR's own events and APIs to match triggers, build the eICR and file the response. Where the EHR vendor already ships an eCR module, we connect and test it instead of rebuilding it.
The quality of local code mapping, whether you need FHIR, CDA or both, how many EHR instances send reports, and how responses must be filed and routed to staff. We size these on the scoping call; no figures are quoted before it.
Yes. Trigger matching and validated eICR creation for one EHR instance is a complete first scope, and transmission and response filing build on the same records.
Engineers may use AI tools to draft mapping tables and test documents from synthetic data, and a person reviews each one. Real case reports and patient records never go into AI tools.