• API Hub
  • Search loading...

    API Hub

    Explore and Make use of Nationally Defined Messaging APIs

     

    Send Federated Consultation Report - Overview

    Overview of the use case to send a federated consultation report to the registered practice of a patient.

    Supporting federated working patterns

    One of the main areas of focus for the GP Connect product as a whole is to support GP practice federated work patterns.

    Firstly, some terms are defined to provide to provide clarity:

    • A federation is a group of GP practices working together within their local area, in some sort of collective legal or organisational entity to deliver services such as out of hours care.
    • A registered practice is a practice within the federation which at which the patient has a care record of type Regular (GMS/PMS).
    • A federated practice is practice within the federation at which the patient does not have a care record of type Regular (GMS/PMS)

    Federated appointments use case

    This use case completes the set of capabilities required to fulfil the following workflow:

    1. The GP Connect Appointments FHIR API enables booking of a consultation at a federated practice.
    2. The GP Connect Access Record HTML FHIR API enables an amenable consultation to take place at the federated practice through access to the patient record stored at the patient’s registered practice.
    3. After the consultation, the Send Document GP Connect Messaging enables the details of this consultation to be written back to the registered practice so that the registered practice patient record continues to provide an up-to-date view of care which the patient receives in a GP practice setting.
    It is worth emphasising that the first two steps above use synchronous GP Connect FHIR API capabilities, and that an asynchronous messaging approach is taken to facilitate the update made at the registered practice by the final step.

    Message flows in Send Federated Consultation use-case

    The following diagram illustrates how messages flow between the federated practice and the registered practice via MESH to fulfil this use case:

    Federated Consultation Sequence Diagram

    The diagram above depicts a successful message flow where registered practice message processing validates and matches the initial message successfully to a patient. This is involves the following steps:

    Event / Step Description
    1 Federated consultation summary message
    1a
    After the federated consultation is complete, a trigger at the federated practice results in a FHIR Message being constructed which includes a PDF describing the consultation
    1b
    The MESH client at the federated practice sends the message to the MESH server where it awaits collection by the registered practice
    1c
    The MESH client at the registered practice collects the message from the MESH server and makes it available to other registered practice system components for onward processing
    1d
    The message is processed at the registered practice. Frequently this will result in a task being created in the practice workflow
       
    2 Infrastructure ackowledgement ITK Response
    2a
    When the federated consultation report message is passed from the MESH client for processing at the registered practice, the message is first validated to ensure that it’s structure is correct. An ITK3 Response message is generated which indicates the success of message processing at a technical level - this is known as an “infrastructure acknowlegement”.
    2b
    The MESH client at the registered practice sends the message to the MESH server where it awaits collection by the federated practice
    2c
    The MESH client at the federated practice collects the message from the MESH server makes. The ITK Response is then available to other federated practice system components for onward processing
    2d
    The acknowledgement message is processed as appropriate by the federated practice.
       
    3 Business ackowledgement ITK Response
    3a
    When the federated consultation report message is passed from the MESH client for processing at the registered practice, after successful message validation, the subject of the message contents - the patient - is looked up to ensure that patient is known and registered at the practice. An ITK3 Response message is generated which indicates the success of patient matching - this is known as a “business acknowlegement”.
    3b
    The MESH client at the registered practice sends the message to the MESH server where it awaits collection by the federated practice
    3c
    The MESH client at the federated practice collects the message from the MESH server makes it available to other federated practice system components for onward processing
    3d
    The acknowledgement message is processed as appropriate by the federated practice.

    Message creation at federated practice

    The following processing steps must take place at the federated practice system to create the message - as described in step 1a above.

    Step Description
    1
    Initiate process to create for federated consultation summary message. Refer to Send Trigger for guidance on available options
    2
    Create ITK3 payload: Construct a PDF description of the encounter, embed in Task resource, and include resources referenced from the Task
    3
    Wrap the payload as an ITK3 message, requesting infrastructure and business acknowledgements.
    4
    Create MESH message. Specify NHS Number, DOB and Surname in MESH metadata to enable MESH to route to registered practice.
    Tags: mesh itk3

    All content is available under the Open Government Licence v3.0, except where otherwise stated