IP Review

Unattributed Code Systems

http://unstats.un.org/unsd/methods/m49/m49.htm

Copyright Fragment

This fragment is not visible to the reader

No use of external IP

Copyright and Registered Trademark Uses

IG © 2019+ Clinical Decision Support WG. Package hl7.fhir.uv.cds-hooks#2.0.1 based on FHIR 4.0.1. Generated 2025-03-12 Links: Table of Contents | QA Report | Version History | CC0 | Propose a change ( src )
hl7.fhir.us.hai: Healthcare Associated Infection Implementation Guide ®© HL7 | CC0 ( src )

External References

Type Reference Content

web github.com 505 : Add optional card.source.topic to allow CDS Service to identify a high-level category

web github.com 513 : CDS Service can suggest override reasons for user's to explain why guidance isn't taken

web github.com 519 : CDS Client provides feedback to Service following user interaction (fka analytics endpoint)

web github.com 187 : Conformance requirements for JWT signing algorithms

web github.com 232 : Moved user from the request to hook context definitions

web github.com 259 : Removed the analytics endpoint pending further implementation experience

web github.com 320 : Added a new required selectionBehavior field to cards

web github.com 340 : Changed 'hard-stop' indicator value to 'critical'

web github.com In addition, numerous clarifications, corrections, and non-substantive updates were made to the specification based on ballot and implementer feedback. For a complete list of changes applied, see the issues under the Github 1.0 Milestone or the repository commit log.

web github.com This was the first STU release for the CDS Hooks specification. For a complete history of changes, see the repository commit log .

web en.wikipedia.org This HL7 CDS Hooks Implementation Guide is published at the level of Standard for Trial Use . It describes a "hook" -based pattern for invoking decision support from within a clinician's workflow. The API supports:

web cds-hooks.org See https://cds-hooks.org/ for additional information, resources and ways to get involved.

web en.wikipedia.org This specification describes a "hook" -based pattern for invoking decision support from within a clinician's workflow. The API supports:

web oauth.net A structure holding an OAuth 2.0 bearer access token granting the CDS Service access to FHIR resources, along with supplemental information relating to the token. See the FHIR Resource Access section for more information.

web oauth.net With CDS Hooks, if the CDS Client wants to provide the CDS Service direct access to FHIR resources, the CDS Client creates or obtains an access token prior to invoking the CDS Service, passing this token to the CDS Service as part of the service call. This approach remains compatible with OAuth 2.0's bearer token protocol while minimizing the number of HTTPS round-trips and the service invocation latency. The CDS Client remains in control of providing an access token that is associated with the specific CDS Service, user, and context of the invocation. As the CDS Service executes on behalf of a user, the data to which the CDS Service is given access by the CDS Client MUST be limited to the same restrictions and authorizations afforded the current user. As such, the access token SHALL be scoped to:

web oauth.net This is the OAuth 2.0 access token that provides access to the FHIR server.

web oauth.net The OAuth 2.0 client identifier of the CDS Service, as registered with the CDS Client's authorization server.

web github.github.com Optional detailed information to display; if provided MUST be represented in (GitHub Flavored) Markdown . (For non-urgent cards, the CDS Client MAY hide these details until the user clicks a link like "view more details…").

web oauth.net An optional field that allows the CDS Service to share information from the CDS card with a subsequently launched SMART app. The appContext field should only be valued if the link type is smart and is not valid for absolute links. The appContext field and value will be sent to the SMART app as part of the OAuth 2.0 access token response, alongside the other SMART launch parameters when the SMART app is launched. Note that appContext could be escaped JSON, base64 encoded XML, or even a simple string, so long as the SMART app can recognize it. CDS Client support for appContext requires additional coordination with the authorization server that is not described or specified in CDS Hooks nor SMART.

web en.wikipedia.org ISO8601 representation of the date and time in Coordinated Universal Time (UTC) when action was taken on the card, as profiled in section 5.6 of RFC3339 . e.g. 1985-04-12T23:20:50.52Z

