FHIR Chat · Interview Q8 · cds hooks

Stream: cds hooks

Topic: Interview Q8


view this post on Zulip Josh Mandel (Mar 03 2020 at 22:35):

Do you think it will eventually replace some of the older internal CDS systems?

Time will tell. My generic answer about whether new standards will "replace" older approaches is: yes, but by attrition. That is to say: older systems that work will keep working, and nobody is going to rip and replace them just for fun. But as folks lauch new projects, or look to seriously overhaul existing systems, they'll gravitate toward newer and more capable (or just easier to use) standards. So this is a process that plays out slowly over time, and a new standard only "wins" over that time period if it's solving a real-world problem. I think CDS Hooks is going to meet that bar, but it's still early days. The best-equipped folks to answer this question are service developers, who today are programming against a variety of APIs in order to get their products on the market. If @Alex Tatiyants or @Kalyani Yerra or @Adam Murray (or other service developers!) have perspectives on this front, they'd be most welcome.

view this post on Zulip Kalyani Yerra (Mar 03 2020 at 23:46):

Josh Mandel said:

Do you think it will eventually replace some of the older internal CDS systems?

Time will tell. My generic answer about whether new standards will "replace" older approaches is: yes, but by attrition. That is to say: older systems that work will keep working, and nobody is going to rip and replace them just for fun. But as folks lauch new projects, or look to seriously overhaul existing systems, they'll gravitate toward newer and more capable (or just easier to use) standards. So this is a process that plays out slowly over time, and a new standard only "wins" over that time period if it's solving a real-world problem. I think CDS Hooks is going to meet that bar, but it's still early days. The best-equipped folks to answer this question are service developers, who today are programming against a variety of APIs in order to get their products on the market. If Alex Tatiyants or Kalyani Yerra or Adam Murray (or other service developers!) have perspectives on this front, they'd be most welcome.

I agree with @ Josh Mandel that “older systems” that work will keep working, and nobody is going to rip and replace them. But as we work on new CDS Content, we create additional adapters/wrappers to expose the CDS content. Basically, the CDS logic is developed with our domain and we create wrappers/adapters to interact with the CDS clients. Some examples of the adapters would be CDS-Hooks adapter, Epic BPA Adapter etc. We also look at the following criteria to determine the best choice of when to use the standard.
1. Does the new CDS content benefit the clinician during the clinical workflow. Ex: Does this content need to show up during ordering or patient view etc or can be content be reviewed / viewed at leisure
2. Does the customer EHR support the needed standard and integration points(hooks).
3. Is there additional data needed for the CDS logic available in the EHR that can be acquired by the standard. (FHIR, pre-fetch etc)
4. Is there additional cost and implementation needed because of the standard?

view this post on Zulip Isaac Vetter (Mar 11 2020 at 04:51):

Do you think it will eventually replace some of the older internal CDS systems?

I fully expect that CDS Hooks will replace some existing CDS integrations, for all the reasons laid in Q1 including the increase in capability and security.


Last updated: Apr 12 2022 at 19:14 UTC