Stream: implementers
Topic: GF#10205 - Cardinality of Conformance.rest
Grahame Grieve (Jul 09 2018 at 07:35):
GF#10205 proposes to change the cardinality of Conformance.rest to 0..2, to reflect the meaning on of the invariants. I've tried to apply this once before, and got in a mess. But now I'm thinking about it again, I'm wondering whether it's actually a good idea - see this thread, for instance
Grahame Grieve (Jul 09 2018 at 07:36):
Grahame Grieve (Jul 09 2018 at 07:37):
so I wonder - maybe we should revoke the invariant rather than insisting that there can only be one endpoint per capability statement.
Grahame Grieve (Jul 09 2018 at 07:37):
@Ewout Kramer @Josh Mandel (@Andrew Marcus)
Josh Mandel (Jul 10 2018 at 16:08):
Revoking the invariant on this is fine for me -- but _some_ guidance on when/why this repeats would be helpful. In particular, if I'm a client looking to determine a server's capabilities, do I filter the CapabilityStatement.rest to look at only the ones in "server" mode, and then take the union of all capabilities I see?
Andrew Marcus (Jul 10 2018 at 17:10):
@Josh Mandel @Grahame Grieve To support our use case in GF#17408, in which a server can support multiple FHIR versions simultaneously at different endpoints, a FHIR client would need to be able to determine which FHIR versions are supported by the server and where to find the CapabilityStatement for each.
So, in this case, a client would look Conformance.rest and filter for the ones in "server" mode, then look at the version associated with each. Once it selected one it was able to work with, it would then fetch all the CapabilityStatement definitions associated with that version.
Andrew Marcus (Jul 10 2018 at 17:27):
On the other hand, each CapabilityStatement can currently only support a single version of FHIR because CapabilityStatement.fhirVersion has a cardinality of 1..1. To make this work as a solution for GF#17408, you would actually need to push the fhirVersion element down one level into the rest element.
That is potentially a viable solution, but probably more of a refactor than you'd like. It also requires each server to publish a single metadata endpoint which aggregates the metadata for all the versions they support, which can be logistically complicated for the implementor depending on the mix of technologies in play. In addition, it is not clear how to support DSTU2 as one of the versions, which has a ConformanceStatement instead of a CapabilityStatement.
Grahame Grieve (Jul 10 2018 at 22:16):
yes I think that the cross version thing isn't solved by this.
Grahame Grieve (Jul 10 2018 at 22:16):
as for mutiple end points.... I guess they'd primarily be differentiated by security?
Andrew Marcus (Jul 12 2018 at 15:01):
@Grahame Grieve yeah, security's an interesting use case. There could be several CapabilityStatement.rest endpoints with "server" mode but with different security.service values; Smart-on-FHIR, certificates, etc.
Another potential use case would be to use this to point to a GraphQL server if it were distinct from the FHIR endpoints. @Robert Winterbottom
In either case, though, the different server rest endpoints would need some attributes a client could use to distinguish between them. In https://chat.fhir.org/#narrow/stream/4-implementers/subject/GF.2317408.20-.20FHIR.20end-point.20discovery/near/163982 I show how each could include its own fhirVersion, but perhaps there are other differentiator fields as well.
Grahame Grieve (Jul 27 2018 at 00:19):
so I just committed a change that allows rest to repeat 0..*. @Andrew Marcus you can include any number of end-points now, and you can introduce your own extension to declare what version(s) the endpoints use. if that turns out to have legs, we can add it in R5
Last updated: Apr 12 2022 at 19:14 UTC
