Introduction

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

• Delivered using Messaging Exchange for Social Care and Health (MESH)
• structured using FHIR STU3 messages
• which meet the ITK3 specification

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

Capability Associations and Interop Dependencies

This section lists the Capabilities this Standard is associated with and any other Interop Standards which are needed to meet this standard (subject to change or refinement)

Generic FHIR Receiver background and requirements:

Compliance, Assurance & 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.

Roadmap