Stream: shorthand
Topic: Logical Models in FSH (Take 2)
Chris Moesel (Mar 03 2021 at 21:44):
We previously confused the discussion on logical models by introducing too many things at the same time (logical models, context paths, offloaded language resources). We'd like to rein in the discussion by focusing ONLY on the syntax necessary to create logical models.
We propose that support for defining logical models requires only two new features of FSH:
- A new
Logicalkeyword - A new AddElement Rule w/ the following syntax:
* {path} {min}..{max} {flags} {type (or type or...)} "{short}" "{definition}"
(where path, min, max, and type are required, but flags, short, and definition are optional).
Chris Moesel (Mar 03 2021 at 21:45):
An example logical model inspired by Open HIE's HIV Record:
image.png
Chris Moesel (Mar 03 2021 at 21:48):
Or if you don't like the long busy lines, you can put the text on separate lines (partial definition in image to illustrate): image.png
Chris Moesel (Mar 03 2021 at 21:49):
For the moment, forget everything we ever said about context paths, offloaded text, etc... What do you think?
Chris Moesel (Mar 03 2021 at 21:50):
BTW -- I forgot to mention -- all other things you might want to do (like binding value sets, etc) would use the same exact rules and rule syntax as when you author profiles.
David Hay (Mar 03 2021 at 22:28):
looks good to me...
Jose Costa Teixeira (Mar 03 2021 at 22:57):
I presume AddElement is then a built-in rule that gets activated for Logical definitions?
Jose Costa Teixeira (Mar 03 2021 at 22:58):
I like the compactness of the language. A few comments:
Jose Costa Teixeira (Mar 03 2021 at 22:58):
- type is not required in LMs
Jose Costa Teixeira (Mar 03 2021 at 23:00):
(deleted)
Jose Costa Teixeira (Mar 03 2021 at 23:02):
Chris Moesel said:
For the moment, forget everything we ever said about context paths, offloaded text, etc... What do you think?
I like where this is going
Jose Costa Teixeira (Mar 03 2021 at 23:03):
(just to be clear: I also like where it is right now, and i think it will get even better)
Jose Costa Teixeira (Mar 03 2021 at 23:03):
I just wonder about a specific syntax for LMs, but I don't see a better way
David Hay (Mar 03 2021 at 23:09):
Which type are you referring to?
Jose Costa Teixeira (Mar 03 2021 at 23:10):
data element type
Chris Moesel (Mar 03 2021 at 23:10):
Yes, the AddElement rule would only be valid for Logical Models (and Resources). You could also put it in a RuleSet, but then you could only apply that RuleSet to Logical Models and Resources. Regarding the notion that type is not required in Logical Models, can you describe what it means to have an element without a type (aside from the root element)?
Jose Costa Teixeira (Mar 03 2021 at 23:11):
a mode abstract-ish logical model...
Elliot Silver (Mar 03 2021 at 23:11):
Is element.id automatically generated?
Chris Moesel (Mar 03 2021 at 23:17):
@Jose Costa Teixeira - OK. And I just realized it is also absent on elements that have a contentReference. We kind of need type in the grammar to distinguish an AddElement Rule from a normal Cardinality Rule. So perhaps we'd need to introduce something like:
* foo 0..1 <no-type> "My element with no type"
Chris Moesel (Mar 03 2021 at 23:19):
@Elliot Silver -- yes, Element.id and Element.path would be automatically generated. FHIR has rules around how those should be constructed anyway, so we'd just be following those rules.
David Hay (Mar 03 2021 at 23:23):
Don't quite understand why elements wouldn't need a datatype...
Jose Costa Teixeira (Mar 03 2021 at 23:23):
We may just want to explain a data structure without defining the types.
Jose Costa Teixeira (Mar 03 2021 at 23:25):
Also note that data types are FHIR data types (except if we are brave enough to create abstract types), so a Logical Model with a physical data type is not purebred
David Hay (Mar 03 2021 at 23:26):
Hmm. You could always use a string. I like having datatypes in there myself (admitting that it is a chimera)...
Jose Costa Teixeira (Mar 03 2021 at 23:27):
saying it is a string may be actually incorrect
David Hay (Mar 03 2021 at 23:28):
But if you don't want datatypes, then why would you care?
David Hay (Mar 03 2021 at 23:28):
I like binding to ValueSets in models, for example...
David Hay (Mar 03 2021 at 23:29):
I find it helps clinical users with context...
Jose Costa Teixeira (Mar 03 2021 at 23:29):
we also do bindings to valuesets in models. We should have an abstract data type for that, but it is not only "nice to have" - it is really important. Some elements are bound to a vocabulary at a functional level, not only at technical level
Jose Costa Teixeira (Mar 03 2021 at 23:30):
- foo 0..1 <no-type> "My element with no type"
why not use this and define a consistent syntax for defining types?
Jose Costa Teixeira (Mar 03 2021 at 23:30):
where else do we define types in fsh?
Jose Costa Teixeira (Mar 03 2021 at 23:31):
in profiles we use only {type}... anywhere else?
Jose Costa Teixeira (Mar 03 2021 at 23:32):
where I'm heading with this, @Chris Moesel : if we define a way to express type constraints, something that works here AND does not conflict (and could also be used in) profiles, that would be a good thing.
Jose Costa Teixeira (Mar 03 2021 at 23:33):
taking the < > as example
Jose Costa Teixeira (Mar 03 2021 at 23:34):
then indeed
- foo 0..1 <> "I don't want to have a type" could work
Jose Costa Teixeira (Mar 03 2021 at 23:34):
(unless we really need the dedicated keyword)
Jose Costa Teixeira (Mar 03 2021 at 23:36):
and if we can use
* element <string>
the same way we use
* element only string
then our grammar is a bit more consistent
(I think ( ) or [ ] are better than < > )
Jose Costa Teixeira (Mar 03 2021 at 23:37):
@David Hay if we don't have a type because we don't care that's one thing. If we don't have a type because we want to say "no types here, this is just about the structure and cardinalities. if you want data types, go one level down", we should not abandon that.
Jose Costa Teixeira (Mar 03 2021 at 23:39):
Note that I recommend always having a LM for everything we do, and I do use (FHIR) types in my IGs. But I don't think a logical model should be forced to have a type if it's done in sushi
Chris Moesel (Mar 04 2021 at 13:16):
@Jose Costa Teixeira -- we do want to try to be consistent, but having no type is the exception to the rule. Given the choice, at this point in time, I'd rather introduce something a little different for a minority use case (e.g., <no-type>) than change the approach for the majority use case (e.g., require <string> syntax everywhere) -- which would affect the 50+ IGs already using FSH.
Chris Moesel (Mar 04 2021 at 13:18):
If it feels better, another approach could be using - in place of the type, like this:
* foo 0..1 - "My element with no type"
Chris Moesel (Mar 04 2021 at 13:23):
@Jose Costa Teixeira -- I want to be sure we're on the same page here. You said:
But I don't think a logical model should be forced to have a type if it's done in sushi
Is a typeless element (aside from a contentReference) allowed by the IG Publisher today? Or are you actually proposing that it should be allowed in FHIR overall (even if it isn't currently)? Because I assumed when you said you could use it in abstract models that it was a current feature of FHIR -- but I can't find it documented anywhere.
In fact, looking at the (very brief) Logical Model documentation, it says (emphsasis mine):
StructureDefinitions are used to define the basic structures of FHIR: data types, resources, extensions, and profiles. The same definition structure can also be used to define any arbitrary structures that are a directed acyclic graph with typed nodes, where the primitive types are those defined by the FHIR specification.
Jose Costa Teixeira (Mar 04 2021 at 13:30):
Typeless LMs are allowed today in the publisher (well, "today" is relative). Type is also 0..* - and I presume this is not only for differential purposes, but it would also make sense to keep them typeless.
Indeed we should have a page on LMs in the core spec (pinging @Grahame Grieve on this, I can volunteer to helw write)
Jose Costa Teixeira (Mar 04 2021 at 13:34):
@Chris Moesel my idea would not be to replace anything on the (hundreds of ?) existing IGs. Just to allow a new syntax that allows people to say either value only string or value <string>
Jean Duteau (Mar 04 2021 at 16:09):
Jose Costa Teixeira said:
Typeless LMs are allowed today in the publisher (well, "today" is relative). Type is also 0..* - and I presume this is not only for differential purposes, but it would also make sense to keep them typeless.
I looked into this last night and although type is 0..*, there are a few constraints and some wording in ElementDefinition that I think makes it required for most logical models. I got bogged down by the language on the page about which category a Logical Model fit into. http://hl7.org/fhir/elementdefinition.html#interpretation
Chris Moesel (Mar 04 2021 at 16:40):
Good point, @Jean Duteau. I missed that table, but it does indicate that type is required for "Type definition, first element" and "Type definition, following elements" -- and I do believe that LMs meet the definition of "Type definition":
Type definition: A StructureDefinition without a baseDefinition element, or where the derivation type is 'specialization'
Jean Duteau (Mar 04 2021 at 16:41):
Yeah, that is what I think to, but where I got confused was trying to determine if a LM is a Type definition or not.
Jean Duteau (Mar 04 2021 at 16:45):
is a constrained LM still an LM or is that now a profile? that was the question that I couldn't figure out because it made my brain hurt. :)
Jean Duteau (Mar 04 2021 at 16:46):
all I know is that all of my LMs would be considered base definitions of a data type so they would have type required for all elements.
Chris Moesel (Mar 04 2021 at 17:12):
If your LM adds any new elements (not inherited from the baseDefinition), then I believe it has to be a specialization -- and that makes it a Type. If you have an LM that doesn't add anything new, I'm not sure if that's still an LM then. Good question.
Grahame Grieve (Mar 04 2021 at 18:39):
typeless LMs are allowed today in the publisher (well, "today" is relative)
yesterday that was true, but not today.
Jose Costa Teixeira (Mar 04 2021 at 18:52):
I don't see why we should force a physical data type on a LM
Jose Costa Teixeira (Mar 04 2021 at 18:58):
and we could express a data structure without types to leave it open (I did use string before but that felt weird)
Jean Duteau (Mar 04 2021 at 18:58):
what is a data structure without types? that's basically just a bunch of strings
Chris Moesel (Mar 04 2021 at 19:00):
@Jose Costa Teixeira - couldn't you just use Element as the type? It's a real type but it doesn't really say much (so doesn't feel as weird as a more specific type like string).
Chris Moesel (Mar 04 2021 at 19:01):
http://hl7.org/fhir/R4/element.html
Jose Costa Teixeira (Mar 04 2021 at 19:02):
less weird indeed
Chris Moesel (Mar 04 2021 at 19:03):
Actually, looks like ele-1 might get in the way of that idea:
image.png
Chris Moesel (Mar 04 2021 at 19:05):
Although I'm not 100% sure how to interpret that constraint, so maybe not? Maybe that says that in an instance an element must have a value or children, but perhaps it's fine in a LM since we don't typically create instances of LM.
Joe Paquette (Mar 10 2021 at 14:24):
@Chris Moesel So, can you share any info on when logical model support in FSH might appear in a new version of fsh-sushi? I'm not looking for a specific date, just an idea as to if/when it might appear. We're looking forward to its availability!!
Chris Moesel (Mar 10 2021 at 19:31):
Hi @Joe Paquette -- we're actually just in the middle of figuring that out. I can tell you, we haven't started implementation yet but want to start it very soon (ideally next week). A few people have indicated they might be willing to help w/ implementing this feature, so we're currently chasing them down!
Jose Costa Teixeira (Mar 10 2021 at 20:33):
Here's a "typeless" but I think still meaningful structure:
image.png
Jose Costa Teixeira (Mar 10 2021 at 20:35):
Jean Duteau said:
is a constrained LM still an LM or is that now a profile? that was the question that I couldn't figure out because it made my brain hurt. :)
A constrained LM is still a LM. Going from LM to profile is not constraining, it is moving to the implementation level.
Jose Costa Teixeira (Mar 10 2021 at 20:36):
(depending on what you mean by Profile). You could say that the above is a "profiled LM" but that would keep me up at night.
Jose Costa Teixeira (Mar 10 2021 at 20:43):
@Chris Moesel to summarise: my suggestion is to avoid any positional syntax (where type is the nth keyword. I'd find a way to express type.
For sake of language simplicity/consistency, I would prefer that syntax for type to be not exclusive for LM - if you define it as <type>, then eventually in a profile definition we could also use <type> - without affecting the keyword "only". Seen from a different angle, <type> would just be a shorter-hand for "only", because they mean the same.
Jose Costa Teixeira (Mar 10 2021 at 20:44):
Is that sensible?
Chris Moesel (Mar 10 2021 at 21:21):
I don't think I understand the value of what you're proposing. As a domain specific language w/ a formal grammar, I think it's fair to have positional syntax -- and I actually like that it enforces some consistency. We already have 50+ projects that use FSH, and I feel like having some syntactical constraints in place to force some consistency is actually helpful.
We also intentionally want the element creation syntax to be different from the constraint syntax. While we want elements of the syntax to be consistent w/ other rules, we don't want people to have to think too much when they look at a rule to determine if it is constraining something or adding something. By having a unique syntactical shape to the rule, we also ensure that it's not possible for an author to mistakenly create a new element because they mistyped the path of an element they meant to constrain.
Jose Costa Teixeira (Mar 10 2021 at 22:23):
Chris Moesel said:
I think it's fair to have positional syntax -- and I actually like that it enforces some consistency.
Right. It's fair to have it, my idea is that it's fair not to have it too :)
I feel like having some syntactical constraints in place to force some consistency is actually helpful.
My preference for constraints and consistency (and the experience I have atm) just makes me _slightly_ lean to the other side.
We also intentionally want the element creation syntax to be different from the constraint syntax.
we don't want people to have to think too much when they look at a rule to determine if it is constraining something or adding something.
That is a deciding preference. Personally I do not see a big difference between those - it's an ElementDefinition in both cases, right?
Jose Costa Teixeira (Mar 10 2021 at 22:26):
I'm not pulling down your proposal, just trying to build on it and adding a perspective. I hope that makes your decision - whatever it is - more solid.
Jose Costa Teixeira (Mar 10 2021 at 22:28):
I really don't mind the positional syntax to express a type that much / I cannot express what makes me somewhat itchy (maybe it because I don't see how that would evolve).
Jose Costa Teixeira (Mar 10 2021 at 22:31):
TBH, in the syntax you write seems ok. There are more important things to discuss -
the "with" or equivalent syntax to avoid all that repeated typing, or the lookup functionality to create test data.
Chris Moesel (Mar 10 2021 at 22:36):
That is a deciding preference. Personally I do not see a big difference between those - it's an ElementDefinition in both cases, right?
Yes, but maybe it is easier to explain via example... Consider this line of FSH:
* justification 1..1
If we allowed the syntax * {path} {min}..{max} to be a constraint on an existing element, or a new element declaration without a type -- then what happens is based on whether or not the path justification already exists.
So now imagine the author wants to constrain an existing justification element in the LM, but mistakenly fat-fingers it:
* justfication 1..1
If we allow that syntax to be constraint or add, this typo results in a new element called justficaton being added. No errors are emitted because SUSHI does not know the intent was to constrain an existing path. It just knows that justfication does not exist, so the author must have meant to add that element. On the other hand, if we require type in order for it to be an "add element" operation, then the above is flagged as an error (because it can only constrain and the path is not valid).
The opposite situation also applies. Maybe the author intends to create a new element and does not realize that an element of the same name already exists. If the syntax can be constrain or add -- if the user meant to add, but it exists already, it would just become a constraint (and no error is emitted). On the other hand, if "add element" has a unique syntax, SUSHI would emit an error saying that it can't create an element because an element with that name already exists.
Chris Moesel (Mar 10 2021 at 22:39):
TBH, in the syntax you write seems ok. There are more important things to discuss -
the "with" or equivalent syntax to avoid all that repeated typing, or the lookup functionality to create test data.
I'll be posting an updated proposal for handling nested paths later tonight or tomorrow. We've been wrestling with that a lot -- trying to iron out the implications and such. We've arrived on an approach that is a little different than previously proposed, but somewhat similar to what some people have asked for in the past, so... stay tuned. ;-)
Jean Duteau (Mar 10 2021 at 22:45):
Jose Costa Teixeira said:
Jean Duteau said:
is a constrained LM still an LM or is that now a profile? that was the question that I couldn't figure out because it made my brain hurt. :)
A constrained LM is still a LM. Going from LM to profile is not constraining, it is moving to the implementation level.
OKay, then if that is true, then all LMs must have typed Elements. ElementDefinition has a constraint that type is required whenever it is used in a StructureDefinition that defines a type, which is what a LM is doing.
But I'm not sure that your language was precise according to the specification. There are different rules on ElementDefinition.type depending on whether you are a Type definition or a Constraint definition. Normal LMs are Type Definitions and thus must have a type specified for each element. It seems that you can create a StructureDefinition LM that is a constraint of a different LM StructureDefinition. I'm unsure whether that is defining a new type or just a constraint on a type. If you are saying that it is defining a new type, then my interpretation holds.
Chris Moesel (Mar 10 2021 at 23:19):
OK. So I'm not sure about the exact terminology, but perhaps the word "Profile" implies it is a constraint of a Resource (not a constraint of a Logical Model). In that case, you have two flavors of Logical Model:
- derivation = "specialization" -- this logical model can add new elements (and I assume constraint inherited elements?)
- derivation = "constraint" -- this logical model can only constrain inherited elements (it cannot create new elements)
Jose Costa Teixeira (Mar 10 2021 at 23:50):
Jean Duteau said:
ElementDefinition has a constraint that type is required whenever it is used in a StructureDefinition that defines a type, which is what a LM is doing.
Where is this constraint? I didn't see it, I may have missed that.
And a LM is a "type" - but not a physical one. I understand the impact of having a "physical" representation of an abstract model, but if our physical constraints prevent us from representing a logical model, I would assume that this is not intentional?.. not sure.
Jean Duteau (Mar 11 2021 at 00:52):
Jose Costa Teixeira said:
Jean Duteau said:
ElementDefinition has a constraint that type is required whenever it is used in a StructureDefinition that defines a type, which is what a LM is doing.
Where is this constraint? I didn't see it, I may have missed that.
I provided the link earlier in this topic: http://hl7.org/fhir/elementdefinition.html#interpretation
Basically, all Logical Models are the definition of a type - they are represented as StructureDefinitions with a baseDefinition of 'Element' and a derivation type of 'specialization', so that makes ElementDefinition.type required.
As Chris said, when derivation = 'constraint', you're only constraining elements so you can't create new ones.
Chris Moesel (Mar 11 2021 at 01:35):
It's kind of hidden in a whole lot of data, but I highlighted the relevant portions in this screenshot: image.png
Richard Kavanagh (Apr 21 2021 at 10:49):
I've been away from the FSH scene for a while, so just catching up on the status re Logical model generation.
I see the grammar on GitHub now makes provision for Logical models, but I am not sure how far the development has got.
I tried running an example through, I got no errors but also no output either.
image.png
Either I'm too keen and this has not fully arrived yet, or I crested my FSH file incorrectly...
Martin Höcker (Apr 21 2021 at 11:40):
Not a developer, just an observer: The current SUSHI release (v1.3.1) includes the parser for the updated grammar, but no output is generated yet. In the repo, there has been some activity regarding the output side. There is a PR for the export, but it is currently in draft-mode: https://github.com/FHIR/sushi/pull/802
Joe Paquette (Apr 21 2021 at 11:56):
@Richard Kavanagh Martin is correct. The grammar had to be completed before we could proceed with the rest of the development. We are actively working on adding support for both logical models and for resources. We are getting close, so stay tuned!
John Moehrke (Apr 27 2021 at 12:03):
is there a sample IG with some logical modeling in FSH? I think I have a need, but am unclear on the concept or how to do it with FSH.
Chris Moesel (Apr 27 2021 at 13:24):
Support for logical models in FSH has not yet been released, so there are not yet any IGs in the wild that do logical models w/ FSH. Right now, the very top of this thread probably contains the best publicly available examples of logical models in FSH.
Last updated: Apr 12 2022 at 19:14 UTC
