Important: This is the release candidate of the FHIR Data Standards Wales for PSOM version 1.0 Implementation Guide. It is intended for trial use, and is published for early comment and feedback. Click here to give feedback.

General FHIR Considerations

Use of the reference data type
Usage of ids and identifiers
- When is identifier expected?
- When is id expected?

Use of the reference data type

A key feature of FHIR is the ability of resources to reference each other. This is done using the Reference data type. This data type supports two modes of referencing:

Literal references, using the .reference element. In this case a relative or absolute REST endpoint containing the .id of the referenced resource is used. In a Bundle context, this may also be a reference to a Bundle.resource.fullUrl.
Logical references, using the .identifier element. Such a reference entails a match on the business identifier (.identifier) for the referenced resource, without specifying where to find the referenced resource.

The basic requirements for using references in this context are:

Either a literal or logical reference SHALL be specified, unless specified otherwise.
- Literal references are preferred over logical references when multiple target resource types/profiles may be used.
- Literal references SHALL be resolvable.
Relative references are preferred over absolute references.
A short description of the target resource SHOULD be included using the .display element.

Usage of ids and identifiers

Implementers are required to adhere to the specifications and Metadata DSCN when it comes to uniquely identifying FHIR instances. In cases where a local identifier is necessary, implementers are permitted to add one or more local identifiers. FHIR recognizes two fields that are used to identify instances: .id and .identifier. Although these are both identifiers, they are unrelated and serve a completely different purpose:

The .id is the logical identifier, or technical identifier, akin to the id field in a database. It is used as a unique handle for every instance on a particular server, and is needed to construct the URL to the instance. As such, it is used for referring between resources. The .id has no further meaning outside of the server. The .identifier is a business identifier, which usually has a meaning outside of the server. Examples are a registration number of a healthcare provider, or social security number for citizens, ISBNs for books, etc. Any instance may have multiple kinds of identifiers.

When is identifier expected?

Systems that use an (internal) stable identifier to track information are encouraged to assign it to the .identifier element of FHIR instances when sending the resource, using a custom identifier.system (e.g. an URL or OID that is under control of the sending organization). The presence of this element helps receiving systems with re-identification and deduplication of resources, especially when the sender system does not natively support logical ids. Specific requirements for the usage of .identifier will be dictated on a use case basis by the particular profiles.

The JSON snipped below is an example of a CarePlan.identifier that contains an additional identifier assigned by a PROMs vendor.

                "identifier":  [
                    {
                        "system": "https://fhir.sbuhb.nhs.wales/Id/referral-identifier",
                        "value": "12345678",
                        "assigner": {
                            "reference": "urn:uuid:fd3f7e8c-3cb2-4b4a-9b2b-d702bc32a905",
                            "display": "Swansea Bay University Local Health Board"
                        }
                    }

                ]

When is id expected?

As stated above, the logical id is meant to uniquely identify instances on a particular server; it is a vital component when using FHIR within a RESTful context. So as a rule of thumb, the .id element should always be present when dealing with instances that have a logical id, thus with instances on a server.