Stream: cds hooks
Topic: Processing Suggestion Cards
Bo Dagnall (Jul 26 2017 at 14:27):
Hi there. I am working with Bryn Rhodes on a health platform that engages a CDS service using CDS Hooks. I don't have a specific use cases necessarily. I am wondering if there is a pre-defined taxonomy of suggestion card types that could be used for downstream processing to determine how a suggestion should be handled? I can imagine that some suggestions are urgent and should be routed to a provider or patient through a real-time messaging system. Other suggestion cards might be stored and only shown when someone actively logs into the system. Who receives the suggestion card, when they receive it and through which communication channel they receive it could all be based on the suggestion card type. Thanks!
Grahame Grieve (Jul 26 2017 at 16:10):
this is a confusing question because the assumption is that there's a user seeing the cards immediately and acting on them
Kevin Shekleton (Jul 26 2017 at 18:33):
Hey @Bo Dagnall. Currently, our use case within CDS Hooks has been focused on an interactive/synchronous hook between a user in the EHR and the CDS Service. In other words, when the CDS Service returns cards the expectation is that the EHR is rendering them and displaying them to the current user.
The use case you're describing sounds like an asynchronous hook where there isn't necessarily a user in context. This is a use case we're interested in exploring but we haven't put much thought into it just yet. :/
Bo Dagnall (Jul 26 2017 at 19:08):
Thanks Kevin. You are right that we are targeting an asynchronous use case. We are taking a platform approach to health interoperability and interacting with EMRs and other systems as either data consumers or data producers. As such, it is not obvious to our platform what action should be taken for different types of suggestion cards. If you have thoughts on this, perhaps we can set up a time to chat. Thanks
Kevin Shekleton (Jul 26 2017 at 19:09):
Are you coming to the upcoming HL7 Connectathon in San Diego this Sept 9-10?
Bo Dagnall (Jul 26 2017 at 19:11):
Are you coming to the upcoming HL7 Connectathon in San Diego this Sept 9-10?
Yes. We are working with Aaron Seib to define the use case for the Consumer Centered Data Exchange track.
Kevin Shekleton (Jul 26 2017 at 19:12):
Cool! Are you planning on participating in the CDS Hooks track there? Is so, please add your name to our tracking list. We can talk more about asynchronous hooks there
Bo Dagnall (Jul 26 2017 at 19:28):
Cool! Are you planning on participating in the CDS Hooks track there? Is so, please add your name to our tracking list. We can talk more about asynchronous hooks there
I will definitely look at that. CDS Hooks is only par of the work we are doing, so active participation from us may depend on how many people I am able to send to the Connectathon. Thanks for the offer though.
Dave Carlson (Jul 26 2017 at 20:19):
Hey Bo, will you be at the HSPC meeting in D.C. next week? I am also interested in your use case and maybe we can discuss then, in preparation for the HL7 connectathon.
Bryn Rhodes (Jul 27 2017 at 22:51):
@Grahame Grieve @Kevin Shekleton for this use case, because we have control of both ends of the pipe we are looking at extending to support the asynchronous and the routing use cases. I was thinking we would take a cue from specs like InfoButton and DSS that have elements for this and adding something that would indicate "recipient" and possibly "urgency".
Grahame Grieve (Jul 27 2017 at 23:00):
the second is what is Card.indicator is. The first... you're going to need a lot more overhead around life cycle management... heading toward a resource for CDS response...
Bo Dagnall (Feb 02 2018 at 18:03):
Revisiting this thread after a long gap..... we are making progress implementing our CDS hooks interface to @Bryn Rhodes CDS Service. As stated above, our product is middleware that offers a layer of abstraction between the clinical data sources (e.g., EMR backends) and the end-user interface (EMR frontends or SMART on FHIR apps). As such, we do not have a session with the end user of the system that is querying us for data and therefore have no one to return a CDS suggestion card to. In the short-term, we have a basic data viewer useful for visualizing the data we provide that can be used to at least see CDS alerts, notifications, suggestions, etc. However, the longer term answer needs to be workflow aware. We need to think about a taxonomy of CDS suggestion types that we can use to determine how and who to route suggestions to asynchronously. @Julie Scherer, @Bryn Rhodes and I discussed this at HL7 this week and have some initial thoughts on how to do this using some workflow models that Julie has. However, this seems like an area that the standards group should weigh in on.
Bo Dagnall (Feb 02 2018 at 18:06):
Revisiting this thread after a long gap..... we are making progress implementing our CDS hooks interface to @Bryn Rhodes CDS Service. As stated above, our product is middleware that offers a layer of abstraction between the clinical data sources (e.g., EMR backends) and the end-user interface (EMR frontends or SMART on FHIR apps). As such, we do not have a session with the end user of the system that is querying us for data and therefore have no one to return a CDS suggestion card to. In the short-term, we have a basic data viewer useful for visualizing the data we provide that can be used to at least see CDS alerts, notifications, suggestions, etc. However, the longer term answer needs to be workflow aware. We need to think about a taxonomy of CDS suggestion types that we can use to determine how and who to route suggestions to asynchronously. @Julie Scherer, @Bryn Rhodes and I discussed this at HL7 this week and have some initial thoughts on how to do this using some workflow models that Julie has. However, this seems like an area that the standards group should weigh in on.
Hey @Jerry Goodnough, is this kind of workflow management and async communication something that has been considered in the SOA workgroup?
Grahame Grieve (Feb 02 2018 at 18:08):
it sounds like you just shouldn't be using cds-hooks for this use case
Bo Dagnall (Feb 02 2018 at 18:11):
it sounds like you just shouldn't be using cds-hooks for this use case
Really? I don't think we should limit CDS Hooks to synchronous connections. This async pattern seems to me like a logical extension of the current state. If I am wrong, what do you suggest as an alternative?
Grahame Grieve (Feb 02 2018 at 18:16):
the purpose of it is UI integration. You're saying you don't have a UI - so that's why I think it might not be the right approach for your problem
Bo Dagnall (Feb 02 2018 at 18:24):
the purpose of it is UI integration. You're saying you don't have a UI - so that's why I think it might not be the right approach for your problem
IMO: the purpose shouldn't be limited to just UI integration. CDS-as-a-Service accessed through CDS Hooks has broader applicability and CDS in general isn't always synchronous. In a system-of-systems architecture, we have to allow for different pieces of the ecosystem to gain access to core capabilities like CDS within the operating model and workflow they support.
Grahame Grieve (Feb 02 2018 at 18:25):
cds-hooks is for UI. There's a related specification for back-end CDS integration like what you are doing. @Bryn Rhodes for further comment
Bo Dagnall (Feb 02 2018 at 18:29):
OK. We have been working with Bryn but this idea of using something other than CDS Hooks for our backend integration has never come up. I look forward to learning more about it. Thanks
Bryn Rhodes (Feb 02 2018 at 18:43):
GuidanceResponse is the resource that we're thinking would support this. There are three main areas we're working on 1) How is it triggered, 2) What does the call look like, and 3) How do we support routing the response
Kevin Shekleton (Feb 02 2018 at 19:13):
Hi @Bo Dagnall - currently with CDS Hooks, our focus is squarely on synchronous, UI based CDS to a user. We have discussed asynchronous event based CDS as a future focus but have not yet determined when we'll tackle that.
Bo Dagnall (Feb 02 2018 at 19:15):
Good to know @Kevin Shekleton . We are pushing ahead with our work with Bryn. We are happy to share our findings and outcomes with the group but I respect your current scope position. That said, if things change and there is community interest in this work please let us know.
Kevin Shekleton (Feb 02 2018 at 19:18):
There is definitely community interest in this use case (I've heard it from lots of folks). Based on this, I'm confident we'll get consensus to explore this use case in the spec. Right now, we want to keep the scope as-is in order to get a first release out :smile:
Last updated: Apr 12 2022 at 19:14 UTC
