Stream: IPS
Topic: Must Support Elements
Peter Jordan (Feb 02 2021 at 22:55):
Am I alone in regarding the number of 'must-support' elements in the IPS Profiles as being completely excessive and a major barrier to adoption? Or, maybe there is a more liberal interpretation of 'must-support' than typically found in the invariants attached to these elements...
"All FHIR elements must have a @value or children (: hasValue() or (children().count() > id.count()))"
Certainly, Composition.encounter is a 'must-support' element, yet it's missing from the examples in the IG.
One element I was expecting to be a 'must-support' is Composition.VersionId - but that's totally absent from the IG (i.e. neither included or explicitly excluded).
Rob Hausam (Feb 03 2021 at 07:46):
Maybe we can discuss this on our call today, Peter. @Giorgio Cangioli
Giorgio Cangioli (Feb 03 2021 at 07:49):
Yes, I agree.
Giorgio Cangioli (Feb 03 2021 at 07:54):
... maybe I'm misinterpreting the must-support (I confess it is a gray-zone for me) , but must-support in my understanding doesn't mean shall be present..
Jose Costa Teixeira (Feb 03 2021 at 09:46):
Correct on 2 fronts: Must-support is a grey zone, and doesn't mean shall be present.
Rob Hausam (Feb 03 2021 at 13:31):
Yes, correct on both.
John Moehrke (Feb 03 2021 at 14:45):
I prefer the definition of must-support that indicates the element must be populated when the source has that information. This is the typical CDA and IHE definition. It has no impact on the recipient, that is declared elsewhere.
Jose Costa Teixeira (Feb 03 2021 at 16:16):
we (Belgium) use it to describe when the source has that information and it is OK to send it (for example for privacy reasons).
Lloyd McKenzie (Feb 03 2021 at 17:51):
Or you can be stronger and indicate that the source must be able to have information. I.e. a conformant instance would need to demonstrate that it's capable of populating the element.
Jose Costa Teixeira (Feb 03 2021 at 19:41):
That makes sense from a testing / conformance perspective.
Jose Costa Teixeira (Feb 03 2021 at 19:41):
Is there an ongoing discussion to make an extension that qualifies MustSupport for any such flavours?
David Hay (Feb 03 2021 at 20:05):
I thought there was an element of client responsibility - a client must have some strategy for 'processing' the element...
Peter Jordan (Feb 03 2021 at 20:54):
Thanks for the feedback. It concerns me if 'must-support' is a 'grey zone' . In terms of optionality, 'must' is clearly synonymous with 'shall' - so 'support' is the ambiguous term. @John Moehrke 's definition makes sense to me - @Lloyd McKenzie 's stake-raising response is problematic as it's difficult to test conformance unless an instance actually contains the requisite element.
As an example, take Composition.encounter - this is a 'must-support' element in the IPS Profile, however it is missing from examples in the IG and, in many real-life HIE use cases an IPS will not be generated as a result of a 'clinical encounter or type of care' that the sender is aware of. Although, IMHO, that shouldn't be a 'must-support' element anyway!
Lloyd McKenzie (Feb 03 2021 at 21:10):
Conformance testing of 'mustSupport' is always going to be hard. You can't ever evaluate it just by looking at an instance. MustSupport is always about system behavior (what's stored, what's displayed, what's considered in analysis, what's printed, what's available for data entry).
An assertion of mustSupport saying "if you have data you must send it" is legal - you can be that soft. But it means that you can't count on systems being able to capture the data and thus can't ascribe any meaning to the data being absent.
Rob Hausam (Feb 04 2021 at 03:02):
@Peter Jordan I think that @John Moehrke's mustSupport definition of "the element must be populated when the source has that information" is going to be too strong in the IPS context. Unless I'm over-reading the intent, I think that would negate the notion of the IPS as a "summary". The whole idea of that is built on the notion that there is a process to "summarize" (or filter) the data and send only the subset of the data that you have that will be clinically relevant for care in a different (cross-border or other) care setting that is not known in advance (i.e. when the IPS instance is created), and with the data selection being condition-independent and specialty-agnostic. Of course that involves a judgement and decision-making process (which could potentially be mis-applied), but we've had a great deal of acceptance of these principles overall, and the idea actually does make a lot of clinical sense. So however we define mustSupport for IPS (as it is currently in the spec or not), it needs to be consistent with that. And we can also talk about some of the potential pitfalls of this approach, like "the receiver didn't get the data that was needed because the sender determined that it wasn't clinically relevant and didn't send it" - that possibility needs to be acknowledged, but I think there are ways to deal with it (besides always sending the entire EHR content).
John Moehrke (Feb 04 2021 at 13:03):
Rob, if that is the case... that some items are marked MustSupport that are bigger than a summary would want... then what is the use of MustSupport? You are someone signaling to a reader that their implementation of a summary MUST SUPPORT something that you think is beyond what a summary should include? It would seem to me that this kind of signal is sent by not tagging the element at all, leaving it at the cardionality given in FHIR core. This is still a signal to the reader. It is a signal that you did not remove the element (0..0), you didn't mandate it (1..), and you didn't mark it must support. The lack of a flag is still a signal.
Giorgio Cangioli (Feb 04 2021 at 13:32):
Peter Jordan said:
As an example, take Composition.encounter - this is a 'must-support' element in the IPS Profile, however it is missing from examples in the IG and, in many real-life HIE use cases an IPS will not be generated as a result of a 'clinical encounter or type of care' that the sender is aware of. Although, IMHO, that shouldn't be a 'must-support' element anyway!
I agree with you that Composition.encounter should not be MS for the IPS :-)
The basic idea for MS was to label the elements that are in the IPS dataset (EN 17269) , plus others we felt relevant.
We revised them several times, but it seems that other iterations are needed.
Giorgio Cangioli (Feb 04 2021 at 13:36):
More in general, we talked a little bit about MS elements in the IPS call yesterday. One option we discussed was to label as MS not all the EN 17269 elements - some of them are in fact truly optional - but only those that should be included if known. But let's identify an agreed design approach for the MS in the IPS....
John Moehrke (Feb 04 2021 at 14:21):
The mapping would still show the linkage to EN 17269, right? That way the reader can see that there is a relationship of that element vs one that has no relationship.
John Moehrke (Feb 04 2021 at 14:22):
so it seems, one might need to give a reader guidance on how to find all of these signals... and what each is intended to mean... would that satisfy the original need/problem?
Giorgio Cangioli (Feb 04 2021 at 14:38):
just to avoid misunderstandings .. the forward or backward mapping between the FHIR profiles and the reference data set (EN 17269 - ISO/FDIS 27269) should be managed in a different way . The best option would be to publish them as FHIR LM and use the <mapping> element or better the ConceptMap to record this linkage.
Giorgio Cangioli (Feb 04 2021 at 14:43):
What I was trying to explain is that for determining what should be MS we used as "thumb rule" its presence in the IPS data set, but I believe we need to slightly revise this approach, above all to enable the reuse of the IPS components beyond the IPS document.
Lloyd McKenzie (Feb 04 2021 at 15:25):
If the differential defines a mapping, the element will show up in the differential, even if not marked as MS, which is probably enough of a 'highlighting' process to achieve your objective.
John Moehrke (Feb 04 2021 at 17:44):
I didn't know that... good to know.
Sheridan Cook (Sep 14 2021 at 16:17):
@Rob Hausam @Giorgio Cangioli - Am I correct in interpreting the current MS expectations for creators ("Implementers conforming to the IPS Implementation Guide, when creating IPS content SHALL be capable of including mustSupport data elements.") necessitates that an implementer can show they are capable of supporting a slice that is bound to a terminology?
I understand that an instance does not have to include the slice to be conformant - but it reads excessive on slicing for any implementer trying to show compliance. It seems counterintuitive to the open slicing approach that allows for alternative code systems to be used.
If so, it presents a real challenge to realm specific guides to derive from the IPS-UV since we may not want to inherit that requirement immediately if some of our vendors aren't implementing the SNOMED CT Global value sets currently.
Rob Hausam (Sep 14 2021 at 16:44):
@Sheridan Cook I think you are making an excellent point. The intent with the slicing, particularly for the cross-border case with closed slicing, is that you need to choose one of the slices using a specific standard terminology when creating an IPS instance, but the intent was definitely not to require that everyone support each slice. It would potentially be helpful on the receiving end to support as many as possible and ideally all of the slices, as that would allow maximum flexibility in interpreting the using the received data, but again it would not be required for all receivers to do that for all of the slices. So as you are pointing out, the way that we've specified mustSupport on each of the 'code' slices is not what was intended and is incorrect to achieve the desired behavior. That's a great pickup. We can have some discussion, but I'm inclined to go ahead and make the change to remove those mustSupport declarations on the slices in our 'connectathon-2' branch (and ultimately CI, as well).
Elliot Silver (Sep 14 2021 at 16:55):
From what I see, @Rob Hausam is suggesting that supporting at least one slice is a minimum, while @Sheridan Cook is suggesting that requiring support of at least one slice is too strict for some uses. Removing MS on the slices doesn't seem consistent with Rob's earlier statement. Did I miss a subtlety?
Rob Hausam (Sep 14 2021 at 17:04):
Yes, I think there may be a subtlety that you did miss, @Elliot Silver . The change is the same for mustSupport (removing those declarations on the slices), but the difference is whether the slicing is open as in the "base" profiles or closed as in the "cross-border" profiles. With the open slicing, it is not necessary to support any of the specified slices. With the closed slicing, you would be required to support at least one of the slices (but not all of them).
Sheridan Cook (Sep 14 2021 at 17:40):
Rob Hausam said:
Yes, I think you did, Elliot. The change is the same for mustSupport (removing those declarations on the slices), but the difference is whether the slicing is open as in the "base" profiles or closed as in the "cross-border" profiles. With the open slicing, it is not necessary to support any of the specified slices. With the closed slicing, you would be required to support at least one of the slices.
@Rob Hausam - So to put examples to it. With the new change in the CI build and connectathon branch- For AllergyIntollerance.code which has an open slice - the expectation is that implementers aren't prevented from claiming conformance if they can't support the terminology bound to code:allergyIntoleranceGPSCode or code:absentOrUnknownAllergyIntolerance if they are using alternative code systems.
And in a closed slice (which are fairly rare from what I've seen), the closed by type is what enforces the intent to have implementers to prove they can support one or the other (rather than a MS flag). E.g., Wit Medication.medication[x] the implementers have the expectation that they can prove conformance to being able to populate EITHER: MedicationStatement.medication[x]:medicationReference OR MedicationStatement.medication[x]:medicationCodeableConcept (which if you're going to use you need to use the extensible IPS value set)
How does that logic apply to slices like condition.onsetDateTime - where the slicing pattern is closed but only one of the slices is marked as MS?
Elliot Silver (Sep 14 2021 at 17:43):
Hold on -- moving to closed slicing has bigger impacts than must support. It means that only the defined slices are allowed, and alternative vocabularies are prohibited, no?
Sheridan Cook (Sep 14 2021 at 21:11):
@Rob Hausam Also adding on that the MS flag on the coding element of the CodeableConcept IPS Data Type also produces a similar dilemma for PS creators that may not be able to produce a coding and only a text for some concepts. Here in Canada, we know that there at least two jurisdictional implementers that may only be able to provide a codeableConcept.text for procedures - but not codings.
I know we all want to work towards codings, and that we need an enforcement mechanism to hold receivers accountable for their portion of conformance - but the IG definition of the meaning of MS flags may need tweaking or a more sophisticated mechanism to modify the meaning at a profile level in a small set of cases.
In the Accumulating MS Guidance thread - Lloyd had mentioned "Constraints can be defined in such away that they can be overridden in the context of an IG. E.g. "Unless otherwise specified at the profile or element level, mustSupport means X". However, they can't be overridden within a referencing IG. If an implementer of a base IG would have had certain expectations, those expectations hold wherever the artifact is referenced".
Would IPS consider taking this approach that would allow for profile specific MS definitions for the CodeableConcept Data type profiles to override the IG MS definition that is more restrictive on PS creators?
Lloyd McKenzie (Sep 14 2021 at 21:33):
The approach I've described doesn't allow overriding the rules for anything defined in IPS, only in net new profiles not derived from IPS ones (so I don't think it'd accomplish what you're hoping it would...)
John D'Amore (Dec 01 2021 at 13:27):
Based on discussion from this thread https://chat.fhir.org/#narrow/stream/207835-IPS/topic/National.20PS.20Implementations and from feedback from several connectathons, we wanted to get an understanding of where and how Must Support was used in IPS
I've found 382 Must Support assertions in the IPS (across multiple profiles). I've shown the profile name and the element id of each Must Support in this spreadsheet: https://docs.google.com/spreadsheets/d/15hNGV7Hol76pA73C5XCx_rHOoSYfG8E56PboF3ij9-k/edit?usp=sharing
I've then taken these elements and begun to cross reference things that are required as part of the ISO dataset (ISO 27269). There's appears to be a decent number of Must Supports that can be evaluated if there's a case to remove. Right now in the Google Sheet, I've provided a very "rough" ranking of how necessary each element is according to ISO and data linkage. Please consider those DRAFT and subject to change based on discussion.
If you can join the IPS call this morning (12/1/2021), we may discuss although this list may take a couple calls to work through. If you're interested to contribute thoughts or perspectives, let me know.
John D'Amore (Dec 01 2021 at 19:12):
Today during the 12/1/2021 IPS Call, we discussed the principles of Must Support for IPS. We will continue that discussion at the 12/8/2021 IPS Call (9am ET US) but wanted to present the great question posed by @Sheridan Cook (please comment if I don't represent accurately):
-
Should IPS be considered a building block that other profiles (e.g. national guidance) will derive from?
OR -
Should IPS be a gold-standard for how implementers will work/aspire toward?
If the first, then there's more consideration given to the reality that Must Support cannot be removed in derived profiles. In the second, IPS could provide more distinct alignment to the underlying ISO 27269 standard which provides perspective on required data elements.
We know that not everyone can attend all calls so invite discussion around this topic in advance of the next IPS call on 12/8.
Lloyd McKenzie (Dec 01 2021 at 23:52):
Aspirational specifications aren't super useful unless they're accompanied by a 'minimum' specification everyone is expected to achieve. Otherwise you end up with a whole lot of non-conformant systems that can't interoperate because no one can meet all the aspirations, and take that as carte blanche to do whatever they like.
Last updated: Apr 12 2022 at 19:14 UTC
