FHIR Chat · Converting multiple answers in QR to OBS · implementers

Stream: implementers

Topic: Converting multiple answers in QR to OBS

Eric Haas (May 10 2016 at 04:48):

In OO today looking at tracker from @Michelle M Miller and @Hans Buitendijk to allow for the same code in code and component.code this use case was posited. If you have a Questionnaire that allows multiple answer for a question in QuestionnaireAnswer ( e.g. a,b,c) what is the best practice for converting these to Observation. I think they transform into three Observations. An argument is made for a single Observation using Observation.components.

Michelle (Moseman) Miller (May 10 2016 at 11:02):

Our system treats a question with multi-select answer as a single observation.

For example:

• Server has a single Alcohol Type code/question, associated to multiple codified values/answers, such as Beer and Wine.
• Server has a single Alcohol Type observation status (e.g. Final).
• Server has a single Alcohol Type observation comment (e.g. some comment about the beer, such as "Prefers craft beers; employed by Boulevard Brewing Company")
• Server has a single id for this Alcohol Type observation.

Splitting these up into 2 distinct observations (e.g. Alcohol Type of Wine and Alcohol Type of Beer) has the following consequences:

• We'd have to make up an Observation.id since 2 distinct observations can't share the same id.
• The single comment about beer gets applied to both observations, such that it is out of context on the Wine observation.
• When an application tries to update one of the two observations (e.g. update a comment, status, etc.), the server has unexpected behavior in that we'd be updating both observations, since our server doesn't allow us to in error beer without also in erroring wine. By contrast, the server would normally consider removing an answer more like a modify action and less like an In Error status change.

Lloyd McKenzie (May 10 2016 at 19:51):

But if you're capturing multiple answers for one question, the only way to do that is with component observations because value[x] can't repeat

Michelle (Moseman) Miller (May 10 2016 at 20:11):

Right, we want to leverage Observation.component, but currently can't do so due to the invariant (obs-7: Component code SHALL not be same as observation code), which is what prompted my change request to be logged to remove this invariant.
http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=9375

Grahame Grieve (May 10 2016 at 20:37):

you can have the same component code more than once. I've never understood that task

Lloyd McKenzie (May 10 2016 at 20:42):

But you want to have a code on the root Observation too. And right now there's a rule that says that code can't be the same as the component codes - and it's not clear what else you could populate the root code with.

Michelle (Moseman) Miller (May 10 2016 at 20:44):

+1 Lloyd -- that is the exact problem. Currently we are asking to remove the invariant, so that it is possible to have Observation.code = Observation.component.code

Michelle (Moseman) Miller (May 10 2016 at 20:46):

Observation.code and Observation.component.code are both required, so another approach (if we keep the invariant) is to make Observation.component.code optional.

Grahame Grieve (May 11 2016 at 10:28):

I'm having trouble following this, actually. You have a code that is simultaineously defined as both a panel and an actual result?

Michelle (Moseman) Miller (May 11 2016 at 10:39):

It's more like a single question (code) with multiple answers (valueCodeableConcept).
Example 1: code = Respirations with 7 codified values of Abdominal, Gasping, Hyperpnea, Labored, Nasal, flaring, Retracting
Example 2: code = Respiratory Pattern with 2 codified values = Irregular, Tachypnea
Example 3: code = Oxygen Therapy with 2 codified values = Humidification, Nasal cannula
Example 4: code = AlcoholType with 2 coded values = Beer, Wine
etc.

Grahame Grieve (May 11 2016 at 10:50):

and these are multi-select lists? So for example one:
Obs.code = Respirations, no value
obs.componant.code Abdominal, value = true/false

Grahame Grieve (May 11 2016 at 10:50):

etc

Grahame Grieve (May 11 2016 at 10:50):

?

Michelle (Moseman) Miller (May 11 2016 at 11:03):

If we went with that suggestion, then the values are always true. It feels a bit awkward to say that in other examples that might not be talking about present state, meaning the component.value is not actually true *right now* based on the question asked, such as:

• Observation.code = Release Criteria for Restraint
• Observation.component.code = Cognitive status improved and no longer interferes with care, with value = true
• Observation.component.code = Medical devices, tubes, and dressings removed, with value = true

I think it is cleaner to represent as:

• Observation.code = Release Criteria for Restraint
• Observation.component.value= Cognitive status improved and no longer interferes with care
• Observation.component.value= Medical devices, tubes, and dressings removed

Grahame Grieve (May 11 2016 at 11:04):

why would the values always be true? I wasn't suggesting that

Grahame Grieve (May 11 2016 at 11:05):

I can't get my head around your alternative actually - doesn't help that it's a different example, because it looks like the same pattern to me

Grahame Grieve (May 11 2016 at 11:05):

but I suspect that the core problem here is that Observation.value is 0..1 not 0..*

Michelle (Moseman) Miller (May 11 2016 at 11:09):

Yes, that is the root problem -- that Observation.value is 0..1 -- so an earlier gForge advised me to use components to represent the multiple values. We don't persist the false (unselected answers) -- only the true (selected answers), so we would be hard-coding all values to true.

Grahame Grieve (May 11 2016 at 11:10):

