Add CDS Hooks #707
Add CDS Hooks #707
Conversation
content/cds_hooks.md
Outdated
| ## General ## | ||
|
|
||
| ### Introduction ### | ||
| The CDS Hooks (Clinical Decision Support Hooks) workflow defines a specification for external CDS Service developers to send notification cards to an electronic health record (EHR). These cards are triggered based on conditions such as the opening of a patient chart of a specified demographic(age, gender, etc.) or when an order is selected. These cards can contain information, a suggestion for the user, or a link to launch a SMART app (See [SMART](./smart) for more information). |
There was a problem hiding this comment.
@fpivonka, @VelocityKnight would it be better to reword it as follows?
The CDS Hooks (Clinical Decision Support Hooks) workflow provides external CDS Service developers the ability to send CDS cards to an electronic health record (EHR). The external CDS service will be triggered based on conditions such as opening a patient chart for the specified demographic(age, gender, etc.) or when an order is selected and the cards returned from the service will be presented to the user in the EHR. The cards can contain textual guidance, actionable suggestion for the user, or a link to launch a SMART app (See [SMART](./smart) for more information).
There was a problem hiding this comment.
content/cds_hooks.md
Outdated
| For more information on CDS Authorization best practices, see [this page](https://cds-hooks.org/best-practices/#jwt). | ||
|
|
||
| ### Service Response ### | ||
| When the specified condition(s) in the EHR are met, the CDS Hooks Server will make a GET request to the provided service url. The CDS service should return an array of cards formatted according to the [CDS Service HTTP Response specification](https://cds-hooks.hl7.org/1.0/#http-response). |
There was a problem hiding this comment.
content/cds_hooks.md
Outdated
| ### Introduction ### | ||
| The CDS Hooks (Clinical Decision Support Hooks) workflow provides external CDS Service developers the ability to send CDS cards to an electronic health record (EHR). The external CDS service will be triggered based on conditions such as opening a patient chart for the specified demographic(age, gender, etc.) or when an order is selected and the cards returned from the service will be presented to the user in the EHR. The cards can contain textual guidance, an actionable suggestion for the user, or a link to launch a SMART app (See [SMART](./smart) for more information). | ||
|
|
||
| As a CDS Service Developer, you will work with clients or on your own to create a service that will be called by the CDS Hooks Server when a condition you specify is met. To develop a service, you should first gather the information needed for clients to register your service (See [CDS Service Registration](./cds_hooks/#cds-service-registration)). Then, build your service API so that is uses correct authorization (See [Service Authorization](./cds_hooks/#service-registration)) and returns a properly formatted response (See [Service Response](./cds_hooks/#service-response)). Finally, your service should be available for the CDS Hooks Server to call on a client by client basis. |
There was a problem hiding this comment.
I must have forgotten to post this comment. I was thinking may be the below text reads better. what do you think?
As a CDS Service Developer, you will work with clients or on your own to create a service based on the [CDS Hooks specification](https://cds-hooks.hl7.org/) that will be called by the CDS Hooks Server when a condition you specify is met. Your service API should be build so that it uses correct authorization (See [Service Authorization](./cds_hooks/#service-authorization)) and returns a properly formatted response (See [Service Response](./cds_hooks/#service-response)). Once you are ready to integrate your service to the EHR system you will need to request your service to be registered (See [CDS Service Registration](./cds_hooks/#cds-service-registration)). Finally, your service should be available for the CDS Hooks Server to call on a client by client basis.
There was a problem hiding this comment.
content/cds_hooks.md
Outdated
| ### Supported Hooks ### | ||
| Currently, Cerner supports the following CDS Hooks: | ||
|
|
||
| - [Patient View](https://cds-hooks.org/hooks/patient-view/) |
There was a problem hiding this comment.
I think we might need to specify which version we support as well
There was a problem hiding this comment.
content/cds_hooks.md
Outdated
|
|
||
| ## General ## | ||
|
|
||
| ### Introduction ### |
There was a problem hiding this comment.
Should we have a note at the end of the introduction to mention CDS Hooks is dependent on specific software releases and then point to our reference pages? I don't want to put the actual releases on our reference page since we've had to change them frequently. I know 3rd party developers won't have access to those reference pages but clients will. Thoughts?
EDIT: after talking in scrum I think we'll disregard this and not make a note on fhir.cerner.com about releases. We'll probably also need to wait to push fhir.cerner.com changes until we have the packages available in c1941 and p1941
Description
PR Checklist