FHIR Chat · Loglcal Models & Element · conformance

Stream: conformance

Topic: Loglcal Models & Element

Grahame Grieve (Oct 19 2019 at 17:12):

GF#25031 raises the issue of the fact that the methodology... assumes... that the base of everything is Element. Element defines 2 properties: id an extension. What happens if a logical model wants to define id and extension properties?

This isn't an academic question - the CDA logical model needs to do that for both elements, and right now, the CDA logical model is broken on these elements. In general, we have 3 options I can think of:

• introduce some kind of 'override' key word so that we can redefine existing elements. This is a feature of many OO heirarchies, but it works variably well. In the CDA context xml:id (which is Element.id) still needs to useable as well as InfrastructureRoot.id

• Change (clarify?) the methodology that logical models can inherit from some abstract base of Element that has no properties. Maybe called 'Base' or something. Then CDA can define the elements it needs... which doesn't really actually fix the problem since CDA still has 2 id proprties, an element and attribute

• rename the .id and .extension elements in the CDA logical model and put some extension on them to say that on the wire they have different names to the logical model

Grahame Grieve (Oct 19 2019 at 17:14):

I'm not sure to what degree I should think about these as tooling issues in the java validator stack vs methodology issues in the specification itself. I kind of feel as though these are generic issues for logical model users, and so likely of interest to the dotnet snapshot generator/validator, not just the java one.

@Michel Rutten @Ward Weistra (@Oliver Egger @Sean McIlvenna fyi) + @Lloyd McKenzie

Grahame Grieve (Oct 19 2019 at 17:19):

btw, the question of extensions in CDA is complicated. CDA allows extensions - any XML in foreign namespace, though in practice all the extensions I have seen have been RIM content in a different namespace. Because of that, I've said that these can map to Element.extension, though how to make that happen in practice hasn't been investigated. And arbitrary XML of any type won't map to Element.extension except as base64Binary which is less than ideal.

