Stream: cds hooks
Topic: Multiple hooks per service?
Ville Lindholm (Jun 01 2017 at 07:50):
Hi guys! There's a lot of info sources, this chat and github etc, so this may have been asked before: what is the rationale between only having one hook per service? I would find it logical to provide multiple hooks under the same theme or "umbrella", i.e. the CDS service.
Ville Lindholm (Jun 01 2017 at 07:55):
My case is that we are implementing decision support for a national self-care service, i.e. the user fills out a questionnaire that asks for symptoms, and this (potentially together with publicly available EHR data) is sent to us and we provide directions for self-care and for seeking professional help if it is needed. It would be nice to have all the hooks under e.g. a 'self-care' service :)
Grahame Grieve (Jun 01 2017 at 09:08):
what do you mean, all under one service?
Ville Lindholm (Jun 01 2017 at 09:19):
As far as I can understand, cds-services lists all the available services, returning each service (i.e. rest endpoint) and the hook name corresponding to that service
Ville Lindholm (Jun 01 2017 at 09:19):
and hook name != service name
Ville Lindholm (Jun 01 2017 at 09:20):
but I haven't seen any example of a service, i.e. endpoint, supporting multiple hooks.
Ville Lindholm (Jun 01 2017 at 09:21):
is it as simple as cds-service returning the same endpoint multiple times, with different hook and parameter values?
Ville Lindholm (Jun 01 2017 at 09:21):
cds-services*
Brett Esler (Jun 01 2017 at 15:12):
Each CDS hooks server can have a list of 'services' each of which has it's own endpoint based on the base url of the server e.g. two 'services' listed https://oridashiquickhooks.azurewebsites.net/cds/cds-services - this means there are two endpoints to call with the specified pre-fetch data - the 'hook' value is the context when to make the call
e.g. for this server endpoints are https://oridashiquickhooks.azurewebsites.net/cds/cds-services/redbook-7 and https://oridashiquickhooks.azurewebsites.net/cds/cds-services/redbook-8
Brett Esler (Jun 01 2017 at 15:13):
is that the sort of thing you are meaning? the 'hook' would not need to be thesame type ; and can see the prefetch content can be different for each service
Ville Lindholm (Jun 01 2017 at 15:42):
I was actually thinking about it the other way around, that I would have one endpoint (i.e. service) which would support multiple hooks. In your example e.g. 'redbook-7' could support both 'patient-view' and 'medication-prescribe' hooks.
Ville Lindholm (Jun 01 2017 at 15:42):
So I was wondering if it was kosher to list the same endpoint multiple times in 'cds-services', only with different hook names and prefetch contents.
Ville Lindholm (Jun 01 2017 at 15:46):
I can of course just name the endpoints e.g. 'redbook-7-patient-view' and 'redbook-7-medication-prescribe' or whatever but that's not very aesthetic :)
Kevin Shekleton (Jun 01 2017 at 18:36):
@Ville Lindholm - While it is true each CDS Service is associated with a single hook, you can (under the covers as an implementation detail of your server) simply have multiple endpoints for your "uber" service, each of which is associated to whatever hook you want
Ville Lindholm (Jun 01 2017 at 18:53):
Not sure what you mean. I'm a bit lost as to the hierarchy between services and hooks. Why is there only one hook allowed per endpoint? My first thought would be that the hook is the "verb" and the service is the context for that verb. I would like to apply that same context to many verbs.
Without going into details, my plan was that one service would equal one vendor, and every vendor would have access to the same set of hooks on their own endpoint, with the hook's prefetches and results tailored for their specific needs.
Brett Esler (Jun 02 2017 at 00:06):
I think setting the 'hook' element on a 'service' to whichever hook type you would like i.e. same or different - then calls are made into the appropriate 'service' at the appropriate trigger point... the 'id' is whatever it is so don't see that being that important (?) - so I think of it as an endpoint {baseUrl}/cds-services and the call {baseUrl}/cds-services/{id} is a call to that endpoint with an 'id' parameter (RESTful) - which is how i've implemented it also
Brett Esler (Jun 02 2017 at 00:10):
each service entry is a self contained definition of - appopriate time to trigger (hook); which data to provider up front (prefetch); an identity to reference (id) + descriptions (name, description)
each cds service call is done at appropriate hook trigger point and contains the id of the 'service' you are invoking
Brett Esler (Jun 02 2017 at 00:14):
granularity of the service is up to the cds provider i.e. I could put all of the chapters of my preventative care guidelines into one call with a lot of prefetch data; or split to have one call per chapter (which is as per my example site);
Brett Esler (Jun 02 2017 at 00:17):
I guess multple 'hook' elements would be something to think about for 'services' definitions i.e. same cds calls at multiple trigger points? although this becomes just a definition/discovery issue - as multiple service defintions can be routed through to a single processor for implementation anway...
Last updated: Apr 12 2022 at 19:14 UTC
