Patterns

Definition

Request-response, also known as request-reply, is a message exchange pattern in which a requestor sends a request message to an external system which receives and processes the request, ultimately returning a message in response. The pattern allows two systems to have a two-way conversation with one another.

When you would use request-response

Request-Response is the most commonly implemented integration pattern and is used to support:

• requests for information
• access to transactional services
• situations where information is being provided or a command issued (such as requests for workflow to be initiated) to an external service and an acknowledgement is required that the information has been received and processed, or that the command has been actioned

Benefits of the request-response pattern

The benefits of the pattern are that it avoids data having to be replicated across multiple systems. This aligns with the principle that digital services should only store data once (usually where collected) and make it available via open application programming interfaces (APIs) whilst maintaining privacy and security.

It also avoids clinical risk of data becoming stale or incorrect where shared and consumed data might not contain changes or corrections, retrieval ensures the consumer has the most up to date and correct data.

There are no significant drawbacks to implementing this pattern.

The default method for implementing the request-response pattern is via a synchronous interaction.

Exceptions can include where:

• the request requires manual fulfilment, meaning a human activity needs to be undertaken, in which case it will not be possible for an immediate response to be returned
• there are non-functional considerations, such as long running transactions, receiving system unable to process requests immediately due to capacity issues, that require an asynchronous interaction to be implemented

FHIR exchange paradigm 

We strongly recommend exchanging data for the request/response pattern by exchanging UK Core resources using the FHIR http exchange paradigm. FHIR http expresses requests as Create/Read/Update/Delete (CRUD) operations upon resource endpoints which are exposed by an HTTP server.

Where the nature of the request being made is clearly the invocation of a business service, or the called function cannot be expressed easily as a granular CRUD operation, the operations framework extends FHIR http for these scenarios. These calls can be defined alongside Restful CRUD requests in the same API. Before diverging to use this remote procedure call (RPC) style of API call, please consider whether the service can be refactored to be expressed in a RESTful manner.

Definition

Publish subscribe is an asynchronous messaging pattern that decouples services that produce events from services that process events. Information sources 'publish' (send) messages to a middleware component, and information consumers 'subscribe' by specifying which messages they want to receive from the middleware component. The middleware component must be able to physically transport messages from one or more publishers to one or more subscribers.

Core concepts

Topic - a named resource to which messages are sent by publishers.

Subscription - a named resource representing the stream of messages from a single, specific topic, to be delivered to the subscribing system.

Message - the combination of data and (optional) attributes that a publisher sends to a topic and is eventually delivered to subscribers.

When you would use publish subscribe

In some scenarios, there are potentially multiple systems interested that information has been generated (an event has occurred or new information about a patient has been recorded) who need to be informed and cannot wait till they next access the relevant record to know about the new information. In addition, the recipients of the information may not know the source of records or, where they do know the source, it would not be practical to continually 'poll' the source system for updates.

Usage of the publish subscribe pattern is dependent upon it being possible to define clear rules for subscribing to information that can be implemented within a middleware component. These may include:

• use of a widely known identifier, such as NHS Number or Organisation Data Service (ODS) code
• clearly defined geographic rules, such as local authority area

Benefits and limitations of the publish/subscribe pattern

The benefits of the pattern are that it: 

• allows business events to be proactively shared with interested parties to enable them to take appropriate and timely action in response to the event
• allows business events to be widely shared with event consumers in control of which events they wish to receive
• allows systems to communicate progress against a specific workflow, such as what tasks and procedures have been completed
• can be used to decouple systems - the message sender and the message consumer do not require any knowledge of each other for relevant event information to be shared

There are a number of limitations the publish subscribe pattern that should preclude it from being used for sharing information in certain circumstances.

It should not be used where the 'publisher' requires an acknowledgement that a message has been received and/or successfully processed by a subscribing system. The publish subscribe pattern will only provide an acknowledgement that a component has been received by the middleware component, NOT that it has been received and processed by a subscriber system.

