FHIR Chat · docs / Issue #50 Document use of Accept-Datetime HTTP req... · cds hooks/github

Stream: cds hooks/github

Topic: docs / Issue #50 Document use of Accept-Datetime HTTP req...

Github Notifications (May 15 2017 at 20:47):

kpshek opened Issue #50

In discussion with @brynrhodes and @Isaac Vetter regarding aligning Clinical Reasoning and CDS Hooks, one of the topics of discussion was around how Clinical Reasoning allows the EHR to include to the CDS service that it should evaluate it's rules at the specified date/time (evaluteAt field). This is used for testing or debugging purposes in Clinical Reasoning.

rfc7089 defines an Accept-Datetime HTTP request header to accomplish this same functional goal. In our case, the EHR would send the Accept-Datetime HTTP header in the CDS Service request. The CDS Service would evaluate it's decision support logic as of this given datetime.

Per rfc7089, the CDS Service should also return a response header in this scenario with the Memento-Datetime HTTP header set to the datetime the decision support was evaluated at.

It is worth mentioning that in order for the decision support rules to be evaluated at an arbitrary datetime, all services and systems used by the CDS Service must be capable of supporting this concept. This includes both the EHR and FHIR server who must be capable of querying FHIR resources at the given datetime.

Github Notifications (May 16 2017 at 12:08):

des4900 commented on Issue #50

Another use case for evaluating CDS at a specified date-time is for scheduling services and providers and patients for routine interventions or analysis in the future. For example, it can be used to determine that a patient needs certain lab work done in advance of an upcoming appointment, or simply that a patient needs to have a preventative appointment, and should be contacted.

Github Notifications (May 17 2017 at 22:30):

euvitudo commented on Issue #50

I would prefer evaluateAt (or some variation) to be part of the payload.

I would prefer not to have to implement RFC 7089 on the backend. Some reasons include:

• RFC 7089 is not an official standard.
• GET and HEAD are mentioned in the RFC, but POST is not, and in fact, in the context of the RFC, POST doesn't make sense, as the RFC is all about obtaining past versions of Web documents.
• Implementing this would be overly complex.

Finally, it seems relevant that a CDS Service should indicate what features it implements (much like the CapabilityStatement). If it cannot support an evaluateAt (or variation), then it simply doesn't include that in its service metadata. prefetch is already stating what it would prefer to have included in the request payload.

Github Notifications (May 18 2017 at 21:02):

yashaskram commented on Issue #50

I might be completedly off base here with my understanding of this ask.

• Is this a scenarios where CDS service provider is expected to queue up the hook request until evaluateAt ?
• How would CDS Hook service get the FHIR data at evaluateAt time? Is the expectation that the access token would live until evaluateAt + x ?
• And also how does EHR handle card response when EHR user close the patient chart before evaluateAt?

In general I agree with @Phillip Warner that it should part of the payload (from implementation efforts perspective) if we plan to have this supported as part of CDS Hook spec.

Github Notifications (Jun 05 2017 at 20:22):

kpshek milestoned Issue #50

Github Notifications (Jun 06 2017 at 03:35):

kpshek commented on Issue #50

@Phillip Warner & @yashaskram - Thanks for your thoughts / comments on this issue!

@Phillip Warner: RFC 7089 is not an official standard.

My original intention of suggesting RFC 7089 was to leverage work that had already been done for a similar concept. I realize it isn't a standard but neither is many other concepts we're designing. :-)

However, I given that RFC 7089 doesn't call out POST requests as supporting Accept-Datetime in addition to that we're only using a small portion of this RFC, I agree that we shouldn't reference RFC 7089 or use the name Accept-Datetime.

@Phillip Warner: Implementing this would be overly complex

How would a request header to the CDS Service be overly complex to read/handle? Whether it is a request header or a POST body parameter, it seems just as easy to implement IMHO. For instance, in Rails, we're talking about the difference between:

# request header
request.headers['Evaluate-At-Datetime']

# POST body param
params['Evaluate-At-Datetime']

In Java, reading a request header is also easy:

// request is a javax.servlet.http.HttpServletRequest
request.getHeader("Evaluate-At-Datetime");

// Or, if we're dealing with a connection of type java.net.URLConnection
connection.getHeaderFields().get("Evaluate-At-Datetime");

@Phillip Warner: Finally, it seems relevant that a CDS Service should indicate what features it implements (much like the CapabilityStatement). If it cannot support an evaluateAt (or variation), then it simply doesn't include that in its service metadata. prefetch is already stating what it would prefer to have included in the request payload.

Just as important if the CDS Service supports this functionality is that the EHR and more importantly FHIR server can support this functionality. We do not something akin to the CapabilityStatement today. The CDS Service definition in Discovery does describe each CDS Service, but I wouldn't equate it to a CapabilityStatement. I'd prefer to avoid venturing into that domain for the time being.

@yashaskram - This use case originally came from Ken, @brynrhodes, & @Phillip Warner's team at Univ of Utah where with Clinical Reasoning, they can evaluate CDS at a given point in time. For instance, they can answer questions like "What decision support was shown to user U for patient P last week on May 30, 2017 8:00am"? This is very cool functionality but requires the entire system to support this sophisticated date-based querying. Critically, the FHIR server must support these time based queries, none of which are support by production FHIR servers from the major commercial EHR vendors today. The Univ of Utah implementation supports it because they have built this all themselves.

@yashaskram: In general I agree with @Phillip Warner that it should part of the payload (from implementation efforts perspective) if we plan to have this supported as part of CDS Hook spec.

