Search loading...


Explore and Make use of Nationally Defined Messaging APIs


Solution Principles

Solution Principles


The Provider controls Record retrieval

The NRL takes the stance that it is for the Provider to determine the mechanism employed to retrieve the Record.

A consequence of this principle is that in some circumstances it may not be possible for a Pointer to describe all of the information needed to retrieve the Record. For example if there are dynamic parameters that need to be passed to the Provider’s system that are not known a priori. In these instances, a Pointer will give the Provider a place to record some optional guidance to advise the Consuming organisation around how to integrate with the Provider.

Having said that if a Record is exposed using National standards then the aspiration is that the NRL Pointer can be used to retrieve a Record using a National broker without the need for the Consumer to perform custom integration.

The NRL does not guarantee that Records can be retrieved by following a Pointer

There are the complexities associated with retrieving data over a network that are outside of the scope of the meta data that will be captured by a Pointer. As an example, consider the need to define firewall rules to allow traffic to flow between a Consumer and a Provider; this kind of consideration will not be captured in a Pointer however if it is not addressed then record retrieval will not be possible even if the actual meta data in the Pointer is correct.

Acknowledging that this complexity exists and sits outside of the NRL’ control means that it should not be assumed by Consumers that a Pointer’s Record is automatically resolvable. There may be additional integration for the Consumer system to do before Pointers from the given Provider can used to resolve their Record. To provide Consumers with some support in this context each Pointer may carry some integration guidance. This audience for this guidance is a technical one. It is envisaged that these will be the people working to integrate Consumer with Provider.

The NRL supports varying levels of digital maturity

The NRL recognises that there will be varying levels of digital maturity across Providers and Consumers. The format of and way that a Record can be retrieved are under the control of the Provider system. At this stage 2 record retrieval scenarios are envisaged:

  • A Provider exposes a Record for direct retrieval such that using the context available in the Pointer, a Consumer is able to retrieve the Record by electronic means.
  • A Provider exposes a set of contact details that a Consumer can use to retrieve the Record. The Consumer does not retrieve the Record electronically, instead they use the contact details as an intermediate step to get to the Record e.g. by phoning a healthcare service found in the contact details, who then can relay the Record to the Consumer via another mechanism.

The Consumer controls Pointer access

When a Consumer requests that the NRL return the Pointers that it has for a given patient it will return all Pointers. The NRL will not perform any filtering before sending that collection of Pointers back to the Consumer.

Once consequence of this is that the end user on the Consumer side may be exposed to Pointers that reveal sensitive information about the Patient, for example it will be possible to infer through a Pointer that a Patient has a certain kind of record. Even though the user may not be able to retrieve the Record, knowing that it exists is in itself revealing a degree of personal information about that patient that may not be appropriate. With this in mind it is acknowledged that there is most likely going to be a need to filter Pointers before they are displayed to the end user. This responsibility is seen as belonging to the Consumer where local access rules will be used to judge whether or not a given user should be permitted to know that a given Pointer exists.

The mechanism for making this decision is predicated on the Record type that the Pointer references.

The Provider controls Record format

The NRL takes the stance that it is for the Provider to determine what format its Records should be delivered in. The NRL does not restrict the format of Records that are pointed to. Whether or not the Consumer can handle that format is not the concern of the Provider and nor is it the concern of the NRL. The NRL expects that a Provider will create a Pointer with additional contextual information (i.e. mime type) to help the Consumer determine the appropriate way to handle the Record.

Pointers should not be removed

In part the NRL is there to track the evolution of a Pointer’s content. This is important so that the NRL can support the retrieval of historical Pointers for medico-legal use cases. To that end the deletion of a Pointer should be avoided. Though the NRL does provide a delete function as in some circumstances deletion of a Pointer may be unavoidable. More information is provided in Pointer maintenance page.

Caching and Storing

It is important that consumers of NRL pointers are able to view and make clinical decisions based on the most up to date information available. For this reason NRL recommends that pointers and referenced content returned from search and read requests should not be cached or stored.

Tags: overview

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