FHIR Chat · 'Slice' a resource? · implementers

Stream: implementers

Topic: 'Slice' a resource?


view this post on Zulip Brian Reinhold (Apr 12 2017 at 11:22):

Michel,
I wonder if there is a semantic analog to slicing for a resource. For example, PHD devices send the following types of measurements which are mapped to an Observation resource in different ways. Right now I am trying to express all of them within the confines of a 'PhdObservation' profile.
A PHD sends either a numeric, a compound numeric, a waveform, a code, a list of codes as a BITs value, and a string.
The numeric maps to a valueQuantity. The compound numeric maps to a set of component.valueQuantity elements. A waveform maps to valueSampledData, a code to valueCodeableConcept, and a BITs list of codes to a set of component.valueCodeableConcept elements.

Of course there is no discriminator at the resource level that I know of. What is the best way to do this? Would it be to make five Observation profiles? The down side is that a lot of the material in each profile would be common. Right now I am still going with a single profile and trying to handle all the conditions internally.

view this post on Zulip Michel Rutten (Apr 12 2017 at 11:34):

Hi @Brian Reinhold You could slice the Observation.value[x] element and define named slices for all the possible datatypes. Discriminator would be on type, or possibly profile. If necessary, you can also define custom profiles for specific datatypes and bind these to the Observation.value[x] named slices.

view this post on Zulip Eric Haas (Apr 12 2017 at 12:19):

@Brian Reinhold you create a profile on Observation then you create a profiles on that profile which only constrains what you are interested in. an example are the vital profiles in the spec here where for example, the bodyweight profile is a profile on the vitals profile and only constrains the code and value.

view this post on Zulip Brian Reinhold (Apr 12 2017 at 12:21):

Eric, In my case I think the slicing on the value[x] would be much more efficient since most of the other elements are duplicated.


Last updated: Apr 12 2022 at 19:14 UTC