This page is part of the FHIR Specification (v3.3.0: R4 Ballot 2). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3

• Content
• Examples
• Detailed Descriptions
• Mappings
• Profiles & Extensions

5.9 Resource GraphDefinition - Content

FHIR Infrastructure Work Group

Maturity Level: 0

Draft

Compartments: Not linked to any defined compartments

A formal computable definition of a graph of resources - that is, a coherent set of resources that form a graph by following references. The Graph Definition resource defines a set and makes rules about the set.

5.9.3 Resource Content

 

Alternate definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) + see the extensions & the dependency analysis

5.9.3.1 Terminology Bindings

Path	Definition	Type	Reference
GraphDefinition.status	The lifecycle status of an artifact.	Required	PublicationStatus
GraphDefinition.jurisdiction	Countries and regions within which this artifact is targeted for use	Extensible	Jurisdiction ValueSet
GraphDefinition.start GraphDefinition.link.target.type	One of the resource types defined as part of this version of FHIR.	Required	Resource Types
GraphDefinition.link.target.compartment.use	Defines how a compartment rule is used	Required	GraphCompartmentUse
GraphDefinition.link.target.compartment.code	Identifies a compartment	Required	CompartmentType
GraphDefinition.link.target.compartment.rule	How a compartment must be linked	Required	GraphCompartmentRule

5.9.3.2 Using GraphDefinitions

The GraphDefinition resource can be used to:

• Summarize a set of profiles on resources
• Define a graph of resources to return in a query
• Define a graph of resources to include in a document
• Document rules about the relationship between a set of resources e.g. must all resources concern the same patient?

5.9.3.2.1 Summarize a set of profiles on resources

FHIR resources are relatively granular. In many/most cases, many resources are needed to handle any particular task. A typical example of this is a complex diagnostic report: it will start with a DiagnosticReport, which will link to a set of panels (Observation resources), each of which link to a set of Observation resources for atomic data items.

One way to represent this is to profile each of the resources, creating hundreds of profiles, and then leave it to the user to infer the overall pattern of the report from the detailed profiles for each observation in the report. But it's not easy to see the forest for the trees. A GraphDefinition can summarize the overall picture and present a summary to the user.

Here's an example of the kind of summary this represents. (Todo: make this an actual graph definition, and clone into the main spec)

5.9.3.2.2 Fetching a graph of resources

As another example of using many resources, to completely represent a medication dispense, an application needs not only the MedicationDispense resource, but also resources to represent the patient, provider, organizations, and the associated prescription.

A client can retrieve a single resource:

  GET [base]/MedicationDispense/example

Then, when it reads the returned resource, it can fetch the referenced resources:

  GET [base]/Patient/example
  GET [base]/Practitioner/example
  GET [base]/MedicationRequest/example
  ... etc.

This is a very inefficient way to retrieve all the required resources. An alternative approach is to do a search, and _include the required resources:

  GET [base]/MedicationDispense?_id=example
    &_include=MedicationDispense:authorizingPrescription
    &_include=MedicationDispense:subject

But scaling this approach to fetch a full package with its dependencies becomes increasingly difficult as the package gets deeper. A graph definition can be used instead to inform the server what to return as part of the search:

  GET [base]/MedicationDispense/example/$graph?graph=med-package

This is a request to return a graph of resource, using the graph definition 'med-package'. In this case, the graph definition would look approximately like this:

MedicationDispense
  .subject
  .context
  .performer.actor
  .authorizingPrescription
     .requester.agent 
  .substitution.responsibleParty

Systems may either provide a pre-defined list of graph definitions that clients may choose from, or allow clients to define their own GraphDefinition resources and then refer to them.

Server may also allow clients also pass in their own graph definition using a text representation:

  GET [base]/MedicationDispense/example/$graph?definition=Patient{managingOrganization:Organization{endpoint:Endpoint}}

See below for further details.

5.9.3.2.3 Building a document

A very similar issue applies when building a document using the $document operation. A document must include all the resources linked directly from the composition, but whether to include additional linked resources is at the discretion of the document author. How does the user inform the $document operation which linked resources to include? One option is a boolean flag for including all linked data, but this may be extensive - up to an entire patient record - and may include resources that are not desired.

An operation can use a graph definition as a parameter to the $document operation:

GET [base]/Composition/example/$document?graph=example

This tells the server to include the graph of resources defined in the example GraphDefinition - in this case, any resources referred to from lists, when the section content is a list. Alternatively, servers may allow a client to pass in a definition directly (as shown above) using the parameter definition.

5.9.3.2.4 Document Relationship rules

One important question about the use of resources is cross-resource consistency. For example, if an Observation refers to both a Patient and Encounter, does the Encounter have to refer to the same patient?

In general, the answer to this is that it usually should - the record needs to be consistent. However there are edge cases where the references may differ. For example, with regard to patient references, they may differ for:

• Health Records concerning mother and baby
• Organ Transplants
• Counselling, particularly family counselling

Other reasons for the references to differ - mixing records about the same patient from different servers, or specific records about patients mixed with records about groups of patients (particularly common in veterinarian care).

The GraphDefinition resource allows for compartment consistency rules to be made regarding the links between resources. For each link in the graph, the graph definition can make a rule about the compartment consistency. The rule can specify one of the following consistencies:

Code	Meaning
identical	The compartment must be identical (the same literal reference)
matching	The compartment must be the same - the record must be about the same patient, but the reference may be different
different	The compartment must be different
custom	The compartment rule is defined in the accompanying FHIRPath expression

Todo: how would this be validated? - where is the graph referred to?

5.9.3.3 Simple Examples

