FHIR Chat · Proper/best way to fix a codeable concept · conformance

Stream: conformance

Topic: Proper/best way to fix a codeable concept

Travis Stenerson (Feb 02 2018 at 15:02):

I've been having some discussions on how this is best done in a profile attribute that you want to fix to a single concept. There don't appear to be a ton of examples but I've seen or heard of a few ways. Does anyone have guidance or can point me to more information?

1. Should you fix the codeableconcept, the coding field or the system/code/display elements of the coding element?
2. Is it necessary to slice coding?
3. pattern[x] seems to be mentioned in the description as a preferred way to fix a concept. Is this accurate? What are the differences between and consequences of fix[x] vs pattern[x]?
4. If you fix a display, will conformance checks fail if a different synonym is used?

Grahame Grieve (Feb 02 2018 at 15:03):

that raises many questions. Can you be clear on what 'fix to a single concept' means?

Travis Stenerson (Feb 02 2018 at 15:07):

I have an observation profile that I would like to represent a single concept. For example 'Estrogen receptor status'. So I want the code field of this observation to always be that concept. I'm not sure how else to describe that, what clarifications do you need?

Also, I am using one terminology, but others ER status profiles are using a different terminology, and I think interoperability can work there if we just have different coding elements in the codeable concept (correct me if I'm wrong). I'm also wondering if this will work when fixing a field.

Grahame Grieve (Feb 02 2018 at 15:10):

so you want to fix to a single fixed value - ok. (thought you might mean just any one single code).

Grahame Grieve (Feb 02 2018 at 15:11):

so for Observation.code, you should just fix to a simple CodeableConcept:

{
  "coding" : [{
    "system" : "(yours)",
    "code" : "(yours}"
  }]
}

Travis Stenerson (Feb 02 2018 at 15:25):

And if I include a display there, will synonyms work? If a resource has a coding with multiple entries from different systems, will it conform to the profile if it has that coding? ie is it intersection != null or is it codeableConcept == the fixed value.

Also, this is nitpicky, but the IG publisher looks a lot nicer when you fix code, system and display separately, otherwise it puts a little json object in there if you fix the CodeableConcept, is there a way to change that?

Grahame Grieve (Feb 02 2018 at 15:27):

if you put that in the fixed value, then it must be exactly that. if you put it in pattern, then it must contain at least those elements, but any other elements are also possible

Grahame Grieve (Feb 02 2018 at 15:32):

as for the nitpick.. there's no way to change that, though we can talk about it... but I for one don't think it would be better

Travis Stenerson (Feb 02 2018 at 16:15):

Ok, so just to make sure I'm understanding:
Fixing the display field will require that synonym exactly for conformance? And if a resource has a CodeableConcept with 2 codings from different systems, it will fail conformance if you have fixedCodeableConcept with a single coding, even if one of the two codings is equivalent to the the fixed one.

Grahame Grieve (Feb 02 2018 at 16:48):

yes. unless you use pattern, instead of fixed

Travis Stenerson (Feb 02 2018 at 17:17):

One more quick question Grahame, for the FHIR profiles, like the Observation profiles like HeartRate, I see on the main site, many of the fixed items have coding sliced which is then followed by a fixed system and code. Is the slicing necessary?

Grahame Grieve (Feb 02 2018 at 17:51):

in that case yes, because of the purpose of those profiles. Those profiles say 'you must use this coding, whatever other codes you are going to use'. And we want to fix the display too while we are at it

Travis Stenerson (Feb 02 2018 at 18:10):

So this is how one would say 'you can use other codings too, but this one has to be there'?

Grahame Grieve (Feb 02 2018 at 18:10):

it's one way to do this. It's done this way to make it easier for further profiling to happen

Travis Stenerson (Feb 02 2018 at 18:11):

Great, thank you, that is what I am trying to do, I will imitate this for fixing codes.

Eric Haas (Feb 03 2018 at 16:43):

Just to be clear. What I am hearing is....

having the pattern:

{
"coding" : [{
"system" : "(yours)",
"code" : "(yours}",
"display":"(yours)"
}]
}

is equivalent to slicing (open) on code and system? I was never 100% clear about that and that is one reason why those profiles are explicitly fixed in a slice. Also the rendered display is clearer to me at least.

Eric Haas (Feb 03 2018 at 16:46):

What GG meant by " It's done this way to make it easier for further profiling to happen" is that you can explictily add your own slices in a downstream profile that is built upon it.

Travis Stenerson (Feb 03 2018 at 20:48):

Thats what I interpreted from what Grahame said, Eric. That patternCodeableConcept would be the same as slicing the coding element and fixing a code/system on that slice, but the slicing/fixing would allow for other coding elements. Hopefully this interpretation is correct.

And yes I agree that the rendered display is better how it was done in those observation profiles on hl7.org/fhir.

Last updated: Apr 12 2022 at 19:14 UTC