Stream: cds hooks/github
Topic: docs / Issue #90 Temporal aspect of the response
Github Notifications (Sep 10 2017 at 00:04):
robs16 opened Issue #90
(pulled from #55)
The temporal aspect of the response needs to be well thought out. To my understanding there are no rules and no documentation which states that the result of the CDS request is valid for a limited amount of time. Depending on the EHR workflow and where the CDS request is executed, it may not be unusual for the card to take some time (hours) before it is utilized. However, taken to an extreme, the cards and all contained data could be expected to be valid literally forever. This is also compounded by the re-triggering functionality to obtain the current state.
For the CDS Service this means it must maintain hook instance state for an unlimited amount of time. It also negatively impacts the security of the resulting integration.
I don't think this is the intention, so there needs to be documentation which defines theses constraints and/or provides them within the API. As a solution, I propose that per card or perhaps at the response level there is a required field which defines the expiration time of the contained data. It might be also useful/necessary to have the EHR define in the request how long they need the CDS service to maintain state for the provided hookInstance.
Github Notifications (Sep 10 2017 at 13:24):
The CDS service could provide the HTTP 'Expires' header in the cds response to indicate how long the content of the response is valid.
While it might be possible to put such metadata in the discovery endpoint, I believe there are cases where the expiration is based on the particular request. Taking a simple example, a result with no cards (successful) may have a different expiration than one with cards presented to the user.
This value may also be different for each consumer based on expectation negotiated out-of-band.
Ultimately for the CDS service it should be a requirement to provide content expiration. The EHR must understand that content expires and the CDS service provides this expiration, but it is up to the particular EHR's implementation to determine how to handle data refresh.
Github Notifications (Sep 10 2017 at 18:48):
kensaku-kawamoto commented on Issue #90
It would be useful to know how EHR systems currently handle this. Could EHR vendors respond with their current approach? From an EHR client/healthcare system perspective, I think it would be confusing if some CDS (those supported by CDS Hooks) behaved one way, while others behaved another way. Because in many cases, from the provider perspective, they can't tell the difference. This may cause a safety issue if healthcare providers now EXPECT for this expiration notion to be in place, but that non-CDS Hooks CDS content don't expire. I think if the expiration notion is supported, it needs to be supported globally within a given EHR system.
Github Notifications (Sep 12 2017 at 17:59):
brynrhodes labeled Issue #90
Github Notifications (Sep 12 2017 at 18:00):
brynrhodes unlabeled Issue #90
Last updated: Apr 12 2022 at 19:14 UTC
