This fragment is not visible to the reader
| Type | Reference | Content |
|---|---|---|
| web | www.gematik.de |
IG © 2026+ gematik GmbH
. Paket connect#6.0.0-rc basierend auf FHIR 4.0.1
. Generiert 2026-04-02
Links: Table of Contents | QA Report |
| web | gemspec.gematik.de | Alle Autorisierungsendpunkte MÜSSEN per HTTPS (TLS-Verschlüsselung) erreichbar sein. Im Echtbetrieb darf die Kommunikation ausschließlich per HTTPS erfolgen. Vorgaben zur einzusetzenden TLS Version, siehe Sicherheitsaspekte ( ANF-CON-011 ). |
| web | fachportal.gematik.de | Perspektivisch sollen für die Authentisierung von Patienten in Krankenhäusern die Sektoralen IDPs der Gematik unterstützt werden. Diese basieren wie das Modul ISiK Connect auf den Standards OAuth2 und OpenID Connect. Wie in der Übersicht des Moduls ISiK-Sicherheit dargestellt, werden in dieser Spezifikation keine Vorgaben bezüglich der einzusetzenden Authentisierungsdienste getroffen. Eine Unterstützung der Sektoralen IDPs ist perspektivisch jedoch unerlässlich. Um dieses herstellen zu können, MUSS der Autorisierungsserver einen im https-Aufruf enthaltenen Parameter ISS_IDP unverändert an den Authentifizierungsdienst (‘innerer Flow’ im Sinne der genannten gematik-Spezifikation) weitergeben. In diesem Parameter wird definiert, welcher Authorisierungsdienst anzusprechen ist. |
| web | profiles.ihe.net | 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. |
| web | profiles.ihe.net | IHE IUA - Abschnitt 34.1.1.3 Resource Server : Der Ressourcen-Server MUSS im CapabilityStatement im Element “CapabilityStatement.rest.security.service” angegeben werden, dass IHE IUA unterstüzt wird. ( ANF-CON-001 ) |
| web | profiles.ihe.net | 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 Ressourcen-Server die Struktur des Access Tokens ermitteln kann. ( ANF-CON-002 ) Die vorliegende Spezifikation geht davon aus, dass Access Token als Base64-kodierte JSON Web Token als Teil des REST-Aufrufs an den Ressourcen-Server übermittelt werden. |
| web | profiles.ihe.net | 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 . Der “resource”-Parameter SOLLTE durch den Autorisierungsserver unterstüzt werden ( ANF-CON-003 ). |
| web | profiles.ihe.net | 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. ( ANF-CON-004 ) |
| web | profiles.ihe.net | 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. |
| web | saml.xml.org | Konnektivität und Sicherheit haben im Zusammenhang mit einem interoperablen Datenaustausch in und mit Krankenhäusern viele Facetten: Nutzer müssen authentifiziert sein, Berechtigungen müssen definiert und durchgesetzt werden, Daten müssen gegen Verfälschung geschützt und verfügbar sein, Datenänderungen müssen nachvollziehbar sein etc. Hierzu können Technologien wie z. B. SAML oder UMA genutzt werden. Diese Technologien basieren auf einem etablierten und erprobten Stack aus Standards wie ReST Representational State Transfer , OAuth2 oder , OpenID Connect . Diese Standards sind domänenunabhängig spezifiziert und müssen daher für den Einsatz im deutschen Gesundheitswesen und ggf. auch für das Zusammenspiel mit dem HL7 FHIR-Standard profiliert werden. FHIR bietet hierzu unterstützende Ressourcen wie z. B. Consent , AuditEvent oder CompartmentDefinition an, die eine Bindung zwischen FHIR und dedizierten Sicherheitsstandards herstellen können. Im Fall von ISiK sind zusätzlich im deutschen Gesundheitswesen bereits definierte Bausteine der Gesundheitstelematik wie z. B. sektorale Identitätsdienste oder Konnektoren/TI-Gateways zu berücksichtigen, die idealerweise für die Authentifizierung an Patienten- und Zuweiserportalen, dem Schutz von Gesundheitsdaten im Krankenhaus, einem Ende-zu-Ende gesicherten Datenaustausch mit Niedergelassenen und anderen potenziell ISiK-relevanten Themen genutzt werden sollen. |
| web | docs.kantarainitiative.org | Konnektivität und Sicherheit haben im Zusammenhang mit einem interoperablen Datenaustausch in und mit Krankenhäusern viele Facetten: Nutzer müssen authentifiziert sein, Berechtigungen müssen definiert und durchgesetzt werden, Daten müssen gegen Verfälschung geschützt und verfügbar sein, Datenänderungen müssen nachvollziehbar sein etc. Hierzu können Technologien wie z. B. SAML oder UMA genutzt werden. Diese Technologien basieren auf einem etablierten und erprobten Stack aus Standards wie ReST Representational State Transfer , OAuth2 oder , OpenID Connect . Diese Standards sind domänenunabhängig spezifiziert und müssen daher für den Einsatz im deutschen Gesundheitswesen und ggf. auch für das Zusammenspiel mit dem HL7 FHIR-Standard profiliert werden. FHIR bietet hierzu unterstützende Ressourcen wie z. B. Consent , AuditEvent oder CompartmentDefinition an, die eine Bindung zwischen FHIR und dedizierten Sicherheitsstandards herstellen können. Im Fall von ISiK sind zusätzlich im deutschen Gesundheitswesen bereits definierte Bausteine der Gesundheitstelematik wie z. B. sektorale Identitätsdienste oder Konnektoren/TI-Gateways zu berücksichtigen, die idealerweise für die Authentifizierung an Patienten- und Zuweiserportalen, dem Schutz von Gesundheitsdaten im Krankenhaus, einem Ende-zu-Ende gesicherten Datenaustausch mit Niedergelassenen und anderen potenziell ISiK-relevanten Themen genutzt werden sollen. |
| web | restfulapi.net | Konnektivität und Sicherheit haben im Zusammenhang mit einem interoperablen Datenaustausch in und mit Krankenhäusern viele Facetten: Nutzer müssen authentifiziert sein, Berechtigungen müssen definiert und durchgesetzt werden, Daten müssen gegen Verfälschung geschützt und verfügbar sein, Datenänderungen müssen nachvollziehbar sein etc. Hierzu können Technologien wie z. B. SAML oder UMA genutzt werden. Diese Technologien basieren auf einem etablierten und erprobten Stack aus Standards wie ReST Representational State Transfer , OAuth2 oder , OpenID Connect . Diese Standards sind domänenunabhängig spezifiziert und müssen daher für den Einsatz im deutschen Gesundheitswesen und ggf. auch für das Zusammenspiel mit dem HL7 FHIR-Standard profiliert werden. FHIR bietet hierzu unterstützende Ressourcen wie z. B. Consent , AuditEvent oder CompartmentDefinition an, die eine Bindung zwischen FHIR und dedizierten Sicherheitsstandards herstellen können. Im Fall von ISiK sind zusätzlich im deutschen Gesundheitswesen bereits definierte Bausteine der Gesundheitstelematik wie z. B. sektorale Identitätsdienste oder Konnektoren/TI-Gateways zu berücksichtigen, die idealerweise für die Authentifizierung an Patienten- und Zuweiserportalen, dem Schutz von Gesundheitsdaten im Krankenhaus, einem Ende-zu-Ende gesicherten Datenaustausch mit Niedergelassenen und anderen potenziell ISiK-relevanten Themen genutzt werden sollen. |
| web | oauth.net | Konnektivität und Sicherheit haben im Zusammenhang mit einem interoperablen Datenaustausch in und mit Krankenhäusern viele Facetten: Nutzer müssen authentifiziert sein, Berechtigungen müssen definiert und durchgesetzt werden, Daten müssen gegen Verfälschung geschützt und verfügbar sein, Datenänderungen müssen nachvollziehbar sein etc. Hierzu können Technologien wie z. B. SAML oder UMA genutzt werden. Diese Technologien basieren auf einem etablierten und erprobten Stack aus Standards wie ReST Representational State Transfer , OAuth2 oder , OpenID Connect . Diese Standards sind domänenunabhängig spezifiziert und müssen daher für den Einsatz im deutschen Gesundheitswesen und ggf. auch für das Zusammenspiel mit dem HL7 FHIR-Standard profiliert werden. FHIR bietet hierzu unterstützende Ressourcen wie z. B. Consent , AuditEvent oder CompartmentDefinition an, die eine Bindung zwischen FHIR und dedizierten Sicherheitsstandards herstellen können. Im Fall von ISiK sind zusätzlich im deutschen Gesundheitswesen bereits definierte Bausteine der Gesundheitstelematik wie z. B. sektorale Identitätsdienste oder Konnektoren/TI-Gateways zu berücksichtigen, die idealerweise für die Authentifizierung an Patienten- und Zuweiserportalen, dem Schutz von Gesundheitsdaten im Krankenhaus, einem Ende-zu-Ende gesicherten Datenaustausch mit Niedergelassenen und anderen potenziell ISiK-relevanten Themen genutzt werden sollen. |
| web | openid.net | Konnektivität und Sicherheit haben im Zusammenhang mit einem interoperablen Datenaustausch in und mit Krankenhäusern viele Facetten: Nutzer müssen authentifiziert sein, Berechtigungen müssen definiert und durchgesetzt werden, Daten müssen gegen Verfälschung geschützt und verfügbar sein, Datenänderungen müssen nachvollziehbar sein etc. Hierzu können Technologien wie z. B. SAML oder UMA genutzt werden. Diese Technologien basieren auf einem etablierten und erprobten Stack aus Standards wie ReST Representational State Transfer , OAuth2 oder , OpenID Connect . Diese Standards sind domänenunabhängig spezifiziert und müssen daher für den Einsatz im deutschen Gesundheitswesen und ggf. auch für das Zusammenspiel mit dem HL7 FHIR-Standard profiliert werden. FHIR bietet hierzu unterstützende Ressourcen wie z. B. Consent , AuditEvent oder CompartmentDefinition an, die eine Bindung zwischen FHIR und dedizierten Sicherheitsstandards herstellen können. Im Fall von ISiK sind zusätzlich im deutschen Gesundheitswesen bereits definierte Bausteine der Gesundheitstelematik wie z. B. sektorale Identitätsdienste oder Konnektoren/TI-Gateways zu berücksichtigen, die idealerweise für die Authentifizierung an Patienten- und Zuweiserportalen, dem Schutz von Gesundheitsdaten im Krankenhaus, einem Ende-zu-Ende gesicherten Datenaustausch mit Niedergelassenen und anderen potenziell ISiK-relevanten Themen genutzt werden sollen. |
| web | smarthealthit.org | Ziel der vorliegenden Spezifikation ist es, per FHIR RESTful API formulierte Anfragen an einen Ressourcen-Server unter Nutzung eines zuverlässigen und sicheren Autorisierungsprotokolls - und damit unter Berücksichtigung von vergebenen Berechtigungen und formulierten Sicherheitsmechanismen - zu beantworten. Hierzu werden Teile des von SMART Health IT und Boston Childrens Hospital auf Basis des OAuth2-Standards definierten, von HL7 als Teil des FHIR-Standards übernommenen ‘SMART on FHIR’ API profiliert, so dass diese im Kontext der bestehenden ISiK-Festlegungen nutzbar sind. Die SMART-on-FHIR-API soll die Weiterentwicklung von Electronic Health Records (EHR) zu Plattformen befördern, bei denen - analog zu mobilen Plattformen wie iOS oder Android - Anwendungen aus einem App Store in eine solche Plattform eingebracht und dort in einer sicheren Umgebung ausgeführt werden ( “SMART App Launch” ). |
| web | semver.org | Im Rahmen der ISiK-Veröffentlichungen wird das Semantic Versioning verwendet. |
| web | gemspec.gematik.de | Es gelten die übergreifenden Festlegungen aus dem Modul ISiK Basis . |
| web | gemspec.gematik.de | Die gematik wurde vom Gesetzgeber beauftragt, im Benehmen mit der Deutschen Krankenhausgesellschaft (DKG) und den maßgeblichen Bundesverbänden der Industrie im Gesundheitswesen, verbindliche Standards für den Austausch von Gesundheitsdaten mit Informationssystemen im Krankenhaus zu erarbeiten. Für diesen Zweck wurden FHIR-Profile und ein REST-basiertes Application Programming Interface (API) entwickelt. Die REST-API wird im Wesentlichen vom FHIR Standard vorgegeben . |
| web | www.gesetze-im-internet.de | Weitere Informationen siehe § 373 SGB V . |
| web | www.bfarm.de | Hinweis: Sowohl für die Implementierung der ISiK-Spezifikation als auch für den Betrieb eines Produktes, das die ISiK-Spezifikation implementiert, ist eine SNOMED-CT-Lizenz notwendig. Diese kann beim National Release Center für SNOMED CT in Deutschland beantragt werden. |
| web | service.gematik.de | Bringen Sie allgemeine Fragen und Anmerkungen gerne über unser Anfrageportal ein: Anfragen ISiK + ISiP |
| web | www.gematik.de | Impressum |
|
Ampel_auf_Rot_Blau_gematik.svg
|
|
Betriebskoordination_Gruen_gematik.svg
|