Stream: implementers
Topic: Code only Observation valid?
Travis Stenerson (Jun 21 2017 at 13:42):
Hi guys, are code only / 'value[x]'-lacking Observations valid? I don't see anything in the StructureDef that prevents it.
A concept like "439311009 | Intends to continue pregnancy (finding) |". What would be the best way to represent that concept in a FHIR Observation? Would including valueBoolean be better?
Grahame Grieve (Jun 21 2017 at 13:43):
yes I think it would
Travis Stenerson (Jun 21 2017 at 13:44):
Thanks Grahame.
Travis Stenerson (Jun 21 2017 at 13:46):
Wait just realized I asked two questions. Did you answer yes to include valueBoolean or yes to code only being valid.
Grahame Grieve (Jun 21 2017 at 13:50):
including valueBoolean would be better
Grahame Grieve (Jun 21 2017 at 13:50):
because what would you do if they said no?
Jenni Syed (Jun 21 2017 at 15:51):
Note that there are other scenarios where code-only is valid, in our system, this is for grouped observations. We would always have a code or a link to other observations.
Chris Grenz (Jun 21 2017 at 16:01):
So, a valueBoolean of "false" should be interpreted as a negative finding? It would be helpful for the notes to explicitly define the meaning of an observation with no value (positive, or null/unknown?) and how to interpret valueBoolean false. Some inertia here since valueBoolean is a relatively new option.
Travis Stenerson (Jun 21 2017 at 16:12):
Do you have a simple example you could share @Jenni Syed ?
Jenni Syed (Jun 21 2017 at 16:14):
Primarily we use this in 2 scenarios right now. One is Social History - for eg, there are 8+ questions that may be answered for "Alcohol Use." (this is a concrete example, but clients choose to group these as it makes sense - so it's flexible)
Jenni Syed (Jun 21 2017 at 16:16):
We would have a "parent" observation that has a code = Alcohol Use, then links to several other observations, each representing a question and anwer. Each of these question/answers could be interpreted on their own, the "parent" is just to help group if someone wants to do a higher level interpretation on the full set of answers
Eric Haas (Jun 21 2017 at 16:16):
The code "439311009 | Intends to continue pregnancy (finding) |" sucks as an Observation.code since is not in the spirit of a question answer pair that Observation is built around. It would be more appropriate as the value with a code asking the question. Using this code in Observation.code is more like an assertion pattern which we really have tried to avoid in large part because of the negation headaches.
Jenni Syed (Jun 21 2017 at 16:17):
And what @Eric Haas just stated what the others look like :) The code on one of the related questions would be something like "drinks per day" with the value being "1" etc...
Jenni Syed (Jun 21 2017 at 16:19):
We don't put what would be considered the "answer" into the code, because that gets confusing.
Travis Stenerson (Jun 21 2017 at 16:22):
I agree Eric. Still looking for the ideal 'question' code.
Thank you Jenni. Makes sense.
Robert McClure (Jun 21 2017 at 16:40):
@Travis Stenerson Consider using LOINC 82810-3 Pregnancy status as the observation "question"
Travis Stenerson (Jun 21 2017 at 17:13):
@Robert McClure Definitely considered that , as well as pregnant at the time of illness. Still doesn't fully capture the idea that this observation represents the patient's decision with regards to pregnancy. But I'll probably end up going with that.
Michelle (Moseman) Miller (Jun 22 2017 at 16:40):
Last month, I had requested some examples be added around negative findings, per GF#13318 because I have seen examples where the value is ignored, which is risky when that value is negating the finding. I had gone as far as suggesting that the Observation.value[x] should be considered a modifier element, too.
For example:
Observation.code = Vomiting symptom (finding) SCTID: 249497008
Observation.valueBoolean = false
or
Observation.valueCodeableConcept = Absent (qualifier value) SCTID: 2667000
Michelle (Moseman) Miller (Jun 22 2017 at 20:04):
Do we think it is acceptable to have a SNOMED finding in the Observation.code with its value being a SNOMED qualifier of No (too many examples to list, but here are a couple more)?
Observation.code = 419045004 - Loss of consciousness (finding)
Observation.value = 373067005 - No (qualifier value)
or
Observation.code = 170805002 - Wants to lose weight (finding)
Observation.value = 373067005 - No (qualifier value)
or
Observation.code = 228524006 - Exposed to tobacco smoke at home (finding)
Observation.value = 373067005 - No (qualifier value)
Eric Haas (Jun 22 2017 at 20:08):
@Michelle (Moseman) Miller What you are doing is recreating an assertion pattern i.e. no proper .codes. And that is a headache to negate. @Rob Hausam is the expert in this area I believe.... And yes your tracker is on the OO radar. I am not crazy about making code a modifier for the reasons I stated in the tracker.
Eric Haas (Jun 22 2017 at 20:12):
I wonder if Assertions needs its own Resource or profile???
Michelle (Moseman) Miller (Jun 22 2017 at 20:18):
It's essentially Q&A on an assessment/form/questionnaire (SHx or otherwise) with questions that have simple Yes/No type answers.
Eric Haas (Jun 22 2017 at 20:29):
I'll need to review the tracker again. if you have a Y/N/U answer list then how is negation an issue.
Grahame Grieve (Jun 22 2017 at 20:33):
the assertion pattern is
code = ASSERTION
value = [some statement of truth]
Grahame Grieve (Jun 22 2017 at 20:34):
we don't like that in FHIR - want the ode to be as specific as possible:
code = ASSERTION about {Something]
value = [some statement of truth]
Grahame Grieve (Jun 22 2017 at 20:35):
I don't really like that pattern, it's pretty hard to deal with. But it's what the information really is, and I think Michelle's observations should valid
Michelle (Moseman) Miller (Jun 22 2017 at 20:36):
@Eric Haas Depending on the question, the Observation.value[x] can either be a Boolean or a CodeableConcept. There are some questions, like Sexually Active (finding), with possible answers of Yes, No, Refused to Answer.
Rob Hausam (Jun 22 2017 at 20:39):
There's a lot of stuff here - and it's the classic TermInfo issue, of course. We had agreed earlier that the V3-style ASSERTION patter (with all of the meaning in value) is best avoided, and so far I think we have. But we still haven't settled all of the other issues (obviously). I will add more as soon as I can.
Eric Haas (Jun 22 2017 at 20:51):
I would say that in FHIR we prefer
Code = QUESTION about {Something}
Value - ANSWER
MIchelle's example Observation's are more of a
Code = Is this ANSWER about {Something} true?
Value - Y/N/other
I agree they are valid too but contend they are close to asserting the value. I'm OK with adding them as examples in the spec which I believe was the gist of the tracker.
Eric Haas (Jun 22 2017 at 20:52):
And take back my statement about needing a new resource.....
Alex Goel (Jun 23 2017 at 13:53):
Hi, we have a use case where we havce a single select list where each answer is coded. In the example below the radiologist has to select the location of the nodule. Each answer is coded with RadLex If we were to set this up as a series of booleans we would have 6 questions instead of 1. If there is no nodule present the radiologist would report in a previous question that this is the case, negating the entire "Nodule" section of the report.
I have an example of this kind of question below. We built this using questionnaire, but I think the same idea applies. Would an example like this be better in observation?
<item>
<linkId value="q4.1.ii"/>
<concept>
<system value="http://www.radlex.org"/>
<code value="RID34694"/>
<display value="lobe of lung"/>
</concept>
<prefix value="ii."/>
<text value="Lobe:"/>
<type value="choice"/>
<option>
<valueCoding>
<code value="q4.1.iia"/>
<concept>
<system value="http://www.radlex.org"/>
<code value="RID1303"/>
<display value="upper lobe of right lung"/><
</concept>
<display value="RUL"/>
</valueCoding>
</option>
<option>
<valueCoding>
<code value="q4.1.iib"/>
<concept>
<system value="http://www.radlex.org"/>
<code value="RID1310"/>
<display value="middle lobe of lung (part of Right lung)"/>
</concept>
<display value="RML"/>
</valueCoding>
</option>
<option>
<valueCoding>
<code value="q4.1.iic"/>
<concept>
<system value="http://www.radlex.org"/>
<code value="RID1315"/>
<display value="lower lobe of right lung"/><
</concept>
<display value="RLL"/>
</valueCoding>
</option>
<option>
<valueCoding>
<code value="q4.1.iid"/>
<concept>
<system value="http://www.radlex.org"/>
<code value="RID1327"/>
<display value="upper lobe of left lung"/>
</concept>
<display value="LUL"/>
</valueCoding>
</option>
<option>
<valueCoding>
<code value="q4.1.iie"/>
<concept>
<system value="http://www.radlex.org"/>
<code value="RID1333"/>
<display value="lingula"/>
</concept>
<display value="Lingula"/>
</valueCoding>
</option>
<option>
<valueCoding>
<code value="q4.1.iiif"/>
<concept>
<system value="http://www.radlex.org"/>
<code value="RID1338"/>
<display value="lower lobe of left lung"/>
</concept>
<display value="LLL"/>
</valueCoding>
</option>
</item>
Travis Stenerson (Jun 23 2017 at 14:10):
Question about {something} certainly is a pain with SNOMED/LOINC for a certain type of observation . The pattern works well for most situations and makes sense to me, but is a real pain for the type of things you would find in an unstructured note.
Like you wouldn't see 'status of vomiting symptom (observable)': 'patient has vomited (finding)'. Just 'vomiting'. So to programmatically extract a FHIR resource from that text you would have to know that 'vomiting' interprets 'status of vomiting'. At least in this case you have the concept "405166007 | Nausea and vomiting status (observable entity) |"
I suppose I'm just voicing frustration after spending like 4 hours trying to find the question 'Is the tumor surgically resectable'. I'm not even sure how to phrase the question if I look to add it, or if it should be a clinical impression.
Alex Goel (Jun 23 2017 at 14:15):
I'm having similar frustrations with Question about {something specific with option} because in this case the answer has more meaning and value than the question. If the answer is unstructured this makes it even more complicated because you have to code the question, and SNOMED/LOINC are not always semantically as discrete or valuable for that case - as @Travis Stenerson said it requires the reader to know the context
Michelle (Moseman) Miller (Jun 23 2017 at 14:26):
I think there is some good guidance/considerations on whether to use Questionnaires vs other resources like Observation in http://hl7.org/fhir/STU3/questionnaire.html#qversusr.
Travis Stenerson (Jun 23 2017 at 14:32):
@Alex Goel You might want to look at the updated BodyStructure resource, location and locationQualifier gives you some flexibility. And check out the Cancer-DTR stream and workgroup calls, there was a some mention of another group specifically looking at non-small cell lung ca this past wednesday though they weren't on the call. Cancer-DTR is starting with breast.
Alex Goel (Jun 23 2017 at 14:47):
@Michelle (Moseman) Miller The primary reason we went with Questionnaire is because of SDC, not sure what drove the decision to use questionnaire over observation http://hl7.org/fhir/current/sdc/sdc.html @Travis Stenerson are you referring to the BodyStructure valueset? I'll check out the Cancer-DTR stream! Thanks
Travis Stenerson (Jun 23 2017 at 14:58):
@Alex Goel I mean this guy: http://build.fhir.org/bodystructure.html . It was altered to support the use case of tracking entities like nodules and tumors over time.
Alex Goel (Jun 23 2017 at 15:45):
@Travis Stenerson How could BodyStructure be used with a single select list like the example I posted earlier? Sorry, I'm just not clear on that. Is it able to break down into segments of the lung?
Travis Stenerson (Jun 23 2017 at 17:00):
@Alex Goel You would have to profile BodyStructure and slice locationQualifier and define discriminators for each slice and make value sets for each slice, have the interpreting system understand it all and present the valuesets.
It's quite a bit more complicated than just making a Questionnaire, but you end up with a resource representing the nodule which can be referenced by Observations. It would let you segment it the locationQualifiers into slices like laterality, lobe, segment, anatomical third (distal/proximal having a little relevance for Stage IA NSCL). I haven't actually made the profile yet that we intend to use to represent a lung nodule or tumor, so this is a tentative plan. But yeah, definitely more work and would depend on what you intend to do with the data I suppose. I just thought I'd point you to it because it was just altered in the last week or two to better capture tumors/nodules.
Alex Goel (Jun 23 2017 at 17:03):
@Travis Stenerson ok thanks! I'll try that out
Last updated: Apr 12 2022 at 19:14 UTC
