Search loading...

API Hub

Explore and Make use of Nationally Defined Messaging APIs

 

Exchange Patterns

The Exchange Patterns introduce the messaging and documents.

Exchange Patterns

This section has been included to show the types of exchange patterns and how these ways of exchanging FHIR Resources relates to Information Sharing Patterns.

The exchange patterns are complimentary, each having it’s strengths and weaknesses. The best solution will probably to use a combination of pattern.

Information Sharing Patterns

tn_Portal
tn_RegistryRepository Consider using Messaging to populate the Repository
tn_Repository Consider using Messaging to populate the Repository
tn_StoreAndNotify
tn_PubSub_250

Messaging

There are many scenarios where messaging can’t be driven entirely by the service owner. This is especially true in large organisations or in scenarios where health and social care organisations need to exchange data. In these situations we need an API that recognises a set of related resources but does not tie them into specific procedures, this may also be called a MessagingAPI.

For example a Referral Request will typically contain supporting information such as a referral letter, images/scans, or other resources relevant to the referral. How the Referral Request and other resources are handled is down to the service. The service handler may block (synchronous) while waiting for a response but typically the response will be generated later (asynchronously).

Request (FHIR Bundle)
ITK3 Outpatient LetterHeader
Main FHIR Resource
(e.g. ReferralRequest)
Other FHIR Resources

Benefits

  • Established and mature pattern in Health and Social Care domain
  • Process isolation, useful for communication between organisations and large systems.

Concerns

  • Not suitable mobile or browser use
  • Information Governance concerns especially when used with broadcast pattern.
  • Messages need handling, this may be unnecessary for small transactions

Information Sharing Patterns

tn_Broker
tn_PointToPoint
tn_RegistryRepository To store resources in the Repository
Use API to retrieve the resources
tn_Repository To store resources in the Repository
Use API to retrieve the resources
tn_StoreAndNotify To store resources in the repository
and provide Notification
Use API to retrieve the resources
tn_PubSub_250

Documents

Send documents to remote systems while avoiding direct coupling to remote procedures.

A DocumentAPI is an extension of the MessagingAPI which provides a set of coherent information that is a statement of healthcare information, including clinical observations and services. A document is an immutable set of resources with a fixed presentation that is authored and/or attested by humans, organizations and devices.

Request (FHIR Bundle)
FHIR Composition
Other FHIR Resources

Benefits

  • Formatted for human readability using structured headings PRSB
  • Static coherent statement of health care at fixed point in time.
  • Can be generated on demand to provide a current statement of Patient care.

Concerns

  • More complex to develop

Information Sharing Patterns

tn_Broker
tn_PointToPoint
tn_StoreAndNotify To populate the repository.
Use Message or API for the notification
Use API to retrieve the document
Tags: design

All content is available under the Open Government Licence v3.0, except where otherwise stated