Stream: cds hooks
Topic: design
Kevin Shekleton (Jan 13 2016 at 16:23):
@Josh Mandel - how important is ensuring that CDS Hooks fits into the FHIR design model? The reason why I ask is because by making CDS Hooks fit into the FHIR design, it affects several things: the URI ($cds-hook), request/response (Parameters resource), and advertising capabilities via Conformance. While I understand the desire & value to communicate prefetched data as FHIR resources (I agree this is a good thing), I'm struggling to understand the value in coupling the rest of the CDS Hooks design with FHIR's model/design.
Kevin Shekleton (Jan 13 2016 at 16:25):
Decoupling from FHIR would allow for much cleaner and easier requests & responses, more straightforward advertising of capabilities by CDS services, and the notion that a CDS service is itself a FHIR server (albeit, potentially a much more narrow server)
Kevin Shekleton (Jan 13 2016 at 16:27):
However, if this is important to you, that's fine. I just want to understand where the value lies. I get the value in communicating the prefetched data via FHIR and re-using the same SMART/FHIR authorization model, but I'm not seeing the value in going all in with FHIR
Kevin Shekleton (Jan 13 2016 at 16:28):
Admittedly, many of my reservations are due to my dislike of the FHIR modeling (Parameters resource)
Josh Mandel (Jan 13 2016 at 16:31):
Well, I think it's important to ask the question. Certainly my life would be easier without Parameters, etc. But at the Connectathon keep in mind that several devs were using FHIR libraries (e.g. In Java) that were a big help.
Kevin Shekleton (Jan 13 2016 at 16:34):
I'm not convinced that dropping Parameters in favor of a more simple/tailored request/response model would affect developer productivity or the success of CDS Hooks
Kevin Shekleton (Jan 13 2016 at 16:36):
If necessary, we could provide similar OSS libraries for developers to handle the serialization code and provide language specific models to work with
Kevin Shekleton (Jan 13 2016 at 16:42):
Coupling all of CDS Hooks to FHIR also concerns me as FHIR evolves. So, as the generic Parameters resource evolves, this will affect CDS Hooks. We could mitigate this by defining our own tailored FHIR Resource rather than using the generic Parameters resource. By the same token, changes to Conformance will affect CDS services
edit: testing editing
Kevin Shekleton (Jan 13 2016 at 16:49):
With all of this being said, I'm just trying to gain a better understanding of where your head was at. :) If you feel strongly about keeping things as-is, I'd just like to understand the value we're getting. If we're open to evaluating this, I'm happy to work on other proposal to the current design on aspects like the request/response, alternatives to conformance/prefetching, etc
Josh Mandel (Jan 13 2016 at 18:33):
I think the "value of FHIR" piece is worth discussion on Google groups. Frankly the branding/enthusiasm angle of it is important, but obviously there are degrees of "using FHIR".
Kevin Shekleton (Jan 13 2016 at 18:33):
Ok, I can start a post on the Google group about all of this
Josh Mandel (Jan 13 2016 at 18:34):
Cool! Thanks.
Kevin Shekleton (Jan 13 2016 at 20:02):
I posted a Google group discussion on this topic: https://groups.google.com/d/msg/cds-hooks/frHmx2VCvIE/TEWxUXLzEwAJ
Josh Mandel (Jan 14 2016 at 17:26):
I think we've heard two suggestions for making CDS Hooks interactions lighter-weight:
1. Conformance as simple JSON data
2. Parameters as simple JSON data
... and the question then becomes, can/should FHIR explicitly introduce support for such things.
Kevin Shekleton (Jan 14 2016 at 17:28):
Later today / tonight I'll post my proposal for handling conformance and the CDS service URIs (currently an operation) via my Google group discussion
Kevin Shekleton (Jan 14 2016 at 19:02):
So in talking with Bryn over lunch today, I thought of a (what I think is) a good analogy around SMART apps and CDS on FHIR's DecisionSupportModle's parameters. SMART apps have the exact same need as DecisionSupportModules with respect to declaring the FHIR resources and attributes they need.
With SMART, there is no declarative model for this information; rather, this information is communicated in documentation or verbally between the EHR and app. In spite of this, SMART has flourished and as someone who has spent a lot of time working on integrating many different SMART apps into my EHR, I can say that this lack of declarative model has not been a hinderance to our implementation or adoption of SMART.
However, with CDS on FHIR, they are trying to model these data requirements declaratively. While that is an admirable goal, I don't see it as being required and think that successful adoption is predicated on having such a declaractive model. One of my concerns with CDS on FHIR is this declarative model and it's complexity for implementors.
What does this have to do with CDS Hooks? I like that this isn't a strict requirement right now on the prefetching of data. I think CDS Hooks will be adopted and successful without such a model. And, since you were in the last quarter on this topic, Josh, I thought you might be interested in this analogy.
Josh Mandel (Mar 12 2016 at 03:37):
I'm starting to put together details for our initial sprint call next week:
https://github.com/cds-hooks/cds-hooks-wiki/wiki/Sprint-Program
Josh Mandel (Mar 12 2016 at 03:38):
I've documented a $cds-hook-metadata operation to expose a hooks basic details (name, description, trigger activity, preFetch requirements)
Josh Mandel (Mar 12 2016 at 03:38):
I've also written up a few tasks where contributions would be especially welcome: https://github.com/cds-hooks/cds-hooks-wiki/issues
Josh Mandel (Mar 12 2016 at 03:39):
We need more of these, but the basic idea is that, unlike in Argonaut sprints where we're really just asking for implementation activity, here I'd like to see if we can get the community engaged in actually building the spec, with test tools, infrastructure, etc. (I wish I had time to do all this myself :-))
Josh Mandel (Mar 12 2016 at 03:40):
Thoughts welcome in advance of the call, of course (especially @Kevin Shekleton , since I know you've been thinking about this)
Kevin Shekleton (Mar 12 2016 at 03:42):
Thanks, @Josh Mandel. I'll review this over the weekend and respond
Kevin Shekleton (Mar 12 2016 at 03:43):
I also really need to respond to @Grahame Grieve's email from several weeks ago. I am so behind in several things… :-(
Grahame Grieve (Mar 12 2016 at 07:21):
yeah you do. The current build includes a definition of cds-hooks, and I'm generating my code from that now
Kevin Shekleton (Mar 17 2016 at 06:53):
@Josh Mandel - I think you've got a great start on the sprint program. I'm a huge fan of your suggestion for getting the community to build tools and contribute towards the documentation.
Kevin Shekleton (Mar 17 2016 at 06:59):
I actually have a Rails app that returns test cards that I used for my own testing. I need an excuse to start open sourcing my work on CDS Hooks and I'd be happy to start with this to help on issue #1
Grahame Grieve (Mar 17 2016 at 10:48):
hey - the calls are not at a time I can join - and I'm probably not the only one - can someone dump a short precis of things here?
Kevin Shekleton (Mar 17 2016 at 12:36):
Absolutely -- I'll take notes and post them to Github and then link that here
Kevin Shekleton (Mar 17 2016 at 12:37):
@Grahame Grieve - Generally speaking, what times do you prefer calls?
Josh Mandel (Mar 17 2016 at 14:46):
FWIW, it's not "calls" -- it's just one call so far. We don't have an ongoing schedule. Would love to figure out a time when you're available, @Grahame Grieve .
Kevin Shekleton (Mar 17 2016 at 17:04):
Yeah, that's why I asked Grahame what times he prefers. I figure we can schedule recurring calls that are more amenable to his (and other non-US) schedules :)
Josh Mandel (Mar 17 2016 at 17:27):
We'll need to see who wants to participate. International synchronous scheduling is hard!
Grahame Grieve (Mar 17 2016 at 18:09):
well, I don't do calls between midnight and 5am. but the time slots between 5am and end of us business are relatively full
Grahame Grieve (Mar 17 2016 at 18:50):
hah turns out I did at it to my calendar, and will be there a little
Last updated: Apr 12 2022 at 19:14 UTC
