When assigning a business identifier to a resource, by way of an Identifier, it is important to identify the namespace ("system") from which that identifier was drawn. The system is indicated by setting the relevant value into Identifier.system.
So what is the relevant value? Well, it depends on where the identifier came from.
FHIR® curates a list of officially supported systems, along with the system value which should be used.
Other externally defined systems exist and these may define their own system identifier which should be used.
PKB has no control over the system values defined externally. They are not required to be resolvable, and if they do resolve the content returned is undefined.
The most common example of this type of identifier is a National ID. The table below shows which National IDs are currently supported by PKB, along with the system value we will use for it.
Note: The equivalent information for our HL7 API can be found here.
* A note about NHS-Type Numbers. The following 3 National ID Types are drawn from the same numbering scheme, but with non-overlapping ranges. PKB considers them to be separate types. It is the responsibility of the client to ensure the correct FHIR Identifier system is used.
CHI Number (Scotland): 010 101 0000 to 311 299 9999
Health and Care Number (Northern Ireland): 320 000 0010 to 399 999 9999
NHS Number (England and Wales): 400 000 0000 to 999 999 9999
Externally defined, PKB hosted
PKB allows customers to define their own local identifier types at the level of both a PKB Organisation and also a PKB Team. In these cases, PKB is hosting information about the identifier types, but is not responsible for the identifiers. Note: this is not to say all the attributes of the identifier type are meaningful outside of PKB. For example, whilst a customer might configure a display name for the identifier type to match that used in their own internal systems, it is possible that they might have configured an Assigning Authority / Type Code for use in HL7 messages which is only correct for messages sent to PKB.
Each of these local, customer-specific identifier types is assigned a UUID by PKB.
This UUID is converted into a system for use in a FHIR Identifier by simply prepending it with "urn:uuid:" such that the UUID becomes a valid URI.
Information about the identifier system is made available to suitably authorised callers via the NamingSystem type service. Callers can search the type service by providing the identifier system as the "value" search parameter. If a known identifier system was provided, and the caller is authorised to see the details, then the NamingSystem will be returned.
Note: this same UUID also acts as the resource id for NamingSystem, but this is merely an implementation detail. Callers should not depend on this remaining true.
PKB does not expose information about a customer's local identifier types to anyone other than the customer. As such, there is no plan to replace the UUID-based URIs with resolvable URLs, since anyone who needs to understand the system will already do so.
Identifiers assigned by PKB are typically exposed directly through resource IDs.
However, there are some occasions where such an ID is required to be used in an identifier, and as such an identifier system needs to be assigned.