Registrierung eines Fachdienstes in der TI-Föderation (für die Testumgebung (TU) und/oder Referenzumgebung (RU))

<?xml version="1.0" encoding="UTF-8"?>
<registrierungtifoederation>
    <!--
        Typ des Föderationsteilnehmers.
        Gültiger Wert:  'Fachdienst'
    -->
    <teilnehmertyp>Fachdienst</teilnehmertyp>
    <!--
        Betriebsumgebung des Federation Master.
        Gültige Werte:  'RU', 'TU' oder 'PU'
    -->
    <betriebsumgebung>RU</betriebsumgebung>
    <!--
        E-Mail Adresse, unter welcher der Föderationsteilnehmer kontaktiert werden kann.
    -->
    <kontaktemail></kontaktemail>
    <!--
        Verfahrensschlüssel (der gematik-Zulassung) bei PU-Registrierung; sonst leer
    -->
    <vfsbestaetigung></vfsbestaetigung>
    <!--
        TI-ITSM-Zuweisungsgruppe des Fachdienst-Herstellers oder eines Vertreters (für DiGA: ORG-0229:BT-0170).
        Kommt es zu Abweichungen der Registrierung, werden diese der hier hinterlegten Zuweisungsgruppe per Incident-Ticket(s)
        im TI-ITSM (ZIS) mitgeteilt.
    -->
    <zuweisungsgruppe>ORG-0229:BT-0170</zuweisungsgruppe>
    <!--
        Eindeutige Identifikation des Föderationsteilnehmers innerhalb einer Betriebsumgebung.
        Die Member-ID wird durch gematik vergeben bzw. von gematik bekanntgegeben.
    -->
    <memberid></memberid>
    <!--
        Name der Organisation, die hinter dem Fachdienst steht.
        
        Gültige Werte:  gemäß Regex ^[ÄÖÜäöüß\w\ \-\.\&\+\*\/]{0,128}$
        Referenz im Entity Statement:
            * metadata.openid_relying_party.organization_name
    -->
    <organisationsname></organisationsname>
    <!--
        Name des Fachdienstes.
        
        Gültige Werte:  gemäß Regex ^[ÄÖÜäöüß\w\ \-\.\&\+\*\/]{1,128}$
        Referenz im Entity Statement:
            * metadata.federation_entity.name
            * metadata.openid_relying_party.client_name
            -> diese Werte müssen im Entity Statement zueinander identisch sein
    -->
    <fachdienstname></fachdienstname>
    <!--
        Adresse des Fachdienstes.
        Angabe ohne '/.well-known/openid-federation'
        Referenz im Entity Statement:
            * iss
    -->
    <fachdiensturi></fachdiensturi>
    <!--
        Keine oder mehrere OIDC-Scopes, die der Fachdienst verlangt.
        Mindestens der scope "openid" muss angegeben sein. Weitere <scope>-Elemente unter <scopes> hinzufügen.
        Gültige Werte: Auswahl gemäß A_22989-01 [gemSpec_IDP_Sek]
        Referenz im Entity Statement:
            * metadata.openid_relying_party.scope
    -->
    <scopes>
        <scope>openid</scope>
        <!-- Beispiel für scope 'versicherter" -->
        <scope>urn:telematik:versicherter</scope>
    </scopes>
    <!--
        Keine oder mehrere Claims, die der Fachdienst verlangt.
        Entweder leer (<claims/>) oder ein oder mehrere <claim>-Elemente unter <claims>.
        Gültige Werte:  Auswahl gemäß A_22989-01 [gemSpec_IDP_Sek] oder beliebige weitere Claims
        Referenz im Entity Statement:
            * metadata.openid_relying_party.claims
    -->
    <claims>
        <!-- Beispiel für claim 'id' -->
        <claim>urn:telematik:claims:id</claim>
        <claim>oder weiterer beliebiger Claim</claim>
    </claims>
    <!--
        Ein oder mehrere Redirect URLs, an welche die vom IDP ausgestellten Identitätsinformationen geschickt werden.
        Entweder leer (<redirect_uris/>) oder ein oder mehrere <redirect_uri>-Elemente unter <redirect_uris>.
        Referenz im Entity Statement:
            * metadata.openid_relying_party.redirect_uris
    -->
    <redirect_uris>
        <redirect_uri></redirect_uri>
    </redirect_uris>
    <!--
        Liste von ein oder mehreren Public Keys (PEM-Format) für JWT.
        Referenz im Entity Statement:
            * jwks.keys
    -->
    <publickeysjwt>
        <!-- Public Keys werden immer in einer `kid`- und `key`-Kombination bekannt gegeben. -->
        <publickey>
            <kid></kid>
            <key>-----BEGIN PUBLIC KEY-----            ....            -----END PUBLIC KEY-----</key>
        </publickey>
    </publickeysjwt>
</registrierungtifoederation>

Folgende Angaben benötigen wir von Ihnen: 

