Stream: implementers
Topic: StructureDefinition
Alexander Henket (May 10 2016 at 20:50):
With regards to StructureDefinition.abstract. Is it a reasonable assumption that a LogicalModel would always be abstract? Or does abstract not have real value for LogicalModels?
Stephen Royce (May 10 2016 at 22:43):
I had assumed that abstract in a logical model context is akin to abstract in a UML context; that's how we're using it at NEHTA.
Michel Rutten (May 11 2016 at 04:03):
@Stephen Royce Alexander raised an interesting point. I've just implemented basic support for logical models in Forge, but I'm really looking for some feedback from users on how to develop this further. So are you suggesting that a Logical model could be abstract and/or concrete? i.e. it's up to the modeller to define this? In that case, we definitely shouldn't fix the property value but leave it up to the modeller to define this. Just looking for some guidance on tooling development.
Stephen Royce (May 11 2016 at 04:24):
We leave it up to the modeller to define this.
Stephen Royce (May 11 2016 at 04:25):
I'm not necessarily suggesting that's the best approach, it's just what we do.
Alexander Henket (May 11 2016 at 10:31):
What does a concrete logical model mean versus an abstract logical model? The way that it is described now is unclear to me: "If the structure is not abstract, or there's a constrained type, then there SHALL be a base" and "Whether structure this definition describes is abstract or not - that is, whether an actual exchanged item can ever be of this type."
especially the second part makes me think that you always need an SD that profiles the stuff that onto the wire. You would exchange logical models just like you would not exchange XMI
Grahame Grieve (May 11 2016 at 10:47):
it would be good to create a task to clarify this. The language was written before we had logical models and could be improved,
Grahame Grieve (May 11 2016 at 10:48):
A logical model is a structure that is not used as a resource or a data type in the FHIR specification. That doesn't mean it isn't concrete, doesn't have a wire format, or an object model.
Grahame Grieve (May 11 2016 at 10:49):
whatever it is, it is a set of element definitions that describe an instance of data, and an abstract type is a type that cannot exist directly in the instance - only a specialization of it can exist
Alexander Henket (May 11 2016 at 13:05):
Created #9987 and added a link to this Zulip thread
Stephen Royce (May 11 2016 at 23:41):
In our space, an abstract model, although it can be mapped to resources/profiles, is not to be implemented as is. You must specialise it first to a concrete model and then complete the mappings and only those are to be implemented.
Stephen Royce (May 11 2016 at 23:42):
Initially we actually disallowed mappings on abstract StructureDefinitions, but that makes it difficult to maintain consistency across concrete StructureDefinitions that specialise it.
Stephen Royce (May 11 2016 at 23:42):
Again, I'm not suggesting that this is the way to go; it's just NEHTA's current practice.
Ewout Kramer (May 13 2016 at 00:34):
I think that makes sense and is in line with that Grahame says....
Stefan Dimitrov (Jan 24 2017 at 21:08):
The StructureDefinition resource appear to have been updated at some point to add "title" and change "name" to be ComputerFriendly. Yet there are a number of Extensions in the FHIR Extension Registry which were built according to the old StructureDefinition where "name" was an informal name (i.e. not Computer Friendly) for the resource. As a system consuming these extensions how are we to know what version of StructureDefinition the extension was built with? And, are all the extensions in the registry going to be updated according to the the new StructureDefinition?
Lloyd McKenzie (Jan 24 2017 at 21:12):
They should, but they probably won't unless the validator yells about them. Can you create a tracker item for us to make sure the validator enforces that "names" are computer-friendly? (no spaces, accents or characters other than what we'd allow in an id)
Stefan Dimitrov (Jan 24 2017 at 22:19):
I think this tracker describes the same issue: http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_id=677&tracker_item_id=9810
Stefan Dimitrov (Jan 24 2017 at 22:34):
@Lloyd McKenzie there appear to be resources which follow the new StructureDefinition format yet their values don't comply with the format: http://build.fhir.org/extension-encounter-primarydiagnosis.json.html
Stefan Dimitrov (Jan 24 2017 at 22:34):
does the validator look at the values at all?
Lloyd McKenzie (Jan 25 2017 at 00:26):
@Stefan Dimitrov I think that tracker is something different. Can you identify the specific issues you see in the extension you referenced?
Stefan Dimitrov (Jan 25 2017 at 15:11):
@Lloyd McKenzie the name attribute of encounter-primarydiagnosis is not computer friendly
Lloyd McKenzie (Jan 26 2017 at 01:27):
Right. But right now there's no regex on name to make it computer friendly, so I wouldn't expect the validator to complain about that.
Lloyd McKenzie (Jan 26 2017 at 01:28):
The purpose of your tracker item would be to add such a regex.
Stefan Dimitrov (Jan 26 2017 at 15:21):
Ok, thanks, this clarifies it, I will create a tracker now.
Stefan Dimitrov (Jan 26 2017 at 16:06):
http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12710
Alexander Henket (Jan 27 2017 at 10:43):
I'm firmly opposing this breaking change and have added that to the tracker item. name != short.
Alexander Henket (Jan 27 2017 at 10:45):
Also mind that StructureDefinitions also encompass Logical Models. There is no intrinsic need to let Logical Models have computer friendly names.
Lloyd McKenzie (Jan 28 2017 at 03:39):
@Alexander Henket If there's both a name element and a title element, it's clear they must have distinct purposes. If you want to argue for loosening the cardinality either for logical models or for all, that's fine. But forcing the name to be computable - when that's definitely its purpose - is quite reasonable.
Alexander Henket (Jan 28 2017 at 15:23):
StructureDefinition.name == Informal name for this StructureDefinition
ElementDefinition.name == Name for element to display with or prompt for element
How would you reckon that "name" has a computability purpose?
Lloyd McKenzie (Jan 28 2017 at 15:38):
STU2 name maps to STU3 title
Alexander Henket (Jan 30 2017 at 15:26):
I see. And makes StructureDefinition.name required no less. I also see ElementDefinition.name is now ElementDefinition.label (not title). I definitely missed a few motions to vote against. Too late now I guess. I've updated/retracted my comment for GF#12710
Ewout Kramer (Jan 30 2017 at 21:24):
All these metadata elements are aligned across the conformance resources and knowledge resources (we tried to make all metadata consistent), so changing this means changing 10+ resources....
Ben Spencer (Oct 26 2017 at 08:33):
Can a StructureDefinition constrain the value of a string? eg force an identifier to be a UUID
Grahame Grieve (Oct 26 2017 at 09:54):
yes see the regex extension
Ben Spencer (Oct 26 2017 at 09:57):
thanks
Last updated: Apr 12 2022 at 19:14 UTC
