A few years ago, XDS introduced the concept of “on-demand” (a.k.a. “dynamic”) documents where the “pointer” to the data is provided but no length/hash, with the explicit understanding that the content is volatile (e.g. perhaps a “current medication list” pulled from a pharmacy system). The cardinalities in the Attachment resource would appear to preclude such an approach for FHIR. I realise of course that a “FHIR document” (as opposed to a document reference) would be intrinsically volatile, but I’m looking at XDS/FHIR interoperability here so a native FHIR document would be tricky…
you have to provide some information about the attachment - such as a reference and contentType and/or a title. You don’t have to provide data, or hash
Thanks - I’d missed the 0…1 cardinality!
On-Demand could be implemented simply by leveraging the relaxed cardionality, or by using the values that IHE defines for on-demand. The important part is that the URL given in the DocumentReference when a GET is done would cause the document to be created. This is the non-REST part. Once it is created ‘on-demand’ then that set of bits could be saved to a REST server, with a new DocumentReference that has a relatesTo that points at the original on-demand with the same metadata but the new URL, hash, and size.
Most clients won’t notice any difference between a static or on-demand. They would tend to process all the other metadata elements for either query-parameters, or to filter results. They would tend to just pull the URL. And they tend to never check the size or hash. The checking of size and hash is there as a method to protect against integrity failures that result from the distributed architecture XDS provides. When there is not N repositories that are distributed broadly, there is little reason for size/hash.
I didn’t include on-demand nor deferred-creation in MHD as we need first experience with static document entries. Please inform IHE of your interest in on-demand. Experience will be helpful to improvements.
Clearly relatesTo needs new relationships (snapshot), and there might need other indicators of on-demand vs deferred-creation. Future improvements that I am happy to do based on experience and use (80%).
John