1. TEILNEHMERTYP*:
   Beim Teilnehmertyp wird zwischen „IDP“ und „Fachdienst“ unterschieden. Da es sich bei einer DiGA um eine Fachanwendung bzw. um einen Fachdienst im Sinne der TI-Föderation handelt, ist hier diese Angabe bereits vorbefüllt mit „Fachdienst". Dieser Wert ist unveränderbar; er wird vom Federation Master bei der Registrierung benötigt.
   
   
2. BETRIEBSUMGEBUNG*:
   Im ersten Schritt stehen für Fachdienste/DiGAs zunächst die Betriebsumgebungen TU (Testumgebung) und RU (Referenzumgebung) für die Registrierung am Federation Master zur Verfügung. Informationen zu den Betriebsumgebungen finden Sie in der IDP-Wissensdatenbank: Umgebungen, Referenzimplementierungen, Codebeispiele Federation Master.
   Bitte beachten Sie folgenden Hinweis: Details für eine spätere Registrierung in der PU (Produktivumgebung) werden zu gegebener Zeit kommuniziert. Eine Registrierung in der Testumgebung wird in jedem Fall eine zwingende Voraussetzung sein.
   
   
3. KONTAKT-E-MAIL:
   Für den Fall, dass es zu Störungen kommt, benötigen wir von Ihnen eine E-Mail-Adresse für Rückfragen zur Registrierung.
   
   
4. VFSBESTAETIGUNG (PU*):
   Im Rahmen des Bestätigungs-/Zulassungsverfahrens der gematik haben Sie einen Bestätigungs-/Zulassungsschlüssel erhalten. Dieser beginnt mit "VFS_". Bitte geben Sie für eine PU-Registrierung dieser Bestätigungs-/Zulassungsschlüssel exakt an. Für eine RU-/TU-Registrierung ist die Angabe optional, falls Sie diesen Schlüssel bereits kennen; Wert kann für RU/TU sonst leer bleiben. Fehlt diese Angabe jedoch für einen PU-Antrag, kann dieser nicht prozessiert werden.
   
   
5. ZUWEISUNGSGRUPPE*:
   Die Zuweisungsgruppe (kurz „ZWG“) ist für gematik-interne Betriebsprozesse notwendig und bereits mit einem Standardwert vorbefüllt, der nicht verändert werden darf. Diese Angabe ist für einen vollständigen Datensatz notwendig und hat folgenden Hintergrund:
   Beim Auftreten von (z.B. technischen) Problemen o.ä. können die Teilnehmer der TI-Föderation per TI-ITSM (auch: zentrales Informations-System, kurz „ZIS“) die/den betroffene(n) Teilnehmer (der betroffenen Komponente) kontaktieren. Hierfür ist die Angabe der entsprechenden ZWG zwingend erforderlich. Da Sie als DiGA-Hersteller zum Zeitpunkt der TU-/RU-Registrierung keinen Zugriff auf das ZIS haben und dementsprechend keine Kontaktaufnahme mit Ihnen/von Ihnen möglich ist, wird die Zuweisungsgruppe des DiGA-Integrators hierfür genutzt. Hierüber können andere TI-Föderationsteilnehmer bspw. Incident-Meldungen, die Ihren Fachdienst/Ihre DiGA betreffen können, einstellen. Falls dies der Fall ist, werden wir Sie darüber informieren, damit Sie das Problem beheben können. Sollten Sie andererseits einen Incident oder Problem mit einem anderen TI-Föderations-Teilnehmer melden wollen, wenden Sie sich entsprechend an den DiGA-Integrator, idp-registrierung@gematik.de oder diga@gematik.de.
   
   
6. MEMBER-ID*:
   Die Member-ID wird von der gematik vergeben. Bitte erfragen Sie initial eine Member-ID unter idp-registrierung@gematik.de. Tragen Sie diesen Wert nach Erhalt in das entsprechende Feld ein, um schließlich einen vollständigen Datensatz zu erhalten.
   
   
7. ORGANISATIONSNAME*:
   Hier geben Sie Ihren Organisationsnamen an. Dieser muss dem Namen des DiGA/Fachdienst-Herstellers bzw. Anbieters entsprechen. Diese Angabe dient den gematik-internen, organisatorischen Prozessen.
   
   
8. FACHDIENSTNAME*:
   Hier geben Sie den Namen Ihres Fachdienstes an. Dieser findet sich in Ihrem Entity Statement sowohl in unter metadata.federation_entity.name als auch metadata.openid_relying_party.client_name. Diese Werte müssen kongruent sein. Falls die Werte voneinander abweichen, kann Ihr Registrierungsantrag leider nicht prozessiert werden.
   
   
9. FACHDIENST-URI*:
   Mit Fachdienst-URI ist die Basis-URL benannt, unter der dieser Fachdienst sein Metadaten-Statement öffentlich bereitstellt; kurz gesagt: Dies ist die Adresse Ihres Entity Statement Ihres Fachdienstes.
   Die Fachdienst-URI muss nach Vorgaben der TI-Föderation der Adresse für den Abruf des (Fachdienst-spezifischen und im korrekten Algorithmus angegebenen) Entity Statement entsprechen. D.h. Ihr Entity Statement muss laut Anforderung A_22643 ([gemSpec_IDP_Sek]) unter dieser URI (unter dem Pfad /.well-known/openid-federation) aus dem Internet abrufbar sein. 
   Bitte geben Sie den Pfad "/.well-known/openid-federation" nicht in Ihrer Fachdienst-URI an.
   Achten Sie hier bitte insbesondere auf folgende Kriterien für URIs:
   
   • • net.URI muss die URI parsen können
     • Schema muss mit "https" beginnen
     • Host darf nicht null sein
     • Query darf nicht vorhanden sein
     • Fragment (#) darf nicht vorhanden sein
     • Port muss zwischen 1 und 65535 liegen bzw. nicht explizit definiert sein.
       
       
10. SCOPES:
    "Scopes" sind die Nutzerattribute, welche über die sektoralen IDPs abgerufen werden können.
    Der scope "openid" ist immer zwingend anzugeben (siehe A_23036-02 - Inhalte des "Scope" für Versicherte, Hinweis 2).
    
    Für DiGA gilt: DiGA dürfen hier nur diejenigen Scopes angeben, die durch die "DiGA und DiPA Datenschutzkriterien" abgedeckt sind. Es dürfen hier insbesondere keine Scopes angegeben werden, welche über die Liste der verarbeiteten Daten hinausgeben, welche Sie beim BfArM angegebenen haben.
    
    Mehr Informationen zu den Scopes finden Sie in der Spezifikation [gemSpec_IDP_Sek].
    
    
    
11. CLAIMS: 
    

    Claims sind im Request einer Relying Party (Fachdienst/DiGA) angeforderte Nutzer-Attribute, die bei Zustimmung des Nutzers an die Relying Party übertragen werden. Die Übertragung erfolgt im ID-Token.

    Scopes sind (im TI-Föderationskontext) Gruppen von claims (also ein oder mehrere spezifische claims).

    In einer Anfrage (Request) können Attribute als scopes gefordert werden. Laut OIDC-Spec sind dies dann immer optionale/freiwillige Attribute, deren Übertragung ein Nutzer ablehnen kann.

    Um "verpflichtend zu übertragende" Attribute, d.h. Attribute, welche der Nutzer nicht abwählen kann, im Request anzufordern, gibt es laut OIDC-Spec nur den sogenannten claims-Request. Darin werden die gewünschten Attribute einzeln genannt und können zusätzlich als "essential" (verpflichtend) oder freiwillig ausgezeichnet werden. Die freiwilligen claims können also vom Nutzer abgewählt werden und der Dienst funktioniert immer noch.

    Anfragen sollten sich für einen Stil (scopes oder claims basiert) für Requests entscheiden, da die OIDC-Spec beschreibt: "das Verwenden beider Stile im gleichen Request führt zu undefiniertem Verhalten".

    
    
12. REDIRECT-URI(S)*:
    Bei redirect_uri sind alle (es können mehrere sein) vom Fachdienst unterstützten Redirect-Adressen anzugeben, die benötigt werden, um Authorization-Codes und/oder ID-Token entgegen zu nehmen sowie Adressen, die vom verwendeten sektoralen IDP verwendet werden, um zum richtigen Authenticator weiterleiten zu können. Kurz gesagt: An diese Adresse(n) werden die vom IDP ausgestellten Identitätsinformationen gesendet.
    
    
13. KID*:
    Hier ist es wichtig, dass Sie genau den Key Identifier (KID) des Schlüssels angeben, welchen Sie ebenfalls im Header Ihres Fachdienst-Entity-Statement angegeben haben. Bitte geben Sie hier nur den String der KID (JWK) an.
    
    
14. KEY*:
    Hier ist der Public Key anzugeben, mit dem das Entity Statement des Fachdienstes validiert werden kann.
    Zur JWK-KID gibt es diesen entsprechenden Public Key. Diesen haben Sie in Ihrem Entity Statement (im JWKS-Block) angegeben. Diesen müssen Sie entsprechend in ein PEM-Format konvertieren (bspw. via https://8gwifi.org/jwkconvertfunctions.jsp) und diesen Wert  (startend mit -----BEGIN PUBLIC KEY----- und endend mit -----END PUBLIC KEY-----) hier angeben.
    
    
    
    

Senden Sie uns anschließend die befüllte XML-Datei unter Angabe der Member-ID als Dateinamen an idp-registrierung@gematik.de.

Hinweis: Eine reguläre Registrierung nimmt durchschnittlich 5 Arbeitstage in Anspruch. Bei fehlerhaften Registrierungsdaten muss eine Klärung mit Ihnen stattfinden, weshalb sich die Bearbeitungszeit dementsprechend verlängert.

DOWNLOAD der unbefüllten XML-Datei zur REGISTRIERUNG (mit erläuternden Kommentaren):

RP_register.xml

DOWNLOAD der unbefüllten XML-Datei zur REGISTRIERUNG (ohne Kommentare):

RP_register_unkommentiert.xml

XML zur LÖSCHUNG eines Fachdienstes (mit erläuternden Kommentaren):

RP_deregister.xml

XML zur LÖSCHUNG eines Fachdienstes (ohne Kommentare):

RP_deregister_unkommentiert.xml