FHIR Chat · Observation code "qualifiers"? · implementers

Stream: implementers

Topic: Observation code "qualifiers"?

Josh Mandel (Jun 22 2016 at 19:30):

Imagine (for a silly example) I want to express an observation like "color of [[something]]". Well, SNOMED "107650008" could express "color of"... but of course we don't have pre-coordinated codes meaning "color of toenail" or "color of spleen" or whatever.

Now, with SNOMED I could create an expression meaning "color of toenail" and stick it in Observation.code, but this has two issues:

1. If clients want to query for "all color observations", there's no clear way to do this unless servers support SNOMED expressions in a deep way.

2. If the objects don't have SNOMED codes (but do have codes in another standard terminology), there's no way to use this approach.

Some possible "fixes" would be to use an Observation.code meaning "color", and express "colored thing = toenail" in an

• a) Observation.extension,
• b) Observation.related, or
• c) Observation.component

Well, a) is nice but doesn't allow "generic" search; b) seems to create a separate observation that doesn't really stand alone. Is (c) plausible here?

Jeremy Walton (Jun 22 2016 at 19:37):

@Josh Mandel can you not say /Observation?code=107650008&code=<snomed toemail code> ?

Josh Mandel (Jun 22 2016 at 19:38):

It's a good point --- another option I've considered. Given that the cardinality of Observation.code is 1..1, it's sort of "cheating" to try to stick different meanings into a single code and pretend their intersection is the meaning of the whole thing. But it does satisfy my use case from a mechanical/functional/syntactic perspective.

Ioana Singureanu (Jun 22 2016 at 19:39):

Pre-coordinate codes are not a good idea, agreed but there a lot of good examples where qualifiers are very interesting: and "oxygen saturation" (O2SAT) with or without oxygen administration . Searching for "O2Sat" then filter by "with oxygen"? I would vote for a) "core extension" qualifier [0..*].

Josh Mandel (Jun 22 2016 at 19:40):

What would be the type of the qualifier, @Ioana Singureanu ?

Jeremy Walton (Jun 22 2016 at 19:42):

Normally I would consider any codes in the Coding field of the same system as AND's instead of OR's, different systems would be an OR

Ioana Singureanu (Jun 22 2016 at 19:42):

Probably a choice of Observation, or Procedure ("oxygen administration .. volume") . Observation.bodySite is already a built-in qualifier.

Josh Mandel (Jun 22 2016 at 19:43):

Hmm -- if the data doesn't go inline, it's still hard to work with through FHIR's current REST API.

Josh Mandel (Jun 22 2016 at 19:44):

@Jeremy Walton well, the notion of repeat codings in a single CodeableConcept is they're supposed to be synonyms/translations.

Jeremy Walton (Jun 22 2016 at 19:48):

@Josh Mandel Which makes sense when you talk about different coding systems, but if there are multiple of the same, either there is something wrong with the coding system you are using, or thats how the system works collectively

Jeremy Walton (Jun 22 2016 at 19:51):

@Josh Mandel Although I would definitely prefer that code/display of CodeableConcept.Coding be an array, that way, you can store one system, with multiple codes that are collective together.

Josh Mandel (Jun 22 2016 at 19:52):

