The Exchange Patterns introduce the three ways of exchanging FHIR Resources using RESTful API, messaging and documents.

1. Exchange Paradigms

This section has been included to show how CareConnectAPI fits in with traditional messaging and document exchanges. Also 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.

2. RESTful API

Retrieve data held in a remote system while avoiding direct coupling to remote procedures.

View Results Screen



Many web services use messages to form their own domain-specific APIs. These messages incorporate common logical commands like Create, Read (i.e. Get), Update, or Delete (CRUD). Also across the health and social care domain, we have many common entities such as Patient, Practitioner, Organisation, etc. For example, many systems will implement an API that allows you to search for Patients by their NHS Number, maybe called GetPatient, QueryPatient, CreatePatient, etc.

Rather than implementing a system specific API, we could utilise standards defined in the HTTP specification (i.e. GET, POST, etc) and standarise how we return the payload.

So rather than a wide variety of GetPatient, QueryPatient we have:

GET Request Response (server)
URI FHIR Resource
E.g. Patient
POST/PUT Request Response (server)
URI + FHIR Resource
Patient
FHIR Resource
E.g. OperationOutcome
DELETE Request Response (server)
URI FHIR Resource
E.g. OperationOutcome

This type of interface may also be called as ResourceAPI and is useful for real time applications and mobile/web based access.

Benefits

  • Mobile and web application friendly, can be reused for messaging simplifying interfacing.
  • Quick to develop
  • Real Time Systems
  • Uses modern web technologies
  • Can be used with modern security and consent technologies (OAuth2, OpenID, SMART on FHIR)

Concerns

  • Less suitable for large transfers of data between organisations and large systems.

2.1. Information Sharing Patterns

The following table highlights a number of information sharing patterns as described in the NHS Developer network.

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

2.2. NHS FHIR Examples

3. Messaging

Send notifications and other information to remote systems while avoiding direct coupling to remote procedures.

View Results Screen



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)
FHIR MessageHeader
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

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

3.2. NHS FHIR Examples

4. Documents

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

View Results Screen



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

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

4.2. NHS FHIR Examples

5. Operations

Execute a procedure on a remote system while avoiding direct coupling.

[TODO]

Tags: design