• Content
• Examples
• Detailed Descriptions
• Mappings
• Profiles & Extensions
• R3 R4 Conversions
• Search Params

5.9 5.10 Resource GraphDefinition - Content

FHIR Infrastructure Work Group

Maturity Level : 1

Trial Use

Security Category : Anonymous

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 5.10.3 References to this Resource

This resource is referenced by

• Resource References: MessageDefinition . This resource does not implement any patterns.
• Extension References: graphConstraint

5.9.4 5.10.4 Resource Content

 

See the Profiles & Extensions and the alternate Additional definitions: Master Definition XML + JSON , XML Schema / Schematron + JSON Schema , ShEx (for Turtle ) + see , the extensions spreadsheet version & the dependency analysis

5.9.4.1 5.10.4.1 Terminology Bindings

GraphDefinition.status GraphDefinition.jurisdiction GraphDefinition.start GraphDefinition.link.target.type GraphDefinition.link.target.compartment.code GraphDefinition.link.target.compartment.rule

Path	Definition	Type	Reference
GraphDefinition.versionAlgorithm[x]	Indicates the mechanism used to compare versions to determine which is more current.	Required Extensible	PublicationStatus VersionAlgorithm
GraphDefinition.status	The lifecycle status of an artifact.	Extensible Required	Jurisdiction ValueSet PublicationStatus
GraphDefinition.jurisdiction	This value set defines a base set of codes for country, country subdivision and region for indicating where a resource is intended to be used. Note: The codes for countries and country subdivisions are taken from ISO 3166 while the codes for "supra-national" regions are from UN Standard country or area codes for statistical use (M49) .	Required Extensible	ResourceType JurisdictionValueSet
GraphDefinition.node.type	All fhir data types (including abstract resources)	Required	ResourceType AllResourceTypes
GraphDefinition.link.target.compartment.use GraphDefinition.link.compartment.use	Defines how a compartment rule is used.	Required	GraphCompartmentUse
GraphDefinition.link.compartment.rule	How a compartment must be linked.	Required	CompartmentType GraphCompartmentRule
GraphDefinition.link.compartment.code	Which type a compartment definition describes.	Required	GraphCompartmentRule CompartmentType

5.9.4.2 5.10.4.2 Constraints

5.9.4.3 5.10.4.3 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.4.3.1 5.10.4.3.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.4.3.2 5.10.4.3.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 with the resource using the $graph operation :

  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.4.3.3 5.10.4.3.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.4.3.4 5.10.4.3.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.4.4 5.10.4.4 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...
    -->

