Stream: shorthand
Topic: Accessing meta attributes
Elliot Silver (Sep 15 2020 at 17:53):
I'm trying to create a profile of Observation that requires the instance declare conformance with a particular profile:
* meta.profile[0] = Canonical(MyObservation)
But this line is failing with:
Sushi: error No element found at path meta.profile[0] for SpecializedObservation, skipping rule (00:04.0512)
Can I access meta elements in sushi? Interestingly, ^meta.profile doesn't give an error, but I believe that sets the meta for the profile itself (ie. the StructureDefinition), not on instances of the profile.
(I know I should do this with slicing rather than hardcoding the slots -- I'll get to that once I've proved the concept.)
Lloyd McKenzie (Sep 15 2020 at 17:58):
It's not great practice to force the declaration to be in a specific order. It would be better to assert meta.where(profile=foo) - so that the assertion can be in any position. Otherwise, you're going to force people to expose custom instances to each recipient. As a rule, if order doesn't have a defined semantic meaning, profiles should be tolerant of desired data appearing in any order.
Elliot Silver (Sep 15 2020 at 18:00):
Agree. And I'll change this to slicing shortly, but for now, it was failing on simply trying to set meta.profile.
Chris Moesel (Sep 15 2020 at 19:46):
@Elliot Silver -- Lloyd's concerns aside, from a technical standpoint, it seems that what you're attempting to do should be supported. So, this appears to be a bug in SUSHI. I've file #601 for this one.
Nick Freiter (Sep 16 2020 at 12:29):
I think this one may not be a bug. If you are writing this line:
* meta.profile[0] = Canonical(MyObservation)
on a Profile, it is expected that SUSHI would not find meta.profile[0], because on a Profile, you cannot constrain specific array elements by their numerical index. You could set up an ordered slicing if you truly wanted to constrain the first element to be Canonical(MyObservation).
Chris Moesel (Sep 16 2020 at 12:50):
Yes, of course, @Nick Freiter is right. Brain lapse on my part. As Lloyd said, however, an ordered slice is probably not ideal, so you probably want something like this:
Profile: MyObservation
Parent: Observation
* meta.profile ^slicing.discriminator.path = "$this"
* meta.profile ^slicing.discriminator.type = #value
* meta.profile ^slicing.ordered = false
* meta.profile ^slicing.rules = #open
* meta.profile contains myobservation 1..1
* meta.profile[myobservation] = Canonical(MyObservation) (exactly)
Elliot Silver (Sep 17 2020 at 22:48):
Thanks -- this looks like it works (with the correction that Profile: MyObservation and Canonical(MyObservation) should be different profiles).
Interestingly, the snapshot only shows the constraints applied in the MyObservation profile (i.e. the requirement to claim the base profile), and none of the constraints from the base profiles. That seems both right and wrong at the same time.
Chris Moesel (Sep 18 2020 at 12:52):
What do you mean by "constraints" exactly? What specifically from the base profile is not showing up? (If it's a lot, you don't need to list it all, but a few examples would help).
Chris Moesel (Sep 18 2020 at 15:35):
Thanks -- this looks like it works (with the correction that Profile: MyObservation and Canonical(MyObservation) should be different profiles).
So you want to have a profile that requires instances of it to declare that they conform to a different profile? I guess that's possible, it's just not what I expected.
Elliot Silver (Sep 18 2020 at 18:45):
So you want to have a profile that requires instances of it to declare that they conform to a different profile? I guess that's possible, it's just not what I expected.
Yes, what I'm trying to do is achieve multiple inheritance of profiles. Given profiles A and B based on Observation, I want a new profile C that incorporates both A and B. Profile C may or may not impose additional constraints. I've approached this by declaring the parent of C is Observation, and C requires instances to claim conformance to A and B.
What do you mean by "constraints" exactly? What specifically from the base profile is not showing up? (If it's a lot, you don't need to list it all, but a few examples would help).
Profile C displays that meta.profile is required include A and B, which is absolutely expected. What I'm not seeing are the constraints from A and B showing up in the display of C. As I said, I can see this makes perfect sense--all the C profile is requiring is that profiles A and B are claimed, not that the constraints of A and B are implemented. The fact that claiming A and B without meeting the constraints of A and B is a conformance error is separate from the display of the C profile. However, from an implementer's point of view, it would be helpful if display of the C profile showed the constraints imposed by A and B.
By the way, none of this are FSH or sushi issues. Also, based on comments from Lloyd in the IG stream, I may need to rethink the approach.
Chris Moesel (Sep 18 2020 at 18:54):
Ah, OK. Thanks for the clarification. I get it now... As you said, your profile C is really only requiring others claim conformance to A and B. I didn't follow the other thread, but could the FHIRPath conformsTo function be used to more explicitly require this? Something like $this conformsTo('http://canonical/for/A') and $this.conformsTo('http://canonical/for/B')? I expect that still might be tricky for implementors though.
Chris Moesel (Sep 18 2020 at 18:59):
Here is another approach, powered by RuleSets that might accomplish what you're looking for:
RuleSet: ConstraintsForA
* code from http://foo.org
Profile: A
Parent: Observation
* insert ConstraintsForA
RuleSet: ConstraintsForB
* value[x] only CodeableConcept
Profile: B
Parent: Observation
* insert ConstraintsForB
Profile: C
Parent: Observation
* insert ConstraintsForA
* insert ConstraintsForB
In this case, if you wanted to make the relationship explicit you could then add the meta.profile declarations -- but the constraints themselves force the relationship.
Chris Moesel (Sep 18 2020 at 19:01):
In an early version of FSH we allowed profiles to act like RuleSets (so you could insert A directly), but I guess we dropped that. I don't remember intentionally dropping it, but it's not in the spec and not supported by SUSHI. Still, having the extra RuleSets isn't too bad.
Elliot Silver (Sep 18 2020 at 19:03):
I thought about that before and it would work if we were publishing one IG that defined all of A, B, and C. However, the situation is a little more complex. I'm about to hop on a call -- I'll be back in a bit with details.
Chris Moesel (Sep 18 2020 at 19:12):
Well, shoot. You've reminded me of why we supported profiles as RuleSets in early versions of FSH. We supported it precisely because we wanted people to be able to "mix in" profiles from regional IGs. For example, you might want to base your Condition on a Condition profile defined in a clinical IG, but "mix in" constraints from US Core Condition to ensure you're aligned with US requirements. That's only possible if we allow something like: insert http://hl7.org/fhir/us/core/StructureDefinition/us-core-condition.
Chris Moesel (Sep 18 2020 at 19:14):
And now I'm also remembering why we don't support it... because it's hard! I think we decided to push it off and consider it for FSH STU2.
Elliot Silver (Sep 18 2020 at 21:48):
That is exactly the situation I'm dealing with. There are existing profiles for a US project, based on US Core, published by a separate group We want to do an international project, not using US Core, covering much of the same ground. We are in discussion with the US project about how they could restructure to allow us to leverage their content. The way I've been visualizing this is they publish an abstract USBaseObservation profile, an abstract ClinicalObservation profile, and a concrete USClinicalObservation profile that "inherits" from both of those; we publish an abstract InternationalBaseObservation, and a concrete InternationalClinicalObservation that inherits from the InternationalBaseObservation and the ClinicalObservation profiles.
John Moehrke (Sep 19 2020 at 15:25):
some of that was done with core vitalsigns... What you need to do is propose these changes to the workgroup owning the resource to be profiled to create a FHIR core profile. Even a CR with your recommended FSH Profile would go a long way to making it happen.
Elliot Silver (Sep 19 2020 at 16:07):
@John Moehrke, I don’t understand. None of this work is being done inside HL7, and I don’t think we can influence already published US Core, but most importantly, I don’t know how to solve the multiple inheritance issue. I done think a new HL7 core profile changes anything.
John Moehrke (Sep 19 2020 at 17:32):
US-Core is a project within HL7
John Moehrke (Sep 19 2020 at 17:32):
and these are global profiles that are inside of core FHIR http://build.fhir.org/observation-profiles.html
John Moehrke (Sep 19 2020 at 17:33):
I was just mentioning that if that is not enough, then you can propose more
John Moehrke (Sep 19 2020 at 17:33):
ANYONE can submit a CR to the FHIR Core
Elliot Silver (Sep 19 2020 at 17:34):
I agree with all of those. But it doesn't address my issue.
Elliot Silver (Sep 19 2020 at 17:41):
A third party is working on profiles derived from US Core. We want to do similar profiles, except not based on US Core. I'm looking for ways that the third party (who we are talking to) can structure one of their profiles to separate the "clinical" part from the US Core-base. We could then take that "clinical" part and mix it in with our "not-US core" content.
Last updated: Apr 12 2022 at 19:14 UTC
