Stream: fhir/infrastructure-wg
Topic: CapabilityStatement2
Yunwei Wang (Nov 30 2020 at 15:43):
Will CapabilityStatement2 keep the same name (with "2") in R5 or will it replace current CapabilityStatement(1)?
Vassil Peytchev (Dec 01 2020 at 17:40):
Last I heard, it is meant to replace the current CapabilityStatement.
Lloyd McKenzie (Dec 01 2020 at 21:59):
Correct. When we publish R5, there will be only one.
Ward Weistra (Jan 26 2021 at 17:33):
@Lloyd McKenzie A question I forgot to ask in time yesterday, would it make sense for Capability Statement in the future to specify which FHIR Packages are loaded to the server? I think we can get to the specific loaded package version based on the referenced Implementation Guide, but the other way around is possible too. And it feels like it would make sense with the package ecosystem being easier for clients to retrieve the referenced item.
Lloyd McKenzie (Jan 26 2021 at 17:50):
I'm not sure what it would mean for a package to be 'loaded' by a server.
Bryn Rhodes (Jan 26 2021 at 18:43):
I understand "loaded" in that context to mean that all the resources that are included in the package are available in the FHIR server.
Bryn Rhodes (Jan 26 2021 at 18:43):
We specifically want that capability to distribute content IGs.
Bryn Rhodes (Jan 26 2021 at 18:44):
All the profiles, value sets, questionnaires, libraries, etc.
Josh Mandel (Jan 26 2021 at 18:46):
Specifically definitional resources? Not, say, examples I assume?
Josh Mandel (Jan 26 2021 at 18:46):
(And "loaded" doesn't imply support for operations, profiles, etc?)
Lloyd McKenzie (Jan 26 2021 at 18:50):
So 'loaded' means "you can query these resources from this registry", not "the instances on this server comply with these profiles" or "the behavior of this server complies with these IGs"
Paul Church (Jan 26 2021 at 18:52):
Loaded is well defined for general purpose fhir servers with configurable profile support - we'll enforce any profile that has its definitional resources in the store and is specified in the store configuration for enforcement. So it means you can query those definitional resources and all instances on the server comply with them.
Josh Mandel (Jan 26 2021 at 18:53):
we'll enforce any profile
meaning ... if a resource applies an explicit profile tag? Or you'll make sure that every resource matches at least 1 profile in the absence of explicit tags?
Paul Church (Jan 26 2021 at 18:54):
the latter
Josh Mandel (Jan 26 2021 at 18:55):
OK -- so in a server with lots of profiles loaded, you'll speculatively validate each new resources against all of them until you find a hit?
Paul Church (Jan 26 2021 at 18:55):
Only the ones configured, but yes if you configured 100 possible profiles it would be rather slow. Just loading definitional resources doesn't cause this to happen.
Josh Mandel (Jan 26 2021 at 18:56):
OK -- so for a client, discovery of which IGs are "loaded" doesn't tell the whole story; server-specific config is where the rules are set.
Paul Church (Jan 26 2021 at 18:58):
That config could be reflected in the cap statement though, so the client doesn't have to understand proprietary configuration.
Josh Mandel (Jan 26 2021 at 19:02):
Cool -- so this is good, but and highlights that "loaded" IGs is one thing clients can discover; "profiles configured for validation" is a distinct thing.
Paul Church (Jan 26 2021 at 19:04):
We are considering a separate mechanism for configuring/describing profiles that would be validated if a resource arrives tagged with them, but are not on the strict enforcement list. But so far the main use case seems to be "I want everything in this store to conform to USCDI/CARIN/etc."
Last updated: Apr 12 2022 at 19:14 UTC
