Stream: IG creation
Topic: Tricky Validation Error
Nagesh Bashyam (Nov 23 2021 at 06:10):
Grahame
I have a tricky error remaining in one of my IGs for ballot.
https://build.fhir.org/ig/HL7/fhir-central-cancer-registry-reporting-ig/qa.html
https://github.com/HL7/fhir-central-cancer-registry-reporting-ig
I am using 2 profiles (One each from US Core and mCode)
Profile 1 - US Core Condition profile.
Profile 2 - mCode Primary Cancer Condition profile -----> Derived from US Core profile if we follow its inheritance hierarchy.
Now I have a Cancer Report Bundle that contains the following:
Bundle
---- mCode Primary Cancer Condition (Mandatory 1..*)
---- problem List (for all other conditions) (Optional 0..*)
When I include a mCode Primary Cancer Condition example in the bundle that meets the Bundle requirement, I get an error saying that the Condition example matches both profiles (mCode and US Core).
The error is reporting the right thing, but I am not sure what I can do about it , because the above bundle structure is what we want to have.
Any options or thoughts you may have would be greatly appreciated.
Everything is checked in and is available in the above links in case you want to take a peek.
Thanks
Dragon
David Pyke (Nov 23 2021 at 15:07):
You're inheriting US Core by setting the dependencies to US Core IGs. You may not need to set the US Core dependency directly. Try removing it and see what happens.
Nagesh Bashyam (Nov 24 2021 at 11:04):
Tried the suggestion, but did not work. Any other thoughts ?
Oliver Egger (Nov 24 2021 at 11:20):
if you slice by profile you need to have distinct profiles, that's why you get the error message. The validator (or even the receiver) would not know if the condition is for the problemList or for the primaryCancerCondtion. if you need to differentiate that maybe introduce sections and slice the entries in the section.
Nagesh Bashyam (Nov 24 2021 at 14:00):
Introducing sections along composition is something that I thought about as an answer but that makes it a little more complex and I am not sure if the community will go for it.
As far as distinguishing the different resources included, I was thinking that the receiver would be able to distinguish by using the profile indicated in the meta element. So if someone sends a condition with just US Core as the profile in the meta, then it is just a generic problem list item, however if they indicated it is a primaryCancerCondition, then it is an mCode Primary Cancer Condition profile.
The fact that the included Condition element meets the requirement for both slices should not give an error, I am not understanding the rationale behind the error unless it is just code complexity that is preventing the error from going away.
Oliver Egger (Nov 24 2021 at 14:30):
Nagesh Bashyam said:
As far as distinguishing the different resources included, I was thinking that the receiver would be able to distinguish by using the profile indicated in the meta element.
sending the profile in meta is not required (and I think not recommended as best practice). but if you would add this requirement to the mCode primary Cancer Condition (or a derived profile of it) your slicing would give no errors because now the slices are distinct.
Oliver Egger (Nov 24 2021 at 14:36):
The fact that the included Condition element meets the requirement for both slices should not give an error, I am not understanding the rationale behind the error unless it is just code complexity that is preventing the error from going away.
its required by the specification, see https://www.hl7.org/fhir/profiling.html#discriminator
When a constraining structure designates one or more discriminators, it SHALL ensure that the possible values for each slice are different and non-overlapping, so that the slices can easily be distinguished.
Lloyd McKenzie (Nov 25 2021 at 03:21):
You're not allowed to use meta.profile to establish meaning. It must always be possible to strip the meta.profiles, validate against all candidates, re-assert the ones that are true and not lose information. Validation cares about what's valid against the profile, not what profiles are declared.
Lloyd McKenzie (Nov 25 2021 at 03:21):
If you need to assert a difference between two instances, it needs to be in the data values for the instances. If necessary, create an extension that disambiguates @Nagesh Bashyam
Nagesh Bashyam (Nov 25 2021 at 04:57):
Thank you for all the suggestions, let me think about how to make it happen.
Oliver Egger (Nov 25 2021 at 07:44):
Lloyd McKenzie said:
You're not allowed to use meta.profile to establish meaning. It must always be possible to strip the meta.profiles, validate against all candidates, re-assert the ones that are true and not lose information.
Is this stated somewhere? This approached is already used in profiled bundle ig's, I see:
- IHE uses this concept for indicating the type of a specific transaction for the 'Provide Document Bundle' - Transaction:
The FHIR Bundle.meta.profile shall have the following value depending on the Actor implementation of no options (Minimal Metadata), Comprehensive Metadata Option, or UnContained References Option.
- Usage on Bundle.meta.profile to indicate what kind of document it is, eg German eRezept
For documents we are currently using Composition.type to fix to a specific document, however this very coarse and we are also considering to include some requirements to further specify to which specifications this documents belongs to, any alternative recommendations highly appreciated.
Grahame Grieve (Nov 25 2021 at 09:05):
For this reason, applications processing resources SHOULD always depend on the contents of the resource when processing them, and/or check resources against the StructureDefinitions directly rather than relying the existence of profile tags for meaning. Profile Tags are provided as a method of finding resources that conform to a particular StructureDefinition, not statements of meaning about the resource.
Grahame Grieve (Nov 25 2021 at 09:06):
https://build.fhir.org/resource.html#profile-tags
Grahame Grieve (Nov 29 2021 at 04:41):
looking at the profiles, this isn't resolved. I think it's naturally a category thing - what kind of category is this condition?
US core has category 1..* with an extensible binding to problem-list-item, encounter-diagnosis, health-concern, and death-diagnosis.
mCode doesn't say anything about category, just describes what a primary cancer diagnosis looks like. So mCode tells you nothing about how to know whether a Condition is a Primary Cancer Condition - and that's your actual problem.
So when a consumer is looking at a bundle with a list of conditions, some of which are the patient's problem list, and some of which are the primary cancer diagnosis. (aside: there seems like a language issue here, if primary can be 0..*. Also, a primary cancer diagnosis would also be in the problem list? So will it be present twice? or just once?). So how do consumers tell them apart? And I note that a problem in the problem list might well conform to the mCode primacy cancer condition without being 'the primary cancer condition' in this context.
You have to disambiguate them - and you can't do it with a profile label, since those are fluid, and conforming the profile is not enough to say that it's the focus here. I think you have to re-profile mcode primary Cancer Condition and add a category to it, that is used to mark a Condition as (one of) the condition you're focused on
Nagesh Bashyam (Nov 29 2021 at 15:20):
Thanks Grahame and others for the feedback, I am evaluating the best way to move forward here, like a category or composition section to disambiguate the various resources which get included and ensuring that they get included only once in the given bundle.
Last updated: Apr 12 2022 at 19:14 UTC
