Record locate retrieve

Maturity

Standard

Motivation

Patient information necessary for care may be held on multiple systems e.g. PAS, EHR and ePaCCS. Users can separately access these systems, but this does not provide best UX. It adds additional workload in managing multiple identities and searching separately for patients. It creates clinical risk should users find the wrong patient or if the workload deters them from accessing information that would influence care.

An application can be configured to query another system so that a user knows whether the system holds relevant information about a specific patient.

Questions

• Where information could be held in multiple sources, can we minimise conflicts by agreeing which organisations will share particular data items? Not at present - share all data and user uses judgement. May change this in future.

• Is Patient.contact sufficient to represent the contact details of third parties involved with a patient and differentiated by type (e.g. next-of-kin, carer, clinician)? This also allows an organisation to be referenced if necessary (e.g. out of hours contact team). Yes - use Patient.contact

• MedicationStatement.effective search could be complex to implement (e.g. does an EPS provide sufficient information to reliably assert that a Patient was using the medication on a particular date?). For our purposes would it be better to limit this to the date when the medication was first used/prescribed? Yes

• Flag resource is a warning or notification of some sort presented to the user. There is an overlap with Condition and AllergyIntolerance so that some data could plausibly appear in both. The data models are virtually identical at the moment. Does the extra complexity of adding Flag provide sufficient benefit that it is justified> Yes

• Do we need to standardise use of Encounter.class, Encounter.type? How do we represent Specialty? Unanswered

• Do we want to use a security tag for restricted or sensitive patients? For example:

"meta": {
	"security": [
		{
			"system": "http://hl7.org/fhir/v3/Confidentiality",
			"code": "restricted"
		}
	]
}

(see https://www.hl7.org/fhir/STU3/valueset-security-labels.html)

How many organisations would share info for restricted patients? If all are denying patient then not relevant! All deny so don't need security labelling

Implementation

A standardised approach with a degree of optionality will be adopted to provide flexibility and extensibility for implementers. This flexibility means that additional information is required by the consumer to ensure that information is interpreted in a safe and reliable manner. The server capability statement will be used to describe the behaviour of the system.

The specification is aligned to the CareConnectAPI specification. Only a subset of the CareConnectAPI specification need be implemented to support the SIDeR use cases.

Overview

A client application (e.g. SIDeR Shared Care Record) will orchestrate interaction with various services as shown in the following sequence diagram:

Conventions

The following conventions apply throughout.

CodeableConcept

Where a resource contains a CodeableConcept, a Coding should be provided including a SNOMED-CT code and rubric:

"code": {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "{{SCT_CODE}}",
        "display": "{{SCT_RUBRIC}}"
      }
    ]
  }

Where an organisation is not able to provide a reliable SNOMED-CT code, the text should be provided:

"code": {
    "text": "This is as much as we know!"
  }

Where coded data is available from other systems, this may be included within the Coding:

"code": {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "{{SCT_CODE}}",
        "display": "{{SCT_RUBRIC}}"
      },
      {
        "system": "{{ANOTHER_SYSTEM}}",
        "code": "{{ANOTHER_CODE}}",
        "display": "{{ANOTHER_RUBRIC}}"
      }
    ]
  }

If no SNOMED-CT code is available, the text should be provided:

"code": {
    "coding": [
      {
        "system": "{{ANOTHER_SYSTEM}}",
        "code": "{{ANOTHER_CODE}}",
        "display": "{{ANOTHER_RUBRIC}}"
      }
    ],
    "text": "{{ANOTHER_RUBRIC}}"
  }

Paging of search results

Endpoints must implement paging of search results so that response size can be constrained.

Endpoints should implement the _count parameter so that consumers can indicate the preferred page size for their use case.

Consumers must provide capability for users to retrieve further pages of results so that complete records can be viewed on demand.

Data currency

Where an organisation shares data that is not current (e.g. it is taken from a data warehouse populated overnight) it must indicate how current the data are.

The Bundle resource returned by each search operation must include the meta.lastUpdated field, for example:

{
  "resourceType": "Bundle",
  "meta": {
    "lastUpdated": "2020-01-01T12:00.000Z"
  }
}

