FHIR Chat · Modelling exported diagnostic data · implementers

Stream: implementers

Topic: Modelling exported diagnostic data


view this post on Zulip Jens Villadsen (Jun 14 2017 at 21:25):

I'm having a debate with myself regarding modelling ECG data that I can only receive as png/jpeg-files which means its one of those Media vs Observation.valueAttachment discussions. Originally I thought of using Media, but due to the fact that Media.type has a VERY restricted valueset, I will probably end up using Observation.valueAttachment instead, mainly because the values are named audio, video and photo. While it may be a little thing and photo is actually in FHIR defined as more than just a photo, I would have loved if it was called image or picture instead, as photo according to various dictionaries define photo as something you make using a camera, which is not my case and which not how photo is defined in FHIR. The FHIR definition is much broader (The media consists of one or more unmoving images, including photographs, computer-generated graphs and charts, and scanned documents).

view this post on Zulip Eric Haas (Jun 14 2017 at 21:39):

Did you see this

view this post on Zulip Jens Villadsen (Jun 14 2017 at 21:54):

Thx @Eric Haas I did see it and it is not exactly the same as I see it. I oppose on using the word photo when it's definition states that it can be other stuff as well which is not aligned with the general definition of a photo.

view this post on Zulip Lloyd McKenzie (Jun 14 2017 at 22:30):

@Jens Villadsen Can you submit a change request? I agree that 'image' would be a better choice.

view this post on Zulip Eric Haas (Jun 14 2017 at 22:34):

that doesn't fix my issue with Media ... can image be a pdf? even more overlap with Observation+valueAttachment is not a good thing IMO.

view this post on Zulip Grahame Grieve (Jun 14 2017 at 22:41):

I'd rather not move more things into Observation. Maybe we should consider changing observation so it can reference a Media

view this post on Zulip Lloyd McKenzie (Jun 15 2017 at 01:42):

Certainly makes sense for Media to be an option in Observation.related.

view this post on Zulip Grahame Grieve (Jun 15 2017 at 01:46):

that's not the same thing

view this post on Zulip Lloyd McKenzie (Jun 15 2017 at 01:48):

What's not the same thing? You wouldn't want Media to be the value of an Observation because the elements on Media largely overlap those on Observation.

view this post on Zulip Grahame Grieve (Jun 15 2017 at 04:17):

it's related... so what's the value. It's not that you don't have a point, but making it 'related' doesn't get to the heart of the matter

view this post on Zulip Lloyd McKenzie (Jun 15 2017 at 13:43):

I'm trying to understand what you're proposing

view this post on Zulip Eric Haas (Jun 15 2017 at 15:42):

I was hoping to discuss on on FHIR-I or MNM with OO and Imagiing. but in summary:

  • the clinical context for Media can be captured by Observation.
  • The Media part of media is not that far removed from Attachment
  • Media is stuck in the middle making it a dealers choice every single time for which to use: Media or Obs + valueAttachment
  • If Media needs be a resource as a big brother to Attachment then why not valueReference(Media) with a stripped down Meda resource.
  • If Media doesn't need to be a resource then why not tack the extra parameters on Attachment and have a single way to handle all media with Obs valueAttachment?
  • Or get rid of valueAttachment (not that I think this is good idea)
  • If we like it the way it is then we just have to document that you have the opportunity to choose between Obs+valueAttachment and Media based on whether you want a half a dozen more media parameters , more or less clinical context and whether can reference one vs the other requires an extension.

view this post on Zulip Eric Haas (Jun 15 2017 at 15:44):

(because every place there is Reference(Observation) does not have Reference(Media))

view this post on Zulip Jens Villadsen (Jun 16 2017 at 07:05):

@Lloyd McKenzie you got it: track id #13533


Last updated: Apr 12 2022 at 19:14 UTC