Stream: implementers
Topic: choosing a discriminator
Brian Reinhold (Jul 07 2017 at 09:53):
First I would like to emphasize that I do not want to use an extension to solve this problem if at all possible.
I have several Observation.components, the majority of which have a fixed Observation.component.code.coding.code element. That makes for an easy discriminator. However, I have one exception. One component slice is for compound measurements and there will be one such entry for each compound entry (for example the x, y, and z projections of an acceleration). The codes in this case are not fixed but will depend upon the measurement. Anyone have an idea what I should use as a slicing discriminator?
Ewout Kramer (Jul 07 2017 at 11:12):
So, to check that I understand this correctly, the possible Observation.component.codes depend on Observation.code? And all component measurements (in this case x,y and z) need to end up in the same Observation.component slice?
Brian Reinhold (Jul 07 2017 at 11:44):
@Ewout Kramer
So, to check that I understand this correctly, the possible Observation.component.codes depend on Observation.code? And all component measurements (in this case x,y and z) need to end up in the same Observation.component slice?
Not quite. This is a measurement from a health device being mapped to an Observation resource, and the measurement may contain extra information that is over and above that which can be expressed in the Observation.* elements, so an Observation.component element is used to record this information. An example would be supplemental types which might say that the measurement is spot modality or a mean or whatever. In the 11073 20601 standard there are fixed set of possible pieces of extra information that may be present. All of these have a fixed code so one can use the Observation.component.code.coding.code value to distinguish them in slices. That works fine until the primary measurement itself is not something simple like a weight, temperature, glucose concentration, etc. It could be something complex like an acceleration. 11073 20601 devices use a 'compound' measurement to represent these babies. To represent that in FHIR, a component element is used for each of the compound entries. In this case the Observation.component.code.coding.code is not fixed but will depend upon the compound measurement being delivered. In the case of the acceleration, the Observation.code.coding.code would be a code for acceleration, but the three Observation.component.code.coding.code elements would be a code for the x, y, and z projections, respectively.
So the component element codes representing the compounds are not fixed (this set would be one slice) but all the other cases are.
Medical devices can be damn complicated and messy at times! Who would of thought? One starts with a simple temperature measurement and it looks so trivial. Alas, a body temperature is not the only thing that might be reported!
TMI?`
Richard Townley-O'Neill (Jul 09 2017 at 23:50):
Maybe rather than using component for the extra information you can use related. Then the x, y, z can be components of one of the related observations.
Last updated: Apr 12 2022 at 19:14 UTC
