FHIR Chat · fhircast-docs / Issue #79 How does a client know what eve... · fhircast-github

Stream: fhircast-github

Topic: fhircast-docs / Issue #79 How does a client know what eve...

view this post on Zulip Github Notifications (FHIRcast) (Mar 04 2019 at 14:56):

bvdh opened Issue #79

Maybe we should allow him to query the supported event using a GET on the cast-url.

view this post on Zulip Github Notifications (FHIRcast) (Mar 05 2019 at 15:57):

isaacvetter commented on Issue #79

Hey Bas,

Great point.

As we move events into OAuth2 scopes (per #64), a client would need to know the supported events before it learned the cast-url.

If we look to SMART for inspiration, the choices are:
1. An extension on the FHIR server's CapabilityStatement
2. A url on the FHIR server, such as .well-known/smart-configuration

Actually, SMART's existing smart-configuration json object already defines the list of supported scopes. If we address #64, we get event discovery as part of this smart-configuration thing for free. The real question is, should we consider adding an additional "capability" to the smart-configuration file?

Isaac

GET /apis/fhir/.well-known/smart-configuration HTTP/1.1
Host: www.ehr.example.com

HTTP/1.1 200 OK
Content-Type: application/json

{
  "authorization_endpoint": "https://ehr.example.com/auth/authorize",
  "token_endpoint": "https://ehr.example.com/auth/token",
  "token_endpoint_auth_methods_supported": ["client_secret_basic"],
  "scopes_supported": ["openid", "profile", "launch", "launch/patient", "patient/*.*", "user/*.*", "offline_access", "fhircast/open-patient-chart.*", "fhircast/close-patient-chart.*"],
  "response_types_supported": ["code", "code id_token", "id_token", "refresh_token"],
  "capabilities": ["launch-ehr", "client-public", "client-confidential-symmetric", "context-ehr-patient", "sso-openid-connect"]
}

view this post on Zulip Github Notifications (FHIRcast) (May 05 2019 at 18:03):

bvdh commented on Issue #79

That would tie the event discovery to FHIR and to the authorization mechanism.
Previous discussions indicated the need for deployments that do not require authorization. FHIRcast will also be used on more DICOM oriented deployments.
A FHIRcast specific endpoint that allows discovery would make this a FHIR Cast specific element that is independent of FHIR and authorization.
We could use a subdirectory beneath the topic URI for this. E.g. <topic>/events .

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -