Stream: conformance
Topic: Forge Logical Models
Richard Kavanagh (Jul 13 2017 at 17:39):
I'm creating a Logical model using the latest STU3 build of Forge. I dont seem to be able to set the "type" for the model (see diagram). The element does not accept any input.
This is a mandatory element so I then get validation errors. What am I doing wrong?
Michel Rutten (Jul 14 2017 at 08:40):
Hi @Richard Kavanagh, thank you for reporting the issue. We're currently working on an update for Forge. I'll investigate this and try to solve it.
Michel Rutten (Jul 14 2017 at 08:48):
FHIR spec states the following:
sdf-11: "If there's a type, its content must match the path name in the first element of a snapshot"
So assuming that this invariant also applies to logical models, this implies that Forge needs to synchronize the type property value with the (user-assigned) root element name.
Michel Rutten (Jul 18 2017 at 08:20):
Hi @Richard Kavanagh, I've fixed the issue, for logical models the StructureDefinition.type property value is now synced with the (user-assigned) root element name. This fix will be included in the upcoming new (STU3) release.
Thank you for reporting!
Richard Kavanagh (Jul 02 2019 at 11:34):
Is there an easy way to create a logical model using an existing resource as a starting point?
Vadim Peretokin (Jul 02 2019 at 12:41):
What usecase have you got here?
Richard Kavanagh (Jul 02 2019 at 16:27):
I want to create a logical model of "patient" which is ost of the patient resources plus a stack of extensions. Some of the elements have slightly different names, datatypes etc. Rather than typing them all in from scratch I wondered whether it was possible to do this in the tool. If not I'll edit the XML directly and do it that way...
Vadim Peretokin (Jul 03 2019 at 07:06):
I don't think there is
Frank Oemig (Jul 03 2019 at 08:15):
do you want to add new attributes?
Richard Kavanagh (Jul 03 2019 at 12:48):
@Frank Oemig yes I will need to, I would envisage that I could do that using the existing functionality of Forge.
Frank Oemig (Jul 03 2019 at 12:52):
ok, but then your stuff will become incompatible. Therefore we do have extensions, in combination with profiling.
Richard Kavanagh (Jul 03 2019 at 20:48):
@Frank Oemig are we talking about the same thing here? My question relates to "logical" models these are abstract models not used for sharing data. When it comes to an implementable solution ten, of course, we would use appropriate resources and if required extend them in the normal manner.
Frank Oemig (Jul 03 2019 at 21:51):
well, logical modules are for data exchange using FHIR technology. If you are looking for grasping relevant information you should use mindmaps or UML, at least IMO
Richard Kavanagh (Jul 03 2019 at 22:35):
I don't think we have the same understanding of the purpose of Logical Models. I am taking mine from https://www.hl7.org/fhir/structuredefinition.html#logical . The original question relates to Forge, which I have an answer for. Thanks.
Grahame Grieve (Jul 03 2019 at 23:18):
Well, you're kind of both right... because there is data exchange happening based on logical models, but what RIchard is trying to is a valid thing to do.
David Hay (Jul 04 2019 at 05:33):
Well, that's what the logical modeller in clinfhir does... check out http://nz.clinfhir.com/ for links to models that we're creating as part of putting a FHIR facade in front of our registries. The Patient one is reasonably complete...
David Hay (Jul 04 2019 at 05:35):
The idea is that the model collects data in a way that a non-techical person can understand, then that forms the requirements for the actual fhir profiles and extension definitions...
David Hay (Jul 04 2019 at 05:37):
Can also use it to create 'pure' information models - ie not based on an existing type. We're doing that for the Australian GP extract project - check out the common model at http://csiro.clinfhir.com/ . While some of the nodes kinda map to resources, this was used with a whole bunch of clinicians to collect their data requirements...
Michel Rutten (Jul 18 2019 at 13:41):
Hi @Richard Kavanagh, Forge does not contain any end-user functionality to convert a constraining profile to a logical model. However you may be able to "hack" it. Start by generating a snapshot from the constraining profile. Change the kind property value to logical and type property to specialization. You may have to remove the .base component from all element definitions. Now try to open the profile in Forge. You should end up with a similar element tree.
Please note that Forge currently does NOT support extensions (nor slicing) on logical models. This is a tooling limitation, not a FHIR limitation. Forge does not fully support your scenario and you will still need to perform some manual updates.
Jose Costa Teixeira (Jul 18 2019 at 17:30):
Can also use it to create 'pure' information models - ie not based on an existing type. We're doing that for the Australian GP extract project - check out the common model at http://csiro.clinfhir.com/ . While some of the nodes kinda map to resources, this was used with a whole bunch of clinicians to collect their data requirements...
@David Hay do you mean we can make logical models without datatypes? I am looking exactly for that.
David Hay (Jul 18 2019 at 18:51):
Well, every element does have a (single) datatype - you could just leave it
as a string if you weren't interested in actually defining it...
Jose Costa Teixeira (Jul 18 2019 at 19:02):
ok thanks that would be a good fallback.
Michel Rutten (Jul 19 2019 at 09:14):
The elements of a logical model can reference other logical custom "datatypes". However ultimately leaf elements (with a value and no children) should always map to a core primitive datatype, as you cannot introduce your own custom primitives.
Jose Costa Teixeira (Jul 19 2019 at 09:46):
Makes sense, being a logical model, there will be a data type.
David's comment raised my interest because I want to see if this can be uses for purely business glossaries /info models, which normally would not have data types. @Michel Rutten this info model is the same as you have in the Netherlands for Nictiz's ZIBs.
David Hay (Jul 21 2019 at 19:21):
I took the view that even in 'business' models (assuming we're talking about the same thing) there was still some value in specifying the datatype. For example, if you're modelling an address or a name you can 'defer' the details to that datatype without having to enumerate them (unless there's extra elements of course). There's also an element of education for the viewer as well - I'm always looking for ways to have people understand some of the core bits of FHIR!
(as an aside, I should look to better support profiled datatypes - at a logical level that is)
Last updated: Apr 12 2022 at 19:14 UTC
