Stream: cds hooks
Topic: Advanced Scenarios
Wolfgang Wiessler (Nov 14 2017 at 15:06):
Hello,
we are implementing an EHR-type application and are currently looking into dynamically handling integration with 3rd party CDS services. We started adopting CDS Hooks and that works well so far in a strongly defined context. As we are thinking about more advanced use cases, we are struggling with matching CDS Hooks to those use cases.
The basic scenario is that for a particular hook type (e.g. "treatment-recommendation") we have various vendors that can provide support (I call them "CDS Providers") and within each vendor, they offer several services ("CDS Services"). For example, one 3rd party has 3 services for lung cancer patients (one predicting outcome, the other offering treatment selection support, etc.) and 2 services for Head and Neck cancer. Another 3rd party has various other combinations of services based on certain inclusion/exclusion criteria.
Use Case 1: Semantic filtering
We only want to show the user CDS services that make sense in the current EHR context. E.g. a lung cancer patient should not be offered H&N-specific services.
The discovery mechanism does not seem to lend itself to that since it is a simple GET call without passing any context that the CDS Provider could use to narrow down the responses.
We could use the normal CDS Service call. The CDS service would then return x App Link Cards with links to context-matching apps? The links to the apps are very basic though and there is no way to provide additional prefetch instructions for each specific service. In this case we would be using the CDS Service to discover the actual CDS Services.
Use Case 2: Admin-level, preselection
CDS Providers often have "several flavors" of algorithms for the same questions (e.g. guideline1, guideline2, guidelineX for breast cancer). A hospital typically decides to go with one particular guideline and does not want their users to see the other options when requesting the decision support within a patient context.
How would we go about that using CDS Hooks? At admin-time, there is no patient context. We would be able to create a general context (e.g. show me all available services for lung cancer patients older than 65 and female). When we get the response from the CDS service, we are not asking for actual decision support, just for a list of CDS Services that match the context. In order for the admin to select which services should be available at the point of care.
The question that I keep circling around is:
If a vendor has several services for the same hook type, do we register one CDS Service for that vendor OR do we register one CDS Service per vendor service category? E.g. One "VenderX" service that figures out the details during the user interaction OR one "VendorX-LungCancer" and one "VendorX-H&NCancer" service? In the latter example, where you draw the line seems arbitrary.
CDS Hooks seem to be very user-interaction focused. Which makes it hard to do some preselection without the user.
I hope I could express my thoughts and the challenges properly. I have a few more items to cover. Just want to get the conversation started.
Any feedback would be greatly appreciated!
Kevin Shekleton (Nov 15 2017 at 20:59):
Hi @Wolfgang Wiessler and thanks for the detailed and well thought out message. There is a lot to unpack in your message and I will try and provide my opinion & answers to all of it.
Kevin Shekleton (Nov 15 2017 at 21:18):
Our current Discovery endpoint is not intended to allow for complete dynamic programmatic configuration/filtering like you describe in your use cases. We were just trying to limit scope here for the 1.0 release. Additionally, we assumed that most EHR vendors who offered this type of dynamism in how CDS Hooks is integrated in a deeper contextual manner like you described is done via other, proprietary processes.
Kevin Shekleton (Nov 15 2017 at 21:22):
For instance, speaking for Cerner's EHR, we provide the client/customer (aka, the healthcare organization) the ability to customize their workflow by role, clinical context, etc. As such, we plan to allow the healthcare organization to leverage this same existing flexibility with our EHR configuration to configure the desired CDS Services that should be invoked.
In this case, the Discovery endpoint is not used solely to determine which CDS Services are integrated into each unique workflow. Instead, the Discovery endpoint is used merely as a means to obtain the set of available CDS Services the administration can configure in their workflow.
Wolfgang Wiessler (Nov 16 2017 at 10:13):
Hi @Kevin Shekleton , thanks for your response! That definitely helps me in categorizing what CDS Hooks are and are not and aligns with my interpretation of it and experience so far. My understanding is that there currently is no standard out there that supports fully dynamic programmatic discovery/filtering. CDS Hooks play a role once the user or context narrowed down the scope. How that "narrowing down" is done, is up to the EHR.
Our goal is to come up with a system where we can tell 3rd parties: If you implement standards XYZ (e.g. CDS Hooks for your service and Smart on FHIR for your app), we can seamlessly integrate your services without any development effort required from our side and your services only show up where it makes sense from a semantics/workflow perspective. Looks like we need to go with a mix of proprietary frameworks and standards.
Kevin Shekleton (Nov 16 2017 at 10:34):
I think it is a great goal to shoot for that eventual end state! -- The ability to streamline and remove any proprietary filtering/configuration in the EHR with respect to the CDS Services that it integrates.
From my experience, the hospitals want ultimate control over which decision support to integrate and where in the workflow it should be. This in effect means that the hospital is defining (via policy + configuration) when & when CDS Services are called in the workflow.
Wolfgang Wiessler (Nov 16 2017 at 12:19):
I am 100% with you that there will always be human interaction and configuration to customize a solution to a hospital. I am just looking for ways to make it easier for the customer to find and configure the services they are interested in and to ease the burden on the EHR development. In the near future there will be 100s or 1000s of support services for all kinds of scenarios. A standard for discovering what services semantically match my problem/"what I am l looking for" would be very useful.
I understand that this is currently out of scope and am looking forward to what the future will bring.
Kevin Shekleton (Nov 16 2017 at 20:51):
Understood. Before we get to 100s or 1000s of CDS Services we will definitely need to make this particular feature a priority! :smile:
Last updated: Apr 12 2022 at 19:14 UTC
