Stream: cds hooks
Topic: docs: issue 14: How should a cds-service let an EHR know ...
Github Notifications (Dec 12 2016 at 20:52):
isaacvetter opened issue 14
How should a cds-service let an EHR know about errors?
Following RESTful best practices, HTTP error statuses returned by a cds-service to an EHR when appropriate:
- 403 Forbidden for authnz failures
- 503 Method not Allowed for incorrect HTTP methodFor business-logic type errors, it might make sense for the service to return a 500 containing a FHIR OperationOutcome with values from the FHIR IssueType valueset, but further constrained.
David Taylor (Dec 16 2016 at 19:19):
Sorry but Zulip didn't take my post before. Is there any specification / discussion on returning feedback from CARDs back to CDS Service? An example would be confirmation of allowing a patient to be added to a study where the CDS Service manages the study enrollement.
Kevin Shekleton (Dec 17 2016 at 03:48):
David - We defined an analytics endpoint which is similar to what you're asking (the EHR providing feedback back to the CDS service on interactions with the card). However, in the example you cited, where is the user being added to a study? Is the EHR adding the user to the study or is the user interacting with a SMART app to do this?
David Taylor (Dec 17 2016 at 03:49):
Neither - the CDS Servce is what adds a patient in this case to a study - manged outside the EHR.
Kevin Shekleton (Dec 17 2016 at 03:50):
So when the CDS Service triggers the creation of a card, it automatically adds the patient to a study?
David Taylor (Dec 17 2016 at 03:57):
Nope, it first needs acceptance from the Provider. An example: Provider orders medication, CDS determines that qualifies a Patient, Provider is prompted from the alert (card) to confirm and then I need that confirmation back to add them to the study
Kevin Shekleton (Dec 17 2016 at 03:57):
Ah
David Taylor (Dec 17 2016 at 03:58):
in this case the CDS system is outside of the EHR control - invoked by the EHR but managed by seperate groups / organizations
Kevin Shekleton (Dec 17 2016 at 03:58):
Sure
Kevin Shekleton (Dec 17 2016 at 03:59):
CDS cards are JSON so they don't contain execute logic/arbitrary code by the CDS service. This prevents the type of interaction that you're asking for.
Kevin Shekleton (Dec 17 2016 at 04:00):
Today, all state changes from the card itself are via 'suggestions' which are in the form of FHIR resources (like adding a new medication or removing an medication).
David Taylor (Dec 17 2016 at 04:01):
Right - that is why this is a challenge for the type of CDS interactions we have had in the past and for this to meet our needs
Kevin Shekleton (Dec 17 2016 at 04:02):
A possible way to satisfy your use case is for the CDS card to return a link that says something like "Click here to enroll the patient in this study". This link would be handled by the CDS service and would serve as your acceptance/confirmation
David Taylor (Dec 17 2016 at 04:02):
This assumes a very tight coupling with the EHR and a very limited role for the CDS system, which might be fine for most users perspectives but for my needs I need more flexiblity - maybe it needs to be more of a drive to a SMART app that is more interactive
Kevin Shekleton (Dec 17 2016 at 04:03):
Yes, our intention is to serve up SMART apps from cards where more interaction or sophisticated logic is desired.
David Taylor (Dec 17 2016 at 04:03):
so does the link need to be to a smart service or can it be to a general restful service?
Kevin Shekleton (Dec 17 2016 at 04:04):
The link doesn't need to be a SMART app -- it could be a generated link with some unique identifier that indicates to you the patient/provider in context and the study they are being enrolled in
Kevin Shekleton (Dec 17 2016 at 04:05):
For example, when you register for a new account on a website and get an email with a confirmation link to confirm your email address (which completes your account creation). This link is generated with some UUID that upon doing a GET to that link (eg, clicking on it), it confirms some state.
David Taylor (Dec 17 2016 at 04:09):
that is great news - sorry I haven't had a lot of time yet looking this over so thanks for clarifying that. So the response card would be a Link with instructions to click the link for accepting? That would work - thank you for clarifying
Kevin Shekleton (Dec 17 2016 at 04:09):
No problem, I'm happy to help!
Kevin Shekleton (Dec 17 2016 at 04:10):
After you think through your scenario more with this possible solution, let me know if this will indeed work
David Taylor (Dec 17 2016 at 04:11):
Will do - btw, swagger is a great choice for documenting your API.
David Taylor (Dec 17 2016 at 04:11):
thanks for helping me so late as well
Kevin Shekleton (Dec 17 2016 at 04:12):
Thanks! I think you're one of a couple people I've heard actually use the Swagger API. Glad to hear it's getting some use
Grahame Grieve (Dec 17 2016 at 06:11):
Swagger got plenty of endorsement from users at DevDays in Amsterdam
Github Notifications (Dec 17 2016 at 09:59):
@Isaac Vetter - Are there particular scenarios or use cases that prompted you to raise this question?
I would imagine the CDS service should return standard HTTP error codes when appropriate. I hadn't thought of the need to explicitly call this our in our spec for CDS services.
Regarding the 'business-logic' errors, what would the EHR do with these errors? This question likely goes back towards the scenarios/use cases that you are thinking of.
Related to this discussion, an outstanding/unresolved question I've had is what expectations should be placed on the EHR to indicate CDS service invocation failures _or_ timeouts? This question can be framed both around error and SLA expectations. I don't know that we need strong requirements around this but instead could provide acknowledge and perhaps guidance on how this can be handled.
Pascal Pfiffner (Dec 21 2016 at 09:14):
Just want to add that it would be relatively trivial to build a simple SMART app around the “click link to enroll” use case. This would be a SMART app that, on button click, talks to @David Taylor 's backend via whatever means necessary and would display the result of enrollment.
Isaac Vetter (Jan 14 2017 at 22:47):
@David Taylor , @Pascal Pfiffner , @Kevin Shekleton -- what about the cds-service returning a (currently very draft) ResearchSubject FHIR object?
David Taylor (Jan 14 2017 at 22:49):
Honestly I've been dealing with recursive java marshaling issues this afternoon with both dstu2 and 3 - StringType derives from Elemement which has a StringType id field
David Taylor (Jan 14 2017 at 22:51):
I'm stuck with marshaling issues - both dstu2 and 3 - anyone able to use JAXB wth HapiFhir at all or know how to replace spring marshlaing with Stax (which looks like the only way forward) Defaults to Jackson which solves everything with annotations only. Example: dtsu3: StringType -> ....Element which has StringType id
Github Notifications (Jan 14 2017 at 23:13):
@kpshek I think there should also be explicit thought about what happens when a CDS service is offline, down for maintenance, or otherwise unavailable. Some sort of graceful degradation would be ideal.
Github Notifications (Jan 14 2017 at 23:28):
@olbrich - I think we can use RESTful conventions of standard HTTP error code for this particular use case. For instance, in the case of a CDS service down for maintenance, I think the CDS service can simply return a 503 status:
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server.
I call this out because I don't think it's necessary to add any additional fields to the response of the CDS service.
The next (and more important question) is how should the EHR handle this scenario when it occurs? This is where I'm unsure if this is something we can handle in the spec. Instead, I'm thinking we should perhaps create an implementation or best practices guide that calls out these scenarios to raise visibility and provide examples of how they should be dealt with. The reason why I'm thinking this is because the nature of the CDS service and it's importance to the organization's workflow/business will determine how the EHR should handle failures such as this.
David Taylor (Jan 15 2017 at 15:32):
Btw, I've channeled my frustration into some CDS Hooks parsers extending from Jame's Stax based parsers. If anyone is interested, I'll share them up on github later in the week. They will need to be overridded to handle specific Prefetch, Create, Delete objects if other than array's of Fhir IBaseResource objects.
Kevin Shekleton (Jan 15 2017 at 15:32):
Thanks, David!
Last updated: Apr 12 2022 at 19:14 UTC
