FHIR Release 3 (STU) Current Build

2.28 2.26 Base Resource Definitions

http://www.hl7.org/Special/committees/fiwg/index.cfm Maturity Level : 5 N   Normative (from v4.0.0) Compartments : Not linked to any defined compartments

This specification defines a series of different types of resource that can be used to exchange and/or store data in order to solve a wide range of healthcare related problems, both clinical and administrative. In addition, this specification defines several different ways of exchanging the resources.

A resource is an entity that:

  • has a known identity (a URL) by which it can be addressed
  • identifies itself as one of the types of resource defined in this specification
  • contains a set of structured data items as described by the definition of the resource type
  • has an identified version that changes if the contents of the resource change

Resources have multiple representations .

The following optional elements and properties are defined for all resources:

  • An identity
  • Meta data
  • A base language
  • A reference to "Implicit Rules"

Most resources are derived from Domain Resources DomainResource - so they also can contain text, contained resources, extensions, and data elements specific to the particular domain of the resource. There is a special type of resource called Bundle for collections of resources.

Note: there is documentation for the Structure , UML , XML , and JSON representations of the resource structure.

Structure

Name Flags Card. Type Description & Constraints doco
. . Resource N n/a Base Resource
. . . id Σ 0..1 id Logical id of this artifact
. . . meta Σ 0..1 Meta Metadata about the resource
. . . implicitRules ?! Σ 0..1 uri A set of rules under which this content was created
. . . language 0..1 code Language of the resource content
Common Languages ( Extensible Preferred but limited to All Languages AllLanguages )

doco Documentation for this format

XML Template

<[name] xmlns="http://hl7.org/fhir"> doco
 <!-- from Element: extension -->
 <id value="[id]"/><!-- 0..1 Logical id of this artifact -->
 <</meta>
 <

 <meta><!-- 0..1 Meta Metadata about the resource --></meta>
 <implicitRules value="[uri]"/><!-- 0..1 A set of rules under which this content was created -->

 <language value="[code]"/><!-- 0..1 Language of the resource content -->
