Stream: fhir/documents
Topic: DocumentReference and XDS
Espen Stranger Seland (Mar 06 2019 at 10:56):
Does anyone have a newer profile of DocumentReference for XDS (XCA)?
In detail, I'm looking for existing extensions for referencing to a specific document inside a XCA with the use of uniqueId, homeCommunityId and repositoryId (names taken from a DSTU1 XDS profile).
Grahame Grieve (Mar 06 2019 at 12:54):
@John Moehrke
John Moehrke (Mar 06 2019 at 13:26):
IHE has the MHD profile https://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)
It has everything one needs for STU3
It is about to be updated as adjusted to R4, but the structureDefinitions are a bit delayed due to me waiting for Forge support
John Moehrke (Mar 06 2019 at 13:27):
You will also find a mapping from DocumentReference to XDS in every version of FHIR. http://build.fhir.org/documentreference-mappings.html#xds
John Moehrke (Mar 06 2019 at 13:27):
Im happy to give more guidance or answer other questions
John Moehrke (Mar 06 2019 at 13:28):
see https://healthcaresecprivacy.blogspot.com/2018/09/mhd-as-api-to-xca.html
Espen Stranger Seland (Mar 08 2019 at 13:01):
Thanks. My use case is using DocumentReference as a pointer for where to fetch a (XDS) document, not as a direct interface for a repository. That is the reason why we need a mapping to repositoryId and homeCommunityId as well ("Here is a list of interesting documents, you can fetch them here and over there").
In an ideal world, maybe DocumentReference.content.Attachment could include an Endpoint when the physical document is somewhere else (not local), but that's maybe too complicated if a XDS capable consumer only needs two additional id's. I guess extensions is the way to go as additional identifiers.
John Moehrke (Mar 08 2019 at 13:04):
Help me understand how that is not what MHD is defining? The URL is that pull, it does not need to be on the same server. It just needs to be a GET based URL.
John Moehrke (Mar 08 2019 at 13:06):
I think you are reading too much into the abstract actor definitions. A Document Responder is not a system, it is an abstraction. Such as in your case, the responder for queries against DocumentReference can be a totally different system from the Document Responder where all of the documents are.
Espen Stranger Seland (Mar 08 2019 at 13:20):
Thinking loud here. The URL in Attachment could point to specific document, cross domain, right? That would be a solution for my problem. In my case, the client would need enough to retreve a specific document from everywhere, either as a query or a direct pointer, regardless of MHD or "classic" ITI web services.
Espen Stranger Seland (Mar 08 2019 at 13:25):
Thanks for the help so far - I'm having a new look at ITI-68 over the weekend.
John Moehrke (Mar 08 2019 at 13:30):
yes, that is the model in MHD. The only requirement is that the DocumentReference attachment url is a GET url. It can't be a soap endpoint. It could be anywhere. The security model is a systems-design concern, so clients would need to know the right security to access all the potential URL servers.
Last updated: Apr 12 2022 at 19:14 UTC