It should not be used when the information being sent by the publisher needs to be read by the middleware component and action taken according to the content of the message; this may include functionality such as content-based routing - that is, determining the recipients of information based upon the type/values of attributes.

It is potentially problematic to use where a system can be both a publisher and subscriber of information. In this circumstance a publisher could also potentially receive information that it had published itself and would therefore need to be able to 'filter' out these records placing an additional burden upon the system developer.

It does not provide guaranteed delivery (at least not in the context of the NHS England implementation).

Additional consideration

Consideration must be given as to how much information needs to be made available in the 'published' message, such as:

1. Just enough information to provide context, that an event has occurred for example, with the recipient able to retrieve further information on demand (via the request-response pattern). This is the preferred approach and is referred to as the 'notify and retrieve' pattern.
2. Full details contained in the payload to avoid the requirement to make a request to retrieve additional information. This approach should only be utilised where the full payload is required to provide context or potentially for performance reasons where in the majority of cases the subscriber would make a call-back to retrieve further information.

Reliability of the shared information - could the shared information become invalid and introduce clinical risk?

Granularity of information sharing and subscriptions mechanism. The consumer must be able receive information they require without being swamped by information they do not require and related information governance around sharing what is needed.

Logical pattern

Subscribers are able to create new subscriptions to a particular topic through a request to the Pub/Sub Server. The request describes the conditions when a subscriber wishes to receive a message, such as:

• specific identifier (NHS Number, ODS code)
• specific rule (local authority area, clinical commissioning group area)

The Pub/Sub Server stores details of all subscriptions that have been made. It returns an acknowledgement to the subscriber that the request was successful (or rejection where the subscriber is not authorised to subscribe to a particular topic).

When new information is available the publisher sends this to the Pub/Sub Server (via a synchronous or asynchronous transaction) which determines relevant subscribers using:

• topic and identifier (such as NHS Number)
• topic and rule (such as patient residing in specific local authority)

The Pub/Sub Server sends message to subscriber (via synchronous or asynchronous transaction).

Physical pattern

Subscribe pattern

Publish pattern

The publish subscribe pattern is implemented within the National Events Management Service which is deployed on the Spine. The National Event Management Service is made up of:

• FHIR APIs (synchronous interactions), which include Subscription API (used by subscribers to create new subscriptions) and Publish API (used to publish new messages)
• store of subscriptions (within Spine Clinicals)
• service to lookup subscriptions and send messages to subscribers - these can be sent via MESH (asynchronous interactions) or REST API (synchronous interactions)

FHIR exchange paradigm 

The recommended means of exchanging data when a publish/subscribe pattern is chosen is to exchange UK Core resources using FHIR Messaging exchange paradigm. This paradigm is a good fit where there is a high level of de-coupling between sending and receiving systems, and where a traditional messaging approach is taken to deliver messages using a store and forward architectural pattern.

Definition

The Information push pattern is used when a sender has to send a message to a specific receiver. In the context of this pattern this would involve a transfer of information or notification of an event to an external organisation with no business acknowledgement required.

There are a number of variations on this pattern.

Hub and Spoke

The Hub and Spoke pattern is used when a sender has to send a message to a known receiver and performs this via a messaging hub. The hub is used to broker the information transfer so that the Information source does not need to know the address of the consumer.

Point to point

The Point to Point pattern involves information being sent directly to an information consumer. The key difference with the Point to Point pattern is that the information source requires the address of the consumer and therefore no hub is required, meaning there is a direct interaction between the information source and information consumer. The Hub and Spoke model is preferred as this avoids tight coupling between applications but the business scenarios described below are equally valid for point to point interactions.

Messaging channel

The messaging channel pattern is similar to the Hub and Spoke pattern with the information source writing information (or an event) to a specific channel from where it will be retrieved via the information consumer.

When you would use the Information Push pattern

Use when information has been captured or an action has occurred, and it is clear where the related information needs to be sent (or it can be easily derived).

