Stream: conformance
Topic: Logical Model and extension
Alexander Henket (May 16 2019 at 11:28):
@Michel Rutten / @Grahame Grieve The V3 datatype II (Instance Identifier) contains an attribute @extension. Hence the logical model for II has II.extension with representation xmlAttr as one of its supported paths.
Forge STU3 will not show this element and will remove it from the logical model upon save. I believe Forge needs updating for this, but I understand the difficulty in finding howto.
Grahame Grieve (May 16 2019 at 11:30):
it's an interesting problem but I don't really know what to do about it
Alexander Henket (May 17 2019 at 07:29):
While we're at it: something similar is going on for the id element available on just about any V3 class.
Alexander Henket (May 17 2019 at 07:29):
Message : Invalid element name: 'id'. The specified name is reserved and is not allowed for a user defined element of a logical model.
Severity: Warning
Source : Element Name
Context : [CDAR2.Act] element.id<#6>.elementName
Grahame Grieve (May 17 2019 at 22:21):
I'll add that to my list
Michel Rutten (May 20 2019 at 09:44):
Logical models are still based on the core datatype Element, which introduces default child elements named "id" and "extension". So I think that in practice, these two element names are reserved and a logical model (or custom resource definition) cannot re-introduce such elements with a different meaning.
Michel Rutten (May 20 2019 at 09:49):
(I don't want to even think about trying to implement some magic logic to determine if an element named "extension" has a custom definition...)
Alexander Henket (May 20 2019 at 09:51):
Understood. But without a solution you're effectively saying: StructureDefinition cannot handle modeling V3. We have to find a way to distinguish between Logical Models and the rest. In FHIR instances, yes, id & extension have a reserved meaning. For V2, V3, ebXML, ADL, XMI and what not, there is no such thing.
So a logical model that aims to do more than FHIR - in fact doesn't even do that: it does arbitrary datasets with a few serialization pointers - cannot impose FHIR assumptions on those arbitrary datasets.
Grahame Grieve (May 20 2019 at 10:32):
yes that is the problem.
Grahame Grieve (May 20 2019 at 10:39):
I don't believe that we say that Logical models must be based on Element anywhere in the specification itself....
Michel Rutten (May 20 2019 at 11:10):
AFAIK, within the FHIR infrastructure, all ElementDefinitions are (ultimately) derived from Element, including Logical Models. This provides support for element identifiers and extensions, which are crucial concepts within FHIR.
Grahame Grieve (May 20 2019 at 11:11):
right. but I don't think we explicitly stated this anywhere
Michel Rutten (May 22 2019 at 08:28):
Yes, I think you're correct, AFAIK the FHIR spec doesn't strictly define this. Theoretically, we could allow for base classes other than Element (or Resource). However all current logic in the .NET API assumes the existence of element identifiers and extension collections. It is possible to make this conditional, however I'm not looking forward to such an exercise...
Oliver Egger (Aug 13 2019 at 06:24):
I don't believe that we say that Logical models must be based on Element anywhere in the specification itself....
For the cda fhir logical model i created a base 'LogicalElement' which has no baseDefinition and an empty snapshot/differential for the V3 datatypes and classes. As far as I can tell this approach works currently with the ig publisher, there are a few things which need to be improved (id not showing up in html, extension element with another icon) if that is a conformant way of doing it.
Oliver Egger (Aug 13 2019 at 06:49):
if you want to have a look: http://build.fhir.org/ig/ahdis/cda-core-2.0/branches/ahdistemplate/index.html, http://build.fhir.org/ig/ahdis/cda-core-2.0/branches/ahdistemplate/qa.html please note that the V3 Data Type snapshot generation is not yet correct.
Ewout Kramer (Aug 13 2019 at 10:00):
Yeah, the FHIR spec uses "Element" and "Resource" abstract types at points (e.g. contained, but there must be more) where we allow "any" resource or datatype. Since these were the bases for everything, this is hard-coded in quite some places in the .NET API (and I am sure in other too). IF we decide to introduce a new base class (which is probably the cleanest solution), this might -for all practical purposes- be considered a breaking change I think.
Michel Rutten (Aug 13 2019 at 10:02):
Introducing new base class(es) is definitely a breaking change
Grahame Grieve (Aug 15 2019 at 03:00):
I won't be accepting the pull request on the CDA model till we get to the bottom of this. However: I don't think that the spec itself is explicit about this. So I don't think it's a breaking change. And I don't think you'll be generating code based on logical models; t's the element-model that has to work with base models like this
Last updated: Apr 12 2022 at 19:14 UTC