(I have heard discussion about using FHIR content as extensions in CDA directly, in the FHIR Namespace, but I've never actually seen it)

Lloyd McKenzie (Oct 19 2019 at 17:22):

My leaning is to say that logical models should inherit from "base" rather than Element. Whether ids and extensions can exist, where they're allowed can all vary. Logical models should generally define that. Though I realize that creates issues for the Re- use of FHIR data types.

Sean McIlvenna (Oct 19 2019 at 17:29):

I agree with Lloyd. #2 seems best to me. I also think it would be the MOST backwards compatible with existing implementations, which is a nice bonus.

Grahame Grieve (Oct 19 2019 at 20:59):

#2 alone is not enough to solve the CDA problem....

Grahame Grieve (Oct 19 2019 at 21:00):

And I don't know whether it's just at tooling issue or a methodology one. I think it's methodology, since we need a formal definition of the base...

Lloyd McKenzie (Oct 20 2019 at 01:44):

The fact CDA has an element and an attribute with the same name means that CDA will need to deal with one of their names getting changed in the logical model. That's just a software reality. (And something implementers of CDA have been doing behind the scenes for ages)

Michel Rutten (Oct 20 2019 at 13:34):

IMHO Bridging the gap to CDA is extremely useful, however let's not throw the baby out with the bathwater and destabilize FHIR infrastructure itself in the process.

Both the .id and .extension fields are quite fundamental to FHIR and probably hard coded into most, if not all, existing processing logic. Allowing these fields to be redefined/overridden would break all this existing logic and require a considerable amount of additional complexity, further increasing the implementation and maintenance burden.

The Element.id field was introduced to allow unique element identification in StructureDefinition resources. It seems this is only useful if the element is mandatory. For if consumers can no longer rely on this information, they would need an alternative element indentification scheme, defeating the original purpose of the .id element altogether.

Only a base class without the .extension child element would seem to be relatively straightforward to support, with minimal impact to consumers.

Lloyd McKenzie (Oct 20 2019 at 14:32):

StructureDefinition wouldn't change
. We're only talking about logical models.

Michel Rutten (Oct 20 2019 at 17:13):

The functional requirements (CDA) concern logical models. Solution #1 and (to a lesser extent) #2 propose changes to the type system, on which all of FHIR is based, with relations to FHIRPath, mapping language etc. Fundamental changes to the type system of a normative spec require a particularly strong motivation - without understating the importance of the actual CDA support use case.

#1. Introducing "override" into the type system would open up a can of worms, especially for system elements one would expect to be non-overrideable. IMHO the complexity doesn't seem warranted to address this specific single use case.

#2. Introducing another base class level below Element could be considered a natural extension to the type system. However similar to #1, introducing optionality/ambiguity to system elements is quite fundamental. Also, this approach does not allow multiple .id elements to co-exist and does not address the CDA use case - suggesting this is a solution without a problem.

Grahame Grieve (Oct 20 2019 at 17:29):

firstly, I do not think that CDA is the only example. Else I wouldn't propose doing something about it.

#1 yes this is a pernicious change. I only proposed it because it appears in most OO formalisms. We're certainly not going to use it in FHIR Definitions

#2 Introducing a base class below Element would make no difference to anything that exists since everything that exists explicitly inherits from Element and outside of Logical models there would be no reason to change that

I think it needs a combination of #2 and #3 to fully solve the CDA use case

Michel Rutten (Oct 20 2019 at 17:29):

I think I'd prefer #3 as the proper way of addressing this. This would effectively encapsulate the additional complexity within (de)serializer logic. The extensions that capture the actual on-the-wire names would neatly map to serialization attributes in source code. No changes to the current type system are required. Can be implemented on demand, e.g. via custom serializer classes. Would also provides an escape for any other element naming conflicts that might arise in some future use case.

Grahame Grieve (Oct 20 2019 at 17:31):

the tricky bit for me there is that in CDA, InfrastructureRoot.id_ and II.extension_ have the wrong names. You use the right names on the wire... sure. but everywhere else, in profiles, when rendering the logical model.... you use the wrong name....

Grahame Grieve (Oct 20 2019 at 17:32):

where as with #2 and #3 the Any properties can by .xmlId and .extensions leaving the very important properties .id and .extension with the right name.

Grahame Grieve (Oct 20 2019 at 17:32):

with regard to #2, the right question is:

"what is the impact on Logical models of having extensions anywhere"

Grahame Grieve (Oct 20 2019 at 17:32):

I actually expected that to come up as the subject first

Michel Rutten (Oct 20 2019 at 17:34):

You mean allowing logical models to introduce extension elements?

Michel Rutten (Oct 20 2019 at 17:54):

BTW The CDA use case involves using StructureDefinition to capture a (non-FHIR) wire format. Calling this a logical model seems inappropriate and a bit confusing, as you cannot create a (FHIR) instance from a logical model, i.e. unsuitable for (FHIR) data exchange. If we decide to introduce support for this type of application, maybe we should also introduce a separate StructureDefinitionKind?

Lloyd McKenzie (Oct 20 2019 at 19:21):

My base concern is that 'id' and 'extension' have no place in a v2 model (and lots of other models). The only reason they're there is because of FHIR baggage. And it sucks when designers can't do what they want with their logical models because of unnecessary inherited baggage.

Michel Rutten (Oct 20 2019 at 23:42):

Indeed, the unfortunate naming conflict introduces pain for v2 designers. I wouldn't consider the default .id and .extension elements unnecessary, as they have an important function in FHIR itself and introducing optionality for system elements comes with a price.
I'd like to keep in mind that the main responsibility of the type system is to make FHIR itself work. Support for logical models could be added naturally and without breaking things. But in this case, we're talking about a potential new application that appears to be "close enough" to fit StructureDefinition, if we just fumble the type system a little bit. I'm worried that this could be overreaching - and set an unfortunate precedent for a normative standard.

Grahame Grieve (Oct 21 2019 at 01:38):

I'm not entirely sure I follow the concern. We wouldn't be changing anything for FHIR, since everything would still inherit from Element or Resource

Grahame Grieve (Oct 21 2019 at 01:39):

we'd be explicitly defining an abstract ancestor for both (which all the reference implementations have, I think)

Lloyd McKenzie (Oct 21 2019 at 01:56):

Logical models were introduced as a sort of after thought, but they've proven quite useful. They shouldn't have to inherit stuff they don't need just because the tooling chain originally evolved that way.

Michel Rutten (Oct 21 2019 at 08:45):

My concerns are about introducing optionality for omnipresent system elements that processing logic can safely rely on - for now. Sure, we can introduce another "bare" base class. This implies that consumers that rely on standardized FHIR element id's will not be able to process CDA models. If logic can no longer rely on .id, then we can just as well deprecate the element altogether. And allowing system elements such as .id and .extension to be redefined will be a cause for confusion, e.g. when models get mixed up. Theoretically, yes we can make this work. I'm more worried about practical implications.

Christiaan Knaap (Oct 21 2019 at 20:14):

I cannot find where Logical model is even formally defined in the spec, so imho it does not justify changes at a crucially core level like this.
I'm wondering whether instead LogicalModel should be defined explicitly as an ancestor to StructureDefinition.

Grahame Grieve (Oct 21 2019 at 20:18):

I don't understand how this is relevant. Making logical model and ancestor to StructureDefinition is irrelevant to this change.

Grahame Grieve (Oct 21 2019 at 20:18):

and I don't understand why this is 'crucially core' - we wouldn't actually be changing anything that matters to anything anywhere that already exists

Grahame Grieve (Oct 21 2019 at 20:23):

This implies that consumers that rely on standardized FHIR element id's will not be able to process CDA models

Are there such a thing? But yes, proposal #2 implies that the element model will need to change such that it doesn't hard code an id, that's true. Does the dotnet element model actually do anything with the id element?

Grahame Grieve (Oct 21 2019 at 20:25):

the java ElementModel class doesn't even have id as an explicit field; it comes out of the definitions and is transparent

Christiaan Knaap (Oct 21 2019 at 20:37):

No, as far as I can see the .NET API is not dependent upon the value of Element.id.
The SnapshotGenerator can be instructed to make sure they are filled, and users may rely on that.
But for details on that I still refer back to @Michel Rutten .

Grahame Grieve (Oct 21 2019 at 20:39):

so there seems to be some kind of confusion here. There's no proposed change to the snapshot generator; the ElementDefinition.id property will still exist, and still be populated as specified.

Grahame Grieve (Oct 21 2019 at 20:39):

.id will still exist in all existing FHIR content - no change.

Grahame Grieve (Oct 21 2019 at 20:41):

Just that a logical model can declare that it is based on a type that doesn't have .id and .element in the content of the logical model

Christiaan Knaap (Oct 21 2019 at 20:46):

I think I need a more concrete example of how that would look in a real StructureDefinition to see the difference it would make. And a more sound definition of what a Logical Model actually is.

Christiaan Knaap (Oct 21 2019 at 20:46):

BTW: The .NET API indeed has a 'Base' class that is the base for everything, even for Element.

Lloyd McKenzie (Oct 21 2019 at 20:47):

I think of "Logical Model" as "non-FHIR data model"

Lloyd McKenzie (Oct 21 2019 at 20:47):

(Though some logical models might still use FHIR types)

Christiaan Knaap (Oct 21 2019 at 20:47):

But still expressed in FHIR StructureDef, isn't it?

Grahame Grieve (Oct 21 2019 at 20:55):

yes. So here is what it would look like. the current definition of CDA Any is:

<StructureDefinition xmlns="http://hl7.org/fhir">
  <id value="ANY"/>
  <url value="http://hl7.org/fhir/cda/StructureDefinition/ANY"/>
  <version value="0.0.1"/>
  <name value="ANY"/>
  <title value="ANY: DataValue (V3 Data Type)"/>
  <status value="active"/>
  <experimental value="false"/>
  <date value="2019-10-21T18:39:49+00:00"/>
  <publisher value="HL7"/>
  <kind value="logical"/>
  <abstract value="true"/>
  <type value="ANY"/>
  <baseDefinition value="http://hl7.org/fhir/StructureDefinition/Element"/>
  <derivation value="specialization"/>
  <snapshot>

Grahame Grieve (Oct 21 2019 at 20:55):

This would change to:

Grahame Grieve (Oct 21 2019 at 20:55):

<StructureDefinition xmlns="http://hl7.org/fhir">
  <id value="ANY"/>
  <url value="http://hl7.org/fhir/cda/StructureDefinition/ANY"/>
  <version value="0.0.1"/>
  <name value="ANY"/>
  <title value="ANY: DataValue (V3 Data Type)"/>
  <status value="active"/>
  <experimental value="false"/>
  <date value="2019-10-21T18:39:49+00:00"/>
  <publisher value="HL7"/>
  <kind value="logical"/>
  <abstract value="true"/>
  <type value="ANY"/>
  <baseDefinition value="http://hl7.org/fhir/StructureDefinition/Base"/>
  <derivation value="specialization"/>
  <snapshot>

Grahame Grieve (Oct 21 2019 at 20:56):

so the only thing that changes is the stated baseDefinition.

Grahame Grieve (Oct 21 2019 at 20:56):

then, this would mean that in the CDA model had not declared that it has .id and .extension

Christiaan Knaap (Oct 21 2019 at 21:09):

Thank you for writing out the example. For consistency I would then expect this to imply that the StructureDef for Element also gets <baseDefintion value ="http://hl7.org/fhir/StructureDefinition/Base">.
And I assume there would be a rule that says you can only use types based on Base in a StructureDef of kind 'logical'?

Grahame Grieve (Oct 21 2019 at 21:12):

For consistency I would then expect this to imply that the StructureDef for Element also gets <baseDefintion value ="http://hl7.org/fhir/StructureDefinition/Base">.

yes

And I assume there would be a rule that says you can only use types based on Base in a StructureDef of kind 'logical'?

well, no, since Element is based on base. And would need no rule to say that we couldn't when we wouldn't? Not sure about that... but there is no intent to do anything different

Grahame Grieve (Oct 21 2019 at 21:13):

Resource would also baseDefinition = "http://hl7.org/fhir/StructureDefinition/Base">

Christiaan Knaap (Oct 21 2019 at 21:15):

Resource would also baseDefinition = "http://hl7.org/fhir/StructureDefinition/Base">

Having a common base for Element and Resource is definitely a change that makes things more consistent. But that is a substantial change to normative content isn't it?

Grahame Grieve (Oct 21 2019 at 21:17):

yes, but not a breaking change. So this is an R5 discussion.

Christiaan Knaap (Oct 21 2019 at 21:21):

OK. Then back to CDA - Trying to understand this from a FHIR perspective as I'm not familiar with CDA itself.
It's not that they don't want .id and .extension. They want it but with a different meaning.
Whereas much effort has gone into harmonizing naming and meaning throughout definitions (through the use of patterns for example), we would explicitly allow modellers to deviate from this.
(PS: Continuing tomorrow - getting late here..)

Grahame Grieve (Oct 21 2019 at 21:22):

CDA already has elements .id and .extension in inherited classes.

Grahame Grieve (Oct 21 2019 at 21:22):

CDA does want .xmlId (say) to do what .id does. And .something that's equivalent to .extension

Grahame Grieve (Oct 21 2019 at 21:23):

yes, this is deviation in meaning, but because it has already happened, in this case

Christiaan Knaap (Oct 22 2019 at 07:33):

As for .id: it already has different meanings in Element.id and Resource.id. You might conclude that a third would not hurt or that we should not confuse things any further and hence not introduce a third.
As for .extension: If we allow overloadiong the term 'extension' I don't see how we ever get this explained to people getting into FHIR.

Maybe the question is also from what perspective this is meant to be understood:

1. Being able to handle CDA documents as FHIR resources - then the definition of CDA in FHIR should adapt to what's already in FHIR to make it fit in the mental model of people working with FHIR.
   Or:

2. Just using the FHIR StructureDef (with kind = logical) as a vehicle to formally describe CDA - then it should resemble CDA as much as possible to make it fit the mental model of people working with CDA.

And from a programmers mind I would say: adapt that what you want to express (CDA) to the language at hand (FHIR) and not the other way round. By comparison: If I want to model education in C# I may have to model the concept of 'class' but I simply can't call a variable or property 'class'. So I find another term.

Grahame Grieve (Oct 22 2019 at 07:35):

you are speaking in defense of my option #3.

Christiaan Knaap (Oct 22 2019 at 07:35):

Indeed

Christiaan Knaap (Oct 22 2019 at 07:36):

And trying to get the arguments for / against it clearer since I'm no CDA or FHIR modelling pro.

Grahame Grieve (Oct 22 2019 at 07:42):

the problem is that this requires everything to use the wrong element names in CDA. And any other content models where .id is used. Which doesn't seem unlikely to me

Grahame Grieve (Oct 22 2019 at 07:44):

but the more general problem is: .id and .extension are clearly FHIR specific concepts, where a StructureDefinition is not necessarily describing something that is. So it's a simple proposal: Define a Base type that both Element and Resource specialise. What I haven't figured out is why you and Michel are so freaked out by that

Grahame Grieve (Oct 22 2019 at 07:44):

with the belief that it somehow alters the fabric of StructureDefinition itself

Christiaan Knaap (Oct 22 2019 at 08:01):

I'm not freaking out:
- I even like the harmonization that a common Base would bring.
- Technically it is not a huge problem - at least not for the .NET FHIR API (can't speak for other implementers).

I guess you touch upon the problem with: "but the more general problem is: .id and .extension are clearly FHIR specific concepts, where a StructureDefinition is not necessarily describing something that is.": The discrepancy between using something that is clearly FHIR (StructureDefinition) to describe something that is outside of the FHIR realm. That is what is covered by Logical Models, but lacking a formal definition of Logical Model I foresee trouble for people less involved in this understanding this in the long run.

One other thing that I don't understand fully: If you want to construct a structure with elements derived from Base, you need to change ElementDefinition.type to Base instead of Element, not?

Frank Oemig (Oct 23 2019 at 15:10):

It should bei possible to derive structure definitions from an appropriate base...

Michel Rutten (Oct 24 2019 at 09:22):

Thanks @Christiaan Knaap for thinking along. No worries @Grahame Grieve, I am not freaking out - that involves a different kind of tone and language :wink: . As Christiaan mentions it appears feasible to implement #2/#3 in the .NET API. I'm just trying to get a clear picture of the potential impact and considering if we are making a proper trade off.

@Christiaan Knaap made another interesting observation: the mapping engine is also driven by StructureDefinition resources describing a (non-FHIR) input format. So providing a generic solution for dealing with or avoiding element naming conflicts will be helpful in a broader scope than just CDA. Certainly a compelling motivation to address the issue at hand.

@Grahame Grieve it appears to me that the StructureDefinitions we are talking about are not exactly "logical models", but definitions of non-FHIR serialization formats that allow instantiation. It seems useful to introduce a new StructureDefinition.kind value to identify this class of structures with special rules, e.g. allow different element base. What do you think?

Grahame Grieve (Oct 24 2019 at 09:45):

with regard to the definition of logical model.. maybe. We went back and forth on this during R4 balloting.

Christiaan Knaap (Nov 08 2019 at 08:14):

What would the StructureDefinition of Base look like?
I assume Base should not have any elements, so it can indeed be the base of everything.
But a StructureDefinition must have either a differential or a snapshot (or both), and both must have at least one element.

Oliver Egger (Nov 08 2019 at 15:27):

I tried a Base StructureDefintion with just the 'Base' element itself in the snapshot and differential. See https://github.com/ahdis/cda-core-2.0/blob/develop/resources/Base.xml

Oliver Egger (Nov 09 2019 at 14:46):

The Defintion Pattern which is defined as a Logical Model has no baseDefinition to Element and provides only a snapshot (no differential) with no id/extension in the pattern.

Grahame Grieve (Nov 09 2019 at 20:27):

can you make a task to fix this in R5 please

Oliver Egger (Nov 11 2019 at 08:33):

GF#25199: Workflow Patterns have no baseDefinition

Chris Moesel (Apr 19 2021 at 22:28):

Resurrecting this conversation w/ a couple of notes and questions, since I don't see resolution in this thread. This is relevant to the FSH team as we implement support for logical models.

1. Given that Base exists in R5, I assume that the resolution of this conversation was indeed to introduce a new top-level base type (Base) without id and extension.
2. But I also see that the pattern logical models (like Definition) still have no baseDefinition. Is this a valid option for logical models or should logical models always extend something (at least Base)?
3. What does this mean for logical models in R4? Are they just stuck w/ id and extension? Or (as in 2 above) can they choose to have no baseDefinition at all?
4. While I have your ear... are there rules regarding what logical models can and cannot set as their baseDefinition? For example, (a) can their base definition be of any kind: logical|complex-type|primitive-type|resource? (b) Can their base definition be a constraint or must their base always be a specialization?

Grahame Grieve (Apr 20 2021 at 05:07):

#1 yes
#1 they should extend Base
#1 unclear. In practice, the tooling fakes Base up so it can be used anyway
#1 good question, and I don't know what the answer is

Alexander Zautke (Apr 20 2021 at 07:50):

Regarding #4, the CDA LogicalModels contain a few examples where constraint is being used. It works fine in the .NET as well as the Java tooling. See https://github.com/HL7/cda-core-2.0/blob/e8f5e61c3219c056db51f853e81415c4a14bce0f/input/resources/ST.xml

Chris Moesel (Apr 20 2021 at 12:31):

Thanks Grahame and Alexander. Re #4, Alexander's example is a case of a logical model being a constraint. I was wondering if a logical model can have a parent/baseDefinition that is a constraint. I guess I don't see why not... Of course, to tie 4a and 4b together, we could ask if a logical model can declare a resource profile as it's baseDefinition (e.g., can I build a LM whose base definition is the BP vital sign profile).

Jose Costa Teixeira (Apr 20 2021 at 12:49):

In that case, the LM would be an abstraction based on the resource profile.
If i understand correctly, I don't see how that would work:
The LM has a few things that it cares about (to oversimplify): Patient, Date, Location, Systolic and Diastolic pressure . 2 of these 4 elements happen to be implemented as slices in the profile, the others are discrete elements. What does it mean if the LM abstracts that? Each slice is its own element at the root level? Or each slice is a sibling under another element?

Jose Costa Teixeira (Apr 20 2021 at 12:50):

I'm not saying it doesn't work, I'm just wondering if/how we can cover the gap

Chris Moesel (Apr 20 2021 at 15:24):

I wouldn't suggest we do anything smart there, @Jose Costa Teixeira. I was just suggesting it would inherit the structure as-is (slices and all). So, if that's not valid in an LM, then I'd be more inclined to say using a constraint as a parent is not supported rather than creating special rules about how to convert it to automatically 1st class top-level elements. That's too complicated. I don't think we want complicated.

Grahame Grieve (Apr 20 2021 at 20:42):

I still don't know the answer and partly because I can't imagine a circumstance where it would be useful

Joe Paquette (May 06 2021 at 20:24):

We are getting close to completing our work to add support for logical models and resources to SUSHI. Based on discussions in this stream (and others) and with an eye towards completing the current work, we are limiting the creation of logical models to be derivation = 'specialization'. Creating logical models to be derivation = 'constraint' can be considered at some point in the future if the community thinks it would be useful.

We are currently allowing the logical model's "Parent" (baseDefinition) to be: Base, Element, and any other logical model (where kind = 'logical' and derivation = 'specialization'). This begs a couple of questions:

• Should we disallow other logical models to be the baseDefinition (keeping only Base and Element as allowed baseDefinition)?
• Assuming we continue to allow logical models to be the baseDefinition, should we also allow a logical model's baseDefinition to be a resource (where kind = 'resource' and derivation = 'specialization')?

We see no difference in allowing either logical models or resources to be the baseDefinition and are inclined to support both. Since one can only add new elements in the definition of a logical model and cannot change any of the inherited elements from the baseDefinition, we see no reason to exclude either logical models or resources as a baseDefinition.

That said, we would like to hear thoughts from the community to make sure we are not missing anything and that what we are thinking makes sense.

Grahame Grieve (May 06 2021 at 21:40):

I

Grahame Grieve (May 06 2021 at 21:41):

I'm not sure what your context for 'support' is. I don't think we have any methodological rule that you can't derive logical models from resources, but I don't think there's much point to doing that

Chris Moesel (May 06 2021 at 21:59):

We couldn't find anything that forbade it in the spec, but weren't sure if there were any known (or expected) issues in the tooling. As far as I remember, the IG Publisher didn't complain when we passed in a logical model based on a resource, but that wasn't enough evidence to make us feel comfortable that it was an okay thing to do.

I'm not sure there would be much point to it either, but we've learned not to be surprised by the ingenuity of IG authors ;-). And we don't wont to explicitly forbid something without a good reason for doing so.

That said, I assume that logical models cannot declare a profile as their parent because that might introduce things that are otherwise not allowed in logical models (like slicings), right?

Grahame Grieve (May 06 2021 at 23:24):

I'm pretty sure that I've said before that it's not illegal, but we have no idea how the tools would behave, or should behave

Last updated: Apr 12 2022 at 19:14 UTC