HL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR) - US Realm
2.1.2 - STU 2
HL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR) - US Realm
2.1.2 - STU 2
HL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR) - US Realm, published by HL7 International / Public Health. This guide is not an authorized publication; it is the continuous build for version 2.1.2 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/case-reporting/ and changes regularly. See the Directory of published versions
The eRSD transaction includes a constrained FHIR PlanDefinition resource profile and a family of actions. 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.
The distribution of case reporting specifications involves two systems, the Implementing System (typically an Electronic Health Record (EHR)) and the Specification Repository, a repository that manages reporting specifications and the versions of those specifications over time:
Conceptually, there are three transactions involved in the distribution of eRSD specifications:
Notification may be accomplished in multiple ways such as simple email or text notifications.
Similarly, the Request and Response transactions may be implemented in multiple ways, including HTTP file download, as well as API access to a FHIR server acting as a repository.
At this time, this implementation guide is only prescriptive about the payload of the Response transaction, as defined by the following sections. We seek implementer feedback on the usefulness of more formal specification of these transactions.
The eRSD specification is structured into two groups to facilitate two different levels of implementation of suspected reportability criteria:
The contents of each of these specifications at a high level are:
Subsequent sections describe each of these specification components in more detail.
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:
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 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 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.
The triggering value sets will include any number of focus useContext slices to indicate which conditions the triggering codes are associated with. 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>Note to implementers: The logic used throughout the reporting workflow definition assumes the data provided as input is valid. For example, an Encounter with a status of in-progress is assumed to have a period element with a start date specified. Implementations may account for differences in the way the clinical system represents encounter information by adjusting the data using context in the reporting application to meet these assumptions.
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:
workflow-definition, to indicate process semantics applyThe eRSD PlanDefinition uses these structures to introduce a "loop" for the creation and submission of reports for a suspected reportable event:
The start-workflow action is initiated by an encounter-start event, and specifies that check-reportable should be called in "A" hours.
The check-suspected-disorder action checks the encounter against a suspected disorders value set, and if a match is found, calls the create-eicr action immediately. If the encounter is in progress and still within the normal reporting duration ("E"), or less than "D" hours have elapsed since the encounter end, check-reportable is called.
The check-reportable action checks for suspected reportability and whether or not the encounter is within the normal reporting duration ("E"), and if true, calls the create-eicr action. If an eICR has not been sent for over "C" hours, then create-eicr is called. If the encounter is still in progress, check-reportable is called again with a delay of "B" hours and this continues until more than "D" hours have elapsed since the encounter end.
The create-eicr action involves the marshaling of FHIR resources needed to create the eICR profile included in this standard. It calls the validate-eicr action.
The validate-eicr action involves validating the created eICR conforms with all appropriate profiles and validation rules. It calls the route-and-send-eicr action.
The route-and-send-eicr action involves the transmission of the eICR to either a third party platform, a Public Health Agency (PHA), or a Health information Exchange or Health Data Network on the way to a PHA.
The encounter-modified action is initiated by an 'encounter-modified' event, and specifies that if the encounter has extended beyond the normal reporting duration ("E") create-eicr should be called.
Note to implementers: The workflow described here provides a minimally complete representation of the required reporting events. However, implementations may wish to extend this functionality to support implementation-level tracking details such as workflow status. For example, the addition of an 'is-encounter-completed' action that can be used to explicitly track when an encounter completes, rather than the implicit completion represented here.
Because of variability in accumulation of data at the start of a patient encounter, the EHR implementer should implement a time-based delay in generating and sending the first encounter eICR to allow time for required data to be captured within the patient chart. This will ensure the eICR is better populated before sending and will reduce the number of case reports that are sent for a single patient encounter.
Full triggering timing can be described using the suggested parameters below from the eRSD:
Parameter A – The time from the start of the patient encounter to when the first eICR is constructed and sent. This eICR should include multiple triggers if they are identified.
Parameter B - The time period from a previous trigger code check to subsequent checking for new trigger code matches in a longer encounter. New trigger code matches do not include matches on an eRSD trigger code that have already been used to generate an eICR for that encounter.
Parameter C - The time period from the send of previous eICRs to the send of an updated eICR during a longer encounter.
Parameter D – The time period after the encounter ends through which trigger code checks and eICR updates should still occur.
Parameter E - The normal reporting duration for the encounter. While an encounter is in progress and within the the normal reporting duration reportability will continue to be checked. Once the encounter has extended beyond the normal reporting duration, it will only be reported on in response to an 'encounter-modified' trigger.
Note to implementers: The offset durations specified in related actions here are relative durations, in that they contain a comparator to indicate that the action should be completed at most X. This allows implementations to support scheduling these actions during non-peak times to minimize load on the clinical system.
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.
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.
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://hl7.org/fhir/us/ecr/Library/RuleFilters|2.1.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://hl7.org/fhir/us/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>As noted in the overview section above, this implementation is not prescriptive about the absolute mechanisms for distribution, only about the contents of the specification in the form of Library, PlanDefinition, CodeSystem, and ValueSet resources conforming to the required profiles. The complete specification may be distributed via files (e.g. a zip of the specification as a FHIR bundle), via API (e.g. as a Bundle resource directly, or as the result of a packaging operation), or via notification.
When packaging as a Bundle, the expectation is that the Bundle would include the Library as the first entry, followed by all the component resources as entries, and finally all the referenced ValueSet resources. If the specification is too large for one Bundle, the specification may be split into multiple Bundles. The following examples illustrate complete bundles of both the Specification and Supplemental distributions:
IG © 2020+ HL7 International / Public Health. Package hl7.fhir.us.ecr#2.1.2 based on FHIR 4.0.1. Generated 2024-10-30
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change