Thoughts CDS Hooks the degree to which FHIR is leveraged

Kevin Shekleton

unread,

Jan 13, 2016, 2:51:23 PM1/13/16

to CDS Hooks

After implementing CDS Hooks this past weekend as both an EHR/server and CDS service, I've had some time to reflect on the current design for CDS Hooks. I'd appreciate any feedback and discussion on this.

CDS Hooks today leverages both FHIR and SMART in several areas of it's design, of which many aspects of this coupling serve great benefit to CDS Hooks. However, there are other areas that CDS Hooks leverages FHIR which I am not sure of the value that it brings.

SMART

CDS Hooks leverages the authorization model which, though this particular use case has yet to be proven out in implementation, likely makes sense. Additionally, the app links returned in cards are intended to be SMART apps which makes a lot of sense.

FHIR

The pre-fetched data given to CDS services are defined as FHIR resources. Additionally, the EHR gives the CDS service the FHIR server URL so that it can read additional data. Clearly, leveraging FHIR in this manner makes a lot of sense.

There are several other areas in which FHIR is leveraged in the design of CDS Hooks. I am not as clear as to the value this additional coupling provides.

Operations Framework

CDS Hooks leverages the FHIR Operations framework as the model in which CDS services expose their functionality and the data model (FHIR Parameters resource). While implementing both my server and client this past weekend, I found the Parameters resource to be overly cumbersome and most importantly, lacking in clarity with respect to the domain of CDS Hooks. For instance, the request & reply definitions on the Wiki are (mostly) succinct but the fine print notes that the actual request and reply structures use the Parameters resource and are therefore more verbose. Parsing this generic Parameters data model is a bit clunky as it relies upon traversing name/value pairs.

Rather than Parameters, I would like to see the request and reply utilize a more specific data model to CDS Hooks. Here is a worked-example that best illustrates my thinking:

Here is how a trivial information card looks today:

{

"resourceType":"Parameters",

"parameter":[

{

"name":"card",

"part":[

{

"name":"summary",

"valueString":"Success Card"

},

{

"name":"indicator",

"valueCode":"success"

},

{

"name":"detail",

"valueString":"This is a test of a static success card."

},

{

"name":"source",

"part":[

{

"name":"label",

"valueString":"Example CDS Service"

},

{

"name":"url",

"valueUri":"https://www.example.com/"

}

]

},

{

"name":"link",

"part":[

{

"name":"label",

"valueString":"Google"

},

{

"name":"url",

"valueUri":"https://google.com"

}

]

},

{

"name":"link",

"part":[

{

"name":"label",

"valueString":"Yahoo!"

},

{

"name":"url",

"valueUri":"https://yahoo.com"

}

]

}

]

}

]

}

And here is how that same trivial information card would look with a more specific data model:

{

"cards":[

{

"summary":"Success Card",

"detail":"This is a test of a static success card.",

"source":{

"label":"Example CDS Service",

"url":"https://www.example.com/"

},

"links":[

{

"label":"Google",

"url":"https://google.com/"

},

{

"label":"Yahoo",

"url":"https://yahoo.com/"

}

]

}

]

}

It is quite apparent that this model is far more clear than the current, Parameters based approach. My question then is what value does Parameters bring, such that this value outweighs the value of a more clear, concise data model?

One might argue that EHRs and CDS service developers can leverage existing FHIR code/libraries when de/serializing the Parameters object. While that is true, I think as a community we could easily match this value by creating our own open source libraries to aid in the serialization of this data model. With that being said, I personally think the simplicity of this data model lessens the need for such a library.

Conformance

The current proposal calls for the CDS Service to publicize the activities they support and the pre-fetched data they require via a Conformance document, effectively making a CDS service a highly specialized FHIR server. I can think of far more simple ways for a CDS service to publicize the activities they support and the data they require, and the reasoning and value aligns with the aforementioned thinking around the Operations framework.

Like my question around Operations, what value does leveraging the FHIR Conformance resource bring over defining a far more simple model?

If you've gotten this far and read everything, thanks! :)

Ron Shapiro

unread,

Jan 13, 2016, 4:35:56 PM1/13/16

to Kevin Shekleton, CDS Hooks

Kevin, as a client implementor, I really like your alternative to the Parameters!

I'll be interested to see what the others have to say about that and the Conformance...

--
You received this message because you are subscribed to the Google Groups "CDS Hooks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cds-hooks+...@googlegroups.com.
To post to this group, send email to cds-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cds-hooks/65d6ebdc-4f98-4e1f-9231-d07df0a654d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Nikolai Schwertner

unread,

Jan 13, 2016, 10:31:14 PM1/13/16

to cds-...@googlegroups.com

