FHIR Chat · CapabilityStatement Resource

Stream: conformance

Topic: CapabilityStatement Resource

Peter Jordan (Oct 18 2016 at 21:26):

Has there been any active discussion around this change... https://fhirblog.com/2016/10/19/renaming-the-fhir-conformance-resource/

Grahame Grieve (Oct 18 2016 at 21:54):

there was quite a lot of discussion, why?

Peter Jordan (Oct 18 2016 at 22:51):

I should have added, "on this media"...it would be interesting to read the Capability v Conformance debate. I can understand the movement away from conformance (which needs to be tested), but I'm not sure about 'capability' - I would have voted for 'implementation', but accept that I've probably missed my chance to vote.

Grahame Grieve (Oct 18 2016 at 22:52):

can't find anything here

Lloyd McKenzie (Oct 19 2016 at 01:53):

@Peter Jordan Note that CapabilityStatement represents both the capabilities of specific implementations as well as statements of desired capabilities (e.g. in a spec or RFP) and general capabilities of a shrink-wrapped application that isn't implemented in a specific endpoint. That's one of the reasons we went with Capability.

Peter Jordan (Oct 19 2016 at 02:03):

...but if a client wants to know what parts of the FHIR specification the Server implements at the point in time of the request?

Grahame Grieve (Oct 19 2016 at 12:09):

we haven't changed what the resource does

Richard Kavanagh (Oct 19 2016 at 12:38):

Is there a way to state the operations can only be invoked via a POST as opposed to a GET.

Grahame Grieve (Oct 19 2016 at 12:39):

idempotent = false

Michael Lawley (Nov 21 2016 at 21:19):

That seems strange - isn't idempotent a statement about behaviour? For example I would expect $expand to be idempotent regardless of whether it's invoked with GET or POST