search

cds-hooks / docs

CDS Hooks website & specification
http://cds-hooks.org
Apache License 2.0
167 stars 61 forks source link

Temporal aspect of the response #90

Open robs16 opened 7 years ago

robs16 commented 7 years ago

(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.

robs16 commented 7 years ago

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.

kensaku-kawamoto commented 7 years ago

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.