FHIR Chat · Slicing on a binding? · IG creation

Stream: IG creation

Topic: Slicing on a binding?


view this post on Zulip Brian Reinhold (Sep 16 2018 at 12:43):

I have a situation where PHDs send extra information that further describe the measurements. These are placed in components. The code for these cases has a value between lower<= code <=upper. I call these 'facet' values since they mirror V2 PCD-01 facets of an OBX segment. However, the PHD may also send what are known as 'compound' measurement such as an acceleration where the compound elements are the x, y, and z values. When this happens, the compound values are also mapped to a component. However, the codes for these components can be anything BUT a value between lower and upper. However, in both cases the codes come from the same code system.

I suppose one way to do it is to define a value set containing the just those codes from the MDC system that are used in 'facet' values and then make another value set that have all the other codes in the MDC system and have the 'system' point to the value set. The downside is that I do not think 'system' can reference a value set but just a code system.

Any other approaches?

view this post on Zulip Lloyd McKenzie (Sep 16 2018 at 15:56):

You can slice by value and declare a value set rather than a fixed value - so long as the valuesets listed don't overlap.

view this post on Zulip Brian Reinhold (Sep 16 2018 at 23:38):

You can slice by value and declare a value set rather than a fixed value - so long as the valuesets listed don't overlap.

@Lloyd McKenzie Sounds like a good option, but I do not know how to do that. Would this be using a pattern[x] or am I able to reference a value set in the coding.system element?
Perhaps slice by value and require a value set binding with the values that are okay?

view this post on Zulip Lloyd McKenzie (Sep 17 2018 at 00:01):

Slice by value on the CodableConcept and specify a different valueset for it for each slice.

view this post on Zulip Lloyd McKenzie (Sep 17 2018 at 00:01):

No need to worry about 'pattern'

view this post on Zulip Brian Reinhold (Sep 17 2018 at 08:41):

Slice by value on the CodableConcept and "specify a different valueset for it for each slice".

@Lloyd McKenzie I guess what I am asking on the "specify a different valueset for it for each slice", can I do that by fixing the coding.system URL to the value set or do I do it by specifying the binding? They system the values actually come from are a subset of a coding system. I think that what I need to do is still fix the coding .system to the urn for the MDC code system and then set the Binding to the unique value set. The coding.system will be the same fixed value in all slices (in my case) but the binding will be different for each slice. That would be 'slicing by binding' but my criteria are slicing by value. In some sense if I was allowed to set the coding.system=url for value set it would be easier for a reader to determine which 'slice' the entry is. The value set would have the code system being used.

view this post on Zulip Lloyd McKenzie (Sep 17 2018 at 14:40):

Coding.system cannot ever be set to a value set. It must always point to a system. To declare a value set, you must use the "binding" mechanism. There's no need to fix the Coding.system if you declare a binding.

view this post on Zulip Brian Reinhold (Sep 17 2018 at 15:02):

Coding.system cannot ever be set to a value set. It must always point to a system. To declare a value set, you must use the "binding" mechanism. There's no need to fix the Coding.system if you declare a binding.

@Lloyd McKenzie I didnt think that would be okay. In any case, its about what I thought, slicing on binding. In my case the code system will be fixed but the codes are a limited set of that system.

view this post on Zulip Lloyd McKenzie (Sep 17 2018 at 15:25):

Understood. Generally we don't bother fixing the code system if we have a binding because that makes things easier if the binding subsequently needs to draw from multiple code systems.


Last updated: Apr 12 2022 at 19:14 UTC