View Source

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:

Standards > FHIR Data Sharing analysis > FHIR-data-sharing-decision-tree.png

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