The “Information Retrieval” pages are intended to give developers detailed requirements and guidance, about how to understand and implement the different types of information sharing and retrieval that can be reference in an NRL pointer.
Retrieval formats identify the types of information sharing that can be referenced by an NRL pointer. Retrieval formats are made up of two components:
| Component | Description |
|---|---|
| Retrieval Interaction | Identifies the mechanism that can be used to retrieve the information. |
| Retrieval Data Model | Identifies the structure and rules of the information that can be retrieved. |
Each retrieval format is a unique combination of a retrieval interaction and retrieval data model. It may be possible to retrieve the same data model via two different retrieval interactions, in which case there will be two retrieval formats to represent this.
The retrieval format by which the information can be retrieved from a provider is shared in the NRL pointer using the following two metadata fields:
| Field | Description |
|---|---|
| Retrieval format | Describes the technical structure, the rules of the information and the mechanism for retrieval. |
| Retrieval MIME type | Describes the data type of the information. |
See the Pointer Overview page and the FHIR Profile Reference page for more details on the data model and the two metadata fields.
The combination of these two metadata fields allows:
- providers to say what format they are sharing information in.
- consumers to know the type and structure of the content they will recieve, allowing them to decide if they will be able to process and render the information.
Retrieval Interactions
The retrieval interaction identifies mechanisms consumers can use to retrieve information from providers and represents the authentication and authorisation requirements for that retrieval.
The retrival interaction information is important to:
- providers so they can expose information using a mechanism that consumers can understand and utilise.
- consumers so they can understand how to retrieve information from a provider.
Supported Retrieval Interactions
The following table describes the retrieval interactions currently supported within NRL pointers:
| Retrieval Interaction | Description |
|---|---|
| Public Web | Some information types, such as Contact Details, can be shared and retrieved via public facing web pages. |
| SSP | The SSP is a content agnostic forward proxy, which is used to control and protect access to health systems. It provides a single security point removing the need for a complex and onerous authentication and authorisation mechanism between parties. |
| Direct Integration | The option for consumers and providers to communicate directly, not to use the SSP, is possible where direct integration and a shared authentication and authorisation model is established. |
Retrieval Data Models
Retrieval data models refer to the structure in which information can be shared. The NRL pointers can refer to information which can be retrieved in a range of formats, including both unstructured documents and structured data, as described on the Information Sharing page.
Structured data formats will be versioned and where any breaking changes to a data structure are required, a new format will be created with an increment to the version number. The NRL supports multiple versions of data structures.
Supported Retrieval Formats
The following table lists retrieval formats that are currently supported within NRL pointers:
| Format | Description | Retrieval Interaction |
|---|---|---|
| Contact Details (HTTP Unsecured) | A publicly accessible HTML web page or PDF detailing contact details for retrieving a record. | Public Web |
| Unstructured Document | An unstructured document, such as a PDF. The content-type of the document returned should be described in the retrieval MIME type field of the pointer. | SSP |
Upcoming Retrieval Formats
The following table lists upcoming retrieval formats that are not yet supported by the NRL:
| Format | Description | Retrieval Interaction |
|---|---|---|
| Allergy List FHIR STU3 v1 | A list of allergies, in a FHIR STU3 structured format. | SSP |
| Observation List FHIR STU3 v1 | A list of observations, in a FHIR STU3 structured format. | SSP |
| Vaccination List FHIR STU3 v1 | A list of vaccinations, in a FHIR STU3 structured format. | SSP |
Supporting Multiple Retrieval Formats
The NRL pointer model allows for multiple formats for the same information to be specified within a single pointer, for example a pointer could contain a reference for retrieval of information in PDF format, but also as a structured FHIR resource. Each retrieval format would be detailed in a separate content element within the pointer (a DocumentReference FHIR resource), allowing consuming systems to choose the most appropriate format to retrieve for use within their system.
Multiple Format Example
The following examples show a pointer for a ‘Mental health crisis plan’ that can be retrieved over the phone (using the contact details listed on the referenced HTML web page) and directly as a PDF document.
XML
<DocumentReference>
<id value="0353e505-f7be-4c20-8f4e-337e79a32c51-76009894321256642261" />
<meta>
<profile value="https://fhir.nhs.uk/STU3/StructureDefinition/NRL-DocumentReference-1" />
<version value="1" />
<lastUpdated value="2016-03-08T15:26:00+01:00" />
</meta>
<masterIdentifier>
<system value="urn:ietf:rfc:3986" />
<value value="urn:oid:1.3.6.1.4.1.21367.2005.3.7" />
</masterIdentifier>
<status value="current" />
<type>
<coding>
<system value="http://snomed.info/sct" />
<code value="736253002" />
<display value="Mental health crisis plan" />
</coding>
</type>
<class>
<coding>
<system value="http://snomed.info/sct" />
<code value="734163000" />
<display value="Care plan" />
</coding>
</class>
<subject>
<reference value="https://demographics.spineservices.nhs.uk/STU3/Patient/9876543210" />
</subject>
<indexed value="2016-03-08T15:26:01+01:00" />
<author>
<reference value="https://directory.spineservices.nhs.uk/STU3/Organization/RGD" />
</author>
<custodian>
<reference value="https://directory.spineservices.nhs.uk/STU3/Organization/RR8" />
</custodian>
<relatesTo>
<code value="replaces" />
<target>
<identifier>
<system value="urn:ietf:rfc:3986" />
<value value="urn:oid:1.3.6.1.4.1.21367.2005.3.6" />
</identifier>
</target>
</relatesTo>
<content>
<attachment>
<contentType value="application/pdf" />
<url value="https://p1.nhs.uk/MentalhealthCrisisPlanReport.pdf" />
<creation value="2016-03-08T15:26:00+01:00" />
</attachment>
<format>
<system value="https://fhir.nhs.uk/STU3/CodeSystem/NRL-FormatCode-1" />
<code value="urn:nhs-ic:unstructured" />
<display value="Unstructured Document" />
</format>
<extension url="https://fhir.nhs.uk/STU3/StructureDefinition/Extension-NRL-ContentStability-1">
<valueCodeableConcept>
<coding>
<system value="https://fhir.nhs.uk/STU3/CodeSystem/NRL-ContentStability-1" />
<code value="static" />
<display value="Static" />
</coding>
</valueCodeableConcept>
</extension>
</content>
<content>
<attachment>
<contentType value="text/html" />
<url value="https://p1.nhs.uk/MentalhealthCrisisTeam" />
<creation value="2016-03-08T15:26:00+01:00" />
</attachment>
<format>
<system value="https://fhir.nhs.uk/STU3/CodeSystem/NRL-FormatCode-1" />
<code value="urn:nhs-ic:record-contact" />
<display value="Contact details (HTTP Unsecured)" />
</format>
<extension url="https://fhir.nhs.uk/STU3/StructureDefinition/Extension-NRL-ContentStability-1">
<valueCodeableConcept>
<coding>
<system value="https://fhir.nhs.uk/STU3/CodeSystem/NRL-ContentStability-1" />
<code value="static" />
<display value="Static" />
</coding>
</valueCodeableConcept>
</extension>
</content>
<context>
<period>
<start value="2016-03-07T13:34:00+01:00" />
</period>
<practiceSetting>
<coding>
<system value="http://snomed.info/sct" />
<code value="708168004" />
<display value="Mental health service" />
</coding>
</practiceSetting>
</context>
</DocumentReference>JSON
{
"resourceType": "DocumentReference",
"id": "0353e505-f7be-4c20-8f4e-337e79a32c51-76009894321256642261",
"meta": {
"profile": [
"https://fhir.nhs.uk/STU3/StructureDefinition/NRL-DocumentReference-1"
]
},
"masterIdentifier": {
"system": "urn:ietf:rfc:3986",
"value": "urn:oid:1.3.6.1.4.1.21367.2005.3.7"
},
"status": "current",
"type": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "736253002",
"display": "Mental health crisis plan"
}
]
},
"class": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "734163000",
"display": "Care plan"
}
]
},
"indexed": "2016-03-08T15:26:01+01:00",
"subject": {
"reference": "https://demographics.spineservices.nhs.uk/STU3/Patient/9876543210"
},
"author": [
{
"reference": "https://directory.spineservices.nhs.uk/STU3/Organization/RGD"
}
],
"custodian": {
"reference": "https://directory.spineservices.nhs.uk/STU3/Organization/RR8"
},
"relatesTo": [
{
"code": "replaces",
"target": {
"identifier": {
"system": "urn:ietf:rfc:3986",
"value": "urn:oid:1.3.6.1.4.1.21367.2005.3.6"
}
}
}
],
"content": [
{
"attachment": {
"contentType": "application/pdf",
"url": "https://p1.nhs.uk/MentalhealthCrisisPlanReport.pdf",
"creation": "2016-03-08T15:26:00+01:00"
},
"format": {
"system": "https://fhir.nhs.uk/STU3/CodeSystem/NRL-FormatCode-1",
"code": "urn:nhs-ic:unstructured",
"display": "Unstructured Document"
},
"extension": {
"url": "https://fhir.nhs.uk/STU3/StructureDefinition/Extension-NRL-ContentStability-1",
"valueCodeableConcept": {
"coding": [
{
"system": "https://fhir.nhs.uk/STU3/CodeSystem/NRL-ContentStability-1",
"code": "static",
"display": "Static"
}
]
}
}
},
{
"attachment": {
"contentType": "text/html",
"url": "https://p1.nhs.uk/MentalhealthCrisisTeam",
"creation": "2016-03-08T15:26:00+01:00"
},
"format": {
"system": "https://fhir.nhs.uk/STU3/CodeSystem/NRL-FormatCode-1",
"code": "urn:nhs-ic:record-contact",
"display": "Contact details (HTTP Unsecured)"
},
"extension": {
"url": "https://fhir.nhs.uk/STU3/StructureDefinition/Extension-NRL-ContentStability-1",
"valueCodeableConcept": {
"coding": [
{
"system": "https://fhir.nhs.uk/STU3/CodeSystem/NRL-ContentStability-1",
"code": "static",
"display": "Static"
}
]
}
}
}
],
"context": {
"period": {
"start": "2016-03-07T13:34:00+01:00"
},
"practiceSetting": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "708168004",
"display": "Mental health service"
}
]
}
}
}NRL Retrieval Management
User Access to Information
When a consumer system requests pointers for a patient, the NRL will return all pointers for that patient which are of a type that the organisation has been approved to receive.
Once the pointers have been returned, it is the responsibility of the consuming organisation/system to control which pointers and what information, retrieved using the pointers, is shared with end users. This will require a level of Role Based Access Controls (RBAC) and filtering within the consumer system and should be implemented in line with local access rules to judge whether a given user should be permitted to know that a pointer type exists or be given access to information retrieved using information from a pointer.
Details of access control requirements are outlined on the Access Controls page.
Retrieval Availability
The NRL does not guarantee that records can be retrieved by following information in pointers.
There are complexities associated with retrieving data over a network that are outside of the scope of the metadata 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. The NRL aims to facilitate record retrieval by supporting the SSP retrieval interaction, reducing the need for point-to-point integration between consumer and provider systems. However, providers still have a responsibility to ensure that the pointer metadata accurately reflects the retrieval mechanism and format of the referenced information.
Caching and Storing
It is important that consumers of NRL pointers, and the information retrieved using information from those pointers, can view and make clinical decisions based on the most up-to-date and accurate information available. For this reason, it’s recommended that pointers, and any information retrived using references contained in pointers, is not cached or stored, apart from as part of audit history. The consumer system should therefore request the pointer and perform any data retrieval each time information is needed, as this guarantees the latest information available is always used.