Search loading...


Explore and Make use of Nationally Defined Messaging APIs


Pointer Identity

NRL Pointer Identity

Pointer Identity

Once persisted within NRL 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 NRL service when it persists a Pointer. It uniquely identifies that Pointer within the boundary of the NRL service. In effect the NRL service instance is the namespace for a given Pointer’s Logical identifier.

  • Master identifier – This identifier serves the same purpose as the logical identifier: it uniquely identifies the Pointer within the boundary of the NRL service. However, 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 NRL service. For futher detail, see the Master Identifier and Uniqueness sections below.

Logical identifier

The logical identifier (id) is generated by the NRL during the creation of a new Pointer. The identifier is unique across all Pointers on the NRL service that created the Pointer. If the Pointer were ever to be migrated to a different NRL service instance then it is possible that its id might need to change to avoid clashes with Pointers on the target NRL service. The format of the id is under the control of the NRL 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. Guidance on the use of a unique master identifier value:

  • Once a pointer with a master identifier value has been created, that same master identifier value cannot be re-used with another pointer.
  • ‘Superseding’ requires a new master identifier value. If a pointer is superseded, the new Pointer which replaces it must have a new, unique master identifier value.
  • Once a pointer with a master identifier is deleted, the master identifier value used in that pointer cannot be used again on the NRL.


It is important that the masterIdentifier be unique. The scope of that uniqueness is recommended to extend beyond the NRL 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 NRL service the Pointer is on. In terms of the uniqueness of a given Master identifier NRL can be seen be seen as existing in a collection of namespaces -

  1. Patient – the smallest namespace in NRL. 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. NRL - 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 NRL 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 NRL service will not prevent this scenario from arising.

NRL namespace

Headline - it is the Provider’s responsibly to ensure that the Master identifiers that it creates are unique across all Pointers in the NRL. 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 NRL with a degree of flexibility in terms of deployment a Provider should not assume that there is a single instance of the NRL service. With this constraint in mind the uniqueness of a Master identifier extends across NRL 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 NRL 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 NRL 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 on 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.

Tags: pointer

All content is available under the Open Government Licence v3.0, except where otherwise stated