This page is part of the FHIR Specification (v3.2.0: R4 Ballot 1). 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
FHIR Infrastructure | Maturity Level: 1 | Informative |
A pattern to be followed by resources that represent a specific proposal, plan and/or order for some sort of action or service.
This is NOT a resource. It is not part of the FHIR schema and cannot appear directly in FHIR instances. It is a logical model that defines a pattern adhered to by other resources. This pattern serves two purposes:
A "definition" resource is a resource that describes a type of activity that *can* occur in a manner that is independent of a particular patient or subject. Examples include protocols, order sets, questionnaires, etc. It only includes definitions of activities, not of objects or roles.
This logical model is one of three common workflow patterns. The other two patterns are Event and Request. This pattern is followed by (or is intended to be followed by a number of other FHIR resources/
Both definitions and requests deal with activities that "can" occur, but requests represent a specific intention for something to occur and are bound to a specific context of subject and time, while definitions represent mere "possibility" rather than intention and are independent of a specific subject or timeframe.
This model represents a pattern. It provides a standard list of data elements with cardinalities, data types, definitions, rationale and usage notes that will ideally be adhered to by resources that fall into the "definition" workflow category. However, adherence to this pattern is not mandatory. Not all healthcare domains are the same. Concepts that may be generally applicable (and thus are included in this standard pattern) might still not be relevant everywhere or may be sufficiently uncommon that they are more appropriate to include as extensions than as core properties of the resource. Work groups are encouraged to adjust descriptions, usage notes and rationale to be specific to their resource (e.g. use the term "protocol" or "questionnaire" rather than "definition"). As well, design notes in the comments column marked with [square brackets] identifies areas where domain variation is expected and encouraged. Other variation, including differences in names, cardinalities, data types and the decision to omit an element outright are also possible, but should be discussed with the FHIR Infrastructure work group's Workflow project to ensure the rationale for non-alignment is understood, to confirm that the deviation is necessary and to identify whether any adjustments to the pattern are appropriate.
Unlike the request and event patterns, this pattern has not yet been formally reviewed, nor applied to any of its candidate resources. It should therefore be treated as a draft for comment. Alignment with this pattern (and the content of the pattern) will be discussed by work groups as part of ballot reconciliation.
This pattern provides a linkage to the W5 list of standard data elements. Resources that adhere to this pattern should ensure their w5 mappings are consistent, as is their data element ordering.
Structure
Name | Flags | Card. | Type | Description & Constraints |
---|---|---|---|---|
Definition | I | Logical | Definition Pattern | |
url | Σ | 0..1 | uri | Logical uri to reference this {{title}} (globally unique) |
identifier | Σ | 0..1 | Identifier | Business Identifier for {{title}} |
version | Σ | 0..1 | string | Business version of the {{title}} |
title | Σ | 0..1 | string | Name for this {{title}} (Human friendly) |
derivedFrom | Σ | 0..* | uri | Based on protocol or definition |
partOf | Σ | 0..* | Reference(Definition) | Part of referenced definition |
replaces | Σ | 0..* | Reference(Definition) | Request(s) replaced by this request |
status | ?!Σ | 1..1 | code | draft | active | retired | unknown PublicationStatus (Required) |
experimental | ?!Σ | 0..1 | boolean | If for testing purposes, not real usage |
subject[x] | Σ | 0..1 | Type of individual the defined service is for | |
subjectCodeableConcept | CodeableConcept | |||
subjectReference | Reference(Group) | |||
date | Σ | 0..1 | dateTime | Date status first applied |
publisher | Σ | 0..1 | Reference(Practitioner | PractitionerRole | Organization) | The name of the individual or organization that published the {{title}} |
contact | Σ | 0..* | ContactDetail | Contact details for the publisher |
useContext | Σ | 0..* | UsageContext | Content intends to support these contexts |
jurisdiction | Σ | 0..* | CodeableConcept | Intended jurisdiction for {{title}} (if applicable) Jurisdiction ValueSet (Extensible) |
description | 0..1 | markdown | Natural language description of the {{title}} | |
purpose | 0..1 | markdown | Why this {{title}} is defined | |
copyright | 0..1 | markdown | Use and/or publishing restrictions | |
approvalDate | 0..1 | date | When {{title}} approved by publisher | |
lastReviewDate | 0..1 | date | Last review date for the {{title}} | |
effectivePeriod | Σ | 0..1 | Period | The effective date range for the {{title}} |
performerType | Σ | 0..1 | CodeableConcept | Desired kind of service performer |
Documentation for this format |
UML Diagram (Legend)
Structure
Name | Flags | Card. | Type | Description & Constraints |
---|---|---|---|---|
Definition | I | Logical | Definition Pattern | |
url | Σ | 0..1 | uri | Logical uri to reference this {{title}} (globally unique) |
identifier | Σ | 0..1 | Identifier | Business Identifier for {{title}} |
version | Σ | 0..1 | string | Business version of the {{title}} |
title | Σ | 0..1 | string | Name for this {{title}} (Human friendly) |
derivedFrom | Σ | 0..* | uri | Based on protocol or definition |
partOf | Σ | 0..* | Reference(Definition) | Part of referenced definition |
replaces | Σ | 0..* | Reference(Definition) | Request(s) replaced by this request |
status | ?!Σ | 1..1 | code | draft | active | retired | unknown PublicationStatus (Required) |
experimental | ?!Σ | 0..1 | boolean | If for testing purposes, not real usage |
subject[x] | Σ | 0..1 | Type of individual the defined service is for | |
subjectCodeableConcept | CodeableConcept | |||
subjectReference | Reference(Group) | |||
date | Σ | 0..1 | dateTime | Date status first applied |
publisher | Σ | 0..1 | Reference(Practitioner | PractitionerRole | Organization) | The name of the individual or organization that published the {{title}} |
contact | Σ | 0..* | ContactDetail | Contact details for the publisher |
useContext | Σ | 0..* | UsageContext | Content intends to support these contexts |
jurisdiction | Σ | 0..* | CodeableConcept | Intended jurisdiction for {{title}} (if applicable) Jurisdiction ValueSet (Extensible) |
description | 0..1 | markdown | Natural language description of the {{title}} | |
purpose | 0..1 | markdown | Why this {{title}} is defined | |
copyright | 0..1 | markdown | Use and/or publishing restrictions | |
approvalDate | 0..1 | date | When {{title}} approved by publisher | |
lastReviewDate | 0..1 | date | Last review date for the {{title}} | |
effectivePeriod | Σ | 0..1 | Period | The effective date range for the {{title}} |
performerType | Σ | 0..1 | CodeableConcept | Desired kind of service performer |
Documentation for this format |
Path | Definition | Type | Reference |
---|---|---|---|
Definition.status | The lifecycle status of a Value Set or Concept Map. | Required | PublicationStatus |
Definition.subject[x] | Codes identifying the type of subject intended to be the recpient or focus of the defined action. These should ideally be consistent across definition resources. | Unknown | No details provided yet |
Definition.jurisdiction | Countries and regions within which this artifact is targeted for use | Extensible | Jurisdiction ValueSet |
Definition.performerType | Identifies types of practitioners, devices or others that are intended to perform a defined action. While the detailed constraints of relevant providers will vary by resource, some degree of consistency around recommended codes across request and definition resources would be desirable | Unknown | No details provided yet |
The following diagram shows the "typical" state machine diagram for resources following the Definition pattern. Note that not all resources will support all states, some resources may choose different names for certain states and some resources may introduce sub-states to the listed states. As well, additional transitions may be supported, including from terminal nodes (e.g. from "withdrawn" back to "active"). That said, most resources should align with this state machine fairly well.