web cds-hooks.org CDS Hooks defines a security model that addresses these risks by assuring that the identities of both the CDS Service and the CDS Client are authenticated to each other; by protecting confidential information and privileged authorizations shared between a CDS Client and a CDS Service; by recommending means of assuring data freshness; and by incorporating business mechanisms through which trust is established and maintained between a CDS Client and a CDS Service. As with any access to protected patient information, systems should ensure that they have appropriate authorization and audit mechanisms in place to support transparency of use of the data. For more information, refer to Security Best Practices .

web jwt.io However, mutual TLS is impractical for many organizations. In the absence of mutual TLS, only the CDS Service endpoint will be authenticated because the CDS Client initiates the TLS channel set-up. To enable the CDS Service to authenticate the identity of the CDS Client, CDS Hooks uses digitally signed JSON web tokens (JWT) ( rfc7519 ). CDS Services SHOULD require authentication if invoking the service poses any risk of exposing sensitive data to the caller.

web cheatsheetseries.owasp.org CDS Services and browser-based CDS Clients will require CORS support. A secure implementation guide for CORS is outside of the scope of this CDS Hooks specification. Organizations planning to implement CDS Hooks with CORS support are referred to the Cross-Origin Resource Sharing section of the OWASP HTML5 Security Cheat Sheet .

web github.com As a specification, CDS Hooks does not prescribe a default or required set of hooks for implementers. Rather, the set of hooks defined here are merely a set of common use cases that were used to aid in the creation of CDS Hooks. The set of hooks defined here are not a closed set; anyone is able to define new hooks to fit their use cases and propose those hooks to the community. New hooks are proposed in a prescribed format using the documentation template by submitting a pull request for community feedback. Hooks are versioned , and mature according to the Hook Maturity Model .

web github.com The above, and … Hook definition is written up as a github pull request using the Hook template and community feedback is solicited on the zulip CDS Hooks stream .

web semver.org When a major change is made, the hook definition MUST be published under a new name. When a minor or patch change is made, the hook version MUST be updated. Hook definers MUST use semantic versioning to communicate the impact of changes in an industry standard way.

