HL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR) - US Realm
1.1.0 - STU 2 Ballot

This page is part of the electronic Case Reporting (eCR) (v1.1.0: STU 2 on FHIR R4 Ballot 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 - Reportability Response (RR) Transaction and Profiles

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 ComputableValueSet profile describes the requirements for computable representation of value set membership criteria, ensuring that value sets using this profile selectively support only one technique for defining the content of expansions.

The ExecutableValueSet profile provides support for including a persisted point-in-time expansion that SHALL conform to the chosen compositional style for the value set. The included point-in-time expansion can then be used by FHIR implementations that do not have a FHIR terminology service capable of evaluating the value set in real-time with an $expand operation. It also provides all the concepts needed in the expansion so that a complete code system resource is not required.

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 Artifacts Index 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.

Workflow Definition

The current PlanDefinition uses ECA Rules, we propose using Workflow Definition instead. The execution semantics of an ECA Rule are such that it would be difficult to fully orchestrate the reporting process without multiple PlanDefinition ECA Rules that were coordinated via state. By using a Workflow Definition, we can describe the overall process and take advantage of the execution semantics provided by worfklows to simplify the representation. Specifically, we make the following proposed changes:

  1. The only “trigger” element is specified on the “start” action as the “named-event” “encounter-start”.
  2. Relationships between actions are always expressed using a relatedAction element in the forward direction (so the relationship is “before-start”).
  3. All timings are expressed using the “offsetDuration” element of the relatedAction, simplifying timing representation throughout.
  4. All repetition is expressed through recursive related actions, rather than trying to express the periodicity using a timing structure.
  5. Introduction of two different “loops” in the structure, one for the reportability check, and one for the creation and send of reports for a suspected reportable event.
  6. All logic for determining reportability of an event is expressed in a single library associated with the PlanDefinition.

Profiles

Extensions

  • When applying the eRSD each action may be represented using a Task, but in order to do this there is a need to relate the Tasks in some temporal way. relativeTo is a complex extension on the StructureDefinition Task to reference the resource type, path to the timing element of that resource, and optional offset duration. This would allow us to create a task 24 hours after the Encounter begins for example.

Reporting Process

ERSD Narrative Guidance

Jurisdiction Determination

Jurisdiction Code System Query

Suspected Reportable Determination Logic

Rule Filter Generation

Next Page - Subscription Service