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

This page is part of the electronic Case Reporting (eCR) (v2.0.0: STU 2 on FHIR R4) 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

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 defined in the US Public Health PlanDefinition Action Codes code system 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.

eRSD Representation Approach

The following diagram illustrates the general process for electronic Case Reporting as triggered from a patient encounter, highlighting each of the components involved in describing the process:

The components involved in representing the reporting process are:

  • Events Clinical workflow events such as encounter start and end
  • Triggering Criteria Terminology-based criteria for detecting potentially reportable events
  • Process Actions, delays, and loops to orchestrate the process
  • Parameters Parameters for varying timings of the process steps
  • Suspected Reportability Criteria Additional criteria that are evaluated to determine suspected reportability

These components are represented using different elements of the PlanDefinition resource, as generally outlined in the following:

Events are represented with the trigger element; Triggering Criteria are represented using the input data criteria; Parameters are represented using offset in relatedAction elements; Process steps are represented using the action element and the relationships between them are represented with the relatedAction element; and finally, Suspected Reportability Criteria are represented with the condition element.

Each of these are discussed in more detail in the following sections.

Events

Events are represented with the trigger element, using the named-event trigger type and bound to the US Public Health TriggerDefinition Named Event value set. In addition, since the name element of the trigger definition is a uri, the eRSD profile uses the US Public Health Named Event Type Extension to provide complete binding information for the value set, as illustrated in the eRSDPlanDefinition example:

<trigger id="encounter-start">
  <extension url="http://hl7.org/fhir/us/ecr/StructureDefinition/us-ph-named-eventtype-extension">
    <valueCodeableConcept>
      <coding>
        <system value="http://hl7.org/fhir/us/ecr/CodeSystem/us-ph-triggerdefinition-namedevents"/>
        <code value="encounter-start"/>
        <display value="Indicates the start of an encounter"/>
      </coding>
    </valueCodeableConcept>
  </extension>
  <type value="named-event"/>
  <name value="encounter-start"/>
</trigger>
Triggering Criteria

Triggering criteria are specified by a combination of the input data elements, and the Reportable Condition Triggering Codes (RCTC) Value Set Library. Note carefully that the RCTC Value Sets included in this IG are examples to illustrate the structure and typical content of the Value Sets.

Each Value Set corresponds to a different type of information that may contain events that are triggers for potentially reportable events. The categories of information are mapped to FHIR resources using the input element. For example, the reportable conditions value set is mapped to the Condition resource:

<input id="conditions">
  <type value="Condition"/>
  <codeFilter>
    <path value="code"/>
    <valueSet value="http://hl7.org/fhir/us/ecr/ValueSet/valueset-dxtc-example"/>
  </codeFilter>
</input>
Process

Process is represented using the action elements of the PlanDefinition. A PlanDefinition can have any number of action elements, and each action may have any number of child action elements, allowing a hierarchy of actions to be constructed. In addition, the relatedAction element of each action allows dependencies between actions to be expressed. For example, action A starts 5 minutes before action B.

To support a broad variety of use cases, the PlanDefinition resource provides a flexible mechanism for representing processes. To facilitate implementation, the US Public Health PlanDefinition profile introduces constraints that limit the set of elements that can be used to:

  1. The PlanDefinition is of type workflow-definition, to indicate process semantics apply
  2. The only “trigger” element is specified on the “start” action as the “named-event” “encounter-start”.
  3. Relationships between actions are always expressed using a relatedAction element in the forward direction (so the relationship is “before-start”).
  4. All timings are expressed using the “offsetDuration” element of the relatedAction, simplifying timing representation throughout.
  5. All repetition is expressed through recursive related actions, rather than trying to express the periodicity using a timing structure.

The eRSD PlanDefinition uses these structures to introduce a “loop” for the creation and submission of reports for a suspected reportable event:

  • start-workflow
    • trigger: encounter-start
    • action: check-reportable in 1 hour
  • check-reportable
    • if is-encounter-reportable, report-eicr
    • if check-update-eicr, report-eicr
    • if is-encounter-in-progress, check-reportable in 6 hours
  • report-eicr
    • create-eicr, validate-eicr, route-and-send-eicr

The start-workflow action is initiated by an encounter-start event, and specifies that check-reportable should be called in 1 hour.

The check-reportable action checks for suspected reportability, and if true, calls the report-eicr action. If an eICR has not been sent for over 24 hours, then report-eicr is called. If the encounter is still in progress, check-reportable is called again with a delay of 6 hours and this continues until more than 72 hours have elapsed since the encounter end.