If meta.lastUpdated is not supplied it is assumed that the data are current at time of the request.

Selective Resource Display

FHIR Endpoints can optionally add a Meta tag to individual FHIR resources to specify whether or not the resource should be displayed in the Shared Care Record.

The tag can have one of three values:

{
  "system": "https://fhir.blackpear.com/ui/shared-care-record-visibility",
  "code": "summary",
  "display": "Display in Summary and Detail View"
}

{
  "system": "https://fhir.blackpear.com/ui/shared-care-record-visibility",
  "code": "detail",
  "display": "Display in Detail View"
}

{
  "system": "https://fhir.blackpear.com/ui/shared-care-record-visibility",
  "code": "none",
  "display": "Do not Display"
}

The visibility of the resources will then be determined by the following rules:

1. A resource with no tag matching the system https://fhir.blackpear.com/display/shared-care-record-visibility will be displayed in all areas of the Shared Care Record.
2. A resource with the summary code will be displayed in all areas of the Shared Care Record.
3. A resource with the detail code will only be displayed in the per-organisation tabs of the Shared Care Record.
4. A resource with the none code will not be displayed in the Shared Care Record.

e.g.

{
  "fullUrl": "https://sider.ydh.nhs.uk/3_0_1/MedicationStatement/11",
  "resource": {
    "resourceType": "MedicationStatement",
    "id": "11",
    "meta": {
      "lastUpdated": "2019-03-12T14:14:33.809+00:00",
      "profile": [
        "https://fhir.hl7.org.uk/STU3/StructureDefinition/CareConnect-MedicationStatement-1"
      ],
      "tag": [
        {
          "system": "https://fhir.blackpear.com/ui/shared-care-record-visibility",
          "code": "detail",
          "display": "Display in Detail View"
        }
      ]
    },
    "status": "active",
    "subject": {
      "reference": "https://blackpear.com/Patient/1234567890"
    },
    "dosage": [
      {
        "text": "one in the morning"
      }
    ],
    "contained": [
      {
        "resourceType": "Medication",
        "id": "8",
        "meta": {
          "profile": [
            "https://fhir.hl7.org.uk/STU3/StructureDefinition/CareConnect-Medication-1"
          ]
        },
        "code": {
          "text": "Furosemide 20mg tablets"
        }
      }
    ]
  }
}

CapabilityStatement

Endpoints must support the FHIR REST API capabilities interaction.

Patient search

Endpoints must implement a Care Connect API Patient search.

Example data from Care Connect reference implementation

Search parameters

Implementations must:

• support identifier parameter where system=https://fhir.nhs.uk/Id/nhs-number
• support birthdate parameter

Consumers must:

• provide both identifier(nhs-number) AND birthdate when searching so that endpoints can match accurately with internal systems

Response

Clients may assume that if no matching patient is returned from an endpoint, no additional resources (e.g. Encounters) will be available.

Patient resource will be decorated with:

• Responsible clinicians and social care professionals & contact details (Patient.contact)
• Home support details including carer contact details (Patient.contact)
• Next of kin contact details (Patient.contact)
• Communication needs (e.g. hearing loss/ preferred language) - using extension for NHS Communication

Restricted patients

Organisations may choose to restrict sharing of information to respect client wishes and/or legal status and/or court order. In this case the organisation may:

• return all information
• return limited information.
• return no information for patient, but signpost
• report that patient does not exist on their system

Implementations must:

• document their behaviour with respect to restricted patients (i.e. within their capability statement)

Data suppression

