Stream: conformance
Topic: ElementDefinition.supportType
Frank Oemig (Feb 14 2020 at 07:51):
The discussion around the variability of implementation guides shows that the kind of support highly varies between different IGs. In order to formalize that, a new optional attribute supportType with coded information (0..*) would be helpful.
Lloyd McKenzie (Feb 14 2020 at 15:09):
I don't understand how this could be standardized with a code. If you have two different elements that describe different types of decision support systems, they might both describe expectations that the element "must be considered in decision support logic" - but the meaning behind that would be different based on the context of each application - so what would having a standard code for the notion of "must be considered in decision support logic" wouldn't really be buying you anything - and the fact that a system declared that it considered the element in decision support logic wouldn't necessarily be meaningful. The only thing you could truly count on is a CapabilityStatement that specifically declared it complied with the CapabilityStatement of a specific IG.
Even for storing information, it's possible that the storage expectations could differ. Just because you know how to store an element for lab Observations doesn't necessarily mean you know how to store the same element for psychiatric evaluation Observations - or vice versa.
Frank Oemig (Feb 14 2020 at 17:01):
The idea behind is not to predefine the codesystem, that should be left for an IG. So you can define behaviour or expectations as codes, and assign them where appropriate. So it is not hidden in the text anymore.
Lloyd McKenzie (Feb 14 2020 at 17:10):
If it's defined by the IG, then you haven't helped interoperability by making it a code - developers still need to read and implement the definition of the code. The reality is that there's lots of text that must be read when you implement an IG - not everything can be exposed in a computable artifact.
Lloyd McKenzie (Feb 14 2020 at 17:10):
If we're going to define something like this, I'd like the use-case to come from the implementer community defining how they'd use it.
Grahame Grieve (Feb 15 2020 at 04:57):
this has been suggested before. I'm sympathetic to this notion - that we should create an extension, define the code system, and start populating the code system with known statements about must-support, but leave it extensible. I think that there's a finite number of variations of the theme, maybe 10-20... it seems like something it would be useful for us to define if it's possible
Ioana Singureanu (Mar 02 2020 at 14:45):
We should consider several _code_ as @Frank Oemig suggested: support/usage (Mandatory , Required, Required but may be empty) from an information producer's stand-point, processing (Process, Store, Display, etc.) from an information consumer's stand-point (e.g. a health application using a US Core conformant FHIR API). We should also discuss whether "local extensions" may be explicitly prohibited. https://confluence.hl7.org/pages/viewpage.action?pageId=55936723#FHIRUSConformance:SpecificationOutline-SupportandPresenceRules
Lloyd McKenzie (Mar 02 2020 at 15:57):
Notions of 'mandatory' have nothing to do with mustSupport - that's driven by cardinality which is totally orthogonal to mustSupport. mustSupport is about "what are systems expected to be able to do with the data" - persistence, rendering, inclusion in decision support logic, etc. However, there are nuances for all of those things. If you must persist, must you be able to exactly round-trip? Are you able to modify the data before storage or retrieval? Are you allowed to reject non must-support data? Also, there's expected behavior for the sender vs. the consumer. Once you start putting together all of the combinations and permutations, you're looking at a lot of codes. Even if you have two identical situations that say something around "must include in decision support", the meaning of that will of course vary based on the type of decision support envisioned by the IG. I'm really not clear on how any system is going to consume that and do anything usefully 'computable' on it.
Frank Oemig (Mar 02 2020 at 16:42):
Agreed, there are a lot of different ways someone may support a resource or attribute. Exactly for that purpose it makes sense to summarize it. Unless the support for each attribute is different, but then it ends up in something that is not implementable.
Reengeneering IGs led to the list @Ioana Singureanu talks about, at least in principle. Of course it needs a more thorough analysis, but we are working on it.
Grahame Grieve (Mar 02 2020 at 19:10):
more thorough analysis
That would be good - have we got a survey of existing FHIR IGs on this subject?
Frank Oemig (Mar 03 2020 at 08:57):
Yes, this is the result of a Conformance project. @Ioana Singureanu ?
Last updated: Apr 12 2022 at 19:14 UTC
