Skip to main content

Transfer of Care APIs

The make-up of the Transfer of Care APIs can be described in terms of a set of layered standards. A fully compliant Transfer of Care solution treats these layers as indivisible.

The Clinical Layer – Professional Standards

Professional standards for digital care records are a fundamental element of delivering successful IT enabled care and interoperability between services. In 2013, the Academy of Medical Royal Colleges (AoMRC) published Standards for the Clinical Structure and Content of Patient Records in an effort to define a set of generic clinical headings.

Adoption of these standards were supported via the NHS Standard Contract, and early examples of AoMRC clinical headings usage for discharges can be found in the Papworth case study and the Oxleas case study

The Professional Record Standards Body (PRSB) has developed and broadened the AoMRC work and have now produced many individual standards that reflect current professional practice. The PRSB work includes new and changed structured content for inpatient and daycase discharge, emergency care discharge and outpatient letters.  

This has been achieved by working closely with its membership which incorporates clinicians, professional bodies, patient/carer groups and vendors. The PRSB standards reflect what information is essential to share to provide high-quality care efficiently that is well-coordinated and meets an individual’s needs.

NHS Digital have utilised the information models produced by the PRSB, at a fixed point, to create the Transfer of Care technical specifications. Subsequent adjustment and publication of the PRSB standards as part of their maintenance activities would not automatically drive a change to the APIs.  

The merits and drawbacks of any API adjustment would need to be considered as part of a benefits analysis embracing changes to all layers. The timing of any evaluation is most likely after much wider adoption of the APIs.


The Terminology Layer – SNOMED-CT

All NHS healthcare providers in England are contractually required to use SNOMED CT.

Transfer of Care structured messages have the capability to carry SNOMED CT encoded diagnosis, procedures, allergies and dm+d encoded medication information. 

Where this capability does not exist or is not usable, secondary care organisations must have plans in place to include encoded information at the earliest opportunity into their Transfer of Care structured messages. 

As a temporary concession, the minimum data set for Transfer of Care allows secondary care organisations to progress with structured messages in the absence of an ability to include this encoded information. With this concession, sections within the message would continue to be denoted using fixed SNOMED CT codes.


The Technology / Representation Layer – FHIR (STU3)

Recognising that Fast Healthcare Interoperability Resources (FHIR) is the international industry standard for integration, NHS Digital took the decision in July 2017 to deprecate Clinical Document Architecture for Transfer of Care and adopt HL7 FHIR (STU3). This was done to avoid the increased clinical risk and cost of a delayed future migration to FHIR.

FHIR standards specific to the NHS include the CareConnect profiles developed by NHS Digital in collaboration with the INTEROPen community. To address the clinical safety case the following documents have been produced:

  • Clinical Safety Case [Archive Content] - for the Curation of National CareConnect FHIR Interoperability Standards as used in Transfer of Care and GP Connect
  • Hazard Log - identified risks and issues for development and implementation of FHIR Resources for Transfer of Care and GP Connect
  • Clinical safety group endorsement - this endorses the clinical safety management approach following by NHS Digital Integration Projects in support of development and planned deployment of FHIR Interoperability Standards as used in Transfer of Care and GP Connect

The Transfer of Care FHIR payload specifications define what relevant resources when bundled together with any additional use case constraints need to be followed by implementers to ensure GP Foundation IT supplier interoperability. Representation of FHIR resources and profiles is achieved with XML. 

The payload specifications were uplifted to “live” status in March 2021 because of extensive first of type testing with leading GP Foundation IT suppliers and volunteer hospitals.


The Transport Layer – MESH

The Message Exchange for Social care and Health (MESH) is a secure service for direct electronic transmission of information. 

Organisations using this service would need their own MESH Mailbox ID, knowledge of appropriate message type identifiers, that is a MESH Workflow ID for each of the message types they send, and for static addressing, details of the recipient MESH Mailbox IDs. The MESH Workflow IDs for the exclusive use of Transfer of Care FHIR messages are as follows:

Use Case

Workflow ID

Workflow ID for Responses

Inpatient/daycase (acute) discharge

TOC_FHIR_IP_DISCH

TOC_FHIR_IP_DISCH_ACK

Emergency care discharge

TOC_FHIR_EC_DISCH

TOC_FHIR_EC_DISCH_ACK

Mental health discharge

TOC_FHIR_MH_DISCH

TOC_FHIR_MH_DISCH_ACK

Outpatient attendance

TOC_FHIR_OP_ATTEN

TOC_FHIR_OP_ATTEN_ACK

Organisations attempting to use the Transfer of Care (ToC) FHIR Workflow IDs for unintended use cases, or for message formats that are not FHIR, would be required to stop and change when detected by NHS Digital. Alternative existing Workflow IDs and a process for creating new Workflow IDs would allow progression under these circumstances.

MESH connects to the Spine infrastructure and supports both ODS Lookup and MESH Demographic Composite Lookup capabilities where static MESH Mailbox ID addressing is not appropriate for the sender.

Other electronic transport approaches such as email and fax are unacceptable for transporting Transfer of Care message types.


Message Distribution and Application-Level Response Layer – ITK3

The Interoperability Toolkit (ITK) specification which all Transfer of Care message types must incorporate received an uplift to live status in March 2021. ITK3 is not a particular release, but instead denotes the use of FHIR messages sent over MESH.

ITK3 provides the message distribution and application-level acknowledgement standard for Transfer of Care. Although MESH has its own error/success level codes, recipient GP Foundation IT systems are required to generate an additional set of application-level responses

Automatic generation of application-level responses is a contributor to the reduction of the work burden at the GP Practice. Secondary care correspondence solutions must handle these response codes and when required appropriately alert staff when action is needed.

Last edited: 22 March 2023 1:37 pm