FHIR CI-Build

This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions icon

Work Group Clinical Decision Support iconMaturity Level: 2Standards Status: Trial Use

14.4 Sharing Knowledge Artifacts

One of the primary use cases of the Clinical Reasoning Module is to enable the sharing and distribution of computable clinical knowledge artifacts. Some general considerations for this use case are documented here, with a more complete and ongoing treatment in the Canonical Resource Management Infrastructure icon implementation guide.

Knowledge Artifact Sharing

The distribution use case involves enabling knowledge artifacts to be distributed as FHIR resources, either by making use of the FHIR implementation guide publication infrastructure, or via a FHIR server.

14.4 Distribution via Implementation Guides

For distribution as part of FHIR Implementation Guides, the existing FHIR publication infrastructure can be used to produce implementation guides whose primary focus is conformance and knowledge artifacts such as ValueSets, Libraries, ActivityDefinitions, PlanDefinitions, and Measures. To help illustrate this approach, the following diagram depicts several types of FHIR implementation guides:

FHIR Implementation Guide Categories

This diagram depicts 4 categories of specifications, with representative examples of each category, illustrating how the various pieces can be used together to deliver shareable clinical reasoning artifacts such as quality measures and decision support rules.

Along the bottom of the diagram are the foundational standards, including FHIR, with the 5 layers of Foundation, Conformance, Administration, Clinical, and Reasoning, as well as expression language and integration standards including FHIRPath, Clinical Quality Language, CDS Hooks, and SMART-on-FHIR.

In the middle left are the Model Implementation Guides, typically derived from Administration and Clinical resources such as Patient, Encounter, and MedicationRequest. Model IGs are typically built to address a broad range of use cases, focused on a particular target realm or domain.

In the middle right are the Specification Implementation Guides, which derive from the FHIR Clinical Reasoning resources to provide implementation guidance and conformance requirements for the creation, distribution, evaluation, and maintenance of shareable clinical knowledge. For example, the Quality Measure IG provides guidance on and conformance requirements for the use of the FHIR Measure and Library resources to create and share clinical quality measures, Data Exchange for Quality Measures (DEQM) provides guidance for reporting quality measures, and the Clinical Practice Guidelines IG (CPG-on-FHIR) demonstrates how to build shareable computable guideline content.

And finally, at the top of the diagram, the Content Implementation Guides are FHIR Implementation Guides, but not necessarily balloted as HL7 standards, rather these use the FHIR publication toolchain to support authoring and distribution, but the content is stewarded by separate authorities such as quality agencies and guideline developers; groups that have their own governance and maintenance policies. For example, the HEDIS IG contains HEDIS quality measures expressed using FHIR Measure and Library resources, and conforming to the Quality Measure IG profiles, while the CDC Opioid Prescribing IG and WHO Antenatal Care IGs contain decision support content to streamline guideline implementation. The content IGs conform to the specification IGs, and typically make use of the model IGs to define content focused on a particular realm.

The Foundation layer of FHIR defines the core data exchange protocol. The Conformance layer defines how resources, profiles, and terminologies are represented and used. The Administration layer defines individuals, locations, organizations, and encounters. The Clinical layer defines clinical information such as observations, medications, procedures, and orders. And the Reasoning layer provides definitional artifacts like plan and activity definitions, libraries, and measures.

FHIRPath is a simple, yet powerful, model-independent expression language that is used extensively throughout FHIR to describe paths to elements on resources, and define invariants on profiles.

CQL is a superset of FHIRPath that provides an author-friendly format for the description of clinical logic, as well as a machine-friendly format for processing the logic.

CDS Hooks is an HL7 standard specification for integrating decision support services with clinical systems. It is primarily focused on provide-facing remote decision support within an EMR.

SMART-on-FHIR is an HL7 standard specification for integrating clinical applications into EMRs using FHIR.

International Patient Summary (IPS) is a set of internationally applicable FHIR profiles used to share patient information across international boundaries. As a result, it forms an excellent foundation for expressing universally applicable content guidelines such as the WHO Antenatal Care (WHO ANC).

US Core is a set of profiles focused on enabling exchange of the US Clinical Data for Interoperability (US CDI), and is supported by a broad range of EMR vendors within the US.

QI Core is a set of profiles that derives from US Core to enable quality improvement use cases such as quality measurement and decision support within the US.

To get started building a content implementation guide, refer to the Sample Content IG icon, and the Content IG icon and Colorectal Cancer icon walkthroughs.

14.4 Distribution via Repository Services