On the CDS service creators site, I can attest that without invoking a library, the "parameters" format require extra steps in the code to process properly (need to apply filters and such - can't just get to an element directly). Would be nice to have something more concise, like in your example.

-Nikolai

Jared Nichols

unread,

Jan 14, 2016, 9:32:07 AM1/14/16

to CDS Hooks

I've implemented the CDS service side and I agree the Parameters resource is a bit of a burden. I was able to leverage the C# reference library, so it wasn't too bad, but there's still a little extra work drilling down into the resource. The same goes for the response side, where there's extra code required to get your response into the Parameters format.

On the other hand, I think the embedded resources like Patient, MedicationOrder, and DiagnosticOrder work reasonably well. I like the idea of a simplified model for Parameters, but is it worth having 1 or 2 pieces that aren't FHIR resources if everything else is?

If there's sufficient interest in the CDS Hooks use case, then is there a possibility of defining first-class resources for CDS requests/responses? There's already a GuidanceRequest that was recently introduced by the CDS Work Group. I'm not sure it's a good fit as is, but perhaps it could be adapted.

I didn't find the Conformance resource to be too bad. Kevin, did you have an alternative model in mind?

Kevin Shekleton

unread,

Jan 15, 2016, 12:33:09 AM1/15/16

to CDS Hooks

Thanks for the feedback everyone!

Jared, I agree with you that communicating clinical data using FHIR resources makes a lot of sense. I certainly don't want to see this change. However, just because we're using FHIR to communicate the clinical data, I don't see why it would follow that we also need to use the FHIR Operations framework and Conformance resources for the other aspects of CDS Hooks.

A more succinct summary of my argument is this: I think CDS Hooks should leverage FHIR data, but not the FHIR framework for the services/transactions.

You also asked for an alternative to Conformance. What follows is my initial thinking. Note that I'm using 'hook' to mean what CDS Hooks calls "activity" today. I feel like this provides a more cohesive verbiage to the CDS Hooks name.

Instead of Conformance, CDS Services can expose the hooks they support via:

Request: GET /cds-hooks

Response:

{

"hooks": [

{

"name": "patient-view",

"description": "Determines if the patient is at risk for septic shock"

"trigger-only": { ... } // this could be a hint/definition for the EHR to only trigger this hook when this condition holds true

"prefetch-data": {

"Patient/{{Patient.id}}",

"Observation?subject:Patient={{Patient.id}}&code=4548-4&_count=1&sort:sac=date"

}

]

}

The EHR can trigger the hook via:

Request: POST /cds-hooks/:hook/:id

eg, POST /cds-hooks/patient-view/551ee4d1-a9cc-4381-a045-56ef148186f7

{

"fhirServer": "https://fhir.example.com/",

"oauth": { ... },

"redirect": "http://ehr.example.com",

"user": "Practitioner/123",

"patient": "456",

"encounter": "789",

"context": { ... },

"preFetchData": { ... }

}

Note that the request here is simplified like the CDS server response from my initial post which started this thread. The context and preFetchData attributes will contain FHIR data. The activity attribute (hereby referred to as 'hook') has been omitted since it is part of the URI in my proposal. Additionally, the activityInstance attribute has been omitted as well as it is the :id param in the URI.

The response that comes back from this POST call is the aforementioned response from the initial post on this thread.

Also note that in my proposal here, CDS services will expose these two endpoints using a consistent path (/cds-hooks and /cds-hooks/:hook/:id). Currently, CDS services are available at either $cds-hook or a path of their choosing. I'd rather see us be prescriptive with the path so CDS services only need to communicate a base URL to the EHR.

Thanks again for the feedback and great discussion everyone!

-Kevin

Boone, Keith W (GE Healthcare)

unread,

Jan 15, 2016, 7:30:54 AM1/15/16

to Kevin Shekleton, CDS Hooks

That is just so wrong.

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "CDS Hooks" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cds-hooks+...@googlegroups.com<mailto:cds-hooks+...@googlegroups.com>.
To post to this group, send email to cds-...@googlegroups.com<mailto:cds-...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/cds-hooks/66321a9a-3291-4f16-8790-c855d607290a%40googlegroups.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_cds-2Dhooks_66321a9a-2D3291-2D4f16-2D8790-2Dc855d607290a-2540googlegroups.com-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dfooter&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=VlIWsAGt5a-1zsbVF91T-c9GEfEjVVrYIQkJsZwRhek&s=Z6dQJJyYmzbVZuU_xPSINROX8YZMzZa0DDpm_EdWKqA&e=>.
For more options, visit https://groups.google.com/d/optout<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=VlIWsAGt5a-1zsbVF91T-c9GEfEjVVrYIQkJsZwRhek&s=wTcqOKOgSaWxRy_pCiurD2pHfLMTWIhwpVnycNFEgwI&e=>.

Kevin Shekleton

unread,

Jan 15, 2016, 7:47:15 AM1/15/16

to CDS Hooks, kevin.s...@gmail.com

Hi Keith. Can you elaborate on what you find wrong?

Regards,

Kevin

On Friday, January 15, 2016 at 7:30:54 AM UTC-5, keith.boone wrote:

That is just so wrong.

Sent from my iPhone

To unsubscribe from this group and stop receiving emails from it, send an email to cds-hooks+unsubscribe@googlegroups.com<mailto:cds-hooks+unsubscribe@googlegroups.com>.
To post to this group, send email to cds-...@googlegroups.com<mailto:cds-hooks@googlegroups.com>.

Kevin Shekleton

unread,

Jan 15, 2016, 9:20:52 AM1/15/16

to CDS Hooks, kevin.s...@gmail.com

Keith replied to me personally, though I'm sure he intended for his response to be in this Google group thread.

Keith wrote:

>You are using FHIR, but rather than using the FHIR framework, you are going to do something else because either, that part of the framework is too hard to use, or you cannot be bothered to figure out how to use it.
>
>Make the standard better. Don't ignore it.

Certainly my line of thinking that initially led to the thoughts that resulted in this discussion were born from my implementation work at the Connectathon. That's not to say that I found the framework hard to use or that I didn't take the time to learn it. To the contrary, I've implemented a FHIR server (now in use in production) on top of a mature EHR with complex business rules and services. So, it's certainly not my lack of understanding with FHIR that brought me to this thinking.

It's also not that that I'm ignoring the standard or not interested in making the standard better. It's that I don't see CDS Hooks as part of FHIR; rather, I see it using FHIR (data). Consider SMART on FHIR: SMART leverages FHIR where it best fits -- sharing data from the EHR. Likewise, I'm proposing that CDS Hooks leverage FHIR in the same way.

Regards,

Kevin

Boone, Keith W (GE Healthcare)

unread,

Jan 15, 2016, 9:29:37 AM1/15/16

to Kevin Shekleton, CDS Hooks

Where SMART differs from FHIR is that it provides features not found therein. The current discussion proposes alternate features already found in FHIR for discovery.

Sent from my iPhone

On Jan 15, 2016, at 9:20 AM, Kevin Shekleton <kevin.s...@gmail.com<mailto:kevin.s...@gmail.com>> wrote:

Keith replied to me personally, though I'm sure he intended for his response to be in this Google group thread.

Keith wrote:
>You are using FHIR, but rather than using the FHIR framework, you are going to do something else because either, that part of the framework is too hard to use, or you cannot be bothered to figure out how to use it.
>
>Make the standard better. Don't ignore it.

Certainly my line of thinking that initially led to the thoughts that resulted in this discussion were born from my implementation work at the Connectathon. That's not to say that I found the framework hard to use or that I didn't take the time to learn it. To the contrary, I've implemented a FHIR server<https://urldefense.proofpoint.com/v2/url?u=http-3A__fhir.cerner.com_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=tLC0F9JN_rbLykC2NBtnI0J2vVcbTNgWCLXmWl7kUJA&s=ugeiaEMc52WOWd8hE7NP-Lg8rNT_pBoIDNoo0n2XWLQ&e=> (now in use in production) on top of a mature EHR with complex business rules and services. So, it's certainly not my lack of understanding with FHIR that brought me to this thinking.

It's also not that that I'm ignoring the standard or not interested in making the standard better. It's that I don't see CDS Hooks as part of FHIR; rather, I see it using FHIR (data). Consider SMART on FHIR: SMART leverages FHIR where it best fits -- sharing data from the EHR. Likewise, I'm proposing that CDS Hooks leverage FHIR in the same way.

Regards,
Kevin

On Friday, January 15, 2016 at 7:47:15 AM UTC-5, Kevin Shekleton wrote:
Hi Keith. Can you elaborate on what you find wrong?

Regards,
Kevin

On Friday, January 15, 2016 at 7:30:54 AM UTC-5, keith.boone wrote:
That is just so wrong.

Sent from my iPhone

On Jan 15, 2016, at 12:33 AM, Kevin Shekleton <kevin.s...@gmail.com<mailto:kevin.s...@gmail.com><mailto:kevin.s...@gmail.com<mailto:kevin.s...@gmail.com>>> wrote:

Thanks for the feedback everyone!

Jared, I agree with you that communicating clinical data using FHIR resources makes a lot of sense. I certainly don't want to see this change. However, just because we're using FHIR to communicate the clinical data, I don't see why it would follow that we also need to use the FHIR Operations framework and Conformance resources for the other aspects of CDS Hooks.

A more succinct summary of my argument is this: I think CDS Hooks should leverage FHIR data, but not the FHIR framework for the services/transactions.

You also asked for an alternative to Conformance. What follows is my initial thinking. Note that I'm using 'hook' to mean what CDS Hooks calls "activity" today. I feel like this provides a more cohesive verbiage to the CDS Hooks name.

Instead of Conformance, CDS Services can expose the hooks they support via:

Request: GET /cds-hooks
Response:
{
"hooks": [
{
"name": "patient-view",
"description": "Determines if the patient is at risk for septic shock"
"trigger-only": { ... } // this could be a hint/definition for the EHR to only trigger this hook when this condition holds true
"prefetch-data": {
"Patient/{{Patient.id}}",
"Observation?subject:Patient={{Patient.id}}&code=4548-4&_count=1&sort:sac=date"
}
}
]
}

The EHR can trigger the hook via:

Request: POST /cds-hooks/:hook/:id
eg, POST /cds-hooks/patient-view/551ee4d1-a9cc-4381-a045-56ef148186f7

{

"fhirServer": "https://fhir.example.com/<https://urldefense.proofpoint.com/v2/url?u=https-3A__fhir.example.com_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=tLC0F9JN_rbLykC2NBtnI0J2vVcbTNgWCLXmWl7kUJA&s=HRuqbNFdI7JvQdjd9I6IevVzTar9cvw0_jM1WzL7yuQ&e=>",
"oauth": { ... },
"redirect": "http://ehr.example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__ehr.example.com&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=tLC0F9JN_rbLykC2NBtnI0J2vVcbTNgWCLXmWl7kUJA&s=IU0ZRFdBb2Ui1Er5zZsmPW_0Jf8XYNJqbz9uvuVpWZU&e=>",

"user": "Practitioner/123",
"patient": "456",
"encounter": "789",
"context": { ... },
"preFetchData": { ... }
}

Note that the request here is simplified like the CDS server response from my initial post which started this thread. The context and preFetchData attributes will contain FHIR data. The activity attribute (hereby referred to as 'hook') has been omitted since it is part of the URI in my proposal. Additionally, the activityInstance attribute has been omitted as well as it is the :id param in the URI.

The response that comes back from this POST call is the aforementioned response from the initial post on this thread.

Also note that in my proposal here, CDS services will expose these two endpoints using a consistent path (/cds-hooks and /cds-hooks/:hook/:id). Currently, CDS services are available at either $cds-hook or a path of their choosing. I'd rather see us be prescriptive with the path so CDS services only need to communicate a base URL to the EHR.

Thanks again for the feedback and great discussion everyone!

-Kevin

On Thursday, January 14, 2016 at 9:32:07 AM UTC-5, Jared Nichols wrote:
I've implemented the CDS service side and I agree the Parameters resource is a bit of a burden. I was able to leverage the C# reference library, so it wasn't too bad, but there's still a little extra work drilling down into the resource. The same goes for the response side, where there's extra code required to get your response into the Parameters format.

On the other hand, I think the embedded resources like Patient, MedicationOrder, and DiagnosticOrder work reasonably well. I like the idea of a simplified model for Parameters, but is it worth having 1 or 2 pieces that aren't FHIR resources if everything else is?

If there's sufficient interest in the CDS Hooks use case, then is there a possibility of defining first-class resources for CDS requests/responses? There's already a GuidanceRequest that was recently introduced by the CDS Work Group. I'm not sure it's a good fit as is, but perhaps it could be adapted.

I didn't find the Conformance resource to be too bad. Kevin, did you have an alternative model in mind?

--
You received this message because you are subscribed to the Google Groups "CDS Hooks" group.

--
You received this message because you are subscribed to the Google Groups "CDS Hooks" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cds-hooks+...@googlegroups.com<mailto:cds-hooks+...@googlegroups.com>.
To post to this group, send email to cds-...@googlegroups.com<mailto:cds-...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/cds-hooks/594bade1-9719-40e6-bb4e-ddb5c1987e1d%40googlegroups.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_cds-2Dhooks_594bade1-2D9719-2D40e6-2Dbb4e-2Dddb5c1987e1d-2540googlegroups.com-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dfooter&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=tLC0F9JN_rbLykC2NBtnI0J2vVcbTNgWCLXmWl7kUJA&s=woXlUEC9ceeHOOZ43NzENWK5-ZM3mPLd4HO9RdafZ3g&e=>.
For more options, visit https://groups.google.com/d/optout<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=tLC0F9JN_rbLykC2NBtnI0J2vVcbTNgWCLXmWl7kUJA&s=b0mFiiewl7vLiyCtCbtxVoMUcW5RL4xBWqD_AV-tL6I&e=>.

Grahame Grieve

unread,

Jan 15, 2016, 9:57:42 AM1/15/16

to Boone, Keith W (GE Healthcare), Kevin Shekleton, CDS Hooks

hi Keith

I think you're being unreasonable. Kevin has proposed something for discussion, and we should be able have discussion about what's the best solution about what the best approach is without worrying about what 'is fhir' or not.

I think it's very useful to me and other implementers that the cds-hook service works well when implemented on a FHIR Server, and that discovery works if you start at the FHIR conformance statement. But I don't think that this should be the only way to discover the service, nor that implementing the service correctly should require a full FHIR Server. There's some aspects of Kevin's proposal that don't play well for those of use who want to implement in the context of a FHIR Server, but there may be - should be - a middle path that will work for both. I will propose one later today, hopefully

Grahame

To unsubscribe from this group and stop receiving emails from it, send an email to cds-hooks+...@googlegroups.com.
To post to this group, send email to cds-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cds-hooks/E027A8A9-5FF2-4849-95BE-48AD8DFCE87B%40ge.com.

For more options, visit https://groups.google.com/d/optout.

--

-----
http://www.healthintersections.com.au / gra...@healthintersections.com.au / +61 411 867 065

Boone, Keith W (GE Healthcare)

unread,

Jan 15, 2016, 11:45:04 AM1/15/16

to Grahame Grieve, Kevin Shekleton, CDS Hooks

Grahame,

I didn't start the discussion about is FHIR or not. My response was to Kevin's statement: I think CDS Hooks should leverage FHIR data, but not the FHIR framework for the services/transactions.

he said NOT FHIR and I objected to that pathway. I'd like to see a solution to his problem, and preferably one that could be FHIR. That doesn't mean do it the FHIR way. It could mean make the (or a) FHIR way look like this (whatever this is).

I don't think that's an unreasonable approach. Consider it, don't rule it out.

keith

On Jan 15, 2016, at 9:57 AM, Grahame Grieve <gra...@healthintersections.com.au<mailto:gra...@healthintersections.com.au>> wrote:

hi Keith

I think you're being unreasonable. Kevin has proposed something for discussion, and we should be able have discussion about what's the best solution about what the best approach is without worrying about what 'is fhir' or not.

I think it's very useful to me and other implementers that the cds-hook service works well when implemented on a FHIR Server, and that discovery works if you start at the FHIR conformance statement. But I don't think that this should be the only way to discover the service, nor that implementing the service correctly should require a full FHIR Server. There's some aspects of Kevin's proposal that don't play well for those of use who want to implement in the context of a FHIR Server, but there may be - should be - a middle path that will work for both. I will propose one later today, hopefully

Grahame

On Sat, Jan 16, 2016 at 1:29 AM, Boone, Keith W (GE Healthcare) <keith...@ge.com<mailto:keith...@ge.com>> wrote:
Where SMART differs from FHIR is that it provides features not found therein. The current discussion proposes alternate features already found in FHIR for discovery.

Sent from my iPhone

On Jan 15, 2016, at 9:20 AM, Kevin Shekleton <kevin.s...@gmail.com<mailto:kevin.s...@gmail.com><mailto:kevin.s...@gmail.com<mailto:kevin.s...@gmail.com>>> wrote:

Keith replied to me personally, though I'm sure he intended for his response to be in this Google group thread.

Keith wrote:
>You are using FHIR, but rather than using the FHIR framework, you are going to do something else because either, that part of the framework is too hard to use, or you cannot be bothered to figure out how to use it.
>
>Make the standard better. Don't ignore it.

Certainly my line of thinking that initially led to the thoughts that resulted in this discussion were born from my implementation work at the Connectathon. That's not to say that I found the framework hard to use or that I didn't take the time to learn it. To the contrary, I've implemented a FHIR server<https://urldefense.proofpoint.com/v2/url?u=http-3A__fhir.cerner.com_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=tLC0F9JN_rbLykC2NBtnI0J2vVcbTNgWCLXmWl7kUJA&s=ugeiaEMc52WOWd8hE7NP-Lg8rNT_pBoIDNoo0n2XWLQ&e=> (now in use in production) on top of a mature EHR with complex business rules and services. So, it's certainly not my lack of understanding with FHIR that brought me to this thinking.

It's also not that that I'm ignoring the standard or not interested in making the standard better. It's that I don't see CDS Hooks as part of FHIR; rather, I see it using FHIR (data). Consider SMART on FHIR: SMART leverages FHIR where it best fits -- sharing data from the EHR. Likewise, I'm proposing that CDS Hooks leverage FHIR in the same way.

Regards,
Kevin

On Friday, January 15, 2016 at 7:47:15 AM UTC-5, Kevin Shekleton wrote:
Hi Keith. Can you elaborate on what you find wrong?

Regards,
Kevin

On Friday, January 15, 2016 at 7:30:54 AM UTC-5, keith.boone wrote:
That is just so wrong.

Sent from my iPhone

On Jan 15, 2016, at 12:33 AM, Kevin Shekleton <kevin.s...@gmail.com<mailto:kevin.s...@gmail.com><mailto:kevin.s...@gmail.com<mailto:kevin.s...@gmail.com>><mailto:kevin.s...@gmail.com<mailto:kevin.s...@gmail.com><mailto:kevin.s...@gmail.com<mailto:kevin.s...@gmail.com>>>> wrote:

Thanks for the feedback everyone!

Jared, I agree with you that communicating clinical data using FHIR resources makes a lot of sense. I certainly don't want to see this change. However, just because we're using FHIR to communicate the clinical data, I don't see why it would follow that we also need to use the FHIR Operations framework and Conformance resources for the other aspects of CDS Hooks.

A more succinct summary of my argument is this: I think CDS Hooks should leverage FHIR data, but not the FHIR framework for the services/transactions.

You also asked for an alternative to Conformance. What follows is my initial thinking. Note that I'm using 'hook' to mean what CDS Hooks calls "activity" today. I feel like this provides a more cohesive verbiage to the CDS Hooks name.

Instead of Conformance, CDS Services can expose the hooks they support via:

Request: GET /cds-hooks
Response:
{
"hooks": [
{
"name": "patient-view",
"description": "Determines if the patient is at risk for septic shock"
"trigger-only": { ... } // this could be a hint/definition for the EHR to only trigger this hook when this condition holds true
"prefetch-data": {
"Patient/{{Patient.id}}",
"Observation?subject:Patient={{Patient.id}}&code=4548-4&_count=1&sort:sac=date"
}
}
]
}

The EHR can trigger the hook via:

Request: POST /cds-hooks/:hook/:id
eg, POST /cds-hooks/patient-view/551ee4d1-a9cc-4381-a045-56ef148186f7

{

"fhirServer": "https://fhir.example.com/<https://urldefense.proofpoint.com/v2/url?u=https-3A__fhir.example.com_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=bB7lu6pTe1h7QviMW0AyOC-501_IGthzwhWJpI3Ty2E&s=JtN0Fkw2RuhwzkQC9nFIvEKo4bkpfdQ3Hz3WB18JdTk&e=><https://urldefense.proofpoint.com/v2/url?u=https-3A__fhir.example.com_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=tLC0F9JN_rbLykC2NBtnI0J2vVcbTNgWCLXmWl7kUJA&s=HRuqbNFdI7JvQdjd9I6IevVzTar9cvw0_jM1WzL7yuQ&e=>",
"oauth": { ... },
"redirect": "http://ehr.example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__ehr.example.com&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=bB7lu6pTe1h7QviMW0AyOC-501_IGthzwhWJpI3Ty2E&s=U3ZdlGXwK1zGynAmLZ0S1msz08XPMrcMN75XjYrAfZc&e=><https://urldefense.proofpoint.com/v2/url?u=http-3A__ehr.example.com&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=tLC0F9JN_rbLykC2NBtnI0J2vVcbTNgWCLXmWl7kUJA&s=IU0ZRFdBb2Ui1Er5zZsmPW_0Jf8XYNJqbz9uvuVpWZU&e=>",

"user": "Practitioner/123",
"patient": "456",
"encounter": "789",
"context": { ... },
"preFetchData": { ... }
}

Note that the request here is simplified like the CDS server response from my initial post which started this thread. The context and preFetchData attributes will contain FHIR data. The activity attribute (hereby referred to as 'hook') has been omitted since it is part of the URI in my proposal. Additionally, the activityInstance attribute has been omitted as well as it is the :id param in the URI.

The response that comes back from this POST call is the aforementioned response from the initial post on this thread.

Also note that in my proposal here, CDS services will expose these two endpoints using a consistent path (/cds-hooks and /cds-hooks/:hook/:id). Currently, CDS services are available at either $cds-hook or a path of their choosing. I'd rather see us be prescriptive with the path so CDS services only need to communicate a base URL to the EHR.

Thanks again for the feedback and great discussion everyone!

-Kevin

On Thursday, January 14, 2016 at 9:32:07 AM UTC-5, Jared Nichols wrote:
I've implemented the CDS service side and I agree the Parameters resource is a bit of a burden. I was able to leverage the C# reference library, so it wasn't too bad, but there's still a little extra work drilling down into the resource. The same goes for the response side, where there's extra code required to get your response into the Parameters format.

On the other hand, I think the embedded resources like Patient, MedicationOrder, and DiagnosticOrder work reasonably well. I like the idea of a simplified model for Parameters, but is it worth having 1 or 2 pieces that aren't FHIR resources if everything else is?

If there's sufficient interest in the CDS Hooks use case, then is there a possibility of defining first-class resources for CDS requests/responses? There's already a GuidanceRequest that was recently introduced by the CDS Work Group. I'm not sure it's a good fit as is, but perhaps it could be adapted.

I didn't find the Conformance resource to be too bad. Kevin, did you have an alternative model in mind?

--
You received this message because you are subscribed to the Google Groups "CDS Hooks" group.

--
You received this message because you are subscribed to the Google Groups "CDS Hooks" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cds-hooks+...@googlegroups.com<mailto:cds-hooks%2Bunsu...@googlegroups.com><mailto:cds-hooks+...@googlegroups.com<mailto:cds-hooks%2Bunsu...@googlegroups.com>>.
To post to this group, send email to cds-...@googlegroups.com<mailto:cds-...@googlegroups.com><mailto:cds-...@googlegroups.com<mailto:cds-...@googlegroups.com>>.

To view this discussion on the web visit https://groups.google.com/d/msgid/cds-hooks/594bade1-9719-40e6-bb4e-ddb5c1987e1d%40googlegroups.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_cds-2Dhooks_594bade1-2D9719-2D40e6-2Dbb4e-2Dddb5c1987e1d-2540googlegroups.com&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=bB7lu6pTe1h7QviMW0AyOC-501_IGthzwhWJpI3Ty2E&s=OURDIURyx2o77Vdgf8VuznCSzCx1O37qDerqz9Dewxk&e=><https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_cds-2Dhooks_594bade1-2D9719-2D40e6-2Dbb4e-2Dddb5c1987e1d-2540googlegroups.com-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dfooter&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=tLC0F9JN_rbLykC2NBtnI0J2vVcbTNgWCLXmWl7kUJA&s=woXlUEC9ceeHOOZ43NzENWK5-ZM3mPLd4HO9RdafZ3g&e=>.
For more options, visit https://groups.google.com/d/optout<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=bB7lu6pTe1h7QviMW0AyOC-501_IGthzwhWJpI3Ty2E&s=Y5f3vY3hIRaMeZRe1A1A55P7lZGU5gE-rNe6q4BR_ic&e=><https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=tLC0F9JN_rbLykC2NBtnI0J2vVcbTNgWCLXmWl7kUJA&s=b0mFiiewl7vLiyCtCbtxVoMUcW5RL4xBWqD_AV-tL6I&e=>.

--
You received this message because you are subscribed to the Google Groups "CDS Hooks" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cds-hooks+...@googlegroups.com<mailto:cds-hooks%2Bunsu...@googlegroups.com>.
To post to this group, send email to cds-...@googlegroups.com<mailto:cds-...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/cds-hooks/E027A8A9-5FF2-4849-95BE-48AD8DFCE87B%40ge.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_cds-2Dhooks_E027A8A9-2D5FF2-2D4849-2D95BE-2D48AD8DFCE87B-2540ge.com&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=bB7lu6pTe1h7QviMW0AyOC-501_IGthzwhWJpI3Ty2E&s=Jq6eS1MNISL799bVvwKYRZOR4jUx5CeL-S_o7trYCqA&e=>.
For more options, visit https://groups.google.com/d/optout<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=bB7lu6pTe1h7QviMW0AyOC-501_IGthzwhWJpI3Ty2E&s=Y5f3vY3hIRaMeZRe1A1A55P7lZGU5gE-rNe6q4BR_ic&e=>.

--
-----
http://www.healthintersections.com.au<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.healthintersections.com.au&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=bB7lu6pTe1h7QviMW0AyOC-501_IGthzwhWJpI3Ty2E&s=l_MhNohz13x9SX0usVMST1lnhVM_3SwQjnqciW_i3Ik&e=> / gra...@healthintersections.com.au<mailto:gra...@healthintersections.com.au> / +61 411 867 065

--
You received this message because you are subscribed to the Google Groups "CDS Hooks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cds-hooks+...@googlegroups.com<mailto:cds-hooks+...@googlegroups.com>.
To post to this group, send email to cds-...@googlegroups.com<mailto:cds-...@googlegroups.com>.

To view this discussion on the web visit https://groups.google.com/d/msgid/cds-hooks/CAG47hGY%2B_E1jSwMarrBu8dMMY5eEnwUF6YR-RMDc3RhoM-Tjzg%40mail.gmail.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_cds-2Dhooks_CAG47hGY-252B-5FE1jSwMarrBu8dMMY5eEnwUF6YR-2DRMDc3RhoM-2DTjzg-2540mail.gmail.com-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dfooter&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=bB7lu6pTe1h7QviMW0AyOC-501_IGthzwhWJpI3Ty2E&s=YajDxgfGB6doivv0DkJQ7e2uqGBwrXyzPRgtr7jMwIg&e=>.
For more options, visit https://groups.google.com/d/optout<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=bB7lu6pTe1h7QviMW0AyOC-501_IGthzwhWJpI3Ty2E&s=Y5f3vY3hIRaMeZRe1A1A55P7lZGU5gE-rNe6q4BR_ic&e=>.

Rajarajan Muthukkannan

unread,

Jan 15, 2016, 4:18:50 PM1/15/16

to Kevin Shekleton, CDS Hooks

I am in agreement for a proposal to have simpler model to represent card and activity as opposed to using parameters.

As a service creator, even though there can be simpler and better ways to publicize an API and given CDS service is consuming and responding FHIR resources, I am inclined for service creator/provider to play a specialized role of FHIR server with a claim to perform CDS services and have it represented through a conformance. Having said that I am interested to hear and discuss other options. One other point is that as a CDS service creator/provider it will also align with providing library services like serving resources like KnowledgeArtifacts.

Best

Raj

--

You received this message because you are subscribed to the Google Groups "CDS Hooks" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cds-hooks+...@googlegroups.com.
To post to this group, send email to cds-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cds-hooks/65d6ebdc-4f98-4e1f-9231-d07df0a654d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Bryn Rhodes

unread,

Jan 15, 2016, 5:51:47 PM1/15/16

to Rajarajan Muthukkannan, Kevin Shekleton, CDS Hooks

Hi All,

The CDS-on-FHIR IG has proposed resources to cover some of these use cases. For example, as Jared suggested, the GuidanceResource is currently used as the response to a CDS $evaluate call, and although it's not quite as simple as a "Card"-specific resource would be, it's very close, and is intended to represent the same information. Of course it's draft, and any feedback on how to make it more usable would certainly be welcome.

As part of the connect-a-thon work, I built a $cds-hook evaluate operation that bridges to the cds $evaluate, and was able to completely represent the functionality, just in a different way. It would be nice to harmonize those approaches at some point, though I understand the focus of this effort is to explore specific functionality.

In addition, the CDS-on-FHIR IG has defined several resource specifically for representing knowledge artifacts, with the intention of being able to use a FHIR service as a knowledge management server/repository as is being suggested here.

Over the coming weeks we will be incorporating feedback from the connect-a-thon as well as the Orlando WG meetings into the CDS-on-FHIR IG, so it will continue to evolve. For anyone interested in that work, you can find more information here:

https://hl7-fhir.github.io/cqif/cqif.html

Regards,

Bryn Rhodes

br...@databaseconsultinggroup.com

To view this discussion on the web visit https://groups.google.com/d/msgid/cds-hooks/CAMTEi2m7DsjJBj9Zkoa1EaZJpJtZGEfRAff3ey8ZnfoCG0pGNg%40mail.gmail.com.

Grahame Grieve

unread,

Feb 4, 2016, 7:12:09 PM2/4/16

to Boone, Keith W (GE Healthcare), Kevin Shekleton, CDS Hooks

> I will propose one later today, hopefully

Finally got to this, but did a bit of research first.

There's actually real benefits to reusing the FHIR definitional framework for cds-hooks, around definitional integrity, introspection, and conformance testing. See, for discussion, cds-hooks defined here: http://hl7-fhir.github.io/resource-operations.html#cds-hook (there for discussion). I think that these benefits justify sticking with using a parameters resource, generally as the existing proposal works. But you've proposed 2 differences of real intent to the way cds-hooks is defined now: wire representation and invocation URL. I'll deal with each of these in turn

Serialization format

The existing format uses json to carry a series of name = value pairs with a nesting. It's a step away from just using json directly. Using json directly would be more natural. We don't do that because of XML, actually, because of how XML schema works. But the issue you identify would apply to any context in which people invoke any FHIR operation using JSON - why not just invoke it directly. Indeed, why not do that? If we modifed the rules slightly so that in json, the parameters resource is encoded directly, rather than indirectly, then the benefit would accrue to clients of multiple operations. (err, the costs would accrue to servers more, but that's generally how we like it).

So, to go back to your original proposal, what would go on the wire under this proposal would be:

{
"resourceType" : "Parameters",

"cards":[

{

"summary":"Success Card",

"detail":"This is a test of a static success card.",

"source":{

"label":"Example CDS Service",

"url":"https://www.example.com/"

},

"links":[

{

"label":"Google",

"url":"https://google.com/"

},

{

"label":"Yahoo",

"url":"https://yahoo.com/"

}

]

}

]

}

For FHIR people, used to thinking in terms of 'parameters', you'd use the definition of the operation to help you read the json structure into a parameters resource, though this method is only possible for elements with a fixed type (no choice of types, but we haven't done that anyway)

I think that's pretty close to your original proposal - close enough, and the difference is justified by the other benefits

Invocation URL

You also proposed:

The EHR can trigger the hook via Request: POST /cds-hooks/:hook/:id

and you said about this:

"CDS services will expose these two endpoints using a consistent path (/cds-hooks and /cds-hooks/:hook/:id). Currently, CDS services are available at either $cds-hook or a path of their choosing. I'd rather see us be prescriptive with the path so CDS services only need to communicate a base URL to the EHR"

well, we can do the prescriptive bit anyway without changing the URL. In fact, if you use the FHIR conformance framework, you were already constrained like that, it's just that we hadn't said that you had to use it. As for POST /cds-hooks/:hook/:id

:hook - ok, naming the hook in the URL makes sense. And wouldn't be part of the existing operations framework, though some other defined operations have a 'key' parameter that sort of scopes out a space that would make sense to use like this (though some don't). So we could talk about that as a a new feature in FHIR.

:id - this part doesn't really make sense to me. I don't think of the activity instance as being a property of the end point, but a parameter of the invocation of the end point. I know that attitudes to this question vary a great deal around the web space, and the whole state/rpc thing, and I don't feel strongly about it.

So: I think that it's worth thinking about how to make cds-hooks easier to use, but I'd like to see that in the context of FHIR, and make FHIR easier to use. And it's not just because of how I implement myself; I think that there's wider benefits.

Grahame

Kevin Shekleton

unread,

Mar 17, 2016, 2:30:30 AM3/17/16

to CDS Hooks

Thanks, Grahame for your thoughts. My apologies on not responding sooner -- time certainly has flown by!

The wire protocol you outlined is much cleaner than the current version we're working with today and very close to what I proposed. The only difference looks like you have resourceType as a top level attribute in the response which, given the choice between what we have today and your version, I'd take yours everyday. I'm curious how this new response would be handled within FHIR. I imagine it would be treated as a custom model by parsers? I have no problem with this but I'm asking as I was under the impression that one of the proposed benefits of leveraging FHIR's operations framework was that consumers would get parsing for 'free'.

Regarding my proposal for the invocation URI, my suggestion for including the activity instance (what I called :id) as part of the URI is that I felt /cds-hooks/:hook/:id best represents a RESTful approach for modeling a CDS Hooks resource for a given activity and id (activity instance). This proposal though was suggested in the context of CDS Hooks not being part of FHIR but rather just leveraging FHIR in some aspects (again, like SMART). Of course, if we decide to keep CDS Hooks as part of FHIR, we'd eschew this invocation URI proposal in favor of FHIR's URI conventions.

Thanks again for providing feedback on this. I'm sure we'll discuss this on our calls/sprints and I'm more than willing to support what we all deem is best for the community.

Best,

Kevin

On Sat, Jan 16, 2016 at 1:57 AM, Grahame Grieve <grahame@healthintersections.com.au> wrote:

hi Keith

I think you're being unreasonable. Kevin has proposed something for discussion, and we should be able have discussion about what's the best solution about what the best approach is without worrying about what 'is fhir' or not.

I think it's very useful to me and other implementers that the cds-hook service works well when implemented on a FHIR Server, and that discovery works if you start at the FHIR conformance statement. But I don't think that this should be the only way to discover the service, nor that implementing the service correctly should require a full FHIR Server. There's some aspects of Kevin's proposal that don't play well for those of use who want to implement in the context of a FHIR Server, but there may be - should be - a middle path that will work for both. I will propose one later today, hopefully

Grahame

On Sat, Jan 16, 2016 at 1:29 AM, Boone, Keith W (GE Healthcare) <keith...@ge.com> wrote:

Where SMART differs from FHIR is that it provides features not found therein. The current discussion proposes alternate features already found in FHIR for discovery.

Sent from my iPhone

On Jan 15, 2016, at 9:20 AM, Kevin Shekleton <kevin.s...@gmail.com<mailto:kevin.shekleton@gmail.com>> wrote:

Keith replied to me personally, though I'm sure he intended for his response to be in this Google group thread.

Keith wrote:
>You are using FHIR, but rather than using the FHIR framework, you are going to do something else because either, that part of the framework is too hard to use, or you cannot be bothered to figure out how to use it.
>
>Make the standard better. Don't ignore it.

Certainly my line of thinking that initially led to the thoughts that resulted in this discussion were born from my implementation work at the Connectathon. That's not to say that I found the framework hard to use or that I didn't take the time to learn it. To the contrary, I've implemented a FHIR server<https://urldefense.proofpoint.com/v2/url?u=http-3A__fhir.cerner.com_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=tLC0F9JN_rbLykC2NBtnI0J2vVcbTNgWCLXmWl7kUJA&s=ugeiaEMc52WOWd8hE7NP-Lg8rNT_pBoIDNoo0n2XWLQ&e=> (now in use in production) on top of a mature EHR with complex business rules and services. So, it's certainly not my lack of understanding with FHIR that brought me to this thinking.

It's also not that that I'm ignoring the standard or not interested in making the standard better. It's that I don't see CDS Hooks as part of FHIR; rather, I see it using FHIR (data). Consider SMART on FHIR: SMART leverages FHIR where it best fits -- sharing data from the EHR. Likewise, I'm proposing that CDS Hooks leverage FHIR in the same way.

Regards,
Kevin

On Friday, January 15, 2016 at 7:47:15 AM UTC-5, Kevin Shekleton wrote:
Hi Keith. Can you elaborate on what you find wrong?

Regards,
Kevin

On Friday, January 15, 2016 at 7:30:54 AM UTC-5, keith.boone wrote:
That is just so wrong.

Sent from my iPhone

To unsubscribe from this group and stop receiving emails from it, send an email to cds-hooks+unsubscribe@googlegroups.com<mailto:cds-hooks%2Bunsubscribe@googlegroups.com><mailto:cds-hooks+unsubscribe@googlegroups.com<mailto:cds-hooks%2Bunsubscribe@googlegroups.com>>.
To post to this group, send email to cds-...@googlegroups.com<mailto:cds-hooks@googlegroups.com><mailto:cds-hooks@googlegroups.com<mailto:cds-ho...@googlegroups.com>>.

To view this discussion on the web visit https://groups.google.com/d/msgid/cds-hooks/66321a9a-3291-4f16-8790-c855d607290a%40googlegroups.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_cds-2Dhooks_66321a9a-2D3291-2D4f16-2D8790-2Dc855d607290a-2540googlegroups.com&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=tLC0F9JN_rbLykC2NBtnI0J2vVcbTNgWCLXmWl7kUJA&s=55PXwiNtdeav2R_b0BIgDETjiVXNoXBhbjAX15rEsuk&e=><https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_cds-2Dhooks_66321a9a-2D3291-2D4f16-2D8790-2Dc855d607290a-2540googlegroups.com-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dfooter&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=VlIWsAGt5a-1zsbVF91T-c9GEfEjVVrYIQkJsZwRhek&s=Z6dQJJyYmzbVZuU_xPSINROX8YZMzZa0DDpm_EdWKqA&e=>.
For more options, visit https://groups.google.com/d/optout<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=tLC0F9JN_rbLykC2NBtnI0J2vVcbTNgWCLXmWl7kUJA&s=b0mFiiewl7vLiyCtCbtxVoMUcW5RL4xBWqD_AV-tL6I&e=><https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=VlIWsAGt5a-1zsbVF91T-c9GEfEjVVrYIQkJsZwRhek&s=wTcqOKOgSaWxRy_pCiurD2pHfLMTWIhwpVnycNFEgwI&e=>.

--
You received this message because you are subscribed to the Google Groups "CDS Hooks" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cds-hooks+unsubscribe@googlegroups.com<mailto:cds-hooks+unsubscribe@googlegroups.com>.
To post to this group, send email to cds-...@googlegroups.com<mailto:cds-hooks@googlegroups.com>.

To view this discussion on the web visit https://groups.google.com/d/msgid/cds-hooks/594bade1-9719-40e6-bb4e-ddb5c1987e1d%40googlegroups.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_cds-2Dhooks_594bade1-2D9719-2D40e6-2Dbb4e-2Dddb5c1987e1d-2540googlegroups.com-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dfooter&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=tLC0F9JN_rbLykC2NBtnI0J2vVcbTNgWCLXmWl7kUJA&s=woXlUEC9ceeHOOZ43NzENWK5-ZM3mPLd4HO9RdafZ3g&e=>.
For more options, visit https://groups.google.com/d/optout<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=_V5W6w_wI5HOMI7JpAQvQdQOzM3ZKwQx-Qa2F-ui1oY&m=tLC0F9JN_rbLykC2NBtnI0J2vVcbTNgWCLXmWl7kUJA&s=b0mFiiewl7vLiyCtCbtxVoMUcW5RL4xBWqD_AV-tL6I&e=>.

--
You received this message because you are subscribed to the Google Groups "CDS Hooks" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cds-hooks+unsubscribe@googlegroups.com.

To post to this group, send email to cds-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cds-hooks/E027A8A9-5FF2-4849-95BE-48AD8DFCE87B%40ge.com.

For more options, visit https://groups.google.com/d/optout.

--
-----
http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065

--
-----
http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065

Grahame Grieve

unread,

Mar 17, 2016, 6:46:40 AM3/17/16

to Kevin Shekleton, CDS Hooks

hi Kevin.

Comments inline

The wire protocol you outlined is much cleaner than the current version we're working with today and very close to what I proposed. The only difference looks like you have resourceType as a top level attribute in the response which, given the choice between what we have today and your version, I'd take yours everyday. I'm curious how this new response would be handled within FHIR. I imagine it would be treated as a custom model by parsers? I have no problem with this but I'm asking as I was under the impression that one of the proposed benefits of leveraging FHIR's operations framework was that consumers would get parsing for 'free'.

well, this is a half-way house. I'm thinking that anyone using operations (the parameters type) in json is pretty much going to be thinking the same thing, so I'd propose it as a special case for parsers to support - though the interesting thing is that it only works if you know the type of the element in advance; it doesn't work well for extensibility.

Regarding my proposal for the invocation URI, my suggestion for including the activity instance (what I called :id) as part of the URI is that I felt /cds-hooks/:hook/:id best represents a RESTful approach for modeling a CDS Hooks resource for a given activity and id (activity instance). This proposal though was suggested in the context of CDS Hooks not being part of FHIR but rather just leveraging FHIR in some aspects (again, like SMART). Of course, if we decide to keep CDS Hooks as part of FHIR, we'd eschew this invocation URI proposal in favor of FHIR's URI conventions.

well, again, we can grow the conventions in FHIR if it's a good idea. Is there always an activity instance? as for 'restful', the cds-hook thing is inherently rpc, isn't it? there's no transfer of state, only the requesting of a comment to be made?...

Grahame

Kevin Shekleton

unread,

Mar 17, 2016, 8:49:18 AM3/17/16

to CDS Hooks, kevin.s...@gmail.com

Inline as well. :-)

