Stream: cds hooks
Topic: Version info / How to tell where to find user?
Matt Varghese (Oct 01 2018 at 17:43):
It sounded like there has been some discussion around whether the "user" should be a top level JSON property, or whether it belongs in context. And it sounded like the lean was towards context. @Kevin Shekleton mentioned this will soon be updated in the spec.
We have released production support for patient-view hook with the "user" at the top level. When we move this to within context, and either back-port the change, or a customer upgrades to a version where the user is now in context and not at the top-level, how will CDS vendors on the other end know?
Will the spec version or something about it be updated, especially as 1.0 has not passed ballot?
And even then, the spec version is not part of the CDS Hooks request. Are there plans to include it?
Kevin Shekleton (Oct 01 2018 at 17:48):
It's not just that we are leaning towards moving user to the context object -- we actually voted and approved that change. So, it is definitely happening. :-) Also, the 1.0 spec has passed ballot but we just haven't published the 1.0 spec yet.
We deferred including a version in the API until at which point in time it was necessary to do so (which would be -- if we need it at all -- after 1.0).
Matt Varghese (Oct 01 2018 at 17:52):
So any recommendations on what I can do right now?
Matt Varghese (Oct 01 2018 at 17:56):
Also, is there any reference to the deferral of including versions in the API? I would like to add myself to that thread, since I am impacted because it was differed.
Robert Sax (Oct 01 2018 at 17:58):
from my perspective, when you start doing this in production, supporting multiple versions becomes inevitable. Coordinating all current customers in an upgrade of the spec is time consuming/costly and often of little value to them. Therefore you should probably consider how you want to support multiple versions concurrently. There is nothing in the spec that provides this, so I guess you roll your own as Stanson has.
Isaac Vetter (Oct 01 2018 at 17:59):
And until the publication process for CDS Hooks 1.0 is finalized, we should all expect the possibility of breaking changes.
Matt Varghese (Oct 01 2018 at 18:02):
@Robert Sax are you able to share any details of your solution?
Robert Sax (Oct 01 2018 at 18:08):
There are a number of different approaches which work (url-based, different hook ids, headers, etc). Our approach is to use a URL prefix to differentiate between the versions. Ultimately you want the solution you choose to allow the addition of new cdshooks versions without impacting existing versions, and allow the customers to move on their schedule without having to do any significant coordination.
Matt Varghese (Oct 01 2018 at 18:11):
Ok - I can develop a custom solution. However, if we have thoughts on what the spec solution would be is what I was looking for.
Since if we develop something custom, then that may not align with the spec. Whereas, if we have thoughts on where the spec will go, I can try to align what we develop with it, so when the spec finalizes version, we can be compliant with minimum changes. That was the reason behind the ask.
Robert Sax (Oct 01 2018 at 18:13):
So I look at this from the service provider side, but it appears you are on the EMR side. I guess on the EMR side, I would maintain configuration about each service which includes the spec version even if it is not strictly within the discovery endpoint.
Robert Sax (Oct 01 2018 at 18:21):
There was a longer discussion in https://github.com/cds-hooks/docs/issues/74, but no outcome
Matt Varghese (Oct 01 2018 at 18:22):
I see what you are suggesting. However, I fear that would not be scalable, especially when I cannot store a version against the endpoint. I guess my take will have to be, while CDS Hooks is still not sending a version, the onus will be on the CDS Service to figure out - for example, look for version in both places. I was trying to see if there was a more elegant option that can be implemented without a lot of cost around it.
Matt Varghese (Oct 01 2018 at 18:22):
Thanks for the pointer to the discussion.
Kevin Shekleton (Oct 01 2018 at 18:38):
@Matt Varghese - You could tie your internal Epic version of CDS Hooks with a CDS Service at registration time. So, when you guys implement the released 1.0 specification, when you register a CDS Service you can capture if that service understands the 1.0 spec or the internal Epic pre-release spec that you went live with. Depending on this you can flex your behavior for where user is sent in the request.
Another thought - do you have the ability to ship changes/patches? If so, can you simply ship an update to populate context.user? Or, populate both request.user (what you're doing today) and request.context.user (1.0 spec) and inform developers that in the next release, you will be removing request.user?
Matt Varghese (Oct 01 2018 at 18:43):
@Kevin Shekleton, sure, these were also options we considered, but only if the spec doesn't give a way to do it. Meanwhile, I've added myself to the GitHub issue, and hope that a standard solution will be agreed upon, so I don't have to do something custom.
Last updated: Apr 12 2022 at 19:14 UTC
