Stream: implementers
Topic: US Core Compliance
Madeline Hoskins (Sep 03 2019 at 20:43):
In order to be US Core compliant, do the resources that are contained inside a base resource need to follow the US Core Profiles?
Grahame Grieve (Sep 03 2019 at 20:44):
in general, yes. The fine print says that it depends on how you reference them
Eric Haas (Sep 04 2019 at 01:47):
The fine print says that it depends on how you reference them
@GG What are you referring to?
Grahame Grieve (Sep 04 2019 at 02:24):
well, if you make your own extension, and refer to the contained resource from the extension, then there's no profiling expectations on the resource. But if you refer to the contained resource from an element which US Core has profiled to say 'it will be a US Core resource', then the fact that it's contained is neither here nor there - it's subject to US Core profile rules
Eric Haas (Sep 04 2019 at 02:45):
We say in the guidance that all referenced resource must be US Core if covered by US Core, but did not specifically consider contained resources. And I do recognize situations where US Core may be "too much" like a contained deidentified patient for QuestionnaireResponse. But I don't understand why making an extension gives you a free pass.
Grahame Grieve (Sep 04 2019 at 02:49):
well, if you say that 'all referenced resources' must be US Core, then referring to it from an extension doesn't make any difference. I didn't realise you had made that statement (since you won't make it in the CapabilityStatement)
Lloyd McKenzie (Sep 04 2019 at 04:03):
The ImplementationGuide could formally make that statement using the 'global' elements. If you define a global profile for Patient, then all references to Patient within instances that conform to that IG are expected to comply with the profile. Contained vs. not doesn't matter.
Grahame Grieve (Sep 04 2019 at 04:04):
the interesting challenge here is that US core can't, because it doesn't have a base profile for a few resources
Eric Haas (Sep 04 2019 at 14:43):
. Contained vs not contained can be use for very different uses such as supplying only a salient bits of a resource like patient demographics.
Eric Haas (Sep 04 2019 at 14:57):
I would like to discuss at the WGM - this is a deeper discussion on Capstatements and IGs and System expectations
Lloyd McKenzie (Sep 04 2019 at 15:32):
Not really following "salient bits". With REST, you send everything you know. It's not for use-case-specific exchanges (that's what messaging is for). The expectation in US Core is that patients are identifiable, which means they'll never be contained. If you're doing annonymized reporting or something, then you're not using US Core because that's outside the scope of those profiles.
Eric Haas (Sep 04 2019 at 16:11):
If you're doing annonymized reporting or something, then you're not using US Core because that's outside the scope of those
That is my point and what I have been trying to say. Its still a profile and is subsumed by the system's base profile.
Eric Haas (Sep 04 2019 at 16:12):
so how to say use the profile A here, here, here, but not here....
Eric Haas (Sep 04 2019 at 16:12):
Is not reachable in the CapStatement
Last updated: Apr 12 2022 at 19:14 UTC