Benefits and limitations of Information Push pattern

Benefits of the pattern are that:

• it is simple and quick pattern to implement
• it allows business events to be proactively shared with interested parties to enable them to take appropriate and timely action in response to the event
• information governance is easier to manage – it is clear what information is being shared between organisations

A limitations of the pattern is that it can create integration issues where information subsequently needs to be shared with another receiver. In this case it can:

• add complexity by having to push updates to multiple systems/care settings with all systems needing to agree on the format and meaning of the data that is being exchanged
• reduce agility - where requirements around what information is being shared change this can involve changes to multiple systems needing to be synchronised or the hub system having to support multiple versions of messages

For this type of integration any of the interaction methods (synchronous, asynchronous, or bulk transfer) could potentially be valid. A reliable method of transferring information is required with a technical acknowledgement that information has been received so that the provider can an continue with other processing as soon as the receiver/middleware has accepted the message. 

Summary of Options:

Synchronous interaction method

A synchronous interaction method can be used with a technical acknowledgement returned immediately once the request message has been accepted by the provider - this would usually be at the point the provider had validated the message to ensure it was able to process it. Following the return of the acknowledgement the provider is responsible for fulfilment of the request including any exception handling. This is referred to as the 'promise of work' pattern and is the preferred implementation approach for this pattern.

Benefits and limitations of this approach

Benefits are that it:

• allows a consumer to continue with processing once it has received an acknowledgement that the message has been received - that is, it does not need to wait for confirmation that the request has been fulfilled
• supports real (or near) real-time updates (if the provider is able to process messages upon receipt)
• is a simple method for consumers to implement

Limitations are that it:

• adds a dependency upon the provider to be able to guarantee that received messages will be processed - that is, no data loss
• requires both systems to be available for the information to be exchanged

Asynchronous interaction method

An asynchronous interaction method can be used with a middleware component. For example, MESH is used to reliably transfer information from the consumer to provider. This is also known as the 'messaging-channel' pattern with information relayed to a specific messaging channel from where it is retrieved.

Benefits and limitations of this approach

Benefits are that it:

• allows a consumer to continue with processing once it has received an acknowledgement of receipt by the middleware component
• decouples consumer and provider (client and recipient)
• is a simple pattern for client to implement

Limitations are that it:

• can lead to complexity with exception handling where the middleware does not fully validate messages
• can lead to delays in updates being applied

Bulk transfer

Bulk Transfer (implementing point to point pattern) is a potential method where there is no requirement to have a real-time view of data. However, the use of batch will provide less flexibility if in the future a real-time view of data is required or if the data needs to trigger a task or workflow.

Therefore the guidance is to consider a synchronous or potentially an asynchronous interaction in the first instance.

FHIR exchange paradigm 

For the synchronous interaction model, FHIR http is the recommended means of exchanging data. FHIR Messaging should be used where an asynchronous interaction model is chosen.

In both these models, UK Core provides the set of data entities to be used.

Definition

This pattern relates to authoritative records existing in a shared repository. In circumstances where related information can be captured via a wide variety of sources there are potential advantages to combining the information within a central repository (database). This allows consumers to be able to retrieve an authoritative view of the information from a single source.

When you would use a shared repository

Related information can be captured via potentially multiple systems and there is a requirement for an authoritative single source of the information to support direct care.

There is a clear mandate (both clinically and politically) for specific information to be held and made available within a shared repository.

Benefits and limitations of Shared Repository

Benefits are that:

• it allows an authoritative and trusted source of data to be created and made widely available
• by combining records within a single repository, a system does not need to access potentially multiple systems to obtain an aggregated record
• it allows business rules to be applied against a consolidated set of records

A limitation is additional data replication. Data is held within both the central repository and the local system.

There is no standard for a physical implementation of a Shared Repository. Guidelines for patterns for accessing the repository (updates or retrieval of information) will be like any other information exchange but, generally, you would implement:

