Skip to main content

Part of Integration Patterns Book

Patterns

Overview of all the relevant patterns for information exchange.

Request-response

Request response pattern infographic

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

Business scenarios

Providing direct patient care – get the information needed to provide best possible care

During care delivery, it is necessary to access the latest information about a patient in order to provide best possible scheduled or unscheduled care.

For example:

  • unscheduled – retrieve latest medication and allergy information regarding a patient who has presented at an A&E department
  • scheduled – retrieve the medical record of a patient during a planned consultation. 

Providing direct patient care – use transactional services at the point of care

During both scheduled and unscheduled care delivery, it is necessary to access transactional services to deliver care according to the identified problem or care pathway. 

For example, during a consultation to:

  • book an appointment for a patient to review progress with confirmation required that the booking has been accepted
  • refer a patient to a specialist service where this has been identified as the correct next step in a care pathway and with a response returned to indicate whether the referral has been accepted or further information is required

Citizen – access transactional services

At the point of need, a citizen requires access to transactional services in order to empower them to self-manage their care.

For example, a citizen wishes to book an appointment in order to discuss a new or existing health problem. Confirmation needs to be returned to the citizen to confirm that the booking has been accepted.

Citizen – update my healthcare record

A citizen has new information, outside of an encounter with a healthcare professional, which has value in ensuring they continue to receive the best possible care.

For example, a citizen wishes to:

  • update their demographic details to ensure they continue to receive notifications sent by organisations delivering their care - confirmation that the update has been (or will be) applied needs to be returned to the system from where the request was made
  • submit information from a healthcare device which they use, as this information is valuable in the context of their healthcare record as accessed either by themselves or by healthcare professionals - confirmation that the information has been received needs to be returned to the device

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.


Request-response – implementation details

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

Non-functional considerations should only be a driver for asynchronous integration with legacy systems and, in the first instance, a review of whether systems can be re-architected to support synchronous transactions should be undertaken.

New systems being developed would be expected to be able to return immediate responses to external requests.

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.


Publish subscribe

Publish-subscribe pattern infographic

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

Business scenarios

Providing patient care – sharing information needed to provide best possible care

Information has been recorded which needs to be shared with potentially multiple systems, but the sender does not have (or require) knowledge of where information needs to be sent.

Example 1- publishing changes to demographic records such as birth, deaths, change of address. These are all unplanned events that multiple systems (GP, child health for example) require knowledge about and which cannot wait until they next access a relevant record to be informed about.

For example, a health visitor needs to be aware of the birth of a child to be able to schedule a birth visit with a child’s mother.

Publish-subscribe example - publishing changes to demographic records

In this example, the GP system would proactively add a child to the caseload (with routing based upon mothers GP) and a health visitor would be able to proactively arrange a birth visit (routing based upon the child's mother's local authority).

Personal Demographics Service (PDS) does not need to know the implementation details of the specific GP or child health system that would be receiving the information. that is, it doesn’t need to implement logic regarding which specific system needs to be sent a specific record.

In addition, it does not require an acknowledgement that the information was received as it would have no mechanism for acting upon such an acknowledgement (the middleware component – NEMS in this example takes responsibility for messages being delivered to subscribers).

Example 2 - publish information regarding an encounter with a patient that has occurred. For example, an attendance at an Accident & Emergency (A&E) department which would be unplanned and which services providing care for a patient would need/want to be informed about.

Publish-subscribe example - health visitor notified of child attending A&E

In this example, a health visitor (using a child health system) is required to be notified when a child in their care attends A&E in order to determine if there is a safeguarding issue. As an A&E attendance is an unplanned event and can take place at numerous A&E departments which use a variety of system it would not be practical to proactively poll systems for records.

The patient administration system (PAS) system does not need to know the implementation details of the specific child health system (or other systems) that would be receiving the information. That is, it does not need to implement logic regarding which specific child health system needs to be sent a record. Nor does it require an acknowledgement that the information was received as it would have no mechanism for acting upon such an acknowledgement.