On Thursday, March 17, 2016 at 5:46:40 AM UTC-5, grahame wrote:

hi Kevin.

Comments inline

The wire protocol you outlined is much cleaner than the current version we're working with today and very close to what I proposed. The only difference looks like you have resourceType as a top level attribute in the response which, given the choice between what we have today and your version, I'd take yours everyday. I'm curious how this new response would be handled within FHIR. I imagine it would be treated as a custom model by parsers? I have no problem with this but I'm asking as I was under the impression that one of the proposed benefits of leveraging FHIR's operations framework was that consumers would get parsing for 'free'.

well, this is a half-way house. I'm thinking that anyone using operations (the parameters type) in json is pretty much going to be thinking the same thing, so I'd propose it as a special case for parsers to support - though the interesting thing is that it only works if you know the type of the element in advance; it doesn't work well for extensibility.

Gotcha. This is was I was expecting but good to hear you confirm. If you're fine with a custom parser, I'm not sure why it's necessary to use any of the operations framework since it would be so different than what exists in FHIR today. Additionally, by leveraging FHIR operations, does this imply that CDS Hooks should support/define XML APIs as well? I know that a FHIR server isn't under any obligation to support a particular format, but I know that FHIR makes deliberate and conscience design decisions to ensure both JSON and XML formats are handled with any feature. If CDS Hooks were part of FHIR, I would imagine it should follow the same path.

