FHIR Chat · docs / Issue #206 Remove "subject" property from "fhirAut... · cds hooks/github

Stream: cds hooks/github

Topic: docs / Issue #206 Remove "subject" property from "fhirAut...

Github Notifications (May 15 2018 at 12:43):

jmandel opened Issue #206

Currently we define a "fhirAuthorization" object with a subject property:


This is the only place in the specification where the CDS Service's client_id (as issued by the EHR at registration time) is used, and it doesn't provide any benefit. The CDS Service already has an EHR-issued JWT at this point in the workflow, including a signature that can be used to authenticate the request, and an aud field tying the request to this particular Service endpoint. Adding a client_id into the mix creates confusion without benefit.

I'd recommend:

1. Removing this property from the fhirAuthorization object definition
2. Removing this property from all examples
3. Strike the indicated six words from: "Pre-registration MUST include ~registering a CDS client identifier, and~ agreeing upon the scope of FHIR access..."
4. Strike the entire first parenthetical from: "The specification requires that each CDS Service provider be registered ~(client_id, key-pair identifier)~ with the EHR Authorization Server, but does not dictate how registration is accomplished (e.g., dynamic vs. manual) — since the client_id should be unnecessary, and we do not in fact require or even describe the use of a CDS-service-held keypair.

Github Notifications (May 15 2018 at 12:44):

jmandel edited Issue #206

Currently we define a "fhirAuthorization" object with a subject property:


This is the only place in the specification where the CDS Service's client_id (as issued by the EHR at registration time) is used, and it doesn't provide any benefit. The CDS Service already has an EHR-issued JWT at this point in the workflow, including a signature that can be used to authenticate the request, and an aud field tying the request to this particular Service endpoint. Adding a client_id into the mix creates confusion without benefit.

I'd recommend:

1. Removing this property from the fhirAuthorization object definition
2. Removing this property from all examples
3. Strike the indicated six words from: "Pre-registration MUST include ~registering a CDS client identifier, and~ agreeing upon the scope of FHIR access..."
4. Strike the indicated parenthetical from: "The specification requires that each CDS Service provider be registered ~(client_id, key-pair identifier)~ with the EHR Authorization Server, but does not dictate how registration is accomplished (e.g., dynamic vs. manual) — since the client_id should be unnecessary, and we do not in fact require or even describe the use of a CDS-service-held keypair.

Github Notifications (May 15 2018 at 12:44):

jmandel labeled Issue #206

Github Notifications (May 15 2018 at 12:44):

jmandel labeled Issue #206

Github Notifications (May 15 2018 at 12:49):

jmandel edited Issue #206

Currently we define a "fhirAuthorization" object with a subject property:


This is the only place in the specification where the CDS Service's client_id (as issued by the EHR at registration time) is used, and it doesn't provide any benefit. The CDS Service already has an EHR-issued JWT at this point in the workflow, including a signature that can be used to authenticate the request, and an aud field tying the request to this particular Service endpoint. Adding a client_id into the mix creates confusion without benefit.

I'd recommend:

1. Remove this property from the fhirAuthorization object definition
2. Remove this property from all examples
3. Strike the indicated six words from: "Pre-registration MUST include ~registering a CDS client identifier, and~ agreeing upon the scope of FHIR access..."
4. Strike the indicated parenthetical from: "The specification requires that each CDS Service provider be registered ~(client_id, key-pair identifier)~ with the EHR Authorization Server, but does not dictate how registration is accomplished (e.g., dynamic vs. manual) — since the client_id should be unnecessary, and we do not in fact require or even describe the use of a CDS-service-held keypair.

Github Notifications (May 15 2018 at 12:51):

jmandel edited Issue #206

Currently we define a "fhirAuthorization" object with a subject property:


This is the only place in the specification where the CDS Service's client_id (as issued by the EHR at registration time) is used, and it doesn't provide any benefit. The CDS Service already has an EHR-issued JWT at this point in the workflow, including a signature that can be used to authenticate the request, and an aud field tying the request to this particular Service endpoint. Adding a client_id into the mix creates confusion without benefit.

I'd recommend:

1. Removing this property from the fhirAuthorization object definition
2. Removing this property from all examples
3. Strike the indicated six words from: "Pre-registration MUST include ~registering a CDS client identifier, and~ agreeing upon the scope of FHIR access..."
4. Strike the indicated parenthetical from: "The specification requires that each CDS Service provider be registered ~(client_id, key-pair identifier)~ with the EHR Authorization Server, but does not dictate how registration is accomplished (e.g., dynamic vs. manual)". Since the client_id should be unnecessary, and we do not in fact require or even describe the use of a CDS-service-held keypair.

Last updated: Apr 12 2022 at 19:14 UTC