I mean, in a hierarchical coding system I could include multiple codings that walk up the tree from "toenail" to "foot part" to "body part" to "thing", and could including all 4 codings if wanted. That helps facilitate some query patterns (but I wouldn't exactly call it a best practice).

Jeremy Walton (Jun 22 2016 at 19:54):

@Josh Mandel You are right, but I don't see those as being synonymous at least in a clinical setting. They are related but definite do not mean the same thing.

Josh Mandel (Jun 22 2016 at 19:58):

Yes -- this is only true in a "subsumption logic" sense.

Eric Haas (Jun 22 2016 at 20:25):

Precoordinated LOINCs have already done this in many cases. So does post coordination of SNOMED code. So a coding system exists to handle many use cases. For the cases where this is not the case, for STU3 , OO is proposing using Observation.component.code is relative to the Observation.code in the same way you propose. http://hl7-fhir.github.io/observation-operations.html.

Grahame Grieve (Jun 22 2016 at 20:34):

I don't think that the proposal for component is the same thing.

Grahame Grieve (Jun 22 2016 at 20:37):

My take on Josh's question is that the question could be code | bodysite. At least the examples Josh gave are about that. Or it could be specimen, though you could make colour observations on other things. And so something so general points to an ontological solution.... so then, well, it's a terminology problem.

Grahame Grieve (Jun 22 2016 at 20:37):

and we've described the proper solution for this, which is a value set with a filter, and a search for :in.

Grahame Grieve (Jun 22 2016 at 20:44):

but as you say "servers support SNOMED expressions in a deep way" - well, yes. But as far as I can tell, that's inevitable. Else, well, you'll have to indulge in trickery and make arbitary rules about snomed queries or extensions (that's what _query is for)

Eric Haas (Jun 22 2016 at 20:54):

To clarify what I think is being discussed is there are several inline qualifiers such as bodysite, method, device., time. What if the class of qualifiers doesn't exist? (and I can't think of any right now - because I think we already have most of the big ones covered) How best to handle that. In retrospect an extension would be my choice. I agree the operation is a bit different.

Grahame Grieve (Jun 22 2016 at 20:58):

well, you could talk about the colour of a thing that is not a body site. You could generalise the heck out of that concept and probably cover this case at the case of no one having any idea what the element is for...

Josh Mandel (Jun 23 2016 at 02:15):

@Grahame Grieve Yeah. My real interest here is not colored-things, but genotype observations. It doesn't make sense to have pre-coordinated codes meaning "genotype determination for [[some gene]]" for every gene in existence. But SNOMED has a generic "genotype determination" code, and HGNC has codes for all of the relevant genes.

The extension approach is okay, but it means search doesn't work out-of-the-box on servers that do support the standard FHIR search params. I'm experimenting with components-as-ad-hoc-qualifiers, which I'm not thrilled about semantically, but it does "work" technically.

Erich Schulz (Jun 23 2016 at 03:02):

at some point the cost/benefit of postcordination has to tip over...

Erich Schulz (Jun 23 2016 at 03:04):

but @Josh Mandel is it possible to use the code for the gene for observation.code then the genotype as the value?

Erich Schulz (Jun 23 2016 at 03:05):

or is the gene the bodySite ??

Grahame Grieve (Jun 23 2016 at 07:30):

@Josh Mandel what have clinical genomics said about this question to this point?

Josh Mandel (Jun 23 2016 at 10:53):

Currently all qualification is in extensions (see http://hl7-fhir.github.io/observation-genetics.html). I'm thinking through the implications here.

Grahame Grieve (Jun 23 2016 at 11:00):

this is a hard problem. Bodysite is obviously wrong, but it might not be wrong if we generalised 'site'. but that might be a less than optimal idea generally

Erich Schulz (Jun 23 2016 at 11:01):

wrong depends on scale :-)

Grahame Grieve (Jun 23 2016 at 11:01):

OO would say that the correct approach is to push both things into the code, so it remains a code / value pair, but we accept method as a variant on that

Grahame Grieve (Jun 23 2016 at 11:02):

that would argue for an extension approach; we can define a search parameter on an extension in the spec if we need to

Josh Mandel (Jun 23 2016 at 11:02):

In the past I proposed an extension on Observation.code (but that's crazy confusing)

Grahame Grieve (Jun 23 2016 at 11:02):

yes, it should be an extension on Observation, not Observation.code

Josh Mandel (Jun 23 2016 at 11:03):

True, but in general there's a real benefit in designs that "just work" with all the reference servers without having to wait 18 months between releases.

Josh Mandel (Jun 23 2016 at 11:04):

I.e. Solutions that can naturally "back port" to the currently published release are nice. Not the only consideration by any stretch, but it counts for something.

Grahame Grieve (Jun 23 2016 at 11:04):

I don't think you have to wait 18 months for a new release.

Grahame Grieve (Jun 23 2016 at 11:04):

though it's not automatic, no

Josh Mandel (Jun 23 2016 at 11:06):

I mean, technically a qualifier here is qualifying the code (at least in the case of "code=genotype assessment, gene=TPMT"). But that's unmanageable.

Grahame Grieve (Jun 23 2016 at 11:16):

why is it unmanagable

Eric Haas (Jun 23 2016 at 14:15):

In viral sequencing in V2 have done this as a type of panel. The CG group moved away from this I think. The gene was part of the panel so that fits into using the components. code = genotype assessment component.code= gene, component.value - TPMT and component.code[1]= blah, component.valeu[2] =blah... Some component code are provided more context for the other values.

Eric Haas (Jun 23 2016 at 14:18):

The CG work actually spurred us to bring component back. These values all had to be looked at together. They were meaningless apart. I think after reading this that this is what you are looking for.

Eric Haas (Jun 23 2016 at 14:19):

CG wanted them to be inline and not name:value so chose the extensions and then created the Sequence resource

Robert McClure (Jun 23 2016 at 16:23):

Seems to me that we need a good reason to push hard very soon to define a post-coordination extension mechanisim that everyone can adopt. Could be that gene data is the right lever to make that push. If we can get the right terminology authorities involved (IHTSDO plus who ever can bring the gene concepts to the party) you might be able to get this moving. I'd really be concerned if you all tried to hack an in-line approach to this that makes all sorts of assumptions. Am I on the right track?

Josh Mandel (Jun 23 2016 at 16:25):

Am I on the right track?

Perhaps @Robert McClure! What do you mean by "hack an in-line approach". That is: what has you most concerned?

Robert McClure (Jun 23 2016 at 16:28):

my biggest concern is that FHIR do post-coordination in a consistent way. By post-coordination I mean communicate meaning using coded concepts alone. And the in-line concern was that simple combinations of concepts would have assumed, instead of explicit, semantics. I know I'm not following everything you all have said so I could be off in a different space...

Rob Hausam (Jun 23 2016 at 16:46):

I agree with Rob's concern. We need to be careful, and also very clear, about whatever we decide to do with this. Post-coordination in SNOMED CT is hard enough, and it has an underlying description logic foundation. The description logic doesn't make it easy, but at least it helps (doesn't always ensure) in making it consistent and sound. If we start "post-coordinating" more extensively with the FHIR elements (most likely without having that formal description logic foundation), we may well create more issues than we are solving. So let's proceed with exploring this, but be cautious and thorough in evaluating whatever is being proposed.

Eric Haas (Jun 23 2016 at 17:34):

I think we mentioned post-coordination of codes as a possibility vs a precoordinated code like LOINC. We are already modifying the context of the code in the resources now when you use the method or bodysite or specimen or any othe element (if we hypothetically add an element "gene" to Observation that would qualify the code.)! Using component codes using a name value pair is a way to relate interdependent observations codes with the same context and maybe qualifier codes is the wrong term.

At this point in FHIR saying hold on is very curious to me. What exactly is the concern here with this discussion?

Grahame Grieve (Jun 23 2016 at 21:36):

well, there's a methodological issue. From a purist informatics point of view, the right way to do this is post-coordination. In practice, though, that's not supportable because of the way systems are architected today, and Josh is searching for something that's implementable now.

Grahame Grieve (Jun 23 2016 at 21:38):

FHIR has the APIs that allow you to build an architecture that doesn't see post-coordinated codes differently, but as far as I know, I'm the only one who's built an architecture that works that way. It's not possible to retro-fit that either

Grahame Grieve (Jun 23 2016 at 21:46):

I don't know whether the component approach meets Josh's needs - what does it look like - example?

Josh Mandel (Jun 23 2016 at 21:52):

I was noodling with Gaston on something like https://github.com/jmandel/pgx-cds/blob/patch-1/examples/tpmt/Observation-example-diplotypecall.json

Eric Haas (Jun 23 2016 at 22:03):

I expected this observation to include at least one more component of an actual measurement.

Josh Mandel (Jun 23 2016 at 22:12):

Currently this example includes the genotype "measurement" at Observation.value. -Would you rather put that in a component instead of Observation.value? If so, what would the Observation.code and component.code be then, @Eric Haas?

Erich Schulz (Jun 23 2016 at 23:21):

i think "solving postcoordination" is a problem bigger than FHIR

Erich Schulz (Jun 23 2016 at 23:21):

getting a consistent model that gives a standardised expression pattern is half the battle

Erich Schulz (Jun 23 2016 at 23:22):

uncontrolled postcoordination rapidly degenerates into something akin to free text parsing unless all stakeholders are on same page

Grahame Grieve (Jun 23 2016 at 23:23):

I think Josh's example is valid

Eric Haas (Jun 23 2016 at 23:53):

I wasn't expecting value so I missed that. I would expect this pattern....

<?xml version="1.0" encoding="UTF-8"?>
<Observation xmlns:xhtml="http://www.w3.org/1999/xhtml" xsi:schemaLocation="http://hl7.org/fhir //Mac/Home/Documents/FHIR/FHIR%20tools/DSTU2Schema/observation.xsd" xmlns="http://hl7.org/fhir" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<id value="gene-example"/>
<status value="final"/>
<code>
    <coding>
        <system value="http://example.org"/>
        <code value="genetic test"/>
        <display value="Genetic test"/>
    </coding>
</code>
<component>
    <code>
        <coding>
            <system value="http://example.org"/>
            <code value="gene"/>
            <display value="Gene"/>
        </coding>
    </code>
    <valueString value="GENE"/>
</component>
<component>
    <code>
        <coding>
            <system value="http://example.org"/>
            <code value="genetic test measure"/>
            <display value="Genetic test Measure"/>
        </coding>
    </code>
    <valueQuantity>
        <value value="1000"/>
    </valueQuantity>
</component>
</Observation>

Eric Haas (Jun 23 2016 at 23:57):

where .code would be a "panel or grouper' code. I think having a .value and a .component.value implies "rank" for lack of a better term. where the .value would be a compilation or summary of all the component values.

Eric Haas (Jun 24 2016 at 00:04):

Oops ... this example is invalid because of an invariant that says .code can't equal .component.code - I fixed it

Josh Mandel (Jun 24 2016 at 00:07):

Can you help me understand why repeating the Observation.code in Observation.component.code (or slightly tweaking it just to make the validator happy) provides a more correct (or otherwise preferable) solution? What's new gain?

Grahame Grieve (Jun 24 2016 at 00:23):

ah. ok. well, that follows the pattern we use for immunology, but makes search a little hard

Grahame Grieve (Jun 24 2016 at 00:26):

Josh's pattern is odd:
obs code = genotype determination, value = {genotype}
component obs code = gene, value = {gene}

Erics's pattern is also odd
obs code = genetic test
component obs code = gene, value = {gene}
component obs code = genotype, value = {genotype}

Grahame Grieve (Jun 24 2016 at 00:27):

when the underlying concept model is
test = genotype, gene = {gene}, value = {genotype}

Grahame Grieve (Jun 24 2016 at 00:27):

gene is a qualifier like bodysite is

Grahame Grieve (Jun 24 2016 at 00:27):

.I think it's better as an extension than a componetn

Grahame Grieve (Jun 24 2016 at 00:27):

having looked at both those

Eric Haas (Jun 24 2016 at 00:40):

My issue is what is implied relationship between .value and the component. What happens when there are multiple Values for Gene X? We actually state that "As is true when using Observation.related above, the observation for a panel that carries the component typically does not have its own Observation.value."

Eric Haas (Jun 24 2016 at 00:42):

mine is less odd and more patterned after a panel! :-)

Grahame Grieve (Jun 24 2016 at 00:43):

less odd was a smalle mountain to climb in this case ;-)

Joel Schneider (Jun 30 2016 at 16:04):

Here's another twist. The underlying sequence data associated with a particular clinical biomarker can change over time. For example, the set of BRCA1 mutations classified as pathogenic may grow. For that reason, when doing genetic analysis of a patient cohort, it may be important to re-interpret the underlying sequence data instead of relying on coded values generated in the past.

Eric Haas (Jun 30 2016 at 17:09):

Is this already addressed by the Sequence Resource or the genetics profile?

Josh Mandel (Jun 30 2016 at 19:43):

Addressed, yes: I'm trying to figure out how well this works in practice, and whether alternatives might work better.

Eric Haas (Jun 30 2016 at 19:58):

OK let me know if and what I or OO can do to help. @Joel Schneider If I understand you correctly what you are measuring is a moving target. Still - Iook at this a type of panel with two classes of result values : 1) direct measurements and 2) a set of "ask at order" observations.

You have to ask each time "Ok what I am measuring" The measurements are looked at in the context of the new set of answers to that question.
One day the sands will stop shifting in genomics and will be just like measuring glucose levels. - quote from Clem :-)

Joel Schneider (Jul 07 2016 at 16:10):

@Eric Haas Thanks for the offer to help. It may take time for concrete details to filter through the CG group. Clem has definitely been working on HL7 v2 representations for genetic test results. The pattern of direct measurements and derived observations makes sense.
For some cases, clinical genetic test reporting might only include results which are deemed significant, but the significance of a genetic measurement can also change over time, as illustrated by a recent negligence suit against Quest's Athena involving SCN1A and Dravet syndrome. That kind of situation may (eventually) require additional consideration.

Last updated: Apr 12 2022 at 19:14 UTC