This means that a number of scenarios outlined below around updating a Pointer can not yet be achieved though the NRLS intends to support these features in a future release.
Specifically the NRLS API does not currently support-
- The following status property transitions:
o current to entered-in-error
o entered-in-error to current
o current to superseded where the current Pointer is not being replaced.
- Modification of other properties
Pointer Errors
The current version of the NRLS API does not give Providers the ability to update the properties of an existing Pointer, other than status . The status property is modified in a very specific way by only allowing a Provider to replace one document reference with another - see Managing Pointers to static content. This means that a number of scenarios outlined below around updating a Pointer cannot yet be achieved though the NRLS intends to support these features in a future release. Specifically the NRLS API does not currently support -
- Modification of the status property –
- current to entered-in-error
- entered-in-error to current
- current to superseded where the current Pointer is not being replaced.
- Modification of other properties
Pointer error handling
Errors happen. It is important to acknowledge this reality and to design a solution with this in mind. To that end the NRLS makes a distinction between the following kinds of error –
- Errors with the Pointer
- Errors with the content that the Pointer references
Errors with the Pointer
There are two routes by which incorrect data could find its way in to a Pointer –
- Error with the data that the Provider system is using to create a Pointer
- Defect in the Provider system that is creating and publishing Pointers
These errors, however they have originated could lead to one of two situations –
- The Pointer itself should not have been added to the NRLS
- It is valid for the Pointer to exist however there are problems with the data stored on a Pointer, for example the record creation date might be incorrect. When the Provider realises that there is a problem with the Pointer then action must be taken by the Provider. Depending on the nature of the problem the Provider has different options when it comes to dealing with the issue.
Pointer should not have been added to NRLS
In this case as soon as the issue is recognised the Provider should mark that Pointer’s status as entered-in-error.
Note that it is important to do this before that Pointer has been superseded as once that transition has been made it is not possible to mark a Pointer as entered-in-error - see Pointer lifecycle. Only those Pointers with a status of current can be moved to the entered-in-error state.
If a Provider finds that one of their superseded Pointers should not have been registered with the NRLS then the entire lineage of that Pointer is considered corrupted. The Provider must mark the Pointer at the head of the lineage (i.e. the current Pointer) as being entered-in-error.
The Provider should then recreate the entire lineage missing out the erroneous Pointer.
Pointer’s data is invalid
Where the presence of the Pointer on NRLS is valid but the data it holds is invalid then the Provider could choose to update the erroneous data in order to repair that Pointer.
Each property on the Pointer is listed below along with a description of what action should be taken if the Provider finds a problem with that property. In most cases where the Pointer at fault is part of a lineage of related Pointers then the state of the other Pointers in the lineage should be taken in to account when deciding what changes to make .
| Property | Notes |
|---|---|
| status | The modification of status is restricted. See Pointer lifecycle |
| author | If the DocumentReference is part of a lineage then the author should be consistent |
| URL | - |
| content type | - |
| created | If the DocumentReference is part of a lineage then the new date should not be before the created date of any of the previous Pointers in the lineage |
Table 1: Mutable properties. These properties can be changed without the need to create a new Pointer.
| Property | Notes |
|---|---|
| patient | If the Pointer is not part of a lineage then mark it as entered-in-error and create a new Pointer that is associated with the correct Patient. If the Pointer is part of a lineage then mark it as entered-in-error and create a new lineage that mirrors the existing one however the Pointers will now be associated with the correct Patient. |
| type | If the Pointer is not part of a lineage then mark it as entered-in-error and create a new Pointer that is associated with the correct type. If the Pointer is part of a lineage then mark it as entered-in-error and create a new lineage that mirrors the existing one however the Pointers will now be associated with the correct type. |
| related | Where the relationship is one of replacement the following advice applies: Mark the Pointer (A) as entered-in-error and create a new Pointer (B) that is related to the correct Pointer. The Pointer (C) that was originally (and incorrectly) replaced by A will be incorrectly marked as having been replaced. Create a new Pointer that is largely identical to C except its status will be “current”. If C was part of a lineage create a new lineage that mirrors the existing one. |
Table 2: Immutable properties. These properties cannot be changed on an existing Pointer. Instead a new Pointer must be created.
Errors with the content that the Pointer references
The Provider should correct the content using whatever local processes are in place. This may necessitate the creation of a new version of the content in which case it may be appropriate to replace the current Pointer with a new one or the correction to the content may be such that the existing Pointer transparently references the corrected content. In either case responsibility for ensuring that the referenced content is correct rests with the Provider.
