FHIR Chat · US Core Compliance · implementers

Stream: implementers

Topic: US Core Compliance


view this post on Zulip 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?

view this post on Zulip Grahame Grieve (Sep 03 2019 at 20:44):

in general, yes. The fine print says that it depends on how you reference them

view this post on Zulip 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?

view this post on Zulip 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

view this post on Zulip 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.

view this post on Zulip 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)

view this post on Zulip 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.

view this post on Zulip 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

view this post on Zulip 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.

view this post on Zulip 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

view this post on Zulip 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.

view this post on Zulip 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.

view this post on Zulip Eric Haas (Sep 04 2019 at 16:12):

so how to say use the profile A here, here, here, but not here....

view this post on Zulip Eric Haas (Sep 04 2019 at 16:12):

Is not reachable in the CapStatement


Last updated: Apr 12 2022 at 19:14 UTC