The report-eicr action calls all three of create-eicr, validate-eicr, and route-and-send-eicr.

The create-eicr action involves the marshaling of FHIR resources needed to create the eICR profile included in this standard.

The validate-eicr action involves validating the created eICR conforms with all appropriate profiles and validation rules.

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.

Parameters

The offsets (1 h, 6h, and 72h, are parameters to the specification)

  • initial-creation-delay: 1 h
  • reportable-check-period: 6 h
  • suspected-reportable-close-delay: 72 h
Suspected Reportability Criteria

To facilitate implementation, there are two levels of suspected reportability determination. The first level involves only checking for the existing of events with codes that match a code in the appropriate triggering value set. The second level involves additional filtering criteria that can include other elements of the data (such as status and lab values), as well as jurisdictional configuration.

The first level is generally termed triggering and is supported by the triggering profiles, while the second level is generally termed supplemental and is supported by the supplemental profiles.

Triggering eRSD Specification

The triggering level is represented using the condition element of the check-reportable action:

<condition>
  <kind value="applicability"/>
  <expression>
    <extension snipped/>
    <language value="text/fhirpath"/>
    <expression value="%conditions.exists() or %encounters.exists() or %immunizations.exists() or %procedures.exists() or %procedureOrders.exists() or %labOrders.exists() or %labTests.exists() or %labResults.exists() or %medicationAdministrations.exists() or %medicationOrders.exists() or %medicationDispenses.exists()"/></expression>
</condition>

This level uses a FHIRPath to test for existence of data in any of the input categories. Each input element is accessed by an environment variable using the % syntax in FHIRPath.

The eRSD specification is delivered as an asset collection library (a Library resource with a type of asset-collection) conforming to the US Public Health Specification Library profile.

The eRSD Specification library is composed of the eRSD Plan Definition and the RCTC Library, a Value Set library that conforms to the US Public Health Triggering Value Set Library profile:

<relatedArtifact>
  <type value="composed-of"/>
  <resource value="http://hl7.org/fhir/us/ecr/PlanDefinition/plandefinition-us-public-health-example"/>
</relatedArtifact>
<relatedArtifact>
  <type value="composed-of"/>
  <resource value="http://hl7.org/fhir/us/ecr/Library/library-rctc-example"/>
</relatedArtifact>

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 ValueSets in the RCTC Library are distributed conforming to both these profiles, enabling systems to make use of expansions, or recalculate expansions based on the computable value set definition if necessary.

Supplemental eRSD Specification

The supplemental level of integration enables sites to participate in the suspected reportability determination by considering additional elements of the event data such as status, lab values, and jurisdiction configuration.

The suspected reportability criteria are also represented with the condition element, but using the US Public Health Alternative Expression to provide the CQL expression for suspected reportability:

<extension url="http://hl7.org/fhir/us/ecr/StructureDefinition/us-ph-alternative-expression-extension">
  <valueExpression>
    <language value="text/cql-identifier"/>
    <expression value="Is Reportable"/>
    <reference value="http://aphl.org/fhir/ecr/Library/RuleFilters|1.0.0"/>
  </valueExpression>
</extension>

This extension indicates that the Is Reportable expression of the RuleFilters library should be used to evaluate whether the event is suspected reportable.

For a complete description of the logic used to determine suspected reportability, refer to the Rule Filter Generation topic.

For a detailed discussion of how jurisdiction is determined, see the Jurisdictions Code System Query topic.

For a detailed discussion of how this code system is structured, see the Jurisdictions Code System Description topic.

The eRSD Supplemental Library is composed of the RuleFilters library and the Supplemental Value Set library, which contains any additional value sets and code systems (including the Jurisdictions code system) beyond the RCTC value sets that are required by the RuleFilters logic:

<relatedArtifact>
  <type value="composed-of"/>
  <resource value="http://aphl.org/fhir/ecr/Library/RuleFilters"/>
</relatedArtifact>
<relatedArtifact>
  <type value="composed-of"/>
  <resource value="http://hl7.org/fhir/us/ecr/Library/library-us-ph-supplemental-valueset-library-example"/>
</relatedArtifact>
<relatedArtifact>
  <type value="composed-of"/>
  <resource value="http://hl7.org/fhir/us/ecr/CodeSystem/ersd-jurisdictions-example"/>
</relatedArtifact>

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.

Profiles

Extensions