CH EPR FHIR (R4)
5.0.0-ballot-ci-build - ci-build
CH EPR FHIR (R4)
5.0.0-ballot-ci-build - ci-build
CH EPR FHIR (R4), published by eHealth Suisse. This guide is not an authorized publication; it is the continuous build for version 5.0.0-ballot-ci-build built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/ehealthsuisse/ch-epr-fhir/ and changes regularly. See the Directory of published versions
At launch time an App may connect to the Authorization Server to retrieve the configuration data. The Authorization Server responds with the configuration data and the Authorization Server endpoint the App shall direct the User Agent to.
Actor: Authorization Client or Resource Server
Role: Sends a request to the Authorization Server to retrieve configuration data and the server endpoint to redirect the User Agent to.
Actor: Authorization Server
Role: Responds with the FHIR Server configuration data.
An EPR App (portal, primary system or SMART on FHIR App) wants to retrieve the Authorization Server metadata (e.g. , authorization endpoint locations, key material required for signature validation, or other relevant authorization data).
The Authorization Client or Resource Server performs an HTTP GET request to the Authorization Server well-known endpoint URL for the smart configuration. The request SHALL neither use parameter nor body data.
The Authorization Client or Resource Server MAY read the URL of the IUA Authorization Server and redirect the User Agent to the Authorization Server.
GET {URL-Server}/.well-known/smart-configuration HTTP/1.1
The Authorization Server SHALL respond with an HTTP response conveying a JSON formatted object as HTTP body element. The JSON object SHALL convey the following attributes:
| Attribute | Optionality | Reference | Description |
|---|---|---|---|
| authorization_endpoint | R | SMART on FHIR / IUA | URL to the IUA Authorization Server endpoint. |
| token_endpoint | R | SMART on FHIR / IUA | Authorization Server's Authorization token end-point location. |
| token_endpoint_auth_methods_supported | O | SMART on FHIR | Client authentication methods supported by the token endpoint. When provided, this list SHALL include "client_secret_basic" and SHOULD include “client_secret_post”. |
| registration_endpoint | O | SMART on FHIR | URL to the OAuth2 dynamic registration endpoint for this FHIR server. |
| scopes_supported | O | SMART on FHIR / IUA | Recommended: Supported scopes. |
| response_types_supported | R | SMART on FHIR / IUA | Supported OAuth 2.1 response_type values. |
| grant_types_supported | R | IUA | SHALL include “authorization_code” and "urn:ietf:params:oauth:grant-type:jwt-bearer". |
| management_endpoint | O | SMART on FHIR | URL an end-user can view which applications currently have access to data and can make adjustments to these access rights. |
| revocation_endpoint | O | SMART on FHIR | Recommended: URL to a server’s revoke endpoint that can be used to revoke a token. |
| capabilities | R | SMART on FHIR | SMART capabilities (e.g., single-sign-on or launch-standalone) that the server supports. |
| issuer | R | IUA | The Authorization Server's issuer identifier. |
| jwks_uri | R | IUA | URL of the Authorization Server's JWK Set [RFC7517, Section 5] document. |
| access_token_format | O | IUA | Array of JSON strings defining the format of the access token as provided by the Authorization Server. The array SHALL contain a single string with value “urn:ietf:params:oauth:token-type:jwt”. |
There are no further requirements beyond those defined in the SMART on FHIR specification.
{
"authorization_endpoint": "https://ehr.example.com/auth/authorize",
"token_endpoint": "https://ehr.example.com/auth/token",
"token_endpoint_auth_methods_supported": ["client_secret_basic", "client_secret_post"],
"registration_endpoint": "https://ehr.example.com/auth/register",
"scopes_supported": ["openid", "profile", "launch", "launch/patient", "patient/*.*", "purpose_of_use=*", "subject_role=*", "person_id=*", "principal=*", "principal_id=*", "organization=*", "organization=_id*", "access_token_format=*"],
"response_types_supported": ["code", "id_token"],
"grant_types_supported": ["client_credentials", "authorization_code", "urn:ietf:params:oauth:grant-type:jwt-bearer"],
"management_endpoint": "https://ehr.example.com/user/manage",
"revocation_endpoint": "https://ehr.example.com/user/revoke",
"capabilities": ["launch-ehr", "client-public", "client-confidential-symmetric", "context-ehr-patient", "sso-openid-connect"],
"issuer": ["launch-ehr", "client-public", "client-confidential-symmetric", "context-ehr-patient", "sso-openid-connect"],
"jwks_uri": "https://ehr.example.com/auth/jws",
"access_token_format": ["urn:ietf:params:oauth:token-type:jwt"]
}
There are no CapabilityStatement resources defined for this transaction.
The actors SHALL support the traceparent header handling, as defined in Appendix: Trace Context.
There is no audit event required for this transaction.