Stream: implementers
Topic: Multiple FHIR versions
Andrew Marcus (Nov 15 2018 at 10:19):
Hi @Grahame Grieve , when you have a chance could you please post where you stuck the new extension allowing a CapabilityStatement to link to related endpoints?
Thanks! We're excited to give it a try.
For reference for others who weren't in the DevDays breakout session: this extension should allow FHIR servers that implement multiple FHIR versions at different endpoints the opportunity to tell clients where those endpoints are. This is in contrast to the $versions operator that works when there are multiple versions supported at a single endpoint.
Andrew Marcus (Nov 16 2018 at 08:02):
Hi @Grahame Grieve , for reference, this discussion follows on from this previous discussion: https://chat.fhir.org/#narrow/stream/4-implementers/subject/GF.2310205.20-.20Cardinality.20of.20Conformance.2Erest/near/164420
I would propose that the related endpoints extension have both computable and human-readable attributes, and be able to identify endpoints for several different use cases. The computable part would enable client apps to quickly identify the endpoint with the features they need.
Obviously we've been talking about different endpoints for different fhirVersions, but it could also potentially be useful to get more specific to the profile level. You'd suggested it would be useful to show which endpoints share common OAuth tokens, and I definitely agree.
Another interesting use case would be if different endpoints support different parts of the spec, such as GraphQL. For example, Asymmetrik's GraphQL server is a different codebase from the regular FHIR server because of the architecture we're using. They could co-exist on the same server, but might have slightly different endpoints.
Thanks, looking forward to seeing what you come up with.
Last updated: Apr 12 2022 at 19:14 UTC
