Alternative Events Model

The two main mechanisms for implementing Publish/Subscribe (Pub/Sub) notification mechanisms are FHIR Subscriptions and Event Notifications, via the Multicast Notification Service (MNS) and the National Events Management Service (NEMS), using messaging in FHIR STU3. The MNS service is built using FHIR R4, utilising the Subscriptions Backport IG to backport funstionality from FHIR R5.

The FHIR Workflow approach is described on the Interactions page, which decribes when events may be triggered to notify organisations when data relevant to them has been received by the Genomic Order Management broker.

Publishing and receiving requirements

The preferred Events model for the Genomic Order Management Service is MNS.

Within MNS, events are sent to notify subscribers when genomic tests, reports, samples, tasks or consent records are created, updated, or reassigned. Details on onboarding and integration with the Multicast Notification Service are available on the Genomic Order Management Event Catalogue.

Currently, the Genomic Order Management Service is the only planned publisher of events. Events will contain the notification only, providing pointers to the data relevant for the event, for retrieval.

To retrieve events, subscribers are required to onboard on to MNS and send in subscription resources detailing the types of events they would like to be notified about, 'filters' in MNS parlance. These include filters on resource types, statuses for those resources and the ODS codes relevant for those resources, e.g. requesters and nominated performers for requests or owners of tasks.

It is expected GLHs/Labs would subscribe to Order (ServiceRequest) and Task creation events, and Requesters would subscribe to Report creation and Task update events.

Task Notifications

Pro-active Notification

For pro-active notification of task and test report creation or updates, where the test order service sends the Task and other resources to a receiving organisation/service, that receiving system SHALL also expose multiple API endpoints to enable that notification to be consumed. Alternative mechanisms such as use of messaging via MESH could be used to push notifications as messages rather than the receiving system needing to expose API endpoints. The channels supported by the MNS service are described on the MNS API Catalogue page.

Due to the short timescales for alpha delivery and possible technical immaturity of participating organisations, making exposing an API or processing a message over MESH challenging, the initial alpha build relied on polling to identify new and updated resources. Proactive notifications is being considered within the private Beta phase.

Whilst MNS is the proposed notification mechanism, there are many options when it comes to pro-active notification, one or more of the below options could be implemented/integrated in the future.

Mechanism Comment
National Events Management Service (NEMS) NEMS implements a publish and subscribe pattern so would be ideal for organisations to receive tasks and updates. There are a few of significant blockers for use of the current NEMS service. - The NEMS service is currently using FHIR STU3, so is not compatible with the UK core resources which the test order system will use. - The service has a principle for light weight payloads where a pointer to where information can be retrieved is shared rather than the content, this would mean that a notification could be sent that a test has been created for an organisation, removing the need to poll, but would not stop a chatty interaction to get all the details about the task and referenced resources unlike if all the detail was sent with the message. - The onboarding, development & assurance of new event types can be lengthy and may not be achievable for the alpha.
Other R4 messaging services There are a number of other services looking at a FHIR R4 messaging capability which supports publish and subscribe as well as other routing mechanisms. NHS England messaging services would most likely implement a common authentication mechanism to that used by the test order service through API-M, facilitating adoption by other services.
MESH As the intended target of a task is known by the test order service it could directly forward the task data to the organisation using their ODS code and MESH. However, the future of the service is unknown, with a Multicast Notification Service (MNS) being proposed as a more extensible solution. MESH would allow the whole FHIR bundle to be shared so could be an efficient way of notifying a consumer of the information.
FHIR RESTful API calls Connected systems could expose APIs for the service to POST resources to their system as a notification. To support the sending of new Tasks, Task updates and DiagnosticReports the services would have to implement the FHIR transaction interactions and the put interactions. They would not need to implement any of the read or search capabilities. There are a number of risks around this approach: - Managing send failures, deciding on retries and assessing the clinical risk if the information does not get to the target system. - API versioning, if the API is updated to include new elements or resources, if value sets are updated or code systems are added there is an increased risk that requests will be rejected if the target system has not implemented the update APIs.
NHS eMails Utilising NHS email capabilities for notification

Poll Based Notification

For notification of Tasks and DiagnosticReports using a polling architecture, the receiving organisation/service needs to call the Test Order Service APIs to query for new or updated Tasks and/or DiagnosticReports, they will NOT need to expose APIs from their system. Different organisations will want to use different filters when querying the test order service, such as using their ODS code as the requester for search service request, the status of a DiagnosticReport to filter down to interim or final test reports etc.

One down side of polling for updates using the RESTful APIs is that the querying system may need to make subsequent requests to other APIs endpoints on the test order system to retrieve referenced resources, such as the Patient, PractitionerRole, ServiceRequest and Specimen, etc. The FHIR _include and _revinclude search parameters will be supported for some references which can be used to minimise the number of requests that are needed as this will allow referenced resources to be returned in the same bundle as the search results.

With polling there is a risk that the API would become a highly 'chatty' interaction between the systems, meaning more transactions, more processing time and more cost for both the central Test Order Service and consuming organisations/services, therefore, strategically, the pro-active notification is the preferred model, with polling as a backup capability where the connecting systems are not able to implement or expose an API from their systems.

The following are the key notification points:

Notification Point Reason
Creation of new Task resource So organisations are informed of tasks they are being asked to perform
Update to Task resource So organisations know when tasks they own or have involvement in have been updated or completed. This will include if the specimen or test is rejected
Creation of DiagnosticReport resource To inform the requester/requesting EHR that the test has been completed and to share the DiagnosticReport
Update of DiagnosticReport resource To inform the EHR that the DiagnosticReport has been updated

For a user of the central service's proposed web portal, notifications would be triggered as the user session commences. In most cases a poll based approach will be utilised to query into the central services and provide updates to users depending on the UI context.