Regarding my proposal for the invocation URI, my suggestion for including the activity instance (what I called :id) as part of the URI is that I felt /cds-hooks/:hook/:id best represents a RESTful approach for modeling a CDS Hooks resource for a given activity and id (activity instance). This proposal though was suggested in the context of CDS Hooks not being part of FHIR but rather just leveraging FHIR in some aspects (again, like SMART). Of course, if we decide to keep CDS Hooks as part of FHIR, we'd eschew this invocation URI proposal in favor of FHIR's URI conventions.

well, again, we can grow the conventions in FHIR if it's a good idea. Is there always an activity instance? as for 'restful', the cds-hook thing is inherently rpc, isn't it? there's no transfer of state, only the requesting of a comment to be made?...

The activity instance as defined today marks an instance of a CDS Hook call. I don't think CDS Hooks is inherently RPC. The client (EHR) certainly transfers state based upon the the cards (and links therein). If you're looking for a full HATEOS design, I agree that's not here (or nearly anywhere for that matter). However, a CDS Service should share all of the other properties of a RESTful design (stateless, layered, uniform interface, etc).

Grahame

Grahame Grieve

unread,

Mar 17, 2016, 3:01:45 PM3/17/16

to Kevin Shekleton, CDS Hooks

hi Kevin.

inline still

