Exchange Patterns

Exchange Paradigms

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.

**Note: for ITK3 only Messaging or Documents can be used. **

RESTful API

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

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:

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.

Information Sharing Patterns

	Consider using Messaging to populate the Repository
	Consider using Messaging to populate the Repository

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

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

	To store resources in the Repository Use API to retrieve the resources
	To store resources in the Repository Use API to retrieve the resources
	To store resources in the repository and provide Notification Use API to retrieve the resources

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.

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

	To populate the repository. Use Message or API for the notification Use API to retrieve the document