seanmsmith23
commented
7 years ago I don't fully understand the use case here, so can't speak to whether the HTTP header is fine-grained enough, but given the simplicity of doing an optional HTTP header - I think it sounds good if someone believes it to be useful.
In discussion with @brynrhodes and @isaacvetter regarding aligning Clinical Reasoning and CDS Hooks, one of the topics of discussion was around ServiceDefinition.date.
ServiceDefinition is comparable to an individual CDS Service defined within the Discovery endpoint. ServiceDefinition supports an optional field,
date, which allows the developer to indicate when changes are made to the underlying service. The intended use of this field is for tooling utilized by organizations to configure CDS services within their workflow, providing users with visibility to changes within the service.When discussing whether a similar concept made sense to support within CDS Hooks, we looked at existing concepts with the HTTP spec which may fill this gap. We landed upon the Last-Modified (see also rfc2616) HTTP response header which can be used to indicate when changes were made to a resource.
Using the Last-Modified header doesn't provide a direct corollary to ServiceDefinition.date as it is more coarse-grainted. The Last-Modified value would apply to all CDS Services within the Discovery endpoint whereas ServiceDefinition.date is specific to an individual CDS Service. However, using Last-Modified allows us to take advantage of native HTTP features and there wasn't a strong opinion the fine-grained model was necessary.
In order to move forward with this, we would document that CDS Server providers can optionally populate the Last-Modified header and update it when changes are made to their CDS Services. EHRs can then use this value to know when changes have occurred.
As always, feedback from the community is welcome!