Where data have been suppressed the endpoint may decorate the returned Bundle with an OperationOutcome resource with issue.details.coding identifying the reason for suppression; this is contained in entry with search.mode = outcome [https://hl7.org/fhir/R4B/operationoutcome.html]. For example:

{
  "resourceType": "OperationOutcome",
  "issue": [
    {
      "severity": "warning",
      "code": "suppressed",
      "details": {
       "coding": [
           {
				"system": "http://snomed.info/sct",
				"code": "416409005",
				"display": "Refused consent for upload to local shared electronic record (finding)"
           }
         ] 
      }
    }
  ]
}

Encounter search

Endpoints should implement a Care Connect API Encounter search search so that Clinical Encounters data can be shared.

Example data from Care Connect reference implementation

Search parameters

Implementations must:

• support date parameter
• support patient.identifier parameter where system=https://fhir.nhs.uk/Id/nhs-number

Response

period

Encounter can be used to represent episodes of care as well as individual encounters.

Where only one date can be reliably determined, use this for both period.start and period.end:

"period": {
  "start": "2018-01-04",
  "end": "2018-01-04"
}

For a longer episode of care (lasting more than 1 day), response should include both period.start and period.end. For example, an inpatient stay:

"period": {
  "start": "2018-01-04",
  "end": "2018-01-18"
}

An ongoing episode of care can be shown using the status. In this case period.end may be populated if known.

"status": "in-progress",
"period": {
  "start": "2018-01-04"
}

Similarly, a planned episode of care can be shown using the status:

"status": "planned",
"period": {
  "start": "2020-12-20"
  "end": "2020-12-28"
}

MedicationStatement search

Endpoints should implement a Care Connect API MedicationStatement search search so that Active Medications data can be shared.

Search parameters

Implementations must:

• support patient.identifier parameter where system=https://fhir.nhs.uk/Id/nhs-number
• support status parameter. For initial use cases only active medication is required.
• support effective parameter.

MedicationRequest search

Endpoints should implement a Care Connect API MedicationRequest search search so that Active Medications data can be shared.

Search parameters

Implementations must:

• support patient.identifier parameter where system=https://fhir.nhs.uk/Id/nhs-number
• support status parameter. For initial use cases only active medication is required.
• support effective parameter.

AllergyIntolerance search

Endpoints should implement a Care Connect API AllergyIntolerance search search so that Active allergy data can be shared.

Search parameters

Implementations must:

• support patient.identifier parameter where system=https://fhir.nhs.uk/Id/nhs-number
• support date parameter

Response

Where no known allergy is recorded for a patient, this can be returned using:

"code": {
    "coding": [
        {
            "code": "716186003",
            "display": "No known allergy",
            "system": "http://snomed.info/sct"
        }
    ]
}

Condition search

Endpoints should implement a Care Connect API Condition search search so that Active conditions and diagnoses can be shared.

Search parameters

Implementations must:

• support asserted-date parameter.
• support clinical-status parameter. It is acceptable if results are only returned for active.
• support patient.identifier parameter where system=https://fhir.nhs.uk/Id/nhs-number.

DocumentReference search

Endpoints should implement a CareConnect API DocumentReference search.

In the initial phases, organisations may propose the data and formats they wish to share based on domain knowledge and complexity of implementation. It is expected that the content provided by each organisation will evolve over time in parallel with user requirements and that there will be harmonisation of structured coded content by adoption of FHIR profiles.

Search parameters

Implementations must:

• support created parameter.
• support patient.identifier parameter where system=https://fhir.nhs.uk/Id/nhs-number.
• support status parameter with value current

Implementations must:

• document the document and data types expected to be returned. (i.e. within their capability statement)
• initially provide Active Care Plans

Flag search

Endpoints should implement a CareConnect API Flag search search so that Active flags can be shared.

It is likely that some Flag resources will also be represented in other resources e.g. AllergyIntolerance, Condition

Search parameters

Implementations must:

• support date parameter.
• support patient.identifier parameter where system=https://fhir.nhs.uk/Id/nhs-number.
• support status parameter with value active

Response

Where a Flag is recorded for a patient, this should be returned using a SNOMED-CT code taken from a locally agreed set between the providers. The previous SSCR-Alerts-SnCT ValueSet is now deprecated.

A patient with a Flag to indicate a condition of Asthma can be shown using:

"code": {
    "coding": [
        {
            "code": "195967001",
            "display": "Asthma",
            "system": "http://snomed.info/sct"
        }
    ]
}

Where flags have been created for other resources, e.g AllergyIntolerance resource describing an allergy to Penicillin, these should also be returned within the search:Flag response so that users with more restricted roles are aware of the information.

Appointment search

Endpoints should implement a FHIR STU3 Appointment search search so that planned or cancelled encounters can be shared.

Search parameters

Implementations must:

Response

Bundle of Appointment resources