well, this is a half-way house. I'm thinking that anyone using operations (the parameters type) in json is pretty much going to be thinking the same thing, so I'd propose it as a special case for parsers to support - though the interesting thing is that it only works if you know the type of the element in advance; it doesn't work well for extensibility.

Gotcha. This is was I was expecting but good to hear you confirm. If you're fine with a custom parser, I'm not sure why it's necessary to use any of the operations framework since it would be so different than what exists in FHIR today.

well, I was thinking it would be applicable to any FHIR operation. But it's inherently not stably extensible, which is a challenge for your proposal anyway

Additionally, by leveraging FHIR operations, does this imply that CDS Hooks should support/define XML APIs as well? I know that a FHIR server isn't under any obligation to support a particular format, but I know that FHIR makes deliberate and conscience design decisions to ensure both JSON and XML formats are handled with any feature. If CDS Hooks were part of FHIR, I would imagine it should follow the same path.

well, it falls out of re-using the FHIR definitional framework, and there are many implementations that prefer XML, yes. But we can say 'not supported in this case' or something if people want to minimise the load in that regard.

Regarding my proposal for the invocation URI, my suggestion for including the activity instance (what I called :id) as part of the URI is that I felt /cds-hooks/:hook/:id best represents a RESTful approach for modeling a CDS Hooks resource for a given activity and id (activity instance). This proposal though was suggested in the context of CDS Hooks not being part of FHIR but rather just leveraging FHIR in some aspects (again, like SMART). Of course, if we decide to keep CDS Hooks as part of FHIR, we'd eschew this invocation URI proposal in favor of FHIR's URI conventions.

