...
Business need | Protocol type | Interactive | Non-interactive | Applies to content | |
---|---|---|---|---|---|
Generic data read/write
| CRUD API
| FHIR REST | low volume -> FHIR REST ‘multi-CRUD’ possible | Resource-based | |
Aggregated data exchange
| Business object
| FHIR Document API | xxxFHIR document | ||
Business-level service
| Transactional service API
| FHIR Operation(s)
| FHIR Operation(s) |
| |
Querying
| Querying APIQuery service
| FHIR REST search | ?applications | Bundle (= set of Resource instances) | |
Messaging i/f or system
| Messaging
| n/a | FHIR messaging
| all |
...
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)