Part of Integration Patterns Book

Selecting an appropriate integration pattern

Previous Chapter

Integration Patterns Book

Current Chapter

Current chapter – Selecting an appropriate integration pattern

View all

Next Chapter

Summary view

Selecting the appropriate integration pattern is not just about delivering your current solution. By selecting the right pattern you can:

promote digital innovation by ensuring data is easily consumable
make it easier to connect different health and social care organisations
ensure solutions are reliable and scalable

General guidelines for new integrations

All integrations must be developed in accordance with approved principles, policies, and standards. The most relevant principle is ‘build a data layer with registers and APIs’. This states 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.

Patterns are not intended to be implemented in isolation. For example, a requirement to make specific information available to a clinician may use a combination of the registry/repository and request/response patterns.

Synchronous interfaces which implement small atomic stateless requests should be selected in preference to other types of interfaces (API first approach).

Batch interfaces should be avoided where possible.

Interfaces should be designed from a consumer viewpoint to simplify the integration experience and minimise barriers to entry for new suppliers.

Integration use cases

Integrations are required to support clinician access to information/services.

Clinicians need to:

get information needed to provide the best possible care
use transactional services required at the point of care
update a healthcare related repository as a result of new information which has arisen during delivery of patient care
share new information which has arisen during delivery of patient care with other clinicians/care settings
retrieve latest reference data to enable or facilitate access to a healthcare related repository

Integrations are required to support citizen access to information/services.

Members of the public need to:

access their healthcare record
access transactional services
update a healthcare related repository with new information
share information with a healthcare professional or care setting
interact with a healthcare transaction service to initiate further care tasks

Business and technical considerations

The following need to be considered when selecting an integration pattern.

Business considerations

Can a user proactively request access to information or a transactional service?

Does a clinician or clinical service need to be informed about new information in order to trigger an activity or workflow?

Does a user/system providing information to another user/system require a response that appropriate action has been taken on receipt of the information?

This is not a technical acknowledgement that the information has been successfully received by a system but is an actual business acknowledgement which may include:

an indicator of whether a request was accepted, rejected or whether additional information is required
an indicator of whether a requested activity has been completed
a response reference, such as a booking ID

Technical considerations

Will a provider system (processor of requests) always be available to process requests?

Will the requesting system know from which care setting system information is located/where a transactional service can be fulfilled?

Note - this is not technical information, such as IP end-point for a service, but actual knowledge around where information is located.

Can a response to a request be returned quickly?

Select an integration pattern

Select an integration pattern decision tree

Follow the general guidelines below for selecting the appropriate interface for direct care purposes.

Q1

Will a user/system proactively request access to information or a service?

For example, is there a specific activity or event that will provide a trigger for a user/system to request access to information (like a healthcare record) or a transactional service (such as a healthcare appointment) from an external care setting?

Yes (proactive request)	Go to question 2
No (user/system has new information which needs to be shared with other systems/users)	Go to question 5

Scenarios where there is a natural trigger point to access data or a transactional service, such as when user/system can proactively request access to information or services. These include:

patient encounter - patient has presented at A&E and a clinician needs to view the patient's medications and allergies history
patient has developed COVID symptoms and wants to book a test
patient wants to request a repeat prescription

Scenarios where a user/system is required to proactively share information with another user/system include:

change in demographics, such as birth, death, change of address
unplanned patient encounter, such as A&E attendance
patient admitted or discharged from hospital
patient referral to another service
clinician sending a task to another clinician
screening call/recall notice to a citizen

In the scenarios above, information may be required to trigger activity or workflow and therefore the recipient needs to be made proactively aware of the change.

Q2

Is the information or service the user/system requires associated with a specific care setting?

Yes (single care setting)	Go to question 3
No (multiple care settings)	Go to question 4

Information or services associated with a specific care setting include:

GP appointments in GP clinical system
child development plans in a child health system
vaccination appointments in the National Booking Service

Information or services associated with potentially multiple care settings include:

vaccination history (GP, community pharmacy, hospital trust)
child height and weight measurements (GP, child health system, hospital trust)

Q3

Does the user or system know the location (care setting/care service and associated system) of the information or service they require, or can it easily derive this information?

Yes	Request/Response (Synchronous Interaction)
No	Registry/Repository

Information/services which always reside in the same service/systems include:

demographic data in Patient Demographic Service (PDS)
medication data in GP system

Information/services which could reside in a number of care settings/systems include:

child health 8 week assessment - could be generated and held in one of multiple child health services
mental health crisis plan - could be created by multiple mental health services

Q4

Is there a clear mandate (both clinically and politically) for the specific information to be held and made available from within a shared repository? Can/should information that is captured in potentially multiple care settings be aggregated within a single repository?

Yes	Shared repository
No	Registry/Repository

Examples of a shared repository include:

repositories of master data (such as people, organisations)
repositories of clinical data for decision support, such as vaccination data within the national vaccination register to support call/recall

In accordance with the principle, ‘build a data layer with registers and APIs’ which states that digital services should only store data once (usually where collected), a shared repository should only be used where there is a requirement to store and manage master data or where it would not be feasible to aggregate data in real-time to provide clinical decision support.

Q5

Does the user/system sharing information require acknowledgement that the information they are sharing has been received and processed?

This could include:

an acceptance or rejection indicator, such as clinical service has accepted referral, requires further information or has been rejected
a response reference to support further interactions such as Booking/Referral Identifier

Response is at a business not technical level. A technical acknowledgement should always be returned to a message sender to confirm a message has been successfully received but a business acknowledgement will not be required in all circumstances.

Yes (Business acknowledgement required)	Go to question 6
No	Go to question 7

Q6

Does a manual activity need to be undertaken before an acknowledgment can be sent and therefore an immediate response to a request cannot be provided?

Yes	Request/Response (Asynchronous Interaction)
No	Request/Response (Synchronous Interaction)

Considerations for whether a user/system can wait for a transaction to complete before an acknowledgement is returned include:

Is the request triggering a manual activity, such as for a clinician to perform a specific task? If an acknowledgement is required to confirm that the task is complete, then the user/system cannot wait for a response.
Is the request triggering a long running workflow on another system? If an acknowledgement is required to confirm that the workflow is complete, then the user/system cannot wait for a response.
Will the system receiving/processing the request do this immediately upon receipt, for example an update of an external healthcare data repository? If yes, then it the requesting system can wait for a response.

Q7

Is it known which specific care settings and associated systems need to be sent the information?

Yes	Information push
No	Publish/Subscribe

Last edited: 24 November 2022 2:02 pm

Internet explorer is no longer supported