I also think it's important to note that this feature is going to be an edge case in that it will not see widespread adoption. I say this because in order for this 'evaluate at' functionality to be supported, the underlying FHIR server must support these types of queries. Currently, I do not know of any EHR vendor that has implemented this functionality. This is why I would prefer keeping this out of the CDS Service request body as we would be defining a new request field for something that is not widely implemented. This is why the request header was appealing to me.

@Phillip Warner - What about this revised proposal?

Evaluate-At-Timestamp - A request header specified by the EHR In the CDS Service request to indicate the timestamp used by the CDS Service as the notion of 'now'. If the CDS Service is able to honor this timestamp, its response back to the EHR must include the Evaluate-At-Timestamp header with the same timestamp value. The timestamp value is an ISO 8601 UTC timestamp using the format YYYY-MM-DDTHH:MM:SSZ

Github Notifications (Jun 06 2017 at 04:37):

euvitudo commented on Issue #50

@kpshek:

@Phillip Warner: RFC 7089 is not an official standard.

My original intention of suggesting RFC 7089 was to leverage work that had already been done for a similar concept. I realize it isn't a standard but neither is many other concepts we're designing. :-)

So you don't intend for cds-hooks to become a standard?

@Phillip Warner: Implementing this would be overly complex

How would a request header to the CDS Service be overly complex to read/handle? Whether it is a request header or a POST body parameter, it seems just as easy to implement IMHO. For instance, in Rails, we're talking about the difference between:

You take my comment out of context. What I said was a bullet point to implementing RFC 7089.

@Phillip Warner: Finally, it seems relevant that a CDS Service should indicate what features it implements (much like the CapabilityStatement). If it cannot support an evaluateAt (or variation), then it simply doesn't include that in its service metadata. prefetch is already stating what it would prefer to have included in the request payload.

Just as important if the CDS Service supports this functionality is that the EHR and more importantly FHIR server can support this functionality. We do not something akin to the CapabilityStatement today. The CDS Service definition in Discovery does describe each CDS Service, but I wouldn't equate it to a CapabilityStatement. I'd prefer to avoid venturing into that domain for the time being.

In my mind the CDS Hooks Discovery mechanism is indeed equivalent to a CapabilityStatement. Also in my mind is the fact there's no way around defining it as such.

@yashaskram: In general I agree with @Phillip Warner that it should part of the payload (from implementation efforts perspective) if we plan to have this supported as part of CDS Hook spec.

I also think it's important to note that this feature is going to be an edge case in that it will not see widespread adoption. I say this because in order for this 'evaluate at' functionality to be supported, the underlying FHIR server must support these types of queries. Currently, I do not know of any EHR vendor that has implemented this functionality. This is why I would prefer keeping this out of the CDS Service request body as we would be defining a new request field for something that is not widely implemented. This is why the request header was appealing to me.

I honestly see this as no different than supporting the request header for this use case.

At any rate, if you insist on a header, naming the header Evaluate-At-DateTime would be my preference; requiring it to conform to ISO 8601 would be fine; requiring UTC is unreasonable, as ISO 8601 supports time zones. Any decent Date-Time library should be able to support this.

Github Notifications (Jun 06 2017 at 05:18):

kpshek commented on Issue #50

So you don't intend for cds-hooks to become a standard?

Of course I want CDS Hooks to be a standard. Sorry, my original comment wasn't clear. What I intended to get across was that it didn't matter to me that RFC 7089 wasn't a standard because most of everything that we're creating also isn't a standard right now. At any rate, this is moot because I agree with you that using RFC 7089 is a good choice.

You take my comment out of context. What I said was a bullet point to implementing RFC 7089.

I'm sorry, I didn't mean to take your comment out of context. I see now that you were probably referring to the complexity of implementing all of RFC 7089. I completely agree it is far more involved and contains more than the small piece I was proposing we leverage.

In my mind the CDS Hooks Discovery mechanism is indeed equivalent to a CapabilityStatement. Also in my mind is the fact there's no way around defining it as such.

I agree our Discovery endpoint is closely related to the CapabilityStatement in FHIR. I'm just trying to keep it as simple as possible for as long as possible.

requiring UTC is unreasonable, as ISO 8601 supports time zones. Any decent Date-Time library should be able to support this

ISO 8601 support time zone offsets but this is a different concept than timezones. Timezone offsets have not concept of DST whereas timezones do. For instance, given an ISO 8601 date of 2005-10-30T02:00:00-05:00, what is the correct UTC value? Here is Java code which illustrates this issue:

import org.joda.time.DateTimeZone;
import org.joda.time.Instant;

Instant i = new Instant("2005-10-30T02:00:00-05:00");
System.out.println(i); // 2005-10-30T07:00:00.000Z
System.out.println(i.toDateTime(DateTimeZone.UTC)); // 2005-10-30T07:00:00.000Z
System.out.println(i.toDateTime(DateTimeZone.forOffsetHours(-5))); // 2005-10-30T02:00:00.000-05:00
System.out.println(i.toDateTime(DateTimeZone.forID("America/Chicago"))); // 2005-10-30T01:00:00.000-06:00
System.out.println(i.toDateTime(DateTimeZone.forID("America/Indiana/Indianapolis"))); // 2005-10-30T02:00:00.000-05:00

So, if we want to support time zones we need to use an ISO 8601 timestamp and a time zone. However, if we align on UTC, we will not have this issue.

Last updated: Apr 12 2022 at 19:14 UTC