ok well, I understand the problem properly now. The advice is certainly inconsistent with the invariant, that's for sure

Grahame Grieve (May 11 2016 at 11:12):

I don't like revoking the invariant, and I don't like the idea of having components without codes, nor inventing a code that say 'instance of value'

Grahame Grieve (May 11 2016 at 11:12):

but the requirement is real.

Grahame Grieve (May 11 2016 at 11:12):

interesting conundrum

Michelle (Moseman) Miller (May 11 2016 at 11:30):

To summarize options (in case this makes the OO Q1 agenda today):

• Option A = change Observation.value to be 0..*
• Option B = change Observation.component.code to be 0..1 (optional)
• Option C = remove the invariant that says Observation.code can't be the same as Observation.component.code
• Option D = hard-code the Observation.component.value = true for all "selected" answers, such that the Observation.component.code is now the coded "answer" (which makes the meaning of the component.value "yes, I answered the question with this value" and not "yes, the component.code is true right now")
• Option E = treat these as separate, independent Observations (which I contend we can't do per my initial comments because the server can't separate them and maintain separate statuses, comments, etc.)

Grahame Grieve (May 11 2016 at 12:07):

option A cannot be on the table. Sorry. option D is my least unfavourite...

Lloyd McKenzie (May 11 2016 at 12:22):

I really don't like option D. The answer is a code, it's not a boolean. Taking answers to a question from Observation.component.code feels totally wrong.

Lloyd McKenzie (May 11 2016 at 12:22):

Option A is possible, it just requires a wrapper.

Lloyd McKenzie (May 11 2016 at 12:23):

My preference is A (with a wrapper), then B

Grahame Grieve (May 11 2016 at 12:23):

implementers will hate the wrapper. with a passion.

Grahame Grieve (May 11 2016 at 12:24):

for other readers of this:

<Observation>
  <valueCodeableConcept>
   <.../>
  </valueCodeableConcept>
<Observation>

Grahame Grieve (May 11 2016 at 12:24):

would become

<Observation>
  <value>
   <CodeableConcept>
     <.../>
   </CodeableConcept>
  </value>
<Observation>

Grahame Grieve (May 11 2016 at 12:25):

The Json would change equivalently

Lloyd McKenzie (May 11 2016 at 12:25):

Not necessarily. We could have:
<value[x]/>
<multiValue>
<value[x]/>
</multiValue>

Lloyd McKenzie (May 11 2016 at 12:25):

With a constraint that you can only have one of the two

Grahame Grieve (May 11 2016 at 12:25):

carumba

Grahame Grieve (May 11 2016 at 12:25):

we do love our complexity

Lloyd McKenzie (May 11 2016 at 12:25):

That's much less complex than forcing component observations

Lloyd McKenzie (May 11 2016 at 12:26):

Some types of observations naturally have multiple values

Grahame Grieve (May 11 2016 at 12:26):

yeah, the really cool thing about your approach is that a value might be found in value, or in multi-value. That's one all implementers will enjoy

Lloyd McKenzie (May 11 2016 at 12:26):

I can live with value/valueCodeableConcept or a choice of valueCodeableConcept and multiValue/valueCodeableConcept

Lloyd McKenzie (May 11 2016 at 12:27):

Well, the value could be found in Observation/value or Observation/component/value now

Lloyd McKenzie (May 11 2016 at 12:27):

I don't see the difference in complexity there.

Michelle (Moseman) Miller (May 11 2016 at 18:51):

This was discussed during Q1 OO session. The rationale/details are documented within gForge (http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=9375), but the outcome/resolution was removing the existing invariant and replacing with a new invariant: "If .code = .component.code then .value must not exist"

Eric Haas (May 11 2016 at 19:13):

Prohibiting Observation.value when you have componets. (Back to Pre DSTU)

Lloyd McKenzie (May 12 2016 at 01:56):

Not quite when you have components. If you have an APGAR, you'd have one code on the root observation and a value, and different codes on the components. However, in the questionnaire example, you'd have the same code on the root observation and the components and because of that, you wouldn't be able to have a value on the root observation.

Michelle (Moseman) Miller (May 12 2016 at 03:31):

Right, so the new/revised invariant still allows an Observation.value when the codes differ (e.g. APGAR example). It only prohibits the Observation.value when the codes are the same (observation.code = observation.component.code)

Eric Haas (May 18 2016 at 04:10):

actually Lloyd is correct you can't have a value and component.value so APGAR uses .related.

Lloyd McKenzie (May 18 2016 at 13:28):

Why can't you have a value and a component.value?

Eric Haas (May 18 2016 at 14:18):

if the code are the same you can not distinguish the relationship of value to component value.

Eric Haas (May 18 2016 at 14:19):

use related instead

Eric Haas (May 18 2016 at 14:26):

component values are siblings value is not . I believe that is why the DSTU1 and DSTU2 invariants where made in the first place but is not documented anywhere I can locate.

Eric Haas (May 18 2016 at 15:34):

@Lloyd McKenzie Actually I mis- represented the disposition. I thought we reverted to the original invariant from pre DSTU (Actually that is what I had suggested) but michelle is correct and
Apgar can use components if the the codes are different.

Last updated: Apr 12 2022 at 19:14 UTC