For distribution via a FHIR server, the search and read interactions defined by the FHIR infrastructure can be used for this purpose. The Library, ActivityDefinition, PlanDefinition, Questionnaire, and Measure resources can all be used to represent knowledge artifacts, and so define several search parameters specifically to enable searching based on the various attributes of a knowledge artifact. A FHIR service that supports at least searching and retrieval of these resources is then a basic Knowledge Artifact Repository. More advanced knowledge management capabilities such as change management, semantic indexing, and dependency tracking can all be provided on top of this basic infrastructure.

Some general considerations for use are documented in what follows, with a more complete and ongoing treatment provided as part of the Canonical Resource Management Infrastructure icon implementation guide.

In particular, the useContext and topic elements are intended to provide both semantic and topical indexing functionality for use in knowledge repositories. For example, the following fragment illustrates the use of the useContext element to indicate semantic usage context for an example suicide risk order set:

  <coverage>
    <patientAgeGroup>
      <coding>
        <system value="http://snomed.info/sct"/>
        <code value="133936004"/>
        <display value="Adult"/>
      </coding>
    </patientAgeGroup>
    <clinicalFocus>
      <coding>
        <system value="http://snomed.info/sct"/>
        <code value="87512008"/>
        <display value="Mild major depression"/>
      </coding>
    </clinicalFocus>
    <clinicalFocus>
      <coding>
        <system value="http://snomed.info/sct"/>
        <code value="394687007"/>
        <display value="Low suicide risk"/>
      </coding>
    </clinicalFocus>
    <targetUser>
      <coding>
        <system value="http://snomed.info/sct"/>
        <code value="309343006"/>
        <display value="Physician"/>
      </coding>
    </targetUser>
    <clinicalVenue>
      <coding>
        <system value="http://snomed.info/sct"/>
        <code value="440655000"/>
        <display value="Outpatient environment"/>
      </coding>
    </clinicalVenue>
  </coverage>

The useContext element can contain any number of characteristics that define the particular context of use for the artifact. Note that the base resource does not communicate the intended semantics when multiple useContext elements are present. To accomplish this, a core extension is defined, usagecontext-group. All use contexts within a group apply, while groups of use contexts indicate that any group applies.

In addition, the useContext element is intended to convey prescriptive semantics about the appropriate context of use for an artifact, while the topic element is intended to convey descriptive semantics suitable for indexing and searching using the topic search parameter.

The FHIR search interaction specifies that search results are returned in a Bundle, and the entries in that bundle allow a score to be specified, consistent with the Decision Support Service (DSS) relevance result. Note that the DSS score range is 1 to 100, while the FHIR score range is 0..1.

The algorithm for determining relevance is not prescribed by this guidance. When calculating relevance, implementations are encouraged to take advantage of the metadata represented within the artifact to help users understand the relevance of the returned artifacts to their search criteria.

To reduce the size of returned results and ensure efficient searching and retrieval, the Bundle returned SHOULD consist only of resources of the requested type. Dependencies of the resources returned SHOULD NOT be included unless specifically referenced by including the resources using the _include and _revinclude parameters.

Support for two different distribution use cases can be provided using the basic GET interaction:

  • Summary - Using the _summary parameter, the resources returned represent only the basic information and metadata about each matching artifact.
  • Full - Using the _include and _revinclude search parameters to include related resources in the result.

The following table lists the search criteria elements defined by the Decision Support Service (DSS) standard along with their appropriate representation in FHIR:

DSS Search Criteria FHIR Equivalent
Maximum Results _count global search parameter
Minimum Score KnowledgeArtifact.minScore search parameter
Knowledge Artifact Trait Knowledge search parameters (identifier, topic, title, description, version)
Knowledge Artifact Status KnowledgeArtifact.status search parameter
Evaluation Result Semantics Not Implemented
Data Requirements Not Implemented
Relationships to specific Knowledge Artifacts Not Implemented

Support for exclusion criteria as described in the DSS is provided by the :not search parameter modifier of FHIR.

Implementing at least the FHIR search and get interactions for the clinical reasoning resources (Library, ActivityDefinition, PlanDefinition, and Measure) is then a basic implementation of a Knowledge Artifact Repository. For example, the following GET retrieves all measures that reference a specific value set:

GET [base]/ValueSet/zika-affected-areas?_revinclude=Library:depends-on&_revinclude:recurse=Measure:depends-on

More sophisticated management functionality including semantic indexing, change management, and dependency tracking can be provided on top of this basic functionality using the same resource structures.