The NRLS is based on the Registry-Repository: pattern which separates the storage and retrieval of a record from data that describes its location.
The NRLS is acting as a registry with the repository function carried out by so-called Providers. Providers are systems external to the NRLS that expose records for retrieval. Pointers are created by Providers to signpost a record that is intended to be exposed for retrieval.
Pointers are really at the core of the NRLS. The NRLS can be thought of as a collection of Pointers. Each Pointer describes how to retrieve a particular record from the Provider’s system or repository. It is key to the success of the NRLS that Pointers are accurate. It is the responsibility of Providers to create and manage Pointers on the NRLS in order to maintain this accuracy.
Accuracy is important from the perspective of those systems who wish to understand what records are available and from there may wish to retrieve records from the Provider. This category of actor is known as a Consumer. Without accurate Pointer data the Consumer’s life is made harder as they cannot be assured that a given Pointer describes what is purports to.
The NRLS does not take part in Record retrieval. The actual retrieval of the Record referenced by a given Pointer can be facilitated by the Spine Security Proxy (SSP).
The NRLS actors are summarised here.
A Record exists on a remote system and collects together related data into a logical grouping.
Records come in a variety of formats but the NRLS broadly makes a distinction based on the notion of structured and unstructured Records. Structured Records are made up of clearly defined data types whose composition makes them relatively easy to manipulate. Contrast this with unstructured Records which crudely could be said to be “everything else” and are comprised of data that is usually not as easy to manipulate.
The NRLS also acknowledges that there is a difference to be drawn between how the contents of a Record can change over time (see the Record creation datetime field on Pointer). To the NRLS a static Record is one whose contents will never change whereas a dynamic Record’s contents is not guaranteed to be the same from one point in time to another in the future.
Pointers are associated with a Record. As noted a Record exists in a remote system, one of the roles of the Pointer is to provide enough context to allow a Consumer to retrieve that Record from the remote system and display it.
The format of and way that a Record can be retrieved are under the control of the Provider system. It might be that the Provider has exposed the Record for direct retrieval such that using the context available in the Pointer, a Consumer is able to retrieve the Record.
In another scenario it might be that rather than point to an electronic copy of the Record, the Provider has exposed a set of contact details that a Consumer can use to retrieve the Record. In this scenario the Consumer is not retrieving the Record electronically, instead they are using the contact details as an intermediate step to get to the Record perhaps by phoning a healthcare service found in the contact details who will then relay the Record to the Consumer via another mechanism.
The diagram above shows two Pointers that reference the same Record (Record A). The ways that they describe how to get the contents of Record A are different. In red is a Pointer that directly references the Provider’s API. In this example, following the Pointer will return the Record in electronic form direct from the Provider’s record store (green).
Contrast this with the blue Pointer that contains a set of contact details. A Consumer following this Pointer would begin their retrieval by dialling the telephone number detailed on the Pointer, from there they would enter into a human controlled process that would lead ultimately to Record A being retrieved for them. In this example the person on the end of the contact details is accessing Record A via the same API that the red Pointer references.