Pointer Identity

Once persisted within NRLS there are up to two ways to refer to a specific Pointer instance. Both are identifiers that are stored on the Pointer itself. One is mandatory, the other is optional -

• Logical identifier – This identifier is assigned by the NRLS service when it persists a Pointer. It uniquely identifies that Pointer within the boundary of the NRLS service. In effect the NRLS service instance is the namespace for a given Pointer’s Logical identifier.

• Master identifier – This identifier is optional and is under the control of the Provider. Contrast this with the Logical identifier which is under the control of the NRLS service.

Logical identifier

The logical identifier (id) is generated by the NRLS during the creation of a new Pointer. The identifier is unique across all Pointers on the NRLS service that created the Pointer. If the Pointer were ever to be migrated to a different NRLS service instance then it is possible that its id might need to change to avoid clashes with Pointers on the target NRLS service. The format of the id is under the control of the NRLS service. Clients should treat the id as an opaque identifier i.e. the client should not make assumptions about the structure of the id.

Master Identifier

The Master identifier is an optional identifier on the Pointer. It is under the control of the Provider. The Master identifier is associated with the version of the content that the Pointer references. Any time that the content’s version changes see Maintaining Pointers page then so too should the masterIdentifier. The NRLS prefers that this is done through the creation of a new Pointer with a new masterIdentifier and the deprecation of the existing Pointer (see Pointer status page).

Uniqueness

It is important that the masterIdentifier be unique. The scope of that uniqueness is recommended to extend beyond the NRLS service that the Pointer was originally created on. This is to support the notion that Master identifier is a business identifier – it is tied to a specific Pointer and should never change regardless of which NRLS service the Pointer is on. In terms of the uniqueness of a given Master identifier NRLS can be seen be seen as existing in a collection of namespaces -

1. Patient – the smallest namespace in NRLS. The set of Master identifiers associated with a given Patient
2. Provider – this namespace spans Patients but is constrained to those Pointers owned by a given Provider
3. NRLS - the largest namespace, holds both the Patient and Provider namespaces

Each of the namespaces are discussed in more detail below in particular who is responsible for ensuring that a given Master identifier is unique in that space and the consequences of failing to ensure uniqueness. Overall though the content can be boiled down in to one strong recommendation to Providers -

Providers should use a unique value for the Master identifier

Patient namespace

Headline – The NRLS guarantees that no two Pointers for the same Patient (identified by NHS number) will have the same Master identifier If the Provider attempts to create a Pointer using a Master identifier that has already been assigned to one of that patient’s other Pointers then the Provider’s request will be blocked.

Provider namespace

Headline – it is the Provider’s responsibly to ensure that the Master identifiers that it creates are unique across all of its Pointers. It is perfectly possible for a Provider to create Pointers for different patients with the same Master identifier. The NRLS service will not prevent this scenario from arising.

NRLS namespace

Headline - it is the Provider’s responsibly to ensure that the Master identifiers that it creates are unique across all Pointers in the NRLS. It is not unheard of for organisations to merge. In this case the Pointers previously owned by two organisations will come under the ownership of one of those organisations.

To provide the NRLS with a degree of flexibility in terms of deployment a Provider should not assume that there is a single instance of the NRLS service. With this constraint in mind the uniqueness of a Master identifier extends across NRLS instances.

In the end we arrive at the recommendation made at the beginning of this section.

Providers should use a unique value for the Master identifier

Unique value for the Master identifier

The NRLS recommends the use of a unique value when assigning a value for a Master identifier. To avoid the negative scenarios outlined above the value should be unique within the scope of the NRLS namespace.

The problem of uniquely identifying an entity such as a Pointer is not a new one and there are several standard ways of generating a unique value. Two approaches of note are –

• The Universally Unique Identifier (UUID) – the uniqueness of a UUID is based on the low chance that the same 128-bit random number will not be generated twice. There is a wealth of libraries that will generate a UUID that result in the practical likelihood that a UUID is unique being very high.

• Object Identifier (OID) – An OID is a set of decimal numbers called arcs that are separated by periods. The OID system relies uses the concept of authorities who can hand out an OID that is guaranteed to be unique. From there the owner of that OID can itself act as an authority handing out an arc to another organisation that is unique below the owner’s arc. This process can repeat and repeat creating a chain of arcs that are all unique within the scope of their parent arc. As long as all organisations execute their responsibility to ensure uniqueness then the OID system makes better guarantees about uniqueness than the UUID however it does rely on all members of an OID chain making sure that they do not reuse an value when assigning an arc to a child.