</[name]>

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .
@prefix fhir: <http://hl7.org/fhir/> .doco
[ a fhir:[name];
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

[

 # from Element: Element.extension
  fhir:Resource.id [ id ]; # 0..1 Logical id of this artifact
  fhir:
  fhir:

  fhir:Resource.meta [ Meta ]; # 0..1 Metadata about the resource
  fhir:Resource.implicitRules [ uri ]; # 0..1 A set of rules under which this content was created

  fhir:Resource.language [ code ]; # 0..1 Language of the resource content
]

Structure

Name Flags Card. Type Description & Constraints doco
. . Resource N n/a Base Resource
. . . id Σ 0..1 id Logical id of this artifact
. . . meta Σ 0..1 Meta Metadata about the resource
. . . implicitRules ?! Σ 0..1 uri A set of rules under which this content was created
. . . language 0..1 code Language of the resource content
Common Languages ( Extensible Preferred but limited to All Languages AllLanguages )

doco Documentation for this format

XML Template

<[name] xmlns="http://hl7.org/fhir"> doco
 <!-- from Element: extension -->
 <id value="[id]"/><!-- 0..1 Logical id of this artifact -->
 <</meta>
 <

 <meta><!-- 0..1 Meta Metadata about the resource --></meta>
 <implicitRules value="[uri]"/><!-- 0..1 A set of rules under which this content was created -->

 <language value="[code]"/><!-- 0..1 Language of the resource content -->
</[name]>

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .
@prefix fhir: <http://hl7.org/fhir/> .doco
[ a fhir:[name];
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

[

 # from Element: Element.extension
  fhir:Resource.id [ id ]; # 0..1 Logical id of this artifact
  fhir:
  fhir:

  fhir:Resource.meta [ Meta ]; # 0..1 Metadata about the resource
  fhir:Resource.implicitRules [ uri ]; # 0..1 A set of rules under which this content was created

  fhir:Resource.language [ code ]; # 0..1 Language of the resource content
]
Path Definition Type Reference
Resource.language A human language. Extensible Preferred , but limited to All Languages AllLanguages Common Languages CommonLanguages

There are two different ways to identify a resource:

  • By a "Location" URL that identifies where is can be accessed (based on the "Logical ID"). This location will be change as it is copied/moved around
  • By some inherent identifier ("Business Identifier" or "Canonical URL") that is part of the resource and remains fixed as it is copied/moved around

Each resource has an "id" id element which contains the logical identity "logical id" of the resource assigned by the server responsible for storing it. Resources always have a known identity logical id except for the a few special case cases (e.g. when a new resource is being sent to a server to assign an identity ( a logical id in the create interaction ). The logical identity id is unique within the space of all resources of the same type on the same server. Once assigned, assigned by the identity server, the id is never changed. Note that if the resource is copied to another server, the copy might not be able to retain the same logical identity.

The unique identifier location of a resource instance is an absolute URI constructed from the server base address at which the instance is found, the resource type and the Logical ID, such as http://test.fhir.org/rest/Patient/123 (where 123 is the Logical Id). Id of a Patient resource). When the literal identity location is an HTTP address, this address can generally be used to retrieve or manipulate the resource. Note that implementations SHOULD NOT assume that the identity location of a resource is always resolvable to a literal an accessible server - it may be temporarily unavailable, or not available by policy (e.g. firewalls) or in some cases, it may might not actually exist (e.g. use of resource outside a RESTful environment). Resources reference each other by their identity. location. These references are allowed to be absolute or relative (see Resource References for further discussion). Copying or moving resources

When a resource is copied from one server to another means that resources acquire a server, the copy might or might not keep the same logical id on the new identity. server. This depends on replication and server policy. For further details, see Managing Resource Identity . (including "Consistent Resource Identification").

Logical ids (and therefore literal identities) locations) are case sensitive. Logical Ids are always opaque, and external systems need not and should not attempt to determine their internal structure. A logical id SHALL always be represented in the same way in resource references and URLs. Ids can be up to 64 characters long, and contain any combination of upper and lowercase ASCII letters, numerals, "-" and ".".

In some contexts, resources are not associated with location on a RESTful server, either because they are only created transiently for transfer between systems, or the systems are not using RESTful servers. In these cases, resources may be assigned some kind of location anyway, for purposes of consistency, or they might not have an assigned logical id, and they are identified based on other kinds of identifiers. See Resolving references in Bundles for one method of using resources not associated with RESTful servers.

In addition to Although the logical id and literal identity discussed above, many resources contain an element named "identifier", which, if populated, contains a different kind of identifier. As resources are copied a resource changes as it moves from server to server, their literal identity will change, and their logical id may change. However, all copies of the resource refer to the same underlying concept, and this concept may also be represented in other formats (variously, HL7 v2 , CDA , XDS, and many more). Each representation carries the same identifier common identifiers that identifies it identify the underlying concept (also called "real world entity") consistently across all contexts of use. This is known as the business identifier, identifier , and is found in the identifier element. In a few resources, there is a url element that serves a similar purpose, but is constrained to be a literal URL for implementation reasons. element, which has the type Identifier .

All resources that have an identifier element support searching by the identifier, so that records can be located by that method. So if an HL7 v2 message has the following OBR:

OBR|1|845439^GHH OE|1045813^GHH LAB|1554-5^GLUCOSE^LN|||200202150730|...

Then the DiagnosticReport it represents can be located using the following query:

 GET [base]/DiagnosticReport?identifier=1045813

If Most resources have a FHIR logical master server, the system on which the record first is created, and which manages the record directly. In the master system, the Logical ID might be the same value found in the business identifier since the master server can enforce business practices that make for stable identifiers. This is usually not a stable server safe practice on secondary systems which are not in a position to enforce their required identifier consistency.

Some resource types have a defined element url which is the 'canonical URL' that always identifies the resource. This is a special kind of Business Identifier. Note that the element actually contains a URI, but is named url for legacy reasons.

The canonical master source URL serves as a stable logical identifier for the definition resource, and is the preferred way to reference a conformance or knowledge resource . The canonical URL SHOULD also resolve to the location where the master copy of the artifact is found, though it is not always possible to arrange this. The canonical URL SHALL NOT refer to some other resource (though it may resolve to a concept, different version of the business identifier same resource).

See Canonical references for all further discussion of canonical references and the canonical data type . The following resources have canonical URLs:

Business Identifiers are the preferred basis to recognize the same content on different systems. For example:

  GET http://a.company.example.com/Patient/23
  
  <Patient xmlns="http://hl7.org/fhir">
    <id value="23"/>
    <identifier>  
      <system value="http://a.particular.system/identifier"/>
      <value value="123456"/>
    </identifier>
  </Patient>
  GET http://other.company.example.com/fhir/Patient/5860200e-0ee3-42f5-8095-506e18dc9ca2
  
  <Patient xmlns="http://hl7.org/fhir">
    <id value="5860200e-0ee3-42f5-8095-506e18dc9ca2"/>
    <identifier>  
      <system value="http://a.particular.system/identifier"/>
      <value value="123456"/>
    </identifier>
  </Patient>

Given that the identifier is the same, the patient resources are understood to mean that they describe the same patient. For this reason, systems may SHOULD:

  • Only assign identifiers to resources when they uniquely identify the real world entity that the resources match (e.g. do not use account numbers as patient identifiers when multiple different patients share the same account number)
  • Preserve identifiers as much as possible and not throw them away. Even if the identifiers are not useful to the system itself, they are likely to be useful to downstream consumers
  • When serving resources, use consistent identifiers from the master persistent store where ever possible (e.g. when a resource is created from a primary record, populate the identifier, and store the identifier somewhere so the same identifier is used next time)

Following these practices will make for consistent identification of concepts and real-world entities across healthcare eco-systems. For example, medication orders can be represented as MedicationRequest and MedicationStatement . Some systems - primary sources - will provide the literal identity medication order as a MedicationRequest while other secondary systems will provide them as a MedicationStatement. Any system processing the resources will need to reconcile these, and the presence of consistent identifiers will considerably simplify the reconciliation process.

Note that this specification provides two other related methods by which common source derivation can be indicated:

The granularity of Provenance.entity.what[x] / Resource.meta.source is not fixed to a single resource - multiple resources can be derived from a single source entity (e.g. a single CDA document), so applications need to be careful assuming that matching entity source information means that the resources are identifying the same real world concept.

A reference to a custom agreement that describes how the resource is being used (e.g. an implementation guide ) that was followed when the resource was constructed, where the implementation guide must be known and understood in order to safely processing the content.

Asserting this rule set restricts the content to be only understood by a limited set of trading partners. This inherently limits the usefulness of the data in the long term, and should be avoided where possible. However, the existing health eco-system is highly fractured, and not yet ready to define, collect, and exchange data in a generally exchangeable sense.

Note that resources are almost always constructed following some custom agreement. Best practice - which is recommended throughout the conformance resources - is that such agreements make all knowledge about the content of the resource explicit in the content of the resource; if custom agreements follow this advice, and declare their extensions as required, then it is not necessary to understand the agreement in order to safely process the resource content. For this reason, use of implicitRules is rare.

Each resource may have a language element that specifies the base language of the content using a code defined in BCP 47 . The language element is provided to support indexing and accessibility (e.g. text-to-speech use the language tag).

If a language is specified, it should also be specified on the master server. Narrative Text . The html language tag in the narrative is used when processing the narrative. The language tag on the resource is provided so that applications processing the data in the resource can specify the language of any alternate presentations generated from the data.

There is no default language, though one may be inferred from the context of use. Not all of the content of the resource has to be in the specified language. Multiple languages can be supported.

Any valid language code as defined in BCP 47 is valid. The language code system is complex, with parts for Primary Language, Script, Region, and other variants and extensions. In order to simplify implementations, the language element has a preferred binding to an enumerated list of common language codes encountered in applications, with translations, and also a maximum binding of any language; this allows most applications to simply use a look up table, without preventing the use of any language code.

Each resource contains an element "meta", of type "Meta", which is a set of metadata that provides technical and workflow context to the resource. The metadata items are all optional, though some or all of them may be required in particular implementations or contexts of use.

Metadata Item Type Usage
versionId (0..1) id Changes each time the content of the resource changes. Can be referenced in a resource reference . Can be used to ensure that updates are based on the latest version of the resource.
The version can be globally unique, or scoped by the Logical Id of the resource. Version identifiers are generally either a serially incrementing id scoped by the logical id, or a uuid, though neither of these approaches is required. There is no fixed order for version ids - clients cannot assume that a versionId that comes after another one either numerically or alphabetically represents a later version. The same versionId can never be used for more than one version of the same resource.
On the RESTful API: On receiving a write operation , the server SHALL update this item to the current value, or remove it. Note that servers SHOULD support versions, but some are unable to
lastUpdated (0..1) instant If populated, this value changes each time the content of the resource changes. it It can be used by a system or a human to judge the currency of the resource content. Note that version aware updates do not depend on this element. Note that a timezone code extension may be present on Meta.lastUpdated. If present, the timezone code applies to the server copy of the resource, and not necessarily to other time related elements within the resource even if the timezone offsets are the same.
On the RESTful API: On receiving a write operation , the server SHALL update this item to the current time on the server
source (0..1) uri A uri that identifies the source system of the resource. This provides a minimal amount of Provenance information that can be used to track or differentiate the source of information in the resource. The source may identify another FHIR server, document, message, database, etc. In the provenance resource, this corresponds to Provenance.entity.what[x] . The exact use of the source (and the implied Provenance.entity.role) is left to implementer discretion. Only one nominated source is allowed; for additional provenance details, a full Provenance resource should be used.
On the RESTful API: On receiving a write operation , the server SHOULD generally leave this element unchanged, unless applicable business rules, along with available provenance, dictate otherwise
profile (0..*) uri canonical An assertion that the content conforms to a resource profile (a StructureDefinition ). See Extending and Restricting Resources for further discussion. Can be changed as profiles and value sets change or the system rechecks conformance conformance. The profile can be used to indicate which version(s) of FHIR a resource conforms to .
On the RESTful API: On receiving a write operation , the server MAY elect to remove invalid claims, SHOULD retain claims that are correct or untested, and MAY add additional claims it believes are valid
security (0..*) Coding Security labels applied to this resource. These tags connect resources in specific ways to the overall security policy and infrastructure. Security tags can be updated when the resource changes, or whenever the security sub-system chooses to to.
On the RESTful API: On receiving a write operation , the server SHOULD preserve the labels unless applicable business rules dictate otherwise
tag (0..*) Coding Tags applied to this resource. Tags are used to relate resources to process and workflow. Applications are not required to consider the tags when interpreting the meaning of a resource.
On the RESTful API: On receiving a write operation , the server SHOULD preserve the labels unless applicable business rules dictate otherwise

Structure

Name Flags Card. Type Description & Constraints doco
. . Meta Σ N Element Metadata about a resource
Elements defined in Ancestors: id , extension
. . . versionId Σ 0..1 id Version specific identifier
. . . lastUpdated Σ 0..1 instant When the resource version last changed
. . . profile source Σ 0..* 0..1 uri Identifies where the resource comes from
... profile Σ 0..* canonical ( StructureDefinition ) Profiles this resource claims to conform to
. . . security Σ 0..* Coding Security Labels applied to this resource
All Security Labels SecurityLabels ( Extensible )
. . . tag Σ 0..* Coding Tags applied to this resource
Common Tags ( Example )

doco Documentation for this format

UML Diagram ( Legend )

Element Extensions - as described for all elements: additional information that is not part of the basic definition of the resource / type extension : Extension 0..* Meta The version specific identifier, as it appears in the version portion of the URL. This values value changes when the resource is created, updated, or deleted versionId : id [0..1] When the resource last changed - e.g. when the version changed lastUpdated : instant [0..1] A uri that identifies the source system of the resource. This provides a minimal amount of [[[Provenance]]] information that can be used to track or differentiate the source of information in the resource. The source may identify another FHIR server, document, message, database, etc source : uri [0..1] A list of profiles (references to [[[StructureDefinition]]] resources) that this resource claims to conform to. The URL is a reference to [[[StructureDefinition.url]]] profile : uri canonical [0..*] « StructureDefinition » Security labels applied to this resource. These tags connect specific resources to the overall security policy and infrastructure security : Coding [0..*] « Security Labels from the Healthcare Privacy and Security Classification System. (Strength=Extensible) All Security Labels + » Tags applied to this resource. Tags are intended to be used to identify and relate resources to process and workflow, and applications are not required to consider the tags when interpreting the meaning of a resource tag : Coding [0..*] « Codes that represent various types of tags, commonly workflow-related; e.g. "Needs review by Dr. Jones" Jones". (Strength=Example) Common Tags CommonTags ?? »

XML Template

<meta xmlns="http://hl7.org/fhir">
 <!-- from Element: extension -->
 <

 <versionId value="[id]"/><!-- 0..1 Version specific identifier -->

 <lastUpdated value="[instant]"/><!-- 0..1 When the resource version last changed -->
 <

 <source value="[uri]"/><!-- 0..1 Identifies where the resource comes from -->
 <profile><!-- 0..* canonical(StructureDefinition) Profiles this resource claims to conform to --></profile>

 <security><!-- 0..* Coding Security Labels applied to this resource --></security>
 <tag><!-- 0..* Coding Tags applied to this resource --></tag>
</meta>

Turtle Template


@prefix fhir: <http://hl7.org/fhir/> .
[
 # from Element: Element.extension
  fhir:

  fhir:Meta.versionId [ id ]; # 0..1 Version specific identifier

  fhir:Meta.lastUpdated [ instant ]; # 0..1 When the resource version last changed
  fhir:

  fhir:Meta.source [ uri ]; # 0..1 Identifies where the resource comes from
  fhir:Meta.profile [ canonical(StructureDefinition) ], ... ; # 0..* Profiles this resource claims to conform to

  fhir:Meta.security [ Coding ], ... ; # 0..* Security Labels applied to this resource
  fhir:Meta.tag [ Coding ], ... ; # 0..* Tags applied to this resource
]

Changes since DSTU2 Release 3


Meta
Meta.source
  • No Changes Added Element
Meta.profile
  • Type changed from uri to canonical(StructureDefinition)

See the Full Difference for further information

Structure

Name Flags Card. Type Description & Constraints doco
. . Meta Σ N Element Metadata about a resource
Elements defined in Ancestors: id , extension
. . . versionId Σ 0..1 id Version specific identifier
. . . lastUpdated Σ 0..1 instant When the resource version last changed
. . . profile source Σ 0..* 0..1 uri Identifies where the resource comes from
... profile Σ 0..* canonical ( StructureDefinition ) Profiles this resource claims to conform to
. . . security Σ 0..* Coding Security Labels applied to this resource
All Security Labels SecurityLabels ( Extensible )
. . . tag Σ 0..* Coding Tags applied to this resource
Common Tags ( Example )

doco Documentation for this format

UML Diagram ( Legend )

Element Extensions - as described for all elements: additional information that is not part of the basic definition of the resource / type extension : Extension 0..* Meta The version specific identifier, as it appears in the version portion of the URL. This values value changes when the resource is created, updated, or deleted versionId : id [0..1] When the resource last changed - e.g. when the version changed lastUpdated : instant [0..1] A uri that identifies the source system of the resource. This provides a minimal amount of [[[Provenance]]] information that can be used to track or differentiate the source of information in the resource. The source may identify another FHIR server, document, message, database, etc source : uri [0..1] A list of profiles (references to [[[StructureDefinition]]] resources) that this resource claims to conform to. The URL is a reference to [[[StructureDefinition.url]]] profile : uri canonical [0..*] « StructureDefinition » Security labels applied to this resource. These tags connect specific resources to the overall security policy and infrastructure security : Coding [0..*] « Security Labels from the Healthcare Privacy and Security Classification System. (Strength=Extensible) All Security Labels + » Tags applied to this resource. Tags are intended to be used to identify and relate resources to process and workflow, and applications are not required to consider the tags when interpreting the meaning of a resource tag : Coding [0..*] « Codes that represent various types of tags, commonly workflow-related; e.g. "Needs review by Dr. Jones" Jones". (Strength=Example) Common Tags CommonTags ?? »

XML Template

<meta xmlns="http://hl7.org/fhir">
 <!-- from Element: extension -->
 <

 <versionId value="[id]"/><!-- 0..1 Version specific identifier -->

 <lastUpdated value="[instant]"/><!-- 0..1 When the resource version last changed -->
 <

 <source value="[uri]"/><!-- 0..1 Identifies where the resource comes from -->
 <profile><!-- 0..* canonical(StructureDefinition) Profiles this resource claims to conform to --></profile>

 <security><!-- 0..* Coding Security Labels applied to this resource --></security>
 <tag><!-- 0..* Coding Tags applied to this resource --></tag>
</meta>

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .
[
 # from Element: Element.extension
  fhir:

  fhir:Meta.versionId [ id ]; # 0..1 Version specific identifier

  fhir:Meta.lastUpdated [ instant ]; # 0..1 When the resource version last changed
  fhir:

  fhir:Meta.source [ uri ]; # 0..1 Identifies where the resource comes from
  fhir:Meta.profile [ canonical(StructureDefinition) ], ... ; # 0..* Profiles this resource claims to conform to

  fhir:Meta.security [ Coding ], ... ; # 0..* Security Labels applied to this resource
  fhir:Meta.tag [ Coding ], ... ; # 0..* Tags applied to this resource
]

Changes since DSTU2 Release 3

Meta
Meta.source
  • No Changes Added Element
Meta.profile
  • Type changed from uri to canonical(StructureDefinition)

See the Full Difference for further information

Note that the RESTful API defines some Operations that provide direct read and write access to the meta element.

There are 3 different versions of interest for a resource:

  1. The Record Version: changes each time the resource changes (usually managed by a server)
  2. The Business version: changes each time the content in the resources changes (managed by a human author or by business policy)
  3. The FHIR Version: the version of FHIR in which the resource is represented (controlled by the author of the resource)

Record (Resource) Version

All resources are conceptually versioned, and each resource sits at the head of a linear list of past versions. The past versions are superseded by the current version, and only available for audit/integrity purposes. The current version is e.g. http://acme.org/fhir/ResourceType/id123, and a past version would be http://acme.org/fhir/ResourceType/id123/_history/v2.

Note that there's no requirement for servers to keep a history. The history interaction is provided for where this is an appropriate service to provide. However, whether a server keeps them or not, past versions are dead and gone. The current version of the resource is in the Resource.meta.versionId . For a value set this would be:

<ValueSet>
  <meta>
    <versionId value="v2"/>
  </meta>
</ValueSet>

That version The versionId changes every time the server updates the resource and writes a new version over the top of an existing one.

Business Version

Some resources have another version marker in them. For instance, ValueSet has another version in it:

<ValueSet>
  <url value="http://acme.com/fhir/ValueSet/example"/>
  <version value="2.0"/>
</ValueSet>

This says that this is version 2.0 of the 'example' value set. This is the business version of the value set, the one that humans get involved with. These 2 versions elements have quite different lifecycles. To illustrate, take these cases:

  1. A value set is posted to a server (POST [base]/ValueSet) with ValueSet.url = "http://acme.com/valuesets/example". This is identified as the 1st version of the value set (ValueSet.version = 1). When the server gets it, it assigns an identity e.g. ValueSet.id = x1, and ValueSet.meta.versionId = 1. Later, another user creates a revised version of the value set, and this is called version 2. It is committed to the server as an update (PUT [base]/ValueSet/x1).
    Now, ValueSet.url = http://acme.com/valuesets/example, ValueSet.id = x1, ValueSet.version = 2 and ValueSet.meta.versionId = 2
  2. A value set is posted to a server (POST [base]/ValueSet) with ValueSet.url = "http://acme.com/valuesets/example". This is identified as the 1st version of the value set (ValueSet.version = 1). When the server gets it, it assigns an identity e.g. ValueSet.id = x1, and ValueSet.meta.versionId = 1. Then a typo is found in the definition, so this is fixed, but it's still v1 of the value set. This is PUT to [base]/ValueSet/x1. Now, ValueSet.url = http://acme.com/valuesets/example, ValueSet.id = x1, ValueSet.version = 1 and ValueSet.meta.versionId = 2.
    Later, another user creates a revised version of the value set, and this is called version 2. It is commmited commited to the server as an update (PUT [base]/ValueSet/x1). Now, ValueSet.url = http://acme.com/valuesets/example, ValueSet.id = x1, ValueSet.version = 2 and ValueSet.meta.versionId = 3
  3. A value set is posted to a server (POST [base]/ValueSet) with ValueSet.url = "http://acme.com/valuesets/example". This is identified as the 1st version of the value set (ValueSet.version = 1). When the server gets it, it assigns an identity e.g. ValueSet.id = x1, and ValueSet.meta.versionId = 1. Later, another user creates a revised version of the value set, and this is called version 2. This time, as well as supporting this new version 2, there are production systems still using version 1, and both need to be valid on the value set server. So a new value set is created on the server (POST [base]/ValueSet) and is assigned the identiity 'x2'.
    Now, there are two different value sets, both with URL "http://acme.com/valuesets/example". One has ValueSet.id = x1, ValueSet.version = 1 and ValueSet.meta.versionId = 1 and the other has ValueSet.id = x2, ValueSet.version = 2 and ValueSet.meta.versionId = 1.
2.28.3.4 Implicit Rules

A reference to a custom agreement that describes how the The version of resource SHOULD change every time some non-significant change is being used (e.g. an implementation guide ) made. Exactly what change constitutes 'significant' depends on context, and is not specified here. Note, though, that was followed when the resource was constructed, where it is possible to change elements such as status and date without changing the implemenation guide must version, such as when marking a past version as retired . In general, any other changes should be known and understood associated with a change in order to safely processing the content. version.

Asserting this rule set restricts the content to The Semantic Versioning specification recommend that versions be only understood by a limited set of trading partners. This inherently limits represented in three parts using the usefulness of form MAJOR.MINOR.PATCH where, for the data kind of artefacts described in this specification:

  • MAJOR version increments when incompatible changes are made to the long term, and should be avoided where possible. However, the existing health eco-system artifact
  • MINOR version increments functionality is highly fractured, and not yet ready added to define, collect, and exchange data an artefact in a generally exchangeable sense. Note that resources backwards-compatible manner
  • PATCH version increments when minor changes are almost always constructed following some custom agreement. Best practice - which is recommended through out the conformance resources - is made that such agreements make all knowledge about the content don't impact on implementations of the resource explicit in artefact (e.g. documentation clarifications)

For the content kind of the resource (e.g. no default values in profiles); if custom agreements follow resources that have canonical URLs , this advice, and declare their extensions as required, then it is not necessary to understand specification recommends that implementers follow the agreement in order to safely process Semantic Versioning principles, but does not require this. Implementers should consider, however, making the resource content. For this reason, use MAJOR version part of the canonical URL rather than putting it in implicitRules is rare. [Resource].version . So instead of this:

2.28.3.5 Language
{ 
  "resourceType" : "ValueSet",
  "url" : "http://example.org/fhir/ValueSet/blah",
  "version" : "2.1.1"
 }

Each resource may have a language element implementers should instead consider:

{ 
  "resourceType" : "ValueSet",
  "url" : "http://example.org/fhir/ValueSet/blah2",
  "version" : "1.1"
 }

The principle advantage is that specifies other artefacts that reference the base language of first artefact can do so by major version:

  "binding" : { 
     "valueSet" : "http://example.org/fhir/ValueSet/blah2"
  }

The alternative - not having the content using a code defined major version in BCP 47 . The language element is provided to support indexing and accessibility (e.g. text-to-speech use the language tag). URL - means that version dependencies must be managed by some other method (e.g. managing a set of resources with specific versioned references via an Implementation Guide ).

There is no default language, though one may be inferred from single best practice here; the context of use. Not all of correct choice depends on many factors outside the content scope of the resource has to be in the specified language. this specification.

If FHIR Version

All resources always have a language is specified, it should also FHIR version against which they were written. Note, however, that resources may be specified on the Narrative Text . The html language tag in the narrative is used when processing valid against multiple different FHIR versions, and this becomes progressively more likely as the narrative. The language tag on maturity of the resource progresses.

The version is provided so that applications processing the data often not stated explicitly in the resource can specify the language of any alternate presentations generated from resource; it is controlled by the data. context. See Managing Multiple FHIR versions for further information.

These 3 metadata attributes are part of the resource, but are never used to keep information that needs to be understood when interpreting the content of a resource; their function is limited to finding and controlling access to the resource, and connecting resources to technical or clinical workflow.

Tags are used to associate additional operational information with the Resources, including such as workflow management. A typical use of tagging would be to maintain an informal list of resources that need review.

In a general tag, the coded concept may be a reference to a healthcare vocabulary, including ones defined in this specification, or vocabularies such as those defined by HL7 for other purposes (e.g. HL7 v2 and HL7 v3 / CDA ), LOINC, or SNOMED CT. Alternatively, the concept may be one defined by the implementation in the local context.

The list of tags on a resource is a set, where each tag is unique based on the system + code combination.

A profile assertion represents a claim that the resource conforms to the identified StructureDefinition , which makes rules about what content is allowed to be in a resource. In a profile tag, the term is a URL that references an identified StructureDefinition resource.

It's always possible to determine whether a resource conforms to any profile simply by testing it against the profile (the validation tools provide the functionality to perform this test in a variety of contexts). However there are several circumstances where simply examining whether a resource conforms to a particular profile as needed is impractical:

  • A server searching a set of resources for ones that conform to a particular profile
  • A receiver that has many profiles to choose when validating resource

Profile Tags serve these use cases - a client/creator of a resource can tag the resource with an assertion that the resource conforms to a particular structure definition. The server/receiver of the resource can choose to take this assertion at face value, or to assist in locating the correct StructureDefinition against which to validate the resource.

Note: resources can conform to multiple profiles at once. A resource can conform to a profile without ever being labeled that it does, or a resource may falsely claim to conform to a profile. For this reason, applications processing resources SHOULD always depend on the contents of the resource when processing them, and/or check resources against the StructureDefinition s directly rather than relying the existence of profile tags for meaning. Profile Tags are provided as a method of finding resources that conform to a particular StructureDefinition , not statements of meaning about the resource.

Many trading partner agreements will make rules about what claims can be made and when they must be tested, which will make the profile assertion more reliable.

The list of profiles on a resource is a set, where each profile is unique based on the value of the URI.

A security label is attached to a resource to provide specific security metadata about the information in the resource. For further information, see Security Labels .

The list of security labels on a resource is a set, where each tag is unique based on the system + code combination.

When a resource is updated (e.g. on the RESTful interface), servers generally follow this pattern:

  • Merge existing and new tags
  • Replace existing profile tags with new profile tags
  • Merge existing and new security labels

However, in some cases, an update may invalidate existing tags. Servers may update or remove previously existing recognized tags if this is known to be appropriate.

The Maturity level documentation has moved .

Common search parameters defined by this resource. See Searching for more information about searching in REST, messaging, and services.

Name Type Description Paths
_content string Search on the entire content of the resource
_id token Logical id of this artifact Resource.id
_lastUpdated date When the resource version last changed Resource.meta.lastUpdated
_profile uri reference Profiles this resource claims to conform to Resource.meta.profile
_query token A custom search profile that describes a specific defined query operation
_security token Security Labels applied to this resource Resource.meta.security
_source uri Identifies where the resource comes from Resource.meta.source
_tag token Tags applied to this resource Resource.meta.tag