- 1 GraphDefinition
- 1.1 Owning committee name
- 1.2 Committee Approval Date:
- 1.3 Contributing or Reviewing Work Groups
- 1.4 FHIR Resource Development Project Insight ID
- 1.5 Scope of coverage
- 1.6 RIM scope
- 1.7 Resource appropriateness
- 1.8 Expected implementations
- 1.9 Content sources
- 1.10 Example Scenarios
- 1.11 Resource Relationships
- 1.12 Timelines
- 1.13 gForge Users
- 1.14 When Resource Proposal Is Complete
Owning committee name
Committee Approval Date:
Contributing or Reviewing Work Groups
FHIR Resource Development Project Insight ID
Scope of coverage
The GraphDefinition resource provides 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. 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?
This is a definitional, infrastructure level resource, so it applies across all types of subjects, disciplines, delivery environments, etc.
This resource lives outside the RIM space. It's about defining how resources can be interlinked, so it's essentially a pattern for defining RMIMs in RIM terms
FHIR breaks concepts down into leaf-level constructs - i.e. resources. It is quite common in healthcare to have more complex structures such as care plans, protocols, documents, etc. that combine a lot of different types of information. We convey "instances" of these complex structures using Bundle. But there's no good way of defining such collections definitionally in FHIR yet without fully profiling every data element that is to be included.
Use-cases include the content model for documents, messages, to allow easy querying of particular subsets of data (everything related to a patient's diabetes, all of the information relating to a CarePlan, etc.
Each Graph will be independently maintained as an infrastructure resource similar to profiles and would share the same sort of metadata.
These graphs will allow providing a high-level view of "how do resources fit together to address an a particular problem space?" which is a question that is starting to be asked with increasing frequency now that the resources themselves are starting to stabilize
This will be used to help define documents and messages as well as to define queries. We will test it at Connectathon in May
The need for this artifact is driven by FHIR's resource nature and structure, so it can't really be pulled from other designs - the requirement for it is uniquely FHIR
- Define all information that is relevant for hypertension
- Define the information that should be conveyed in a particular message
- Explain how the notion of CarePlan is expressed in FHIR (not just the resource, but everything that goes around it that is relevant in the minds of clinicians and developers to the notion of CarePlan)
- Grant access to a clinician to "all information related to my diabetes" and be able to use the GraphDefinition to identify which resources fall within that definition
Overlaps with StructureDefinition - a fully defined set of profiles with AggregationMode specified can provide a "light-weight" GraphDefinition.
GraphDefinition does not reference any resources. It will likely be referenced by MessageDefinition and StructureDefinition. It may also be referenced by Contract, Consent and others (either in core or through extensions)
Include as draft in STU 3 with expectation to go STU status in the following release
When Resource Proposal Is Complete
Approved by FMG 2017-03-01 When you have completed your proposal, please send an email to FMGcontact@HL7.org