Skip to content

Commit cecb7ce

Browse files
authored
Clarify the expectations upon an EHR around the data visible to a CDS Service. (#374)
Fixes #250
1 parent 2959c2a commit cecb7ce

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

docs/specification/1.0.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -293,7 +293,7 @@ The CDS Service is able to use the EHR's FHIR server to obtain any FHIR resource
293293

294294
Like SMART on FHIR, CDS Hooks requires that clients present a valid access token to the FHIR server with each API call. Thus, a CDS Service must be able to obtain an access token before communicating with the EHR's FHIR resource server. While CDS Hooks shares the underlying technical framework and standards as SMART on FHIR, the CDS Hooks workflow must accommodate the automated, low-latency delivery of an access token to the CDS service.
295295

296-
With CDS Hooks, if the EHR wants to provide the CDS Service direct access to FHIR resources, the EHR creates 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 EHR remains in control of creating 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 MUST BE limited to the same restrictions and authorizations afforded the current user. As such, the access token SHALL BE scoped to:
296+
With CDS Hooks, if the EHR wants to provide the CDS Service direct access to FHIR resources, the EHR creates 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 EHR remains in control of creating 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 EHR MUST BE limited to the same restrictions and authorizations afforded the current user. As such, the access token SHALL BE scoped to:
297297

298298
- The CDS Service being invoked
299299
- The current user

0 commit comments

Comments
 (0)