<!-- this graph starts with a composition. We don't care what the specific profile is
     (though the statement above 'this case doesn't cross patients' implies that we do care a little) -->
  <start value="composition1"/>
  
  <node>
    <nodeId value="composition1"/>
    <description value="The base composition"/>
    <type value="Composition"/>
    <profile value="http://hl7.org/fhir/StructureDefinition/clinicaldocument"/>
  </node>
  <node>
    <nodeId value="list1"/>
    <description value="A list resource that a section entry reference points to"/>
    <type value="List"/>
  </node>
  <node>
    <nodeId value="resN"/>
    <description value="Generic resource that's the target of a list reference"/>
    <type value="Resource"/>
  </node>

  <!-- define the section -> list link -->

  <link>
    <description value="Link from Composition.section to list"/>
    <sourceId value="composition1"/>
    <!-- any section entry. Todo: this recurses; are we profiling this at all levels? --> 
    <path value="Composition.section.entry"/>

    <!-- 
      follow and Composition.section.entry that refers to a list

      one target. This graph is not making rules about the content of the section entries - that
      would be done in a profile. it's just saying, if you see a reference to a list in a section
      entry, these are the rules that describe the graph

    -->
    <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>

    <targetId value="list1"/>
  </link>    

  <!-- and from the list, any references -->
  <link>
    <description value="Include any list entries"/>
    <sourceId value="list1"/>
    <path value="List.entry.item"/>
    <targetId value="resN"/>
  </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:

  <!-- define the section -> list link -->

  <link>
    <description value="Link from Composition.section to list"/>
    <sourceId value="composition1"/>
    <!-- any section entry. Todo: this recurses; are we profiling this at all levels? --> 

    <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>

    <!-- 
      one target. This graph is not making rules about the content of the section entries - that
      would be done in a profile. it's just saying, if you see a reference to a list in a section
      entry, these are the rules that describe the graph
    -->
    <targetId value="list1"/>
    <compartment>
      <use value="requirement"/>
      <code value="Patient"/>
      <rule value="identical"/>
    </compartment>
  </link>    

  <!-- and from the list, any references -->
  <link>
    <description value="Include any list entries"/>
    <sourceId value="list1"/>
    <path value="List.entry.item"/>
    <targetId value="resN"/>
    <compartment>
      <use value="requirement"/>
      <code value="Patient"/>
      <rule value="identical"/>
    </compartment>

  </link>

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

  <link>
    <sourceId value="comp1">

    <!-- 
      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>

    <targetId value="list1">

  </link>
  <!-- and inside this list, follow any references -->
  <link>
    <sourceId value="list1">
    <path value="*"/>
    <targetId value="resN"/>
  </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>

    <targetid value="resN"/>

  </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>
    <sourceId value="obs1"/>

    <!-- 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>

    <targetId value="prov"/>  <!-- any provenance -->
    <!--
      and specify the search parameters to include 
      all the provenances that refer to this resource
    -->
    <params value="target={ref}"/>      

  </link>

5.9.4.4.1 5.10.4.4.1 Text Representation

For convenience, a graph definition may be represented using a text short hand form, loosely based on the graphQL language . form. A graph definition is introduced by two or more node statements:

node start comp1 'The base composition' = Composition (http://hl7.org/fhir/StructureDefinition/clinicaldocument);
node list1 'A list resource that a section entry reference points to' = List;
node resN 'Generic resource that's the target of a list reference' = Resource;

Each node declaration starts with the name of the Resource ( fixed word GraphDefinition.start , node followed by an optional profile in parentheses ( the nodeId, the node description, GraphDefinition.profile = , then the node type, and then, if the node has a group profile, the profile value in brackets. One of links, surrounded by { and } : the nodes have the key word "start"

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

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

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

link 'Link from Composition.section to list' = comp1[Composition.section.entry] -> list1 requires identical patient;
link 'Include any list entries' = list1[List.entry.item] -> resN requires identical patient;

The format for a path-based look up link is:

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

link '{description}' {min}..{max} = sourceId[{path}:{sliceName}] {targetId}?{params} {resource-compartment-rules};

where:

• path = GraphDefinition.link.path cardinality [min]..[max] is optional, and min = GraphDefinition.link.min description, min, max, path, sliceName, params and max = GraphDefinition.link.max resource-type-rules are all optional
• description resource-compartment-rules is optional, present if there's a compartent, 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 syntax is optional, and = GraphDefinition.link.description In addition, {use} {rule} {code}. If 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 'custom' then the syntax is optional, and = GraphDefinition.link.description '=' '{fhirpath}' '{description}'

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

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

node pat = Patient;
node org = Organization;
node org2 = Organization;
node ept = EndPoint;
node prac = Practitioner;
node grp = Group;


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
  }
}

link 'patient managing org' 0..1 = pat[managingOrganization] -> org;
link = org[endpoint] -> ept
link 'groups patient is in' = pat -> grp?item={ref}
link 'registered GP' = pat[generalPractitioner] -> org;
link 'Observations for the patient' = pat -> org?patient={ref};
link = org[performer] -> prac;
link = org[related.where(type='has-member').target] -> org2 requires matching Patient;
link = org[related.where(type='derived-from').target] -> org2 requires identical Patient;
link = org[related.where(type='sequel-to').target] -> org2 requires different Organization;
link = org[related.where(type='qualified-by').target] -> org2 requires custom Patient = path;

5.9.5 5.10.5 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
context	token	A use context assigned to the graph definition	(GraphDefinition.useContext.value as CodeableConcept)	30 Resources
context-quantity	quantity	A quantity- or range-valued use context assigned to the graph definition	(GraphDefinition.useContext.value as Quantity) | (GraphDefinition.useContext.value as Range)	30 Resources
context-type	token	A type of use context assigned to the graph definition	GraphDefinition.useContext.code	30 Resources
context-type-quantity	composite	A use context type and quantity- or range-based value assigned to the graph definition	On GraphDefinition.useContext:   context-type: code   context-quantity: value.as(Quantity) value.ofType(Quantity) | value.as(Range) value.ofType(Range)	30 Resources
context-type-value	composite	A use context type and value assigned to the graph definition	On GraphDefinition.useContext:   context-type: code   context: value.as(CodeableConcept) value.ofType(CodeableConcept)	30 Resources
date	date	The graph definition publication date	GraphDefinition.date	30 Resources
description	string	The description of the graph definition	GraphDefinition.description	28 Resources
jurisdiction	token	Intended jurisdiction for the graph definition	GraphDefinition.jurisdiction	26 Resources
name	string	Computationally friendly name of the graph definition	GraphDefinition.name	26 Resources
publisher	string	Name of the publisher of the graph definition	GraphDefinition.publisher	30 Resources
start	token	Type of resource at which the graph starts	GraphDefinition.start
status	token	The current status of the graph definition	GraphDefinition.status	34 Resources
url	uri	The uri that identifies the graph definition	GraphDefinition.url	33 Resources
version	token	The business version of the graph definition	GraphDefinition.version	30 Resources