Resource - FHIR v4.0.1 Release 4 FHIR Home Getting Started Documentation Resources Profiles Extensions Operations Terminologies Foundation Resource This page is part of the FHIR Specification (v4.0.1: R4 - Mixed Normative and STU) in it's permanent home (it will always be ava…
Resource - FHIR v4.0.1 Release 4 FHIR Home Getting Started Documentation Resources Profiles Extensions Operations Terminologies Foundation Resource This page is part of the FHIR Specification (v4.0.1: R4 - Mixed Normative and STU) in it's permanent home (it will always be available at this URL). 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 2.26 Base Resource Definitions http://www.hl7.org/Special/committees/fiwg/index.cfm Maturity Level: N Normative (from v4.0.0) Compartments: Not linked to any defined compartments This page has been approved as part of an ANSI standard. See the Infrastructure Package for further details. 2.26.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. 2.26.2 Boundaries and Relationships 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 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. 2.26.3 Resource Content Structure UML XML JSON Turtle All Structure Name Flags Card. Type Description & Constraints 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 (Preferred but limited to AllLanguages) Documentation for this format UML Diagram (Legend) XML Template <[name] xmlns="http://hl7.org/fhir"> <!-- from Element: extension --> <id value="[id]"/><!-- 0..1 Logical id of this artifact --> <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]> JSON Template { "resourceType" : "[name]", "id" : "<id>", // Logical id of this artifact "meta" : { Meta }, // Metadata about the resource "implicitRules" : "<uri>", // A set of rules under which this content was created "language" : "<code>" // Language of the resource content } Turtle Template @prefix fhir: <http://hl7.org/fhir/> . [ 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: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 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 (Preferred but limited to AllLanguages) Documentation for this format UML Diagram (Legend) XML Template <[name] xmlns="http://hl7.org/fhir"> <!-- from Element: extension --> <id value="[id]"/><!-- 0..1 Logical id of this artifact --> <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]> JSON Template { "resourceType" : "[name]", "id" : "<id>", // Logical id of this artifact "meta" : { Meta }, // Metadata about the resource "implicitRules" : "<uri>", // A set of rules under which this content was created "language" : "<code>" // Language of the resource content } Turtle Template @prefix fhir: <http://hl7.org/fhir/> . [ 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: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 ] 2.26.3.1 Terminology Bindings Path Definition Type Reference Resource.language A human language. Preferred, but limited to AllLanguages CommonLanguages 2.26.3.2 Resource Identity 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 2.26.3.3 Logical ID Each resource has an id element which contains the "logical id" of the resource assigned by the server responsible for storing it. Resources always have a known logical id except for a few special cases (e.g. when a new resource is being sent to a server to assign a logical id in the create interaction). The logical id is unique within the space of all resources of the same type on the same server. Once assigned by the server, the id is never changed. The 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 of a Patient resource). When the 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 location of a resource is always resolvable to an accessible server - it may be temporarily unavailable, or not available by policy (e.g. firewalls) or in some cases, it might not actually exist (e.g. use of resource outside a RESTful environment). Resources reference each other by their location. These references are allowed to be absolute or relative (see Resource References for further discussion). When a resource is copied from one server to another server, the copy might or might not keep the same logical id on the new server. This depends on replication and server policy. For further details, see Managing Resource Identity (including "Consistent Resource Identification"). Logical ids (and therefore 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. 2.26.3.3.1 "Business" Identifiers Although the logical id of a resource changes as it moves from server to server, 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 common identifiers that identify the underlying concept (also called "real world entity") consistently across all contexts of use. This is known as the business identifier, and is found in the identifier 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 Most resources have a 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 safe practice on secondary systems which are not in a position to enforce their required identifier consistency. 2.26.3.3.2 Canonical URLs 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 URL serves as a stable logical identifier for the 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 different version of the same resource). See Canonical references for further discussion of canonical references and the canonical data type. The following resources have canonical URLs: ActivityDefinition CapabilityStatement ChargeItemDefinition CodeSystem CompartmentDefinition ConceptMap EffectEvidenceSynthesis EventDefinition Evidence EvidenceVariable ExampleScenario GraphDefinition ImplementationGuide Library Measure MessageDefinition NamingSystem OperationDefinition PlanDefinition Questionnaire ResearchDefinition ResearchElementDefinition RiskEvidenceSynthesis SearchParameter StructureDefinition StructureMap TerminologyCapabilities TestScript ValueSet 2.26.3.4 Consistent Resource Identification 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 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) Pres…