Stream: conformance
Topic: Must Support on Logical models
Jose Costa Teixeira (Nov 15 2019 at 20:34):
Does it make sense to indicate MustSupport on a Logical Model?
If so, what would that mean? A functional need to support it (which is then expected in the implementation)? or something else?
Grahame Grieve (Nov 15 2019 at 20:40):
The meaning would have to be defined for the logical model
René Spronk (Nov 16 2019 at 14:00):
In other words: please propose the wording ;-)
Jose Costa Teixeira (Nov 16 2019 at 14:58):
In other words: please propose the wording ;-)
Me, I'm using Logical Models to capture the functional part of a specification - common ground between business and developers - which will then have to be derived towards implementations. So I have this so far:
Jose Costa Teixeira (Nov 16 2019 at 15:01):
For Logical Models
- Functional Analysis MUST take into account the "Must support" data elements and their definition and constraints
- Implementation of “Must Support” logical data elements, MUST inherit the behaviour and constraints defined for the logical data element
- “Must Support” elements not needed in a particular implementation MAY be excluded from implementation but such exclusion MUST be described
- Elements derived from “Must Support” logical data elements SHOULD inherit the field’s “Must Support” flag
Jose Costa Teixeira (Nov 16 2019 at 15:02):
Looking for feedback
Richard Townley-O'Neill (Nov 18 2019 at 00:27):
@Jose Costa Teixeira
These are very weak conditions. I read the first conditions to mean must support means "must implement as specified or document an excuse". The last condition is weaker than what applies to derived profiles, where must support is inherited undiminished.
Richard Townley-O'Neill (Nov 18 2019 at 00:29):
MUST inherit the behaviour and constraints defined for the logical data element
I think that if you say that readers must pay attention to definitions and constraints you have assumed the readers are antagonistic or unskilled. Such readers will always find something that you have left out which they can ignore and blame on your incomplete statement. Leave out statements that amount to "be competent".
Richard Townley-O'Neill (Nov 18 2019 at 00:30):
Maybe
In the context of this implementation guide, must support SHALL be interpreted as follows:
- Implementations SHALL either implement the element as defined or shall omit the element and provide a documented reason for its omission (where?)
Frank Oemig (Nov 19 2019 at 06:56):
I don't think that documenting an excuse ist appropriate or acceptable for mustSupport elements. The basic idea for mustSupport was the establishment of minimal requirements. If this is broken there is no ground for any trust.
Jose Costa Teixeira (Nov 19 2019 at 10:38):
Maybe
In the context of this implementation guide, must support SHALL be interpreted as follows:
- Implementations SHALL either implement the element as defined or shall omit the element and provide a documented reason for its omission (where?)
@Richard Townley-O'Neill Thanks. I will rephrase. But the idea is not to say "be competent", rather "the logical model constraints must be reflected in the technical implementation, e.g. FHIR resource constraints".
I don't know if is is clear - When I wrote "implementations" I mean "the FHIR profiles (or CDA or V2...) that will be derived from this".
Richard Townley-O'Neill (Nov 20 2019 at 03:46):
@Jose Costa Teixeira
Your wording "the logical model constraints must be reflected in the technical implementation, e.g. FHIR resource constraints" is much more informative than my expression "be competent".
If an implementation does not follow the expectation "the logical model constraints must be reflected in the technical implementation, e.g. FHIR resource constraints" I would not call it a competent implementation.
Frank Oemig (Nov 20 2019 at 09:41):
Exactly. We have two problems: a spec must bei precise with exact requirements. Excuses shall not be allowed per se. Implementation must be correct and conformant. If this does mit map adaptations are necessary in both sides.
Jose Costa Teixeira (Nov 20 2019 at 09:45):
Thanks. This is a logical model and I am talking about "Must Support" so I expect this is at a different level than a technical spec.
Jose Costa Teixeira (Nov 20 2019 at 09:47):
My initial idea was to map the logical model to the profiles, and see when there is a "must support" on the logical model that is not present or not "must support" on the profiles
Jose Costa Teixeira (Nov 20 2019 at 09:47):
Doe that goal make sense?
Frank Oemig (Nov 20 2019 at 09:48):
MustSupport in or within logical models should not differ from resourcen/profiles.
Jose Costa Teixeira (Nov 20 2019 at 11:06):
MustSupport in or within logical models should not differ from resourcen/profiles.
That would apply for the physical layer on fhir (profiles) but not for other standards - other standards do not have the "must support" option. And the definition of Must Support on the physical layers may differ.. which is exactly why I wondered if we could put it on the logical layer
Frank Oemig (Nov 20 2019 at 15:17):
What do you mean with 'other standards'?
And mustSupport represents the corresponding construct in other layers..
Richard Townley-O'Neill (Nov 20 2019 at 22:50):
Maybe we have different ideas of the meaning and use of a FHIR logical model.
Maybe that needs to be stated before the meaning of must support is defined.
Frank Oemig (Nov 21 2019 at 09:38):
Well, a logical model is a structural definition with certain attributes. MustSupport is a tag indicating whether an attribute needs specific handling or not. The kind is then described in an IG. Or not?
Jose Costa Teixeira (Nov 22 2019 at 09:39):
One example for context: IHE Pharmacy has a profile for medication in v2, and one in CDA.
I proposed next step should be a common model that could be used to contain common specs, and then we apply specs onto technical standards. Cardinality, bindings,... and possibly things like MustSupport. Logical Model is not implementable, it just contains things that should be on both implementable standards.
Frank Oemig (Nov 22 2019 at 11:56):
OK, that opens the question for whether we would like to have information models as UML diagrams or structure definitions? The first is necessary for interoperability, the latter for implementations. However, they are highly related.
Rob Hausam (Nov 26 2019 at 05:06):
Why (and how) would UML diagrams be necessary for interoperability? That doesn't seem to me an obvious assertion to make, but I could be missing your point - maybe you can clarify?
Grahame Grieve (Nov 26 2019 at 05:13):
some people can't think without UML :wink:
Frank Oemig (Nov 27 2019 at 16:11):
Well, If the underlying logic and relationships are clear, you can have other mechanism to document that. But UML as a graphic notation is easy to read, mache mit for everyone.
Interoperability is more than mapping and understanding single fields/attributes. It is also about complex structures from different perspectives. Hierarchic views are single serialized perspectives only..
Most projects fail because of missing understanding. Migrating to FHIR for example does not fix this..
Grahame Grieve (Nov 27 2019 at 16:13):
indeed I often way that when presenting. But there are other ways to generate useful diagrams than UML. Of course, we can generate UML diagrams for logical models, so I'm actually wondering what we are discussing?
Frank Oemig (Nov 27 2019 at 16:21):
A single logical model is hierarchic, isn't it?
So what you generate is just a visualization.
UML models are cyclic graphs. So we would need a generator that create a visualization for a set of interlinked logical models/structure definitions...
Grahame Grieve (Nov 27 2019 at 16:23):
well, we'd only need that if we were generating from something that defined like that. Maybe you are talking about a generator for GraphDefinition?
Frank Oemig (Nov 27 2019 at 18:13):
Not yet, but good idea.
Right now I am talking about visualizing the way a set of logical models are related.
Grahame Grieve (Nov 27 2019 at 19:01):
That means GraphDefintion in FHIR
Frank Oemig (Nov 27 2019 at 21:25):
Including Details?
René Spronk (Dec 01 2019 at 08:29):
Yes. GraphDefinition refers to StructureDefinitions, so it describes the overall structure in detail.
Last updated: Apr 12 2022 at 19:14 UTC