The child health system will be provided with the provenance of the information but does not need to know any of the implementation details of the PAS system.

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 Digital 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.


Publish subscribe - implementation details

Logical pattern

Publish subscribe integration pattern - logical pattern diagram

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

Publish subscribe integration pattern - subscribe pattern diagram

Subscribe pattern

Publish subscribe integration pattern - publish pattern diagram

Publish pattern

Within NHS Digital, the publish subscribe pattern is implemented within the National Event 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)

REST API (synchronous interactions) is not yet implemented.

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.


Information push 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.

Information push pattern - hub and spoke pattern diagram

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.

Information push pattern - point to point

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.

Information push pattern - messaging channel diagram

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).

Business scenarios

The Information Push pattern can be used in circumstances where information has been generated (an event has occurred or new information about a patient has been recorded) and the consumer needs to be informed as either:

  • they cannot wait until they next access the relevant record to view the information
  • it would not be practical for the consumer to request the information

If the consumer had to request the information it would lead to significant numbers of unnecessary requests to the provider system, for example where data is updated infrequently or only exists for a small subset of the consumers caseload. The information consumer also does not know where information will be generated from.

The Information Push pattern can be used to make requests to drive specific workflows or activities on the part of the information recipient or ensure a complete patient record is maintained.

Providing patient care – sharing information needed to provide best possible care

Information has been recorded which needs to be shared with a specific care setting. For example:

  • a hospital trust sharing a patient discharge summary with a GP practice
  • a GP practise sharing information regarding a patient adverse reaction to a vaccination with the Medicines and Healthcare products Regulatory Agency (MHRA)

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

Information Push implementation details

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.

Information push pattern - synchronous interaction method diagram

The diagram describes how the point to point pattern and direct coupling of the applications involved in the exchange can be avoided through the use of an API management layer (acting as the hub).

In addition, where there is more than one known consumer of the information, an orchestration façade can be used to apply updates to multiple systems.

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.

Information push pattern - asynchronos interaction method diagram

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.


Shared repository

Shared repository pattern - data flow diagram

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.

Business scenarios

Providing direct patient care

Providing an authoritative source of master data, such as:

  • demographic data within the Personal Demographic Service (PDS)
  • Organisation data within the Organisation Data Service (ODS)

Demographic data is held and maintained across multiple care settings, by having a single authoritative source maintained by all care settings it ensures that when a change to demographic data occurs (or a new record is created) it can be made available to all care settings.

Consolidation of records to enable business rules to be applied against an aggregated dataset. For example, vaccination data is consolidated within a national vaccination register to support both national call/recall and eligibility checks from the National Booking Service.

Citizen access

Providing a consolidated patient healthcare record, such as electronic Personal Child Health Record (ePCHR).

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.


Shared Repository implementation detail

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

Shared Repository implementation detail


Registry-repository

Registry Repository pattern infographic

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.

Business scenarios

Providing direct patient care

Enabling an authorised clinician, care worker and/or administrator, in any health or care setting, to access a patient’s information to support that patient’s direct care.

During care delivery, it is necessary to access the latest information about a patient in order to provide best possible scheduled or unscheduled care.

Example: unscheduled care – retrieve mental health crisis plan when a patient being supported by ambulance services is identified as having potential mental health issues. The ambulance service system would not directly know if a mental health plan actually existed and if so which of multiple systems the plan might reside in so would search the registry to identify if a record did exist and then contact the mental health service provider or retrieve the record itself from the identified system.

Example: scheduled care – as part of a GP consultation with a child patient the GP system would be able to lookup which child health system contained a record of the child's development history and then subsequently retrieve this record to be viewed by a GP.

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.


Registry-repository implementation details

Logical pattern

Registry repository pattern implementation - 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

Registry repository pattern - 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

Once the pointer has been retrieved from the registry the mechanism for retrieving the associated document/record would be via Request/Response using a synchronous interaction.

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

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.

Last edited: 2 August 2021 2:28 pm