Stream: implementers
Topic: Slicing a Logical Model
Alexander Henket (Oct 24 2016 at 21:53):
I was reading back on change requests I filed and found GF#12063. How does the vote apply to Logical Models? Not all of the things we take for granted in profiling apply to Logical Models. I would not apply slicing to any base logical model. I *may* apply slicing to a logical model that profiles another logical model.
Alexander Henket (Oct 24 2016 at 21:57):
In a base logical model, I'm very likely giving options for certain value elements (e.g. Observation.value[x]). GF#12063 outlines why that will sometimes fail, and thus why the current StructureDefinition will not work for Logical Models.
So if StructureDefinition is not the right carrier, are we then in need for a different resource for LogicalModels?
Alexander Henket (Oct 24 2016 at 21:59):
That *could* also provide a way out of the multiple bindings discussion, and *could* relieve us of the required min/max/conformance attributes that I do not need in logical models of definitional nature.
Stephen Royce (Oct 25 2016 at 00:13):
It would also mean that you can have a logical model with the same id as a structure definition. This may seem a small thing, but it is proving a _real_ pain for us.
Grahame Grieve (Oct 25 2016 at 09:21):
we've talked about min/max before. I believe you're wrong: you always need to indicate whether something can repeat or not when you are defining it; it fundemantally alters it's nature and interpretation
Grahame Grieve (Oct 25 2016 at 09:21):
min, not so much. but it doesn't hurt you to say min=0
Grahame Grieve (Oct 25 2016 at 09:22):
conformance - which one?
Grahame Grieve (Oct 25 2016 at 09:22):
you always have extensions if you want to do things like specific examples for specific types.
Grahame Grieve (Oct 25 2016 at 09:23):
agree that you wouldn't slice a base logical model
Alexander Henket (Oct 25 2016 at 09:23):
Binding conformance mostly I guess. Extensions for examples will not make them render anywhere by default
Grahame Grieve (Oct 25 2016 at 09:23):
somewhere but not everywhere, perhaps.
Grahame Grieve (Oct 25 2016 at 09:24):
we're not comfortable with adding seemingly unlimited complexity because you have it in your model. No one else is using it
Grahame Grieve (Oct 25 2016 at 09:24):
your example included more complexity again than you described.
Grahame Grieve (Oct 25 2016 at 09:25):
what circumstances could you have more than one default value, and how would that make sense? I cannot think of any.
Grahame Grieve (Oct 25 2016 at 09:25):
same for minValue / maxValue - how can that make sense?
Grahame Grieve (Oct 25 2016 at 09:25):
same for fixed.
Alexander Henket (Oct 25 2016 at 09:28):
My default value for a string based value could be "30 meters", while my default value for quantity based values could be "value="30" and unit="m"".
When counting in meters the minInclude/maxInclude are different from when counting in centimeters.
Grahame Grieve (Oct 25 2016 at 09:29):
so, firstly, you're way past type specific behavjour here. You want unit specific behavior.
Grahame Grieve (Oct 25 2016 at 09:29):
also, if you provide 2 default values, which one applies? no one can resolve that
Alexander Henket (Oct 25 2016 at 09:29):
So in general: the way I express my concept affects certain properties. This is not possible with the way StructureDefinitions are set up. My feeling is increasingly that StructureDefinition is better at profiling than it is at LogicalModeling
Alexander Henket (Oct 25 2016 at 09:30):
I must admit that defaultValue/fixedValue are not the best of examples for my point.
Grahame Grieve (Oct 25 2016 at 09:32):
no, I think examples are.
Grahame Grieve (Oct 25 2016 at 09:33):
what is also something we could say is that we have not provided machinery to assert control over units, and the impact of units on values, and on reference ranges. That's something that's come up occasionally, but is deferred to R4
Alexander Henket (Oct 25 2016 at 09:34):
So long as deferring is not the same as "not doing it", I'm fine with that statement
Grahame Grieve (Oct 25 2016 at 09:35):
the course of several different threads of work makes me sure that we'll have to get to it for R4
Alexander Henket (Oct 25 2016 at 09:37):
we've talked about min/max before. I believe you're wrong: you always need to indicate whether something can repeat or not when you are defining it; it fundemantally alters it's nature and interpretation
Definitions do not have cardinality. Look at any dictionary. It does not matter to a definition of a person whether or not he can have 0..1 or 0..* SSNs.
The context of use is what determines cardinality. If a person has had faulty SSNs registered to his person that were subsequently replaced by the correct one, he might have multiple, where only one of which is active.
Alexander Henket (Oct 25 2016 at 09:38):
the course of several different threads of work makes me sure that we'll have to get to it for R4
I'll try to be there for the discussion
Grahame Grieve (Oct 25 2016 at 09:39):
structure definitions/ element definitions are not concept definitions. If you look at ConceptDefinition in codeSystem, you'll see that it doesn't have cardinality
Alexander Henket (Oct 25 2016 at 09:39):
So LogicalModels should have actually been a series of pointers to ConceptDefinition then?
Grahame Grieve (Oct 25 2016 at 09:41):
no. they're different things
Grahame Grieve (Oct 25 2016 at 09:42):
language dictionaries are defining concepts, not data elemetns
Alexander Henket (Oct 25 2016 at 09:44):
LogicalModels are called datasets from where I stand, so in fact a data dictionary where concepts and concept groups live. Each concept and each concept group has definitional properties and may have 0..* code/valueSet bindings. valueSet cannot be a applied to concept groups.
Grahame Grieve (Oct 25 2016 at 09:44):
then your comparison to a language dictionary was not relevant
Alexander Henket (Oct 25 2016 at 09:45):
The only thing that makes a dataset different from a dictionary is the grouping. Otherwise it is the same
Alexander Henket (Oct 25 2016 at 09:47):
The second layer is where LogicalModels match more to what you are used to. We call them transactions. In a transaction you cherry pick what you need from the dataset for a given context. The context determines min/max/conformance/conditions and could make a choice from the bindings that the dataset has to offer.
Alexander Henket (Oct 25 2016 at 09:51):
So in FHIR speak it means my datasets are base Logical models (no cardinality/conformance), and transactions are profiled Logical Models (adding cardinality/conformance)
I have yet to find out what to do about the fact that dataset concept( group)s can refer to concept( group)s from other datasets. I haven't found how to represent that using StructureDefinition
Marc de Graauw (Oct 25 2016 at 14:34):
The only thing that makes a dataset different from a dictionary is the grouping. Otherwise it is the same
Not really, the grouping introduces the need for min/max. You cannot have:
Person.gender 0..*
It never makes sense for a single Person to have multiple genders at the same time. Same for Person.birthDate. Multiple genders or birthDates only make sense when some administrative period is added; otherwise, like in Person, there can be only one within the group. That's just the way the world is.
So I'd agree with Grahame that you need max values (and maybe a lot will be *), and that min values are usually 0 in base models.
Marc de Graauw (Oct 25 2016 at 14:37):
I have yet to find out what to do about the fact that dataset concept( group)s can refer to concept( group)s from other datasets. I haven't found how to represent that using StructureDefinition
Aren't those simply references to separate resources?
Alexander Henket (Oct 26 2016 at 08:58):
Aren't those simply references to separate resources?
That is one of the solution I'm considering. Logical Models referring to Logical Models, that in turn could be referring to Logical models, etc.
Alexander Henket (Oct 26 2016 at 09:02):
So I'd agree with Grahame that you need max values (and maybe a lot will be *), and that min values are usually 0 in base models.
Since you originate from the ART-DECOR setup too, I'm amazed here. Datasets do not have cardinality. Period. If Logical Models SHALL have cardinality, then I'll substitute 0..* in every single instance. There is no way to distinguish between concept X or Y at that level. The world doesn't care about cardinality at definition time. At least my world doesn't.
I then need a transaction to tell me what my cardinality is going to be in the given context.
The other option is the statement that Logical Models are conceptually transactions and that FHIR does not have something on the level of datasets. In that case we should just skip mapping of datasets altogether, but that sounds like a lackluster as you'd miss correlation between Logical Models.
Lloyd McKenzie (Oct 26 2016 at 17:21):
@Alexander Henket I don't understand the purpose of grouping elements if you're not going to talk about cardinality. Grouping creates a context and with context, cardinality usually applies. Logical models definitely create a context. Saying Patient can have a birth date without saying that they can't have more than one doesn't make any sense. If you're just looking to aggregate "data elements I defined this month", then you want List, not StructureDefinition to group them (you might have a single StructureDefinition for each element - one for birthDate, one for gender, etc. (And even then we still indicate on a data element whether, when used, it can repeat based on the intended use of the data element. If your context is sufficiently wide, then making the root elements 0..* could work.)
Alexander Henket (Oct 26 2016 at 18:38):
I can and will go for 0..* for anything when doing datasets > Logical Model. But let's go back to the tracker item. What if I want to say that a given element may be expressed like:
<choice>
<quantity in meters, valid range 0-3, fraction digits max 2, example "2.10 m"/>
<quantity in centimeters, valid range 0-300, no fraction digits, example "210 cm"/>
<quantity in millimeters, valid range 0-3000, no fraction digits, example "2100 mm"/>
</choice>
Does that always mean that I will be slicing in my Logical model?
Grahame Grieve (Oct 26 2016 at 21:12):
no that's not slicing. it's just - at the moment - something that you can't say without extensions
Stephen Royce (Oct 27 2016 at 00:01):
From a data dictionary perspective, statements like "Saying Patient can have a birth date without saying that they can't have more than one" is common practice. It's utility tends to be shorter term, but ISO 11179 observes this practice (Data Element Concepts don't have cardinality). What you would normally do then, is create a implementation-specific logical model -- i.e. a logical model peculiar to the particular domain that your implementation is addressing -- which then refers to the concepts in the data dictionary and applies the cardinality required by the domain. The theory is that you cannot assume that, using your example, a Patient can never have more than one birth date; there may be (admittedly extremely obscure) edge cases where more than one birth date is required.
Lloyd McKenzie (Oct 27 2016 at 00:08):
You can say it without extensions - you could enforce it with FluentPath.
Marc de Graauw (Oct 27 2016 at 11:04):
Patient can never have more than one birth date; there may be (admittedly extremely obscure) edge cases where more than one birth date is required
I'd like to see an example, then. I can come up with (not so edge) cases where the registered birthDate may change, so a Person can have multiple ones registered over time, like:
birthDateRegistrationPeriod 0..*
- startDateRegistration 1..1
- endDateRegistration 0..1
- birthDate 1..1
Note that while birthDateRegistrationPeriod repeats, birthDate still does not. I cannot think of one solid example where a Person could conceivably have multiple birthDates without contextual information regarding validity (in which case, as shown, the actual birthDate will still have max=1, not *).
Grahame Grieve (Oct 27 2016 at 11:19):
I agree with Marc; assertions regarding cardinality are quite often meaningful in that they inter-related with the definition of the element. A status with cardinality of >1 is inherently different to a status with a cardinality of 1. But cardinality is - here I agree with Alexander - often only meaningful in a particular context; it makes inherent assumptions about containment. So here is my real point: many data elements only have meaning in the context of their containment. While others are independent of their containment.... because they carry their own context.
Grahame Grieve (Oct 27 2016 at 11:21):
we haven't really ever properly differentiated them - in spite of having both DataElement and LogicalModel. And my experience is that very often a 'DataElement' is a small LogicalModel with a clear focal element - and we agree with Alexander that logical models or resources which are entry points do not have meaningful cardinalities
Marc de Graauw (Oct 27 2016 at 12:09):
For atomic items in a data element repository, cardinality indeed does not make sense. (One can have a list of birthDates in a non-person context). Seems everybody agrees there. For non-atomic items (like adresses etc.) it can indeed be more blurry. The non-atomic item itself would not have cardinalities; for its children, possibly (there are no adresses with multiple postal codes in Holland).
Stephen Royce (Oct 28 2016 at 01:29):
The point is not whether or not any edge cases exist where a Patient can have more than one birth date, the point is that in a data dictionary, you have _no_ context and so it is actually rare where you can assert a cardinality that will _always_ be true in _all_ contexts. (Patient birth date is probably such an exception, but in reality, if you think you can apply a cardinality, you probably already subconsciously have a context in mind.) Since this is rare, data dictionaries do not capture cardinality even though there may be a small number of cases where they could. The cardinality is only applied once the context is determined; this is done in a context-specific logical model that refers to, but sits outside of, the data dictionary.
Lloyd McKenzie (Oct 28 2016 at 03:05):
My question is why you would use a StructureDefinition to group elements in a data dictionary. I would expect a data dictionary to be a List where each element would be its own StructureDefinition.
Stephen Royce (Oct 28 2016 at 06:08):
At the moment we're just creating a collection of DataElement resources.
Marc de Graauw (Oct 28 2016 at 11:41):
Hi @Stephen Royce , I absolutely agree that there'd be no cardinality when there is no context - such as data dictionaries with atomic data elements. We're working here with that, and I probably will make those available as DataElements, w/o cardinalities. I was speaking only about cases when there is a context, such as gender within a Person or postalCode within an address. Like Lloyd says, I'll share my data dictionary in a List or similar.
Last updated: Apr 12 2022 at 19:14 UTC
