NOTE: THESE ARE THOUGHTS IN PROGRESS - Not the end result - just yet and up for discussion
When using a FHIR SMART App there are times where the App wants to write a summary action back into the clinical record summarizing what was done. For the RTW-SA App, that would be writing the capacity certificate that was sent to RTW into the clinical record.
(existing functionality in use today)
http://fhir.oridashi.com.au/wiki/Deliver_to_Inbox
http://fhir.oridashi.com.au/wiki/DocumentReference_Delivery
Main properties are:
- Patient
- Category
- Author
- Content (PDF/HTML)
The binary content can be stored in 2 ways, either in the attachment datatype (on various resources), or in a Binary resource, and a reference to this content from the attachment datatype.
The NCSR uses the reference to Binary approach for it's assessment documents, which are stored as DocumentReference resources.
And Oridashi provides these as inbound as DocumentReference and outbound as Communication.
Also we need to document the "discovery" mechanism to determine which of these a system does actually support (and terminologies that are applicable)
The original intent of this is to cover direct writing, not content that needs decisions in messaging - like doing patient matching and workflow assignments.
Creating/submitting the content to the FHIR API
As with any other data updates, this will be done through the FHIR REST API as POST calls.
If the binary content is "inline" then simple POST /DocumentReference can work quite well, however if you want to have the Binary content as a separate resource, then using a bundle batch/transaction would be appropriate.
The other option would be to use a FHIR Message, in a similar way to the bundle/batch.
| Approach | pro | con | other notes |
|---|---|---|---|
| POST /DocumentReference | simple, single call | large blob content mixed with metadata creates larger content for searching (unless using _summary=true) | Could suggest that systems split the content on receiving the data? |
| POST / (batch) | represents final storage (if the receiver splits it) | slightly more complex not expected to be transactional | |
| POST / (transaction) | " | expected to be transactional | |
| POST / (message) | could be inline with other future processing of inbound content | Not really intended for recording details of outbound content? | Could be confused as an expectation to message someone. |
| DocumentReference (embedded content) | single resource definition, single call | large blob content mixed with metadata creates larger content for searching (unless using _summary=true) | |
| DocumentReference + Binary | Able to have easier search indexing with lighter weight results Can retrieve the binary resource as raw bytes rather than base64 encoded | creation is less simple
| Can do _include to also bring back the Binary in the same call. |
| ServiceRequest | Not everything is a service request (ingoing/outgoing) | ||
| Communication | This is less clinical in content, and often less appropriate than a DocumentReference or ServiceRequest NOT RECOMMENDED | ||
| QuestionnaireResponse | this can be exactly what was entered (atomic data) however not widely supported | Would recommend to include this where possible | |
| Observation(s) | Likely needs pre-processing, and not typically what's done in forms submission, however could be included. |
Note: This is not intended to be a replacement or handle DiagnosticReport resources (like an ORU in a HL7 v2 message).
Follow on question, how do you append/write a progress note! - append in progress content (unsaved) - maybe this part is the new web messaging spec?
This could be done as a levels of capability, and how can we "discover" cleanly which levels are supported.
Note: The current spec doesn't support us doing an _include reference due to the search index type.
http://fhir/DocumentReference?_id=blah&_include=DocumentReference.location
Posted by philip.wilford at 23 Aug, 2021 15:27