• Request/Response pattern using synchronous interaction method for retrieval of information
• Request/Response or Hub and Spoke pattern using synchronous interaction method for updates to a repository

Definition

In some circumstances information (or documents) is held in disparate systems. It is not obvious to a system or user who needs access to the information, that the information actually exists and, if so, in which system the information may reside. The registry-repository pattern resolves this issue by providing a set of pointers to records held in the disparate systems. It can subsequently be used to contact the organisation where the record is held to request more information, or directly retrieve the record if authorised to do so.

The registry-repository pattern is primarily focussed on providing pointers to where records (and documents) reside, not how the records are subsequently accessed. The general guidance for retrieval of information via the request-response pattern using a synchronous interaction should be followed.

When you would use a registry-repository

The registry-repository pattern should be used in any circumstance where the information consumer does not know or cannot determine which system to access to request information.

Benefits and limitations of registry-repository pattern

The benefits of the pattern are that:

• it avoids data having to be replicated across multiple systems
• it supports access to documents/FHIR compositions, such as mental health crisis plans held across multiple systems
• where information/services are held across a number of systems or care setting, it provides the option for a consumer to select where to retrieve information from or which service to access
• it may facilitate standard-based approaches for sharing information and document across a wide range of healthcare settings

Not replicating data across multiple systems aligns with the principle that digital services should only store data once (usually where collected) and make it available via open application programming interfaces (APIs) whilst maintaining privacy and security.

It avoids the overhead of unnecessarily moving data between systems and potential for data moved between systems to become out of sync - for example, presenting inconsistent patient records.

It avoids the clinical risk of data becoming stale or incorrect where shared and consumed data might not contain changes or corrections to the data, retrieval ensures the consumer has the most up to date and correct data.

Potential limitations of the pattern include:

The Pattern works best where there is a single authoritative source of data- that is, one type of system holding a particular source of information. Where the same information is potentially held across multiple care setting systems then a consumer would be potentially required to lookup multiple pointers and make multiple data calls which would place an overhead on the consumer system.

For record access the granularity of records that are pointed to in a registry can be difficult to resolve and there are no specific rules for determine determining this. For example, simply pointing to the existence of a record within a repository could lead to issues such as:

• consumers having to build logic to determine where to access records from (many systems could point to the same record type) with there being no explicit method for the consumer to be able to locate where parts of an overall record are held
• unnecessary requests to systems for content that does not exist

Pointing to more specific record type, such as a vaccination, measurements or ePCHR is preferred but has to be weighed up against proliferation of pointers and requirements for more specific APIs to retrieve content.

Logical pattern

When an information item/document is submitted to the provider repository, a pointer to the information item/document is registered within the registry, with relevant associated metadata describing the information item/document.

A consumer can then query the registry to retrieve a list of information items/document matching their criteria. They can then retrieve specific items from that list by requesting them from the relevant repository.

The orchestration façade pattern can be used in conjunction with a registry/repository to remove complexity for consumers. An API gateway can be placed between a consumer and providers to simplify the interface by retrieving the pointers from the registry and then aggregating data from all repositories before presenting the information to the consumer through a single synchronous transaction.

Physical implementation

The registry/repository pattern is implemented in NHSD via the National Record Locator Service (NRLS). This is made up of a:

• FHIR API (synchronous interaction) with operations to allow pointers to be created, updated or retrieved
• registry (within Spine Clinicals) of pointers

In addition to the NRLS which is used to provide pointers to the existence of records/documents there are other registry solutions.

MESH Mailbox lookup – an information source can use the MESH Mailbox lookup service to determine which mailbox a message has to be placed in based upon the Organisation Data Service (ODS) code of the intended recipient organisation, and Workflow Id which is related to the type of message being sent.

Service Directories – the Directory of Services provides a registry of clinical services applicable for a patients disposition. An information consumer is able to lookup appropriate services from the directory and then access transactional services, such as book an appointment.