FHIR Data Sharing analysis

Owned by Thomas Beale
Last updated: 22-Apr-2020

The content on this page is based on the https://docs.google.com/document/d/1H3bhO2zhL2SuyIEU6RukPIea7h1pdQDHOQs1eeCSw7Q/edit . In particular this diagram of a decision tree:

We propose here an alternative decision mechanism to the above, based on the recognition that there are at least these independent dimensions, namely:

  • interactive v non-interactive

  • payload structure & semantics - bundle, message, collection, …

  • communication semantics - CRUD v transactional micro-service v querying v messaging

  • presentation /rendering - e.g. FHIR document v resource

In an initial attempt to separate these, we posit a 2-D decision table:

Business need

Protocol type

Interactive
(C2B realtime)

Non-interactive
(B2B)

Applies to content

Business need

Protocol type

Interactive
(C2B realtime)

Non-interactive
(B2B)

Applies to content

Generic data read/write

  • single-enterprise

  • atomic Tx ok

  • usually app-driven

  • granular content

  • assumed persistence

CRUD

  • C2B, B2B

  • decomposed content

  • Tx applies to atom

FHIR REST

low volume -> FHIR REST
high volume -> Bulk data

‘multi-CRUD’ possible

Resource-based

Aggregated data exchange

  • x-enterprise

  • want to commit N items as a single operation

  • avoid fragmentation issues

  • no assumed accessibility

  • opaque content

Business object

  • receive a set of included parts as single Tx

FHIR Document API

 

FHIR document

Business-level service

  • business specific i/f

  • processing semantics

  • transparent content

Transactional service

  • often C2B

  • end-end comms

  • closer to business view

FHIR Operation(s)

  • multiple end-points

  • may use Parameter resource

  • more granular

FHIR Operation(s)

  • transactional Bundle (i.e. ACID semantics)

  • batch Bundle (non-Tx)

Querying

  • match criteria-based

Query service

  • C2B

FHIR REST search
(query-related)

?applications

Bundle (= set of Resource instances)

Messaging i/f or system

  • non-peer-peer

  • system-system (non-app)

  • routing (post) model

  • minimised exchange

  • consolidated content

  • business semantics = provide / process / respond

Messaging

  • B2B

  • async

  • routing comms model

n/a

FHIR messaging

  • simulates v2, v3 msg

  • Bundle of type message

  • header w/ trigger events

all

Here:

  • Protocol type is mode of communication, i.e. class of service interface;

  • Interactive / non-interactive are specific communication scenarios that can use various protocols to achieve different things;

  • The last column attempts to indicate which content types each row may apply to;

  • PK: pointed out the ‘version v end-point’ question.

We assume that:

  • ‘FHIR document’ is a kind of content structure; requires Composition Resource; all have same behaviour;

  • a ‘message’ is not a content type as such, but a protocol-specific container (i.e. envelope) in the usual fashion into which the content of interest is put; header contains addressing info +/- some workflow processing;

  • CommunicationRequest is assumed to be a particular kind of content corresponding to a particular kind of interaction (LM: human-mediated authenticator needed)