GraphDefinition can walk a graph forward through the links, which is the natural order. As an example, consider a profile on composition that wants to specify that the graph follows the section entry into a list:

    <!-- 
      starting from a Composition...
    -->
  <link>
    <!-- 
      follow and Composition.section.entry that refers to a list
    -->
    <path value="Composition.section.entry"/>
    <target>
      <type value="List"/>      
      <!-- and inside this list, follow any items -->
      <link>
        <path value="List.entry.item"/>
        <target>
          <type value="Resource"/> 
        </target>
      </link>      
    </target>
  </link>

The pattern can be extended to require that the none of the resources in this little graph reference a different patient - that is, it is a requirement when traversing the links that the patient compartment remain identical:

  <link>
    <path value="Composition.section.entry"/>
    <target>
      <type value="List"/>      
        <compartment>
          <use value="requirement"/>
          <code value="Patient"/>
          <rule value="identical"/>
        </compartment>
      </target>
      <link>
        <path value="List.entry.item"/>
        <description value="Include any list entries"/>
        <target>
          <type value="Resource"/> 
          <compartment>
            <use value="requirement"/>
            <code value="Patient"/>
            <rule value="identical"/>
          </compartment>
        </target>
      </link>      
    </target>
  </link>

Another useful approach is to walk any link * (e.g. wildcard support):

  <link>
    <!-- 
      follow all links that refers to a list
    -->
    <path value="*"/>
    <target>
      <type value="List"/>      
      <!-- and inside this list, follow any references -->
      <link>
        <path value="*"/>
        <target>
          <type value="Resource"/> 
        </target>
      </link>      
    </target>
  </link>

or you can follow any links in any resource:

  <link>
    <!-- 
      follow all links 
    -->
    <path value="*"/>
    <target>
      <type value="Resource"/>      
      <!-- and inside the target, follow any links -->
      <link>
        <path value="*"/>
        <target>
          <type value="Resource"/> 
        </target>
      </link>      
    </target>
  </link>

It's also possible to build a graph by walking links in reverse. This technique is useful, for example, when including provenance resources in a document:

  <link>
    <!-- if the path is missing <path value=""/> -->
    <target>
      <!-- 
        any provenance
      -->
      <type value="Provenance"/>
      <!--
        and specify the search parameters to include 
        all the provenances that refer to this resource
      -->
      <params value="target={ref}"/>      
    </target>
  </link>

5.9.3.3.1 Text Representation

For convenience, a graph definition may be represented using a text short hand form, loosely based on the graphQL language. A graph definition is introduced by the name of the Resource (GraphDefinition.start, followed by an optional profile in parentheses (GraphDefinition.profile, then a group of links, surrounded by { and }:

Patient(http://hl7.org/fhir/us/core/Patient) { 
}

Between the brackets are one or more links (GraphDefinition.link), separated by commas. Links statements can either be path-based look ups, or a search to perform a reverse lookup:

Patient { 
  managingOrganization : Organization,
  generalPractitioner : Practitioner,
  search Observation?patient={ref}
}

The format for a path-based look up is:

  [path] cardinality [min]..[max] '[description]' : [ResoureType rules]

where:

• path = GraphDefinition.link.path
• cardinality [min]..[max] is optional, and min = GraphDefinition.link.min and max = GraphDefinition.link.max
• description is optional, and = GraphDefinition.link.description

The resource type rules statement consists of one or more of the following, separated by ; characters:

  [ResourceType] (profile)  

where:

• ResourceType = GraphDefinition.link.target.type
• profile is optional, and = GraphDefinition.link.target.profile
• description is optional, and = GraphDefinition.link.description

In addition, the resource type rule may be followed by a links section, surrounded by {}, with the content as described above.

Search statements for reverse look ups have a slightly different format:

Patient{ 
  search [ResourceType]?[params] cardinality [min]..[max] '[description]' 
}

where:

• ResourceType = GraphDefinition.link.target.type
• params = GraphDefinition.link.target.params
• cardinality [min]..[max] is optional, and min = GraphDefinition.link.min and max = GraphDefinition.link.max
• description is optional, and = GraphDefinition.link.description

In this format, the amount of whitespace, and its form, is irrelevant. For the purposes of clarity, the examples here are laid out on different lines, but this is not required. When a GraphDefinition is used as a parameter in a url, no whitespace is used.

Here is a full example that uses all the features of the syntax:

Patient(http://hl7.org/fhir/us/core/Patient) { 
  managingOrganization cardinality 0..1 'description of item' : 
    Organization(http://hl7.org/fhir/us/core/Organization) { 
      endpoint : Endpoint 
    };
    Basic;
    Group { 
      item : Patient 
    },
  generalPractitioner : Organization,
  search Observation?patient={ref} cardinality 0..10 'Observations for the patient' {
    performer : Practitioner,
    related.where(type='has-member').target : Observation require matching Patient,
    related.where(type='derived-from').target : Observation where identical Patient,
    related.where(type='sequel-to').target : Observation where different Patient,
    related.where(type='qualified-by').target : Observation where custom Patient = path
  }
}

5.9.4 Search Parameters

Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

Name	Type	Description	Expression	In Common
date	date	The graph definition publication date	GraphDefinition.date
description	string	The description of the graph definition	GraphDefinition.description
jurisdiction	token	Intended jurisdiction for the graph definition	GraphDefinition.jurisdiction
name	string	Computationally friendly name of the graph definition	GraphDefinition.name
publisher	string	Name of the publisher of the graph definition	GraphDefinition.publisher
start	token	Type of resource at which the graph starts	GraphDefinition.start
status	token	The current status of the graph definition	GraphDefinition.status
url	uri	The uri that identifies the graph definition	GraphDefinition.url
version	token	The business version of the graph definition	GraphDefinition.version