This page is part of the FHIR Specification (v0.0.82: DSTU 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 R2 Content Detailed Descriptions Operations 1.10 Base Resource Definitions 1.10.1 Scope and Usage 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 . 1.10.2 Boundaries and Relationships All resources have the following optional or mandatory elements and properties: An identity Meta data A base language A reference to "Implicit Rules" Most resources are derived from Domain Resources - so they also 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. 1.10.3 Resource Content Structure UML XML JSON All Structure Name Flags Card. Type Description & Constraints Resource n/a Base Resource id 0..1 id Logical id of this artefact 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 Language ( Required ) UML Diagram Resource «Resource» The logical id of the resource, as used in the url for the resoure. Once assigned, this value never changes id : id 0..1 The metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content may not always be associated with version changes to the resource meta : Meta 0..1 A reference to a set of rules that were followed when the resource was constructed, and which must be understood when processing the content (this element modifies the meaning of other elements) implicitRules : uri 0..1 The base language in which the resource is written language : code 0..1 « A human language Language » XML Template < <!-- from Element: --> < <</meta> < < </[name]> JSON Template { "resourceType" : "", " " " " } Structure Name Flags Card. Type Description & Constraints Resource n/a Base Resource id 0..1 id Logical id of this artefact 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 Language ( Required ) UML Diagram Resource «Resource» The logical id of the resource, as used in the url for the resoure. Once assigned, this value never changes id : id 0..1 The metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content may not always be associated with version changes to the resource meta : Meta 0..1 A reference to a set of rules that were followed when the resource was constructed, and which must be understood when processing the content (this element modifies the meaning of other elements) implicitRules : uri 0..1 The base language in which the resource is written language : code 0..1 « A human language Language » XML Template < <!-- from Element: --> < <</meta> < < </[name]> JSON Template { "resourceType" : "", " " " " } 1.10.3.1 Terminology Bindings Path Definition Type Reference Resource.language A human language Required IETF language tag 1.10.3.2 Resource Identity Each resource has an "id" element which contains the logical identity of the resource assigned by the server responsible for storing it. Resources always have a known identity except for the special case when a new resources is being sent to a server to assign an identity ( create interaction ). The logical identity is unique within the space of all resources of the same type on the same server. Once assigned, the identity is never changed, though copies of the same resource made elsewhere may not retain the same identity. The full identity of a resource is an absolute URL constructed from the server base address at which it is found, the resource type, and the Logical Id, such as http://test.fhir.org/rest/Patient/123 (where 123 is the Logical Id). Note that implementations SHOULD NOT assume that the identity of a resource is always resolvable to a literal server - it may be temporarily unavailable, or not available by policy (e.g. firewalls) or in some cases, it may not actually exist (e.g. use of resource outside a RESTful environment). Resources reference each other by their identity. These references are allowed to be absolute or relative (see Resource References for further discussion). Copying or moving resources from one server to another means that resources acquire a new identity. For further details, see Managing Resource Identity . Logical ids are case sensitive. Ids are always opaque, and external systems need not and should not attempt to determine their internal structure. An 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 ".". 1.10.3.2.1 "Business" Identifiers In addition to the Resource identity element "id", many resources contain an element named "identifier", which, if populated, contains a different kind of identifier. The resource identity is a direct ("literal") reference that is intended to be accessed via http for a resource to be returned. As a resource is copied from server to server, the resource identity will change as the servers assign identities to the resource. However all copies of the reosurce refer to the same underlying concept, and this concept may also be represented in other formats (variously, v2, CDA, XDS, and many more). Each representation carries the same identifier that identifies it consistently across all contexts of use. This is known as the business 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. If a FHIR server is a stable server that is the canonical master source for the definition of a concept, the business identifier for all systems may be the same as the literal identity of the resource on the master server. 1.10.3.3 Resource Metadata 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 of 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. 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 can be used by a system or a human to judge the currency of the resource content. Note that version aware updates do not use this element profile (0..*) uri 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 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 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. Structure UML XML JSON All Structure Name Flags Card. Type Description & Constraints Meta Element Metadata about a resource versionId 0..1 id Version specific identifier lastUpdated 0..1 instant When the resource version last changed profile 0..* uri Profiles this resource claims to conform to security 0..* Coding Security Labels applied to this resource tag 0..* Coding Tags applied UML Diagram 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 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 list of profiles [[[StructureDefinition]]]s that this resource claims to conform to. The URL is a reference to [[[StructureDefinition.url]]] profile : uri 0..* Security labels applied to this resource. These tags connect specific resources to the overall security policy and infrastructure security : Coding 0..* Tags applied to this resource. Tags are intended to 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..* XML Template < <!-- from Element: --> < < < <</security> <</tag> </meta> JSON Template  { // from Element: " " " " " } Structure Name Flags Card. Type Description & Constraints Meta Element Metadata about a resource versionId 0..1 id Version specific identifier lastUpdated 0..1 instant When the resource version last changed profile 0..* uri Profiles this resource claims to conform to security 0..* Coding Security Labels applied to this resource tag 0..* Coding Tags applied UML Diagram 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 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 list of profiles [[[StructureDefinition]]]s that this resource claims to conform to. The URL is a reference to [[[StructureDefinition.url]]] profile : uri 0..* Security labels applied to this resource. These tags connect specific resources to the overall security policy and infrastructure security : Coding 0..* Tags applied to this resource. Tags are intended to 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..* XML Template < <!-- from Element: --> < < < <</security> <</tag> </meta> JSON Template { // from Element: " " " " " } Meta is used in the following places: Resource Note that the RESTful API defines some Operations that provide direct read and write access to the meta element. 1.10.3.3.1 Technical vs Business Versions All resources are conceptually versioned, and each resource sits at the head of a linear list of past versions. The past versions are superceded 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 changes every time the server updates the resource and writes a new version over the top of an existing one. 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: 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 commmited 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 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 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 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. 1.10.3.4 Implicit Rules A reference to a custom agreement about how the resources are used that was followed when the resource was constructed, and which must be understood when 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 is that such agreements make all knowledge about the content of the resource explicit; if custom agreements do this, and declare their extensions as required, then it is not necessary to understand the agreement when processing the resource content. 1.10.3.5 Language 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). 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. If a language is specified, it should also be specified on the Narrative Text . The html language tag in the narrative is used when processing the narrative. The language tag on the resource is provided for use to specify the language of alternate presentations generated from the data in the resource 1.10.3.6 Tags, Profiles, and Security Labels 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. 1.10.3.6.1 Tags 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 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. v2 and v3/CDA), LOINC, or SNOMED CT. Alternatively, the concept may be one defined by the implementation in the local context. 1.10.3.6.2 Profile Tags 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 a the 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 labelled 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. 1.10.3.6.3 Security Labels 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 . 1.10.3.7 Further Information Conformance Rules Resource Definitions References between Resources Narratives Formats: XML , JSON Extensibility ( Examples ) Detailed Descriptions Inter-version Compatibility try { var currentTabIndex = sessionStorage.getItem('fhir-resource-tab-index'); } catch(exception){ if (navigator.userAgent.toLowerCase().indexof('msie') == -1) alert(exception); } if (!currentTabIndex) currentTabIndex = '0'; $( '#tabs-Meta' ).tabs({ active: currentTabIndex, activate: function( event, ui ) { store(ui.newTab.index()); } }); function store(currentTab) { try { sessionStorage.setItem('fhir-resource-tab-index', currentTab); } catch(exception){ if (navigator.userAgent.toLowerCase().indexof('msie') == -1) alert(exception); } $( '#tabs-Meta' ).tabs('option', 'active', currentTab); } 1.10.4 Search Parameters Common search parameters defined by this resource. See Searching for more information about searching in REST, messaging, and services. Name Type Description Paths _id token Logical id of this artefact Resource.id _language token Language of the resource content Resource.language _lastUpdated date When the resource version last changed Resource.meta.lastUpdated _profile uri Profiles this resource claims to conform to Resource.meta.profile _security token Security Labels applied to this resource Resource.meta.security _tag token Tags applied Resource.meta.tag © HL7.org 2011+. FHIR DSTU (v0.4.0-4902) generated on Fri, Mar 27, 2015 00:17+1100. Links: What's a DSTU? | Version History | Specification Map | Compare to DSTU1 | | Propose a change try { var currentTabIndex = sessionStorage.getItem('fhir-resource-tab-index'); } catch(exception){ if (navigator.userAgent.toLowerCase().indexof('msie') == -1) alert(exception); } if (!currentTabIndex) currentTabIndex = '0'; $( '#tabs' ).tabs({ active: currentTabIndex, activate: function( event, ui ) { store(ui.newTab.index()); } }); $( '#tabs-Meta' ).tabs({ active: currentTabIndex, activate: function( event, ui ) { store(ui.newTab.index()); } }); function store(currentTab) { try { sessionStorage.setItem('fhir-resource-tab-index', currentTab); } catch(exception){ if (navigator.userAgent.toLowerCase().indexof('msie') == -1) alert(exception); } $( '#tabs' ).tabs('option', 'active', currentTab); $( '#tabs-Meta' ).tabs('option', 'active', currentTab); }