HL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR) - US Realm CI Build

This page is part of the electronic Case Reporting (eCR) (v1.0.0: STU 1) based on FHIR R4. The current version which supercedes this version is 2.1.0. For a full list of available versions, see the Directory of published versions

Electronic Reporting and Surveillance Distribution (eRSD) Transaction and Profiles

Previous Page

electronic Reporting and Surveillance Distribution (eRSD) Transaction and Profiles

The eRSD transaction includes a constrained FHIR PlanDefinition resource profile, a family of actions, and a FHIR Subscription service. It supports the distribution of reporting guidance and parameters, trigger code value sets, and more complex reporting rules and clinician / reporter support resources. This work seeks to align with developing public health guidelines that cover the same conditions. The PlanDefinition includes guidance for the overall orchestration of electronic case reporting. Each member of the family of actions (Match Trigger, Create eICR, Periodic Update eICR, Close Out eICR, Validate eICR, Route and Send eICR) aligns with what may be different healthcare information systems or modules involved in reporting. The narrative elements of this profile will be used to help structure and guide implementation until EHRs have the ability to automatically consume them.

Triggering value sets and metadata can be used for EHR implementations whether they are FHIR-based or not.

The Create eICR action involves the marshaling of FHIR resources needed to create the eICR profile included in this standard and the Route and Send eICR action involves the transmission of the eICR to either the APHL AIMS Platform, a Public Health Agency (PHA), or a Health information Exchange or Health Data Network on the way to a PHA.

The FHIR Subscription service (also see Subscription examples on the examples page) supports public health needs for the routine and emergent distribution of the eRSD. The Subscription does not require FHIR implementation on the receiving (EHR) end of the transaction, but can provide XML or JSON formats via RESTful query or proactive notification channels.

Next Page