Stream: conformance
Topic: slicing vs more profiles
Jens Villadsen (Nov 28 2017 at 14:36):
I'm looking for guide lines or best practices towards when to create a new profile or when to just create a slice. This is specifically relevant for observations
Jens Villadsen (Nov 28 2017 at 14:48):
it relates to the use of Observation.component. I can choose to add a lot of slices within the component or I can define multiple profiles.
Jens Villadsen (Nov 28 2017 at 14:49):
each having a smaller amount of slices
Jens Villadsen (Nov 28 2017 at 14:49):
(deleted)
Jens Villadsen (Nov 28 2017 at 14:50):
As stated in the doc "Examples include systolic and diastolic component observations for blood pressure measurement and multiple component observations for genetics observations."
Eric Haas (Nov 28 2017 at 16:31):
That is a good question. I've seen both approaches. " All quantitative lab measure follow profile A" or "for lab test X use profile Y" I'd like to know what works best in the wild too ...
Ewout Kramer (Nov 28 2017 at 17:00):
@Lilian Minne @Ardon Toonstra @Marten Smits ?
Jens Villadsen (Nov 29 2017 at 07:53):
Because slicing is so powerful, it can almost be considered a profile within the structuredef when looking at Observation.component - that at least goes for my scenario where observations would be recording of ECG, BPM, heartrate, temperature and so on (whatever is measured/observed in an ambulance ). I can choose to use only one profile with a set of optional sliced components ... or I can choose to use multiple profiles (and in that case I'll probably have to make one master profile and a set of derived profiles). Both kinds of use will have the same structural/computational strengths
Ewout Kramer (Nov 29 2017 at 09:03):
In the same sense that any set of constraints on an element can be turned into a named structuredef for that node, yes. And you could turn the inlined constraints in a slice into a profile, and just make the slice reference the profile as well. Is that what you mean? Doing that is especially useful when the constraints on the slices share common properties, so you could push those out to a shared parent profile on the slice. Are we talking about the same thing?
Jens Villadsen (Nov 29 2017 at 10:27):
the question is this: My observations could be modelled as mulitple profiles, eg. a bpm structure-def of an observation stating a required Observation.component containing sys, dia and pulse, and a temperature structure-def of an observation containing a required Observation.component containing the temperature
Jens Villadsen (Nov 29 2017 at 10:28):
I could also just make one structure-def of an observation stating optional use of all the Observation.components stated before
Jens Villadsen (Nov 29 2017 at 10:30):
maybe with a Fhirpath.expr stating that at least one of the components should be present
Jens Villadsen (Nov 29 2017 at 10:33):
@Ewout Kramer I can't say if we are talking about the same thing. I think @Eric Haas understands where I'm heading
Ewout Kramer (Nov 29 2017 at 12:00):
Ah, I see, no my statement was more generic (but enabled your usecase)
Jens Villadsen (Nov 29 2017 at 13:03):
Yes, I sounds like you were heading into making slices as profiles ... a more generic (and complex .... ::thinking_face: ) approach - but yes, my question does not go that deep. I would however still like to get input and hear about best practices
John Moehrke (Nov 29 2017 at 14:01):
I would prefer multiple nested StructureDefinitinos to complex fhirpath.expr embedded. It may look to a human as more messy, but it seems it is overall more provable-correct. I just have a tendency to avoid script language whenever possible.
Jens Villadsen (Nov 29 2017 at 14:09):
as long as the nesting don't imply inheritance with more than one (MAX 2) level(s), I'll probably agree with you @John Moehrke . @Eric Haas, whats your experience?
Lloyd McKenzie (Nov 29 2017 at 15:46):
Splitting constraints out into a separate profile makes sense if you expect those constraints to be re-used and if you're comfortable with the separate profile having its own lifecycle and being maintained separately from the referencing profile. Otherwise, it makes more sense to constrain inline.
Eric Haas (Nov 29 2017 at 15:50):
As an author is easier to create separate profiles but harder to maintain. Would like to know what is easier for implementers using the profiles.
Last updated: Apr 12 2022 at 19:14 UTC
