Stream: implementers
Topic: FHIR Document Permanence/Persistence
Ken Sinn (Dec 24 2018 at 18:13):
We are looking at implementing FHIR Documents. The FHIR Server will create a Document Bundle on request, assigning it a unique Bundle ID. Are there any conformance requirements that the Document Bundle ID be persisted? For performance reasons, the Document Bundle will only be available via the unique Bundle ID during the user session, and will not be available on subsequent sessions. They can request the FHIR Document again, but it will be a new Bundle ID. Wondering if this design approach is breaking any rules (we understand that users/systems that try to save a link to the Document Bundle by ID will end up at a dead link later, but we are willing to live with this).
Thanks for any suggestions/insights!
Lloyd McKenzie (Dec 24 2018 at 20:04):
It's equivalent to changing the id of any other resource. It means it's considered a distinct instance - regardless of what the data inside the document is. (Just as a Practitioner instance is considered to be different even if it has the same license number.) Also, if there's a digital signature on the document, it'll be broken.
Ken Sinn (Dec 31 2018 at 17:03):
We're not changing the id of a created document once it has been gathered up and and made available for the requester. On a subsequent request on a subsequent session, they may request the same content again, but as you say, it would be a separate instance of the same content. Is there any conformance requirement (in REST or FHIR) that a resource is available at fixed endpoint beyond the termination of a session?
Lloyd McKenzie (Dec 31 2018 at 17:53):
If you're exposing a RESTful interface, there isn't really any such thing as a "session". If the endpoint supports search or read, the expectation is that the content will be available at the same URL until such time as it's deleted. Of course, not all users/systems will necessarily have permission to read that resource, but if they do, it should be there.
John Moehrke (Dec 31 2018 at 19:08):
Need to clarify if you are referring to a Composition resource accessed via http REST, as a 'document'? I think that is a Composition, not a document. Once assembled into a Bundle, it is given a unique identifier and is a "Document". I would agree that once Bundled it is a unique thing that would not change hence forth, which is a good use of DocumentReference. However the Composition may be retrieved via "GET" as a new thing... Similar discussion around $document as an operation to request a new document be creaed
Ken Sinn (Jan 02 2019 at 17:01):
Thank you for the feedback, Lloyd and John.
To be a bit more specific, we are exposing the DocumentReference resource, and we will create and assign a value to DocumentReference.id when searched. The DocumentReference will point to a freshly-assembled "document"-type Bundle, whose first resource will be a Composition resource. The "document'-type Bundle will also have a Bundle.id assigned when initially created. Both the DocumentReference.id and Bundle.id will be unique for this "document"-type Bundle request, but the resources may not be available a day or a week from now, if they try to retrieve it strictly by ../DocumentReference/id or ../Bundle/id. They would need to perform the DocumentReference search request again, where we would create a new DocumentReference.id and respective Bundle.id.
Much of this design is driven by existence of legacy CDA systems, and the performance/storage implications of creating/storing new tables to map these DocumentReference and Bundle resources to the existing CDA content, and instead creating them transiently on-the-fly for the user session (or alternately for a fixed duration of time).
John Moehrke (Jan 02 2019 at 17:45):
Understood. You might find that you can have a DocumentReference that describes the "on-demand" or "delayed-assembly" document, where the attachment.url is a $document operation or some other special endpoint. In this case you would not fill out the DocumentReference.masterIdentifier (which would normally be the Bundle.id of the document, as in your case the document is not yet made as it is on-demand). You would also not be able to populate hash or size. This is normal on-demand in XDS/XCA, and what I expect would be done in MHD(FHIR).
- https://healthcaresecprivacy.blogspot.com/2017/01/fhir-documents-in-xds.html
It sounds like you don't intend on saving a "snapshot" of the document that was created? This is a possible policy, but note that a snapshot can be saved as another DocumentReference with a relationship to this top level one.... just like in XDS/XCA
Last updated: Apr 12 2022 at 19:14 UTC
