Stream: media issue
Topic: Summary and Options
Hans Buitendijk (Oct 06 2017 at 19:47):
Questions have come up whether to collapse Media into Observation (considering large overlap between Media and Observation), keep the current resources but make various modifications, or perhaps combine Media and DocumentReference.
The minutes to the first meeting on this topic are available here: http://www.hl7.org/documentcenter/public/wg/orders/minutes/Minutes%2020171005_ConCall%20-%20Media.docx. This includes a set of slides outlining the options:
- Option Zero: Do nothing, keep as-is
- Option One: Collapse Media into Observation and either (A) create a new media data type or (B) update the attachment data type
- Option Two: Keep Media and Observation, but make a series of changes to Media, Observation, and attachment data type. A number of these changes could be done incrementally over time.
- Option Two A or B: Do Option Two and (A) keep DocumentReference as-is, or (B) merge DocumentReference and Media into a new resource.
John Moehrke (Oct 06 2017 at 21:31):
One comment was that there is many duplicated values between these three. I think the message of this comment is that the user-community would not understand when to use the alternatives, or when the user-community goes looking for 'observations' they might not find all of them as they might be scattered and not well contained. One solution to this is better clarity on the alternatives, pro/con, with clear guidance on use of all available alternatives. I favor this, as a core standard needs to recognize momentum of existing approaches, and thus can't ask for radical changes thus eliminating an alternative. Thus the duplicate values are not a problem if the alternative resource methods are well understood.
Elliot Silver (Oct 06 2017 at 21:53):
Agree. I don't even think we've go clarity in our discussions about the purpose of various resources. For example, my view is that Media is for "clinical multimedia"--things that might go into an Enterprise Imaging system--that is various types of images, videos, and waveforms (audio or otherwise). I'm thinking about things produced during or obtained for patient care (pathology, dermatology, wound care imaging; endoscopy, surgical video; ECG). Others are approaching Media as more generic such as photos of drivers licenses.
Elliot Silver (Oct 06 2017 at 22:09):
Keeping Media.view/bodysite would seem entirely reasonable and in-scope if we says Media is for clinical multimedia, but might not meet the 80% if we allow non-clinical content. However, I again think that is where the boundary with DocumentReference becomes important: if you need bodysite, then use Media, if bodysite is irrelevant, than use DocumentReference.(And the view/bodysite of an image isn't necessarily the same as the bodysite of the related procedure, and view might not be implied at all in the procedure.)
Grahame Grieve (Oct 08 2017 at 09:50):
I've been thinking about this as product director. At least a couple of these resources are FMM >4. Feedback is trending pretty negative on breaking changes from stakeholders who have implemented. That's not a veto. That doesn't mean no changes. But it does mean that what ever we decide has to be very implementation focused.
Grahame Grieve (Oct 08 2017 at 09:50):
saying that, I think we are trying to be... but there is a consistency vs convenience issue to keep in mind
Eric Haas (Oct 09 2017 at 18:46):
The absence of boundaries between Media and Observation is a huge issue to me - removing value attachment solves that. Media only really started to move into the Observation Turf at the very end of the R3 publishing cycle. I think it was a mistake not to bring up with OO prior to those changes in Media and now we are playing catch up.
Elliot Silver (Oct 10 2017 at 17:38):
The absence of boundaries between Media and Observation is a huge issue to me - removing value attachment solves that. Media only really started to move into the Observation Turf at the very end of the R3 publishing cycle. I think it was a mistake not to bring up with OO prior to those changes in Media and now we are playing catch up.
Well, the absence of boundaries was there prior to R3, since Media claimed to be useful for clinical content. I just tried to make it actually useful for that. It may have been a mistake not to consult with O&O first, but the resource was is/owned by FHIR-I. The difference that talking to O&O would have made is that we would have had this discussion 6 months earlier. We can still roll back the changes to Media if people think that is clearer, but I don't think it is.
Eric Haas (Oct 10 2017 at 18:25):
@Elliot Silver I am not advocating rolling back - the issues you brought up were important ones and we didn't realize the impact on Observation until too late in the R3 cycle. I was justifying why we are try to tackle this now vis a vis Resource maturity.
Hans Buitendijk (Oct 12 2017 at 18:10):
Got side swiped, so did not get to Option Two and DocRef yet. Here goes Option Two:
Observation and Media remain, but with some changes.
In Observation the valueAttachment choice is removed, while .related gets a reference choice of Media.
In Media .basedOne gains Procedure as a reference choice, while ProcedureRequest is removed. .view, .bodySite, and .content are removed, while .fileSize and data (with Binary as a reference choice) are added.
In the meantime, the attachment data type is adjusted to remove .contentType, .title, and .creation, while content with a reference choice to Media is added.
The suggestion is also to change .photo in Patient to reference Media, but that was not a critical part of this option.
These changes could be applied stepwise starting with the changes in Observation and attachment data type (as it is getting ready for normative), while Media could happen more gradually if desired.
Hans Buitendijk (Oct 12 2017 at 18:10):
And for DocurmentReference, assume Option Two as the starting point for Observation and attachment data type, but then create a new resource combining Media and DocumentReference. Name tbd.
Using DocumentReference as it currently exists and consider the following changes plus a new name.
Add photo, vidio, and audio as valid types. Add .subtype, basedOn (with reference to Procedure), reasonCode, height, width, frames, duration, fileSize, and note. Allow a binary for .content and add episodeOfCare as a reference choice to .context.
That completest the choices as presented. Discussion is already in full swing and see where we land.
Jenni Syed (Oct 18 2017 at 16:59):
To me, saying "remove Media and just use DocumentReference" is the equivalent of collapsing Media into Binary... and I don't know why we would do that. I would likely NOT reference something that would have been "Media" from DocumentReference. I understand that Tifs (images resulting from fax) may seem to intersect there, but otherwise, we've tried to keep Doc Ref to things we traditionally think of as "documents"
Jenni Syed (Oct 18 2017 at 17:00):
Doc Ref was also explained to me once (way back in the day, pre-DSTU2) as the thing "document indexing" systems used
Jenni Syed (Oct 18 2017 at 17:00):
I think that use has changed quite a bit over time, eg: we now expose most documents through that resource, and still don't know where to put Notes :)
Jenni Syed (Oct 18 2017 at 17:01):
But I don't think the answer should be "let's just slam some more stuff into that very generic bucket" :)
Jenni Syed (Oct 18 2017 at 17:01):
We try to avoid using the raw attachement data for size reasons listed earlier. Additionally, Argonaut and a few other IGs recommended using the url field in Attachment
Jenni Syed (Oct 18 2017 at 17:02):
Those generally link to Binary for our server, rather than some other "unknown/non-FHIR" link
Jenni Syed (Oct 18 2017 at 17:10):
I don't like Option 1 because of administrative/non-clinical media uses. EG: patient photo and drivers license. I'm curious if there are servers out there that would use Media for other items, though maybe not the 80% (eg: videos of kids playing at children's hospitals for parent portals, etc)
Jenni Syed (Oct 18 2017 at 17:12):
For option 2: why remove reference to procedureRequest (ServiceRequest now)? Not everything that is requested from that resource results in a "Procedure" - and I'm not sure Media can only result from a Procedure?
Jenni Syed (Oct 18 2017 at 17:13):
(I generally like Option 2, btw, I just don't like all the changes proposed)
Jenni Syed (Oct 18 2017 at 17:15):
And I'll repeat the question above if we're sure the "value" of an observation can never be an attachment. If an observation is discrete values, is an EKG or Heart rythm not the representation of that? The interpretation of those values usually lies in reference ranges and DiagnosticReport. Or are we saying those types of results should only ever be present in DiagnosticReport, and would have no discrete data in Observation?
Jenni Syed (Oct 18 2017 at 17:16):
I definitly understand the concern of someone trying to use a wound picture as an Observation value, when in fact it's likely the supporting info (the Observation.related link in the Option 2 proposal). I agree those should be related and not value.
Jenni Syed (Oct 18 2017 at 17:17):
For this: "In the meantime, the attachment data type is adjusted to remove .contentType, .title, and .creation, while content with a reference choice to Media is added."
Jenni Syed (Oct 18 2017 at 17:19):
The existing Attachment url is already used to reference whatever we want - FHIR resource or not. EG: we reference Binary today with this, and would have referenced Media for patient photos (and some other scenarios). If we feel we have to add a specific field to reference FHIR Resources instead of just using url, why limit to Media? Why not Binary as well?
Jenni Syed (Oct 18 2017 at 17:20):
I'm fine if we want to make that call (if you are referencing a FHIR resource with Attachment, then use the content field, otherwise use url), I just feel like we should be consistent and not make Media the single exception
Jenni Syed (Oct 18 2017 at 17:23):
Sorry for the brain dump - trying to catch up on Zulip discussions today :)
Eric Haas (Oct 18 2017 at 17:24):
I agree with almost everything Jenny says. DocRef and Media IMO are not the same thing and although the intent of DocRef is to cover everything, that scope is not clear and as I stated in this stream somewhere the DocRef is document focused and Media is patient focused...
Eric Haas (Oct 18 2017 at 17:28):
Jenny brings up a good point about valueAttachment as to how is it currently being used ( if at all) links to EKGs files or similar? etc. I proposed tossing it overboard in favor of media but then Media needs to be clear that images include more than just photos i.e. graphs, pdfs etc...
Eric Haas (Oct 18 2017 at 17:28):
I'll ask on implementers stream how folks are using valueAttachement
John Moehrke (Oct 18 2017 at 18:20):
I would be happy to see a more clear distinction between Media and DocumentReference; but today there is none. I am really confused by @Eric Haas statement that "... Media is patient focused". What does that mean? How is DocumentReference not patient focused?
Paul Knapp (Oct 20 2017 at 00:40):
Why would we want to remove " .contentType, .title, and .creation," from the Attachment data type and then force someone to include a Media resource to get that information?
Elliot Silver (Oct 20 2017 at 16:41):
@Jenni Syed, I second your comment on notes -- really would like an appropriate resource (or guidance on use of an existing resource).
@Paul Knapp, I'm also unclear why we would remove those attributes. I think we have uses for attachment that are outside the scope of Media/Binary/DocumentReference (although some clarity on that scope will be helpful), and for those uses the attributes are needed.
Eric Haas (Oct 20 2017 at 23:12):
@Paul Knapp I agree they should stay on attachment + add height/width/frame/etc. to Attachment.
@Elliot Silver I found that after lengthy discussions in PC we really did not nail down what a note is.... In fact I thought I knew what a note was but I came out of those discussions dazed and confused.
Last updated: Apr 12 2022 at 19:14 UTC
