Kompatibilität zu IHE-Profilen

Das IHE Technical Framework Supplement "Internet User Authorization (IUA)" bietet, ähnlich wie SMART on FHIR, Möglichkeiten zur Autorisierung von Transaktionen einer RESTful HTTP API. Nachfolgend werden Unterschiede zwischen SMART on FHIR und IHE IUA aufgelistet, um hervorzuheben, auf welche Details zu achten ist, sodass eine Implementierung konform zu beiden Standards ist.

  • IHE IUA - Abschnitt 34.1.1.3 Resource Server: Der Ressourcenserver MUSS im CapabilityStatement im Element "CapabilityStatement.rest.security.service" angegeben werden, dass IHE IUA unterstüzt wird.

  • IHE IUA - Abschnitt 3.103.2.1 Resource Server: Im well-known-Metadata-Dokument SOLL das Element "access_token_format" angegeben werden, sodass der Client und/oder Ressourcenserver die Struktur des Access Tokens ermitteln kann. Die vorliegende Spezifikation geht davon aus, dass Access Token als Base64-kodierte JSON Web Token als Teil des REST-Aufrufs an den Ressourcenserver übermittelt werden.

  • IHE IUA - Abschnitt 3.71.4.1.2.2. Authorization Code grant type: Anstelle der Verwendung des "aud"-Parameters im Schritt "App bittet um Autorisierung" - schlägt IHE IUA die Verwendung des Parameters "resource" vor. Siehe Diskussion in [SMART on FHIR - 2.0.9 - Obtain authorization code]https://www.hl7.org/fhir/smart-app-launch/app-launch.html#obtain-authorization-code).

  • IHE IUA - Abschnitt 3.71.4.1.2.2. Authorization Code grant type: Die Verwendung des "redirect_uri"-Parameters ist in IHE IUA optional, wenn der Client genau eine "redirect_uri" beim Autorisierungsserver hinterlegt hat. In SMART on FHIR MUSS diese URI stets angegeben werden.

  • IHE IUA - Abschnitt 3.71.4.1.2.2. Authorization Code grant type: Die Verwendung des "scope"-Parameters ist in IHE IUA optional. In SMART on FHIR MUSS die gesamte Menge der gewünschten Scopes stets angegeben werden.