-
Notifications
You must be signed in to change notification settings - Fork 61
Original Proposed Security Model
Latest Security Model in the CDS Hooks Specification
Material here for historical reference only.
There are several concerns regarding security within CDS Hooks:
- The EHR trusting the CDS Services to invoke
- The CDS Service trusting communication with EHRs invoking them
- The CDS Service being able to access the FHIR server of the EHR
Each of these concerns is covered below.
The EHR must be able to trust the CDS Services that it invokes. TLS is the means of establishing this type of trust with a CDS Service deployed to a TLS protected base URL. The EHR should use a standard means of verifying identity and trust to this endpoint (see rfc 5280 and rfc 6125).
It is also assumed that CDS Services are configured by the EHR via some offline process according to the business rules and practices of both the EHR and CDS Service organizations.
ℹ️ At the January 2017 Connectathon in San Antonio, TX, a significant number of CDS Hooks track participants representing both EHRs and CDS Service providers met in a breakout session and discussed this approach. The group reached consensus on the above proposal.
The CDS Service must be able to trust that the EHR organization invoking its decision support is authorized to do so. This is often to ensure that the EHR organization has licensed the decision support service.
As an initial proposal, we'd like to consider a model where the EHR generates a signed ehr_id_token as part of the CDS Hooks Request. The token would take the same form as the Authentication JWT in SMART's Backend Services specification, with small tweaks to clarify that the EHR is acting in the "client" role. The EHR creates a JWT with each of the following claims, signed using the EHR's private key:
| EHR ID Token JWT Claims | ||
|---|---|---|
iss |
required | The EHR's FHIR Service endpoint URL |
aud |
required | The CDS Service endpoint that is being called by the EHR |
exp |
required | Expiration time integer for this authentication JWT, expressed in seconds since the "Epoch" (1970-01-01T00:00:00Z UTC). This time MUST be no more than five minutes in the future. |
jti |
required | A nonce string value that uniquely identifies this authentication JWT. |
❓ Should the "issuer" be the EHR's FHIR Server URL, or a URL determined by the EHR's authorization server? If it's the authorization server, we need to make sure the CDS Service has a way to learn/verify id (e.g. by adding an "issuer" extension to the EHR's Conformance statement). If it's the FHIR Server, we need to make sure the public key can be discovered by the CDS Service (e.g. by adding a "public key" extension to the Conformance statement).
The CDS Service is able to use the FHIR server of the EHR to obtain any additional data it needs in order to perform its decision support. As the CDS Service is executing on behalf of a user, it is important that the data the CDS Service has access to is under the same restrictions/authorization as the current user.
It is assumed that the FHIR server will be protected by an authorization server leveraging OAuth 2 and the security model defined by SMART on FHIR.
In SMART on FHIR, the SMART app is responsible for requesting an access token each time it is invoked. In CDS Hooks, the EHR is responsible for passing the CDS Service the necessary information to invoke the FHIR server of the EHR. Where a SMART app is likely to just be invoked once while in a patient's chart, the EHR may invoke the CDS Service multiple times in a workflow. As such, the cost of the CDS Service requesting and obtaining an access token to the FHIR server would impede the performance of the decision support. While the CDS Service could request an access token on behalf of the current user, doing so introduces a practical requirement on each CDS Service to maintain a progressive cache of access tokens for user user/patient combination in order to mitigate the performance cost.
By putting the burden on the EHRs to obtain this access token, it is left to the EHR to manage this cost appropriately. Given the authorization server and EHR are controlled by the same organization, it is assumed the EHR is in a much better position to implement strategies to both obtain and manage access tokens in a performant manner in a model like CDS Hooks.
Unlike SMART apps, CDS Services should treat access tokens as transient tokens used during the course of a single evaluation of decision support.
ℹ️ At the January 2017 Connectathon in San Antonio, TX, a significant number of CDS Hooks track participants representing both EHRs and CDS Service providers met in a breakout session and discussed this approach. The group reached consensus on the above proposal.