Stream: cds hooks
Topic: cds services that are also fhir servers?
Josh Mandel (Mar 24 2016 at 23:03):
What are the use cases for having a single "FHIR server" that can respond to CDS hooks and also expose the FHIR API (with CRUD on clinical/infrastructure resources)? I understand that all other things being equal @Grahame Grieve would build both kinds of functionality into his test server. But what is the real use case? What do we stand to gain by having both kinds of functionality co-located in a single server?
Grahame Grieve (Mar 24 2016 at 23:05):
Push a bunch of clinical records to the CDS server, then ask for an opinion.
Grahame Grieve (Mar 24 2016 at 23:06):
Enhance a clinical record system - say a lab system - to offer interpretive comments on lab results as well
Grahame Grieve (Mar 24 2016 at 23:06):
mediccaion
Josh Mandel (Mar 24 2016 at 23:07):
But for both of these use cases, you could have a standalone CDS server (receiving data via preFetch, or requesting it from the source system as necessary)
Grahame Grieve (Mar 24 2016 at 23:07):
medication management system that provides workflow and also prescription advice,
Grahame Grieve (Mar 24 2016 at 23:07):
yes. You could always do that. You just increase the deplore
Josh Mandel (Mar 24 2016 at 23:07):
But again, what is the gain from hosting them in one binary, at one FHIR endpoint?
Josh Mandel (Mar 24 2016 at 23:07):
Deplore?
Bryn Rhodes (Mar 24 2016 at 23:09):
Simplicity?
Grahame Grieve (Mar 24 2016 at 23:09):
deployment surface, and the configuration and security space
Grahame Grieve (Mar 24 2016 at 23:09):
and if you start managing the metadata properly, then it will be a server of some kind anyway,
Grahame Grieve (Mar 24 2016 at 23:09):
with all the same considerations as a FHIR server
Josh Mandel (Mar 24 2016 at 23:10):
Is it "simple" though? In the "http://www.infoq.com/presentations/Simple-Made-Easy" sense, combining these use cases intertwines two kinds of functionality into a single "complex" entity.
Josh Mandel (Mar 24 2016 at 23:10):
Anyway, I'm trying to explore this space to understand what problem we're really solving here.
Josh Mandel (Mar 24 2016 at 23:10):
Thanks for the feedback.
Josh Mandel (Mar 24 2016 at 23:13):
I think the summary here is "if you already are building a FHIR server, then using FHIR to manage CDS hooks seems natural".
Grahame Grieve (Mar 24 2016 at 23:14):
Yes. And if you start trying to reproduce all the definitional infrastructure to do CDs hooks properly, then it will start to look the same....
Josh Mandel (Mar 24 2016 at 23:16):
Well, that's fair -- but just because something might "start to look [like FHIR]" doesn't mean it needs to become FHIR.
Grahame Grieve (Mar 24 2016 at 23:18):
Of course. But since it's already doing lots of FHIR content, the advantages of using the FHIR definitional layer are obvious. As are the long term advantages for when more formal standardisation is appropriate
Brian Postlethwaite (Mar 25 2016 at 00:22):
I would also want to be considering how to scale this stuff out and distribute responsibilities too (and yes we can do bus style routing behind the fhir door)
Josh Mandel (Mar 25 2016 at 00:30):
Yes. Being able to scale services independently is part of the reason I'm thinking hard about this.
Brian Postlethwaite (Mar 25 2016 at 00:31):
(assumed you were, but wanted to ensure it was explicit to others)
Josh Mandel (Mar 25 2016 at 00:31):
We want it to be easy to deploy services that can auto-scale behind a reverse proxy.
Josh Mandel (Mar 25 2016 at 00:33):
And the way we're using the FHIR operations framework is a bit cumbersome in that regard. Tacking an operation onto a custom resource would help (/CdsService/med-pricing/$invoke), or adding a path parameter to operations (/$cds-service/med-pricing), to make different services easy to route/scale by path.
Josh Mandel (Mar 25 2016 at 00:34):
(Right now the issue is we define just one operation, $cds-hook.)
Brian Postlethwaite (Mar 25 2016 at 00:39):
Have we considered a notion of doing this with other operations too?
i.e. [fhir-base]/OperationDefinition/PatientMatch/$invoke
Now that I write it, loses the context of the ResourceType, or Instance
Josh Mandel (Mar 25 2016 at 00:40):
Right - if you have resource or instance context, you're in better shape there.
Grahame Grieve (Mar 25 2016 at 01:39):
Well, I think that the custom resource pathway is the best so far identified. You might want to not miss fmg calls for the next few weeks then. Difficult discussion about custom resources there yesterday
Josh Mandel (Mar 25 2016 at 04:41):
Yes, good point! (Yesterday was AMIA in SF.)
Kevin Shekleton (Mar 25 2016 at 12:05):
My opinion and views on this are that mature/experienced organizations will likely not conflate a FHIR server and CDS service into a single deployment. I do not think this will be common deplyoment/management scenario so while I certainly wouldn't want to preclude someone from going down this path, I wouldn't want this to be primary driver/influencer behind design decisions.
By mature/experienced organization, I'm referring to:
- Large organizations (eg, enterprise)
- Teams/companies who experienced with building/deploying/managing services (eg, they likely already have services deployed today)
With many organizations embracing the architectural pattern of microservices (http://martinfowler.com/articles/microservices.html), separating the FHIR server and the CDS service would be a very natural course of action for them. Microservices are certainly buzzy right now (so I don't use the term lightly), but a microservice design has very real benefits.
Jason Walonoski (Mar 25 2016 at 17:38):
@Kevin Shekleton +1
Brian Postlethwaite (Mar 26 2016 at 06:38):
I also think that most CDS services will not be from the same company as the fhir service.
Grahame Grieve (Mar 26 2016 at 07:36):
I think you are confused between "fhir service" and "patient data provider"
Brian Postlethwaite (Mar 26 2016 at 07:39):
Just for clarity in my case was referring to that there are likely 3 components taking place, the FHIR data server, a user interface application (cds consumer) and CDS services (that are hooked together)
As is in the cds demo.
I think this will be quite normal that all 3 can and will come from different vendors/systems.
Josh Mandel (Mar 26 2016 at 14:41):
Thanks @Brian Postlethwaite! And after discussing with @Kevin Shekleton I'm convinced that this special case (a FHIR server that also exposes CDS Hooks) is unduly influencing our design thinking.
Of course some servers may want to (e.g. @Grahame Grieve's server) but it's probably unusual outside the FHIR echo chamber.
Last updated: Apr 12 2022 at 19:14 UTC
