Generic FHIR Receiver

ID

S76

Version

1.0.0

Type

Standard

Status

Effective

Effective Date

Feb 28, 2021 

Contracting Vehicle(s)

 

Introduction

The Generic FHIR Receiver is a component which will receive messages to the GP Practice which are:

The Generic FHIR Receiver will obtain messages from the MESH Client or API depending on the Workflow ID within the MESH message header.

Various types of messages are received into GP Practices via MESH; some other component (referred to in the documentation as a Message Distributor) will usually handle all the incoming messages for the Practice MESH "mailbox", and distribute them to the appropriate handler for processing according to a workflow identifier and/or other metadata in the MESH header. The Generic FHIR Receiver will, therefore, receive its messages from this Message Distributor.

In summary, the responsibilities of the Generic FHIR Receiver are:

  • Receive incoming ITK3 FHIR messages.

  • Verify the message is a well-formed XML.

  • Verify the message is a valid FHIR message conforming to the ITK3 specification.

  • Match the message subject to a known Patient.

  • Send Infrastructure and Business Acknowledgement messages (which are also FHIR messages which conform to the ITK3 specification) where these have been requested. 

  • Raise workflow tasks as appropriate using the data in the payload.

Requirements

Generic FHIR Receiver background and requirements:

Compliance, Assurance and Testing

Generic FHIR receiver will not be assured in isolation. Assurance will be achieved by the successful development and assurance of the Payloads. 

GP Solution Suppliers wishing to validate their ability to receive and process messages received through GP Connect Messaging use cases will be provided with a “synthetic sender” Solution to facilitate their development process.

This Solution is currently in the design phase. However, it is envisaged that NHS Digital will provide access to a test portal where GP system providers will be able to manually trigger the sending of a test message selected from a set of exemplar messages which conform to the set of messaging use cases defined at the time.

For example, the following steps would represent validation that a message receiver appropriately handles a particular messaging use case:

  1. GP System Supplier tester logs on to NHS Digital portal, select the GP Connect Message “Send Federated Consultation Summary” use case, and triggers sending of an exemplar message for this use case.

  2. The exemplar message is sent to the MESH mailbox associated with the portal login context.

  3. The GP system Supplier retrieves the message from the MESH inbox and processes the message.

  4. During message processing, any requested acknowledgements are sent by the GP provider system to a test mailbox ID specified by NHSD.

  5. The validation reports for the acknowledgements are emailed back to the sender (relies on an email/mailbox having been registered within the synthetic sender).

Positive and negative acknowledgement responses can be triggered, either by using specific Patients, already loaded into the open test environment or by setting the practitioner given name to a specific value.

Dependencies

Creating a compliant implementation requires implementing the following dependent interface Standards:

  • Messaging Exchange for Social Care and Health (MESH) - Message transport mechanism required to receive ITK3/FHIR messages asynchronously

  • Custom Workflows - This component requires functionality to raise workflow tasks to be actioned by a suitable user. If the Practice has a Solution that meets the Custom Workflows Capability then it should be met via that route, otherwise via simple workflow functionality provided with the PIM Solution.

  • Patient Information Maintenance - GP - A link to a PIM Solution is required to match a message to a known Patient

Roadmap

Items on the Roadmap which impact or relate to this Standard

Items on the Roadmap which impact or relate to this Standard