Date: 2023-03-14

Status

Accepted

Context

Our architecture currently sets out the use of the National Events Management Service (NEMS) as the subscription management system and Message Exchange for Social Care and Health (MESH) as the message delivery system.

NEMS is a publish-subscribe subscription management system that allows for subscriptions to be created, and thereafter filters and distribute messages that are published to it. It is designed to do this and is a live production-ready service currently supported by NHS England.

In our pilot system, the messages from the hospital will be converted to the FHIR STU3 resources required by NEMS, and NEMS is responsible for removing messages we do not have a subscription for and then onward delivery to us via MESH. We will need an event type focussed on admissions to be able to publish our messages to the system.

There are some disadvantages of using NEMS. Namely, the only way of receiving messages from NEMS is to do so via MESH which requires an additional integration. It also requires the use of the older STU3 (CareConnect in the UK) version of FHIR rather than the latest R4 version (UK Core in the UK).

Due to timeline constraints we need to have a working service by the end of March 2023. We have met with the NEMS team and now know that:

  1. No current event type for admissions exists on the system
  2. Adding a new event type for admissions is not possible within our timelines

In addition, a new national messaging system is currently in development but is not yet ready for our use.

We could either wait, and continue to use NEMS (and MESH) when capacity becomes available to implement a new message type, or we can proceed immediately, removing NEMS (and MESH) from our architecture and ensuring decisions are compatible with a future messaging system.

Decision

We will remove the use of NEMS and MESH from our architecture.

Specifically this means:

  • We will have messages delivered directly to our subscription handler over HTTPs rather than over MESH
    • We will use an AWS API Gateway to expose a Lambda Function to handle message arrival
    • In order to preserve state we will place messages that arrive onto an SQS Queue
  • We will change the way we salt messages (superseding 002 - Salt NHS Number hashes for storage)
    • We will use scrypt rather than SHA3-256 to increase the difficulty of dictionary attacks
    • We will use Date of Birth in YYYY-MM-DD format as a salt
    • We will use the following parameters for scrypt (each contributes to the total memory and CPU usage)
      • N (iterations count) = 32768
      • r (block size) = 12
      • p (parallelism factor) = 6
      • 128 * N * r * p = 301,989,888 bytes = 288 Mb in memory usage (see here for calc format)
  • We will perform the filtering of messages ourselves as this will no longer be performed by NEMS
    • We will provide an endpoint on the Django web back-end to allow for lookup of the care provider email based on the NHS Number of received messages
    • To mirror the layout of the future messaging service, this will occur during message translation rather than in the subscription handler
  • We will continue to provide a mock subscription creation / deletion function to ensure any future messaging service can be placed into the architecture easily
  • We will move all of our resources to use FHIR R4 (UK Core) rather than FHIR STU3 (CareConnect)
    • We will use JSON for all FHIR transactions rather than mostly using JSON but dealing with the receipt of XML messages.
  • We will continue to design with any future national NHS messaging service in mind

Consequences

In the short term, there are few consequences of the above, as much of the implementation that depends on NEMS/MESH has not been started yet. The consequence in change of design of salting has been outlined above.

It somewhat increases development effort, but reduces integration effort so the net amount of development effort required remains the same.

In the longer term these decisions restrict (or complicate) future options.

In regards to NEMS specifically:

  • Our use of JSON FHIR R4 resources will mean we cannot use NEMS until they support JSON FHIR R4 resources (at least being able to validate and transport them)
  • Our removal of MESH means we would need to implement a MESH interface to read messages onto our processing queue if we used NEMS in the future - this would be relatively simple due to our modular architecture
  • We have not asked to be on their roadmap, so would still need to do this and accept the lead time if we wanted to use NEMS in the future

Our modular architecture means we could use any messaging system in the future, provided we can use our FHIR R4 resources.

This flexibility will continue to be useful, especially with a longer-term ambition to use the new messaging service.