FHIR Chat · docs / Issue #50 Inform a CDS Service its decision suppor... · cds hooks/github

Stream: cds hooks/github

Topic: docs / Issue #50 Inform a CDS Service its decision suppor...

---

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

kpshek edited 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 (Jun 06 2017 at 05:27):

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

That's the thing--I don't agree that RFC 7089 itself is a good choice.

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.

I think you misunderstand again--I don't think the Discovery endpoint should be a CapabilityStatement, but it should express what the service is capable of and is meant to do. Hence the intent of the Discovery endpoint is similar to the CapabilityStatement.

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.

Fair enough. You are correct--something I guess I've forgotten.

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

euvitudo commented on Issue #50

To clarify--call the header support something else. Don't call it RFC 7089.

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

kpshek commented on Issue #50

@Phillip Warner - We agree, I just had a crucial typo (that's what I get for writing comments at midnight). I agree RFC 7089 is not a good choice. I think we're all good on this point.

Github Notifications (Jun 06 2017 at 06:52):

euvitudo commented on Issue #50

@kpshek How would you suggest a CDS Service advertise that it is capable of evaluating at a specified time?

Github Notifications (Jun 16 2017 at 19:50):

alextdejong commented on Issue #50

Even if the CDS Service is capable of doing this, if the FHIR resources used are not capable of this, it still would not work, correct? I am not suggesting it would not be worthwhile for the CDS Services to advertise it; it just does not automatically means it would actually work when calling the CDS service.

Github Notifications (Jul 10 2017 at 20:17):

brynrhodes commented on Issue #50

Can we do this with just a custom header and have it be optional, but systems that don't support it would throw?

Github Notifications (Jul 10 2017 at 20:17):

kpshek assigned Issue #50

Github Notifications (Jul 12 2017 at 16:27):

euvitudo commented on Issue #50

@brynrhodes Any custom headers (header names/keys) that are not understood should be ignored.

For example, if a specified-time header were provided and the system threw an error that it didn't understand the specified-time header, then in reality it does understand it sufficiently to throw the error. Rather contradictory in my mind.

Github Notifications (Jul 12 2017 at 17:51):

isaacvetter commented on Issue #50

I think that I agree with you, @Phillip Warner, but is there a simple existing method for the EHR to know that the CDS service didn't understand the header?

Github Notifications (Jul 12 2017 at 17:59):

euvitudo commented on Issue #50

I wouldn't think so. If it's not an explicit part of the standard, then how would a service even know how to handle the header (or, for the case where, e.g., specified-time is included in the request standard, the data element in the actual request)?

To wit: If it's not part of the standard, then there's no way of knowing.

Github Notifications (Jul 12 2017 at 18:09):

euvitudo commented on Issue #50

I suppose an alternative is to add an element to the response indicating the time at which the CDS evaluation occurred. It wouldn't necessarily need be tied to a specified-time header, but would need to be part of every response.

Github Notifications (Jul 26 2017 at 19:15):

kpshek commented on Issue #50

After further thought, I don't think this is something we should tackle right now. My main reasoning is that the FHIR server would need to support the ability to retrieve data at a given point in time. FHIR doesn't support this today so even if we added a field to the CDS Hooks API somewhere, it is unclear how the FHIR endpoint would also honor this.

Additionally, while I see there is a place for this use case (primarily for testing), I think it is fairly limited right now (especially since FHIR isn't capable of this today).

I propose we defer this until this is addressed within FHIR. I'd appreciate the thoughts from @brynrhodes and @Isaac Vetter on this particular issue too.

Github Notifications (Jul 26 2017 at 19:26):

euvitudo commented on Issue #50

@kpshek Could you elaborate why you don't think FHIR has the ability to retrieve data at a given point in time? Many (all?) of the search operations include the ability to include date constraints (e.g., lt2017-01-01, etc.) that makes this use case feasible.

Github Notifications (Jul 26 2017 at 20:31):

brynrhodes commented on Issue #50

@Phillip Warner it's not just returning data at a point in time, but returning what the data _was_ at that point in time that is the difficulty. FHIR supports versioning so in theory an engine could do it, but none of the production-track implementations I'm aware of support this functionality.

Github Notifications (Jul 26 2017 at 22:36):

grahamegrieve commented on Issue #50

"What decision support was shown to user U for patient P last week on May 30, 2017 8:00am" - that's an audit functionality that is supportable. "What decision support would have been shown to user U for patient P last week on May 30, 2017 8:00am" - that's tricky, because there's a lot of moving parts that change independently of each other.

It's correct that FHIR doesn't try to enable this; I've only ever seen one system that could behave like this (it had an insert only database), and even then, it was fragile because changes to configuration intersected with changes to the code, and cross-cut the ability to retrieve old records exactly as they were. And consistent with my experience, no one has asked for it (till now)

Github Notifications (Jul 26 2017 at 23:24):

kpshek commented on Issue #50

Well put @grahamegrieve. This issue wasn't trying to address the auditing capability you referred to. It really was to try and explore the latter use case which as you've confirmed, is not possible today.

Github Notifications (Jul 28 2017 at 03:24):

isaacvetter commented on Issue #50

Hey @Phillip Warner - I've started a comment on this thread a few times today, let me know if I can give you a call to talk through this. I want to ensure that your voice and needs are heard and given appropriate weight.

Perhaps due to the relatively simple, early use-cases for the standard, there isn't much call for this feature. Further, we can't figure out a way to accommodate it without weakening the current, appealingly simple CDS request message. Based upon the above few posts and my knowledge of my own FHIR server and roadmap, there's not widespread support for "point-in-time" FHIR queries.

For these reasons, I think that it makes sense to defer an _evaluateAt_ feature until at least one of the above statements is no longer true.

Isaac

Github Notifications (Jul 28 2017 at 04:26):

euvitudo commented on Issue #50

Hey @Isaac Vetter - given the above, it seems reasonable to defer.

Github Notifications (Jul 28 2017 at 14:48):

kpshek labeled Issue #50

Github Notifications (Jul 28 2017 at 14:48):

kpshek commented on Issue #50

Thanks everyone -- labeling this as deferred for now.

Github Notifications (Jul 28 2017 at 14:48):

kpshek closed Issue #50

Github Notifications (Jul 28 2017 at 14:48):

kpshek demilestoned Issue #50

Github Notifications (Jul 28 2017 at 15:57):

kensaku-kawamoto commented on Issue #50

In the interim, we will plan to either (i) create a proprietary extension to support this notion of a specified time or (ii) do that at the level of the decision engine underlying CDS Hooks. E.g., if we pursue (ii), we can still do what we currently do -- create dozens or hundreds of test cases for a CDS module with static input test data (e.g., a FHIR bundle), have the CDS module evaluate this information at a given specified time, and to verify that the end result/output is as expected in statically defined expectations. I agree that for real-time/dynamic CDS Hooks usages, the specified time is tricky to get working and may not be worth the effort. As long as the ability to get consistent evaluation results from a static set of test case data is there, I would be fine. Also would need to be able to evaluate consistency of behavior that is date/time dependent, e.g., making sure that an after-hours alert (such as "for ECHO outside of business hours, please page XYZ") can be tested at boundary conditions without actually running them at 4:59pm vs 5:00pm on a Monday, on Labor Day, etc.

Github Notifications (Jul 28 2017 at 16:05):

kpshek commented on Issue #50

Thanks @kensaku-kawamoto - please let us know how this goes for you

---

Last updated: Apr 12 2022 at 19:14 UTC