Stream: IG creation
Topic: where should extensions be defined in a capability statement
Sean McIlvenna (Oct 09 2019 at 23:11):
I'd like to assert that a server must support certain extensions using a capability statement. How would I make that assertion in the CapabilityStatement? I don't see anything that indicates where extensions should be listed...
Also, CapabilityStatement.rest.resource.type is limited to the ResourceType value set, which does not include "Extension".
Lloyd McKenzie (Oct 09 2019 at 23:50):
I support extension X isn't a useful assertion. What really matters is "I support extension X in locations A, B and C" - and that declaration is exposed through CapabilityStatement.rest.resource.profile (and/or in the profiles for messages or documents if those are the paradigms you're using.)
Sean McIlvenna (Oct 10 2019 at 15:42):
so, I should put extensions that apply to Organization resources within CapabilityStatement.rest.resource[type=Organization].supportedProfile?
Sean McIlvenna (Oct 10 2019 at 16:06):
@Lloyd McKenzie
Eric Haas (Oct 10 2019 at 16:12):
I think what Lloyd is saying you assert the extensions in the strucdef and assert the profile in the capstatements using conformance expectations extensions.
Sean McIlvenna (Oct 10 2019 at 16:31):
ok, got it... that was the other option I was thinking
Sean McIlvenna (Oct 10 2019 at 16:31):
wanted to make sure, though
Sean McIlvenna (Oct 10 2019 at 16:31):
so CapabilityStatement asserts the core profiles for resources
Sean McIlvenna (Oct 10 2019 at 16:31):
and the core profiles for resources assert the extensions
Sean McIlvenna (Oct 10 2019 at 16:31):
I still imagine it would be good for the CapabilityStatement to be able to assert what extensions the server must support generally speaking
Sean McIlvenna (Oct 10 2019 at 16:31):
but, understand that the CapabilityStatement may not be able capable of that, right now
John Moehrke (Oct 10 2019 at 16:41):
The StructureDefinition that creates the Extension is what is declared in a CapabilityStatement.rest.resource.supported. That StructureDefinition is the extension. So it is a single step. Use of an ImplementationGuide should be seen as MORE specific, as it casts that StructureDefinition within a use-context. This is also supported through CapabilityStatement.implementationGuide. right?
John Moehrke (Oct 10 2019 at 16:45):
Sean, are you asking about CapabilityStatement in Instance, Capability, or Requirements?
Sean McIlvenna (Oct 10 2019 at 16:52):
@John Moehrke that seems like it conflicts with what @Eric Haas was saying...
Sean McIlvenna (Oct 10 2019 at 16:53):
CapabilityStatement as Requirements
John Moehrke (Oct 10 2019 at 16:59):
I don' think Eric is saying anything different. He is just using the word "Profile" as a proxy for the StructureDefinition where you have defined the extension. Unfortunately FHIR community has taken on this use of the word "Profile".
John Moehrke (Oct 10 2019 at 17:01):
So you are defining an ImplementationGuide, an actors within using CapabilityStatement (Requirements), thus yes you should declare for each .rest.resource exactly where the extensions (StructureDefinition) are to be implemented (.supported)
Sean McIlvenna (Oct 10 2019 at 17:29):
so, then, I again ask: where should the StructureDefinition for an Extension for an Organization go in the CapabilityStatement?
Sean McIlvenna (Oct 10 2019 at 17:29):
there is no CapabilityStatement.rest.resource.type of "Extension"
Sean McIlvenna (Oct 10 2019 at 17:30):
so, does it that extension belong under CapabilityStatement.rest.resource[type=Organization].supportedProfile?
Lloyd McKenzie (Oct 10 2019 at 18:05):
In general, there is no 'general' support for an extension :) Servers don't arbitrarily support "data absent reason". They typically support it in specific resources at specific locations. CapabilityStatement.rest.resource.profile defines exactly what elements (including extensions) your server can handle.
Lloyd McKenzie (Oct 10 2019 at 18:05):
supportedProfile is more about what kind of profiles you can search for
John Moehrke (Oct 10 2019 at 18:22):
supportedProfile is more about what kind of profiles you can search for
I would not have read it that way... which points out the folly of the word "support" in a standard.
John Moehrke (Oct 10 2019 at 18:23):
Sean, are you speaking of an extension that is defined as being applicable anywhere; where you want to define in your IG that that extension is required to be supported in Observation?
Sean McIlvenna (Oct 10 2019 at 19:42):
@John Moehrke that is one scenario
Sean McIlvenna (Oct 10 2019 at 19:43):
what I'm gathering is that there is generally no guidance on whether extensions should be asserted in the CapabilityStatement
Lloyd McKenzie (Oct 10 2019 at 19:50):
@Sean McIlvenna Why would you want to assert support for extensions generally rather than point to exactly where they're supported?
Sean McIlvenna (Oct 10 2019 at 19:57):
how about scenarios where the extension is allowed globally? ex: any resource?
Lloyd McKenzie (Oct 10 2019 at 19:58):
Any resource, any location? I guess that's theoretically possible, but I haven't actually seen a situation where that was true of certain extensions but not true of all
Sean McIlvenna (Oct 10 2019 at 20:36):
So, if I have an extension that is used by two different Patient profiles, at the top of both Patient resources (not nested within its elements), how should I assert that in the CapabilityStatement, if at all?
Sean McIlvenna (Oct 10 2019 at 20:37):
again, I go back to one of my original statements... it doesn't sound like there was ever any intent to assert extensions in the CapabilityStatement
Lloyd McKenzie (Oct 10 2019 at 20:52):
Correct, there was never an intent for that - and to my knowledge, there's been no use-case presented for doing so.
With CapabilityStatement, there's only an ability to define a single Patient profile that reflects what patient data the system is capable of storing. I.e. either you support Patient.telecom or you don't. Same thing with the US-race extension. If there are business rules where you support the concept sometimes, but not other times, that nuance isn't really exposed other than as constraints and/or documentation.
Eric Haas (Oct 10 2019 at 21:32):
how about CapStatement.rest.resource.type = StructDef then define all the extensions there as supported profiles?
Sean McIlvenna (Oct 10 2019 at 22:45):
an interesting idea...
Lloyd McKenzie (Oct 10 2019 at 22:45):
That would mean that you supported StructureDefinitions being posted to or read from and searched from your server - it wouldn't say anything about extensions appearing in instances
Last updated: Apr 12 2022 at 19:14 UTC
