FHIR Chat · Attaching an image to observation

Stream: implementers

Topic: Attaching an image to observation

Sebastiaan Raap (Jul 10 2019 at 12:22):

We're profiling an observation for the description of wounds and we would like to attach a picture of the wound too. What would be the way to go? My suggestion is to make an extension with valueAttachment. Is this a good idea or are there better options?

Mareike Przysucha (Jul 10 2019 at 12:39):

We are also profiling resources for wound management (WoundSummary, National Consensus for the documentation of leg ulcera). We plan to use a media resource for the picture, but I am currently thinking about how to tell the media it is made because of a special wound. Probably you/we could use a clinical impression to summarize the observations and the media. What do you think?

Sebastiaan Raap (Jul 10 2019 at 13:22):

We're using Condition to state that a patient has a wound, one Observation (with lots of components) for our wound observables like wound edge, woundwith, woundlength. we've chosen to put this all in one observation so you've got them grouped together because you to be able to discriminate between assessments over time. As we're on STU3 we're using the extension Observation.reasonReference to link it to the Condition, in R4 we would use Observation.focus.

We planned on using Media for the wound photo's, but linking it to an Observation is not something the standard is describing. That's why we just want to extend the Observation with Attachments where you can place the photo's made during the assessment.

Do I understand correctly (from your previous posts as well) that you want to make Observations (one per observable) and Media's (for the photo's) in which you will refer to ClinicalImpression (to group the observables to discriminate between assessments), which will refer to a Condition (which describes the existence of the wound at a certain bodySite?

I certainly think that implementation would make sense, but we're a bit hesitant on using ClinicalImpression because of the maturitylevel of 0, which has been 0 over STU3 and R4.

Kevin Mayfield (Jul 10 2019 at 13:24):

Is one Encounter or a series of Encounters? (I think I've seen similar events linked by Encounter)

Mareike Przysucha (Jul 10 2019 at 13:34):

I think both approaches have their charm and consider the different use cases.
@Sebastiaan Raap Your description of our approach is correct. For us this is the better approach as in our project the idea is to gather information from other systems and use these data for clinical decision support.
@Kevin Mayfield Therefore we may have different Encounters.

Kevin Mayfield (Jul 10 2019 at 13:36):

I think I modelled a ER use case using multiple encounters under a master encounter. Each obs, condition, etc was linked to the child encounter.

Sebastiaan Raap (Jul 10 2019 at 13:44):

Sounds legit. but wouldn't you refer to the Condition in the master encounter? Since Encounter.diagnosis.condition and Encounter.reasonReference is a Condition for which the encounter has taken place, not the resulting diagnosis from that encounter, as is the consensus in https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Type.20of.20Condition

John Moehrke (Jul 10 2019 at 14:05):

use DocumentReference. It would then be Observation.derivedFrom

John Moehrke (Jul 10 2019 at 14:06):

reminder that a 'document' in the terms of DocumentReference is not the same as CDA defines as Document. It is more the definition of document in the context of http... that is some bits that have a mime-type. DocumentReference is then filled with the available metadata about that document. In your case the image.

Mareike Przysucha (Jul 10 2019 at 14:08):

But would "derivedFrom" not mean that the content of the observation is derived from the document?

Mareike Przysucha (Jul 10 2019 at 14:09):

so you have the picture and look at it and say: 5 cm wide, 2 cm broad, 1 cm deep, ...

Kevin Mayfield (Jul 10 2019 at 14:17):

I would have recorded a new Condition against a child encounter (Condition.encounter). If that Condition was also a diagnosis I would record it in the parent encounter. I suppose I'm using the child encounters as a journal.

Eric Haas (Jul 10 2019 at 14:49):

If the value is the observation then I think valueAttachment is the way to go. If it’s a “here is the image upon which my observation is based used the docref as derived from. We are planning to merge Media into docref and are considering bringing valueAttachment back for R5. There is resistance from the from the owning workgroup on adding it so will be posting a straw poll here in near future to measure implementer sentiment.

Lloyd McKenzie (Jul 11 2019 at 00:16):

You can also use BodyStructure to link Observations,Procedures and other resources to a single locayion/wound/lesion. There is a standard extension for that linkage

Mareike Przysucha (Nov 22 2019 at 15:22):

I just had a look at the extensions for Media: reasonReference is possible (https://www.hl7.org/fhir/extension-workflow-reasonreference.html)

Vassil Peytchev (Nov 22 2019 at 15:31):

Media is likely to go away, replaced by docref

Mareike Przysucha (Nov 22 2019 at 15:33):

Thanks for the hint!!!
As we are now profiling in r4 we need it this way. For further developments we will keep this in mind and add our IG accordingly.