Stream: implementers
Topic: Media - sending images from patient to healthcare provider
Ardon Toonstra (Nov 26 2018 at 18:10):
We are looking to support a (simple) use case where a patient sends a picture to a healthcare provider. Imaging an image of a wound or some dermatological condition. We think of using the Media resource for this purpose.
The use case should be implementable within XDS networks as well. We are exploring which metadata should be included and the possible workflows we should support/cover.
Does anyone have experience with such a use case? Or experience with the Media resource and/or XDS networks. I would like to learn from your experiences :)
John Moehrke (Nov 26 2018 at 18:24):
if you want compatibility with XDS, then use DocumentReference. This is just as legitimate of a resource to use for your use-case, and is more broadly applicable.
John Moehrke (Nov 26 2018 at 18:29):
DocumentReference was born out of compatibility with XDS, and there is an Implementation Guide from IHE on the topic -- Mobile access to Health Documents (MHD) -- https://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)
John Moehrke (Nov 26 2018 at 18:30):
patient is certainly within scope as a creator of documents. a picture of a wound is certainly a good use-case for patient generated documents. See scope on DocumentReference
Elliot Silver (Nov 26 2018 at 20:31):
Except for the XDS integration, Media is appropriate. This was certainly a use case I had in mind while we worked on Media.
Note that I haven’t heard much feedback on Media, so your experience would be good to hear. There is an ongoing discussion about the boundaries between Observation and Media, and Media/Binary/DocumentReference, so it is possible one of those may be going away, and the boundaries may shift.
Ardon Toonstra (Nov 27 2018 at 10:39):
Thnx @John Moehrke and @Elliot Silver ,
We have IHE MHD in scope because we use it for another use case. Will be a good discussion to see if we will create two specifications, one based on DocumentReference for XDS networks and one based on Media for peer to peer or if we will go only for the DocumentReference. Will try to keep you updated on our progress.
Other implementer experiences or advice are still more than welcome :)
Brian Postlethwaite (Dec 03 2018 at 10:53):
I would have thought Media or Observation would be the obvious choice. A wound photograph would certainly feel like an observation to me.
Ewout Kramer (Dec 04 2018 at 14:54):
This reminds me of a discussion at the September 2018 WGM which @Michael Donnelly told me about. I think that's what @Elliot Silver is refering to too. What I remember from that discussion is whether it would be wise to expose the data on multiple endpoints concurrently - so a client would always find it, regardless of whether you represented it using Media or DocumentReference. Maybe Michael knows more about where that discussion ended up? Or what direction Epic took?
John Moehrke (Dec 04 2018 at 15:52):
that discussion is where the clinical notes discussion ended up. In that case it was DocumentReference and DiagnosticReport both pointing at the same Binary. Yes it is possible for Media to also point at the same binary. This seems more like an identification of a problem, than a solution. Why do we have so many ways to do the same thing?
Eric Haas (Dec 04 2018 at 22:39):
Media is essentially == observation + valueAttachment although DocumentReference could also work too.
Ardon Toonstra (Dec 05 2018 at 15:34):
Media feels most suitable for transferring images. It is a nice specific resource and allows for medically related elements. Also, a strong point is the connection with DiagnosticReport. Only thing annoying is that in STU3 it is not possible to reference a Patient as an operator (fixed in R4).
DR feels less fitting, however, I believe this is the way to be compatible with XDS. As mentioned, we use IHE MHD for transferring PDFA documents. Therefore we would like to reuse these IHE MHD profiles as well if we would go in this direction.
Ardon Toonstra (Dec 05 2018 at 15:36):
@John Moehrke , to be compatable with XDS we should look at the comprehensive metadata profiles, right?
Looking at the provide document transaction bundle profile, I noticed that:
1. A patient cannot be an author,
2. .type is not really suitable. Perhaps this codes fits: “72170-4 Photographic image Unspecified body region Document”. However, it has a preferred binding strength so we can do something ourselves if needed.
3. .class codes are not suitable. Also mostly HCP centered, --> but also example binding strength
4. .content.attachment.language is mandatory, but for images, this is a bit nonsense
5. content.format is mandatory this will be a fixed value for images, stating mimetime sufficient right?
6. The whole .context backbone does not really map for our patient-centred use case. The mandatory items are for healthcare providers.
7. Provide Document bundle profile has a wrong(?) .meta profile constraint, namely http://ihe.net/fhir/tag/iti-65. It does not match the canonical url of the profile. Or is this intended?
Ardon Toonstra (Dec 05 2018 at 15:40):
I identify three possible strategies for our use case:
1. Let everything be XDS compatible and write down specification to transfer images with DocumentReference resources – based on or hopefully close to IHE MHD
2. Use the Media resource and let XDS actors convert the Media resource to a desired format. Provide a mapping, or let our Media resource be XDS compatible.
3. Use both ways. Media for non-XDS actors, and DocumentReference for XDS actors
Ardon Toonstra (Dec 05 2018 at 15:42):
2018-12-05-16_16_22-Mapping-IHE-MHD-DR-Media.xlsx-Excel.png
Regarding strategie 2: I made a mapping of the mandatory DocumentReference elements to the Media resource
Ardon Toonstra (Dec 05 2018 at 15:45):
What do people think of the idea to use the media resource in our use case, and to make it XDS compatible? So a XDS actor can convert it to a DR if needed or straightaway to a XDS entry. @John Moehrke ?
John Moehrke (Dec 05 2018 at 19:07):
@Ardon Toonstra I would be very interested to hear what about Media is attractive to you. I ask because I am trying to drive for the two to be combined into one as there is so little difference. Thus the difference seems to be emotional rather than technical. So I am interested in why... Seems some of your comments are on MHD, not the FHIR specification, specifically not current specification.
John Moehrke (Dec 05 2018 at 19:09):
XDS has never forbidden a patient to be an author. FHIR DocumentReference has always allowed patient to be an author. So I am not sure where you see a foridance of the patient to be an author. If there is one, then it is likely a mistake that needs to be corrected.
John Moehrke (Dec 05 2018 at 19:11):
as to type and class (now category), these are valuesets. Valuesets evolve as new use-cases are brought forward. I very much like to bring new use-cases forward.
John Moehrke (Dec 05 2018 at 19:12):
I don't know of any requirement for language to be specified... if you see one, please point it out so that it can be corrected.
Ardon Toonstra (Dec 06 2018 at 11:00):
@John Moehrke Perhaps I just gave too much disperse information. My comments are indeed on IHE MHD (more specific, on the profile http://ihe.net/fhir/StructureDefinition/IHE.MHD.Provide.Comprehensive.DocumentReference). Because we already use MHD, we would like to reuse or stay close to it, if we move forward with the DocumentReference approach.
I am no XDS expert. Currently, I believe that the “Comprehensive MHD profile” (a.k.a. XDS on FHIR) states the minimum requirements for indexing something in typical XDS network. Is this assumption correct?
Ardon Toonstra (Dec 06 2018 at 11:00):
My mapping is based on these mandatory elements to see how far the Media resource is from being used in indexing by an XDS network.
Ardon Toonstra (Dec 06 2018 at 11:05):
Regarding the potential use of Media, this may partly be an emotional choice. It 'feels' more applicable for images than a DocumentReference. But in addition, I see value in the following additional fields compared to DR for our use case: view, reasonCode, bodySite, device, to a lesser extend the height and width elements. And the connection from a DiagnosticReport to Media.
John Moehrke (Dec 06 2018 at 13:34):
thanks. this is the kind of specifics that are helpful. All of these can be addressed now that they are identified. Feelings are hard to address.
Last updated: Apr 12 2022 at 19:14 UTC