well, again, we can grow the conventions in FHIR if it's a good idea. Is there always an activity instance? as for 'restful', the cds-hook thing is inherently rpc, isn't it? there's no transfer of state, only the requesting of a comment to be made?...

The activity instance as defined today marks an instance of a CDS Hook call. I don't think CDS Hooks is inherently RPC. The client (EHR) certainly transfers state based upon the the cards (and links therein). If you're looking for a full HATEOS design, I agree that's not here (or nearly anywhere for that matter). However, a CDS Service should share all of the other properties of a RESTful design (stateless, layered, uniform interface, etc).

well, there's only get. can I post a card to a URL? It's not really what I think of when I think of RESTful

Grahame

Kevin Shekleton

unread,

Mar 18, 2016, 7:49:46 AM3/18/16

to CDS Hooks, kevin.s...@gmail.com

Inline

I've never heard that RESTful implies/requires full CRUD for resources. In this case, the EHR is retrieving cards from the RESTful CDS service; the EHR isn't creating cards.

Grahame

Grahame Grieve

unread,

Mar 18, 2016, 2:41:45 PM3/18/16

to Kevin Shekleton, CDS Hooks

You're a man of many words ;-)

I agree that there's no functional requirement. I was just trying to figure out why I don't think of it as RESTful. I guess because the activity itself has no meaning; the outputs are entirely based on the inputs

Grahame

--
You received this message because you are subscribed to the Google Groups "CDS Hooks" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cds-hooks+...@googlegroups.com.

To post to this group, send email to cds-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cds-hooks/e196a98a-245c-4446-ba74-2c39ecadb032%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

-----
http://www.healthintersections.com.au / gra...@healthintersections.com.au / +61 411 867 065

Reply all

Reply to author

Forward