Type	Reference	Content
web	github.com	505 : Add optional card.source.topic to allow CDS Service to identify a high-level category
web	github.com	513 : CDS Service can suggest override reasons for user's to explain why guidance isn't taken
web	github.com	519 : CDS Client provides feedback to Service following user interaction (fka analytics endpoint)
web	github.com	187 : Conformance requirements for JWT signing algorithms
web	github.com	232 : Moved user from the request to hook context definitions
web	github.com	259 : Removed the analytics endpoint pending further implementation experience
web	github.com	320 : Added a new required selectionBehavior field to cards
web	github.com	340 : Changed 'hard-stop' indicator value to 'critical'
web	github.com	In addition, numerous clarifications, corrections, and non-substantive updates were made to the specification based on ballot and implementer feedback. For a complete list of changes applied, see the issues under the Github 1.0 Milestone or the repository commit log.
web	github.com	This was the first STU release for the CDS Hooks specification. For a complete history of changes, see the repository commit log .
web	en.wikipedia.org	This HL7 CDS Hooks Implementation Guide is published at the level of Standard for Trial Use . It describes a "hook" -based pattern for invoking decision support from within a clinician's workflow. The API supports:
web	cds-hooks.org	See https://cds-hooks.org/ for additional information, resources and ways to get involved.
web	en.wikipedia.org	This specification describes a "hook" -based pattern for invoking decision support from within a clinician's workflow. The API supports:
web	oauth.net	A structure holding an OAuth 2.0 bearer access token granting the CDS Service access to FHIR resources, along with supplemental information relating to the token. See the FHIR Resource Access section for more information.
web	oauth.net	With CDS Hooks, if the CDS Client wants to provide the CDS Service direct access to FHIR resources, the CDS Client creates or obtains an access token prior to invoking the CDS Service, passing this token to the CDS Service as part of the service call. This approach remains compatible with OAuth 2.0's bearer token protocol while minimizing the number of HTTPS round-trips and the service invocation latency. The CDS Client remains in control of providing an access token that is associated with the specific CDS Service, user, and context of the invocation. As the CDS Service executes on behalf of a user, the data to which the CDS Service is given access by the CDS Client MUST be limited to the same restrictions and authorizations afforded the current user. As such, the access token SHALL be scoped to:
web	oauth.net	This is the OAuth 2.0 access token that provides access to the FHIR server.
web	oauth.net	The OAuth 2.0 client identifier of the CDS Service, as registered with the CDS Client's authorization server.
web	github.github.com	Optional detailed information to display; if provided MUST be represented in (GitHub Flavored) Markdown . (For non-urgent cards, the CDS Client MAY hide these details until the user clicks a link like "view more details…").
web	oauth.net	An optional field that allows the CDS Service to share information from the CDS card with a subsequently launched SMART app. The `appContext` field should only be valued if the link type is `smart` and is not valid for `absolute` links. The `appContext` field and value will be sent to the SMART app as part of the OAuth 2.0 access token response, alongside the other SMART launch parameters when the SMART app is launched. Note that `appContext` could be escaped JSON, base64 encoded XML, or even a simple string, so long as the SMART app can recognize it. CDS Client support for `appContext` requires additional coordination with the authorization server that is not described or specified in CDS Hooks nor SMART.
web	en.wikipedia.org	ISO8601 representation of the date and time in Coordinated Universal Time (UTC) when action was taken on the card, as profiled in section 5.6 of RFC3339 . e.g. 1985-04-12T23:20:50.52Z
web	cds-hooks.org	CDS Hooks defines a security model that addresses these risks by assuring that the identities of both the CDS Service and the CDS Client are authenticated to each other; by protecting confidential information and privileged authorizations shared between a CDS Client and a CDS Service; by recommending means of assuring data freshness; and by incorporating business mechanisms through which trust is established and maintained between a CDS Client and a CDS Service. As with any access to protected patient information, systems should ensure that they have appropriate authorization and audit mechanisms in place to support transparency of use of the data. For more information, refer to Security Best Practices .
web	jwt.io	However, mutual TLS is impractical for many organizations. In the absence of mutual TLS, only the CDS Service endpoint will be authenticated because the CDS Client initiates the TLS channel set-up. To enable the CDS Service to authenticate the identity of the CDS Client, CDS Hooks uses digitally signed JSON web tokens (JWT) ( rfc7519 ). CDS Services SHOULD require authentication if invoking the service poses any risk of exposing sensitive data to the caller.
web	cheatsheetseries.owasp.org	CDS Services and browser-based CDS Clients will require CORS support. A secure implementation guide for CORS is outside of the scope of this CDS Hooks specification. Organizations planning to implement CDS Hooks with CORS support are referred to the Cross-Origin Resource Sharing section of the OWASP HTML5 Security Cheat Sheet .
web	github.com	As a specification, CDS Hooks does not prescribe a default or required set of hooks for implementers. Rather, the set of hooks defined here are merely a set of common use cases that were used to aid in the creation of CDS Hooks. The set of hooks defined here are not a closed set; anyone is able to define new hooks to fit their use cases and propose those hooks to the community. New hooks are proposed in a prescribed format using the documentation template by submitting a pull request for community feedback. Hooks are versioned , and mature according to the Hook Maturity Model .
web	github.com	As a specification, CDS Hooks does not prescribe a default or required set of hooks for implementers. Rather, the set of hooks defined here are merely a set of common use cases that were used to aid in the creation of CDS Hooks. The set of hooks defined here are not a closed set; anyone is able to define new hooks to fit their use cases and propose those hooks to the community. New hooks are proposed in a prescribed format using the documentation template by submitting a pull request for community feedback. Hooks are versioned , and mature according to the Hook Maturity Model .
web	github.com	The above, and … Hook definition is written up as a github pull request using the Hook template and community feedback is solicited on the zulip CDS Hooks stream .
web	github.com	The above, and … Hook definition is written up as a github pull request using the Hook template and community feedback is solicited on the zulip CDS Hooks stream .
web	semver.org	When a major change is made, the hook definition MUST be published under a new name. When a minor or patch change is made, the hook version MUST be updated. Hook definers MUST use semantic versioning to communicate the impact of changes in an industry standard way.

Unattributed Code Systems

Copyright Fragment

Copyright and Registered Trademark Uses

External References

Internal Images