Stream: implementers
Topic: Wrapping Cloud Providers and Definition of Implementer
James Nicolas (Feb 18 2022 at 01:25):
I have an architectural question around using a cloud provider's managed FHIR server to support our own implementation of FHIR. Managed FHIR servers are great because they provide most of the functionality that we need out-of-the-box. However, our current cloud provider's FHIR server doesn't support the ability to define operations with arbitrary business logic. My question is, does it make sense to implement custom operations in a wrapper around the cloud provider's FHIR server? I've seen other implementers simply fork an open-source reference implementation and add their custom operations that way, but then we'd lose a lot of the speed and scalability that the managed FHIR server guarantees. And possibly related, but I was also looking for the definition of 'implementer' to know if people who put wrappers around an existing FHIR server are still 'implementers', as this word pops up in the spec a lot, and I can't tell if when 'implementer' is used, it applies to us.
Lloyd McKenzie (Feb 18 2022 at 05:18):
"implementer" is just someone who builds a system that complies with the spec. It is not dependent on architectural approach or your place in it. If you write code or configure systems to use FHIR in any way, you qualify as an implementer. I'll leave it to others to respond to your specific architecture question.
René Spronk (Feb 18 2022 at 07:49):
In the FHIR community the two main relevant groups are 'modellers' (who create FHIR profiles, FHIR IGs, the FHIR spec itself) and 'implementers' who 'use/implement' those specs. So the definition is a pretty wide ranging one.
As for defining your own FHIR API wrapper on top of some sort of FHIR backend: we've seen plenty of such implementations. Whether they're a good idea or not from an architectural standpoint, that's another discussion.
Josh Mandel (Feb 18 2022 at 15:06):
It sounds like you've correctly identified a set of options and trade-offs. If I might turn the question around: what would your ideal contract look like in terms of the split of responsibility and interactions between a managed service and your own flexibility to extend? Are there services that you would point to as getting this balance right?
(Outside of FHIR, I think Kubernetes does a good job of this -- e.g. https://kubernetes.io/docs/concepts/extend-kubernetes/operator/#writing-operator)
Last updated: Apr 12 2022 at 19:14 UTC
