Stream: implementers
Topic: Media.code
Grahame Grieve (Feb 15 2018 at 01:48):
GF#14145 proposes to change Media.code to a CodeableConcept with an example binding.
Grahame Grieve (Feb 15 2018 at 01:48):
that seems like a mistake to me. why example? Shouldn't it be extensible?
Grahame Grieve (Feb 15 2018 at 01:48):
@Eric Haas @Elliot Silver
Elliot Silver (Feb 15 2018 at 01:51):
Agree. Don’t recall why we’d said example.
Eric Haas (Feb 15 2018 at 02:40):
we change to a category like is used in other resources. I don't see why this special. if you can search by audio as category or some other orthogonal category like "patient generated" or "clinicial generated". We could reopen and make them preferred but with a cardinality 0..* can't go beyond that.
Grahame Grieve (Feb 15 2018 at 02:41):
why not make it extensible?
Grahame Grieve (Feb 15 2018 at 02:42):
we can't agree on image | video | sound so that everyone uses the same codes?
Eric Haas (Feb 15 2018 at 02:44):
structural limitation just like in Observation.category. can't have both an orthogonal categorization and an extensible binding.
Grahame Grieve (Feb 15 2018 at 02:45):
I don't understand that
Lloyd McKenzie (Feb 15 2018 at 02:45):
Why not?
Lloyd McKenzie (Feb 15 2018 at 02:46):
If someone wants to add "haptic" as an extensible code, they can. If they want to add "black & white image", then they slice and add an extra binding to one of the codings with their more fine-grained value set.
Lloyd McKenzie (Feb 15 2018 at 02:47):
(With the understanding that they'd still send the "image" code too.)
Eric Haas (Feb 15 2018 at 02:47):
As I understand bindings every repeat will be bound to the same valueset if its extensible or required and the cardinality is 0.* We have ad this discussion before. You need to slice in a profile
Eric Haas (Feb 15 2018 at 02:48):
Same reasoning for Observation.category
Grahame Grieve (Feb 15 2018 at 02:48):
I slightly understand that reasoning for Observation.category, but Media.code needs to be simpler
Lloyd McKenzie (Feb 15 2018 at 02:48):
The binding is for the overall CodeableConcept, not for every coding in it. Yes, the slicing would need to be done in a profile
Lloyd McKenzie (Feb 15 2018 at 02:49):
The codeableConcept binding is satisfied so long as one coding matches the binding. Additional codings can convey further detail. (And slices in profiles can require the presence of those additional codings)
Eric Haas (Feb 15 2018 at 02:49):
respectfull disagree and its Media.category
Grahame Grieve (Feb 15 2018 at 02:50):
there needs to be a reliable way to tell whether a media is image, sound, or video. removing that for some slippery category... why? I simply don't understand the logic
Grahame Grieve (Feb 15 2018 at 02:50):
is there some other kind of thing it can be?
Lloyd McKenzie (Feb 15 2018 at 02:50):
Disagree that what you want is technically possible?
Grahame Grieve (Feb 15 2018 at 02:50):
well, Lloyd, you missed the point
Eric Haas (Feb 15 2018 at 02:50):
It is the same logic as Observation.category
Grahame Grieve (Feb 15 2018 at 02:51):
the Media.code shouldn't have been folded into that.
Lloyd McKenzie (Feb 15 2018 at 02:51):
I do that sometimes. Can you explain the issue?
Grahame Grieve (Feb 15 2018 at 02:51):
you looked the repeats of CodeableConcept.coding, not the repeats of media.category
Eric Haas (Feb 15 2018 at 02:52):
why would you not have orthogonal categories in media? E.g some are captured by my Iphone at home and some by a clinician. you may want that as a set of category codes
Grahame Grieve (Feb 15 2018 at 02:53):
I'm not arguing against category per se. I'm just saying that there used to be a real simple idea: image, video, or sound. And now it's gone into this morass of who knows what. As if there's some other type of media that isn't one of those
Grahame Grieve (Feb 15 2018 at 02:53):
why?
Eric Haas (Feb 15 2018 at 02:53):
what is so sacrosanct about audio, image and video? an image could be a pdf of a chart or a picture of my elbow
Grahame Grieve (Feb 15 2018 at 02:54):
because it drives how the media is displayed
Grahame Grieve (Feb 15 2018 at 02:54):
.code was never meant to differentiate between 'image of what'
Eric Haas (Feb 15 2018 at 02:56):
Isn't that done by the content type? an image could be a lot of things.
Grahame Grieve (Feb 15 2018 at 02:57):
yes you can derive it from that. But it's kind of hard to search for images by specifying a set of mime types
Eric Haas (Feb 15 2018 at 03:03):
that is not what the original definition implied and when you say " search for images" that is exactly how we have defined the element so need to clarify purpose of the element. I will reach out to II to discuss this further.
Grahame Grieve (Feb 15 2018 at 03:03):
ok sure. the problem is, there's no way to know what to search for now.
Eric Haas (Feb 15 2018 at 16:54):
I think what you meant is there no single standard way to search for category image, audio or video. @Elliot Silver ? Can we touch base on this to discuss. I see two competing issues:
- a standard way to carve out the three category image, video, audio
- a way to allow other orthogonal categories irrespecitve of what the content is - e.g. captured in clinic, captured at home by patient, etc.
Also the purpose of category is clear - a handy way to search and filter..... does the audio, video, image categories go beyond that as GG stated " "drives how the media is displayed" ie, is that all you need ?
Options are :
- keep 0..* make a preferred category and explain its facility in displaying content if indeed that is the case.
- to make category 1..1 and binding extensible and assume other categorizations are extensions outside the 80%
- have both - but then I would like a pretty good reason why need to carve out image,video, audio. from other categories.
Grahame Grieve (Feb 15 2018 at 20:31):
I thoguht I provided a pretty good reason
Eric Haas (Feb 20 2018 at 02:56):
but you said two things. 1) is a way to find and filter resources and then 2) " it drives how the media is displayed"
I don't understand 2) is that a technical thing because naively I don't see how and image can be displayed without knowing if its a pdf, png or jpg same for audio and video files.
if you meant 1) then it is just another category scheme (JAC?) in my book. so I could vote for option 2 then if we think there are no other common ways to categorize Media.
Grahame Grieve (Feb 20 2018 at 03:30):
well, when building a UI, you'll use a different UI widget and stuff around it for the different types. Where as media types are 'yes I do or no I don't' support it
Elliot Silver (Feb 20 2018 at 20:16):
Sorry, I've been travelling for the last week, and just catching up.
I'd like an element for basic audio/video/image. This should probably be extensible, since there are probably other major groupings we haven't thought of. I partially disagree with Grahame on "do I support it?" -- that should come from attachment.contentType. -- however it is closer to a "is this something I'd be interested in showing?".
I think an arbitrary classification is useful too for patient generated, etc. and to parallel Observation.
I don't have a significant preference as to whether this is one or two elements, although I'm leaning towards two.
Eric Haas (Feb 21 2018 at 02:42):
OK, we shall reopen this GF#14145 on next tuesday's OO on FHIR. or this Thursday OO if there is time ( which is questionable). I've preapplied the updated proposal
Elliot Silver (Feb 22 2018 at 01:23):
@Eric Haas , the feb 20 followup seems to address the issues of image/audio/video and extensibility, but doesn't seem to address the need for arbitrary classification. Is that intended?
Eric Haas (Feb 22 2018 at 01:58):
yes since nobody thought that was needed. I was going to defer it until implementers requested it.
Elliot Silver (Feb 22 2018 at 05:16):
OK. I thought it would be useful, and would be analogous to Observation, but I don't have a particular use case.
Eric Haas (Feb 22 2018 at 05:17):
i tried to think up some examples but couldn't off hand.
Elliot Silver (Feb 22 2018 at 05:20):
Can we keep the "category" name reserved in case someone does come up with a need for it? Go back to "type" for image/audio/video?
Eric Haas (Feb 22 2018 at 05:20):
type means code
Eric Haas (Feb 22 2018 at 05:21):
category means class
Elliot Silver (Feb 22 2018 at 05:22):
Ah, was not aware of those conventions.
Elliot Silver (Feb 22 2018 at 05:26):
Well, it would be nice to not have "category" in two similar resources with different uses.
Eric Haas (Feb 22 2018 at 05:26):
well is not a formal convention but is pretty pervasive throughout the spec. This is the difficulty with two elements that are essentially mean the same thing. anything we choose will cause some confusion
Eric Haas (Feb 22 2018 at 05:27):
I do think the audio,image, video as a classification scheme. so to me that is consistent
Elliot Silver (Feb 22 2018 at 05:28):
a mimetype is broken into type/subtype, and this element actually maps pretty closely to the type part of mimetype, so I think we could justify returning to type.
Eric Haas (Feb 22 2018 at 05:29):
type, category it is then
Eric Haas (Feb 22 2018 at 05:30):
with category reserved for future use....
Elliot Silver (Feb 22 2018 at 05:30):
Sounds good.
John Moehrke (Feb 22 2018 at 14:15):
interesting observation about the use of category. Should we make this a formal pattern? @Lloyd McKenzie @Grahame Grieve
Eric Haas (Feb 22 2018 at 14:49):
I'm making a tracker and putting your name on it OK @Elliot Silver ?
Eric Haas (Feb 22 2018 at 14:50):
to reopen and revote. The WG is getting testy with reopening stuff
Lloyd McKenzie (Feb 22 2018 at 16:22):
A formal pattern with 2 elements? The notion is already reflected in the w5 pattern
Elliot Silver (Feb 22 2018 at 17:22):
@Eric Haas Putting my name on it as submitter? Sure.
Eric Haas (Feb 22 2018 at 17:25):
Last updated: Apr 12 2022 at 19:14 UTC
