1.1

Was kann ich jetzt schon testen und welche Voraussetzungen müssen dafür erfüllt sein?

Aktueller Testumfang und die notwendigen Voraussetzungen sind in der IDP Wissensdatenbank/Fachdienste Test-Umgebungen beschrieben.

1.2

Ich kann nicht auf die Referenzimplementierung des sektoralen IDPs der gematik über das Internet zugreifen. Woran könnte das liegen?

Zugriff auf unseren IDP ist nur möglich, wenn Ihre outbound IP auf unserer Allowlist steht oder Sie unseren X-Auth-Header verwenden. Einfach eine Mail an uns schicken und entweder Ihre outbound IP angeben oder den X-Auth-Header erfragen.

Bezüglich der App-Veröffentlichung: Wir arbeiten mit Hochdruck daran und hoffen, Ihnen die Anwendung bis Ende November zur Verfügung stellen zu können.

Für weiterführende Informationen verweisen wir zusätzlich auf die der IDP Wissensdatenbank/Fachdienste Test-Umgebungen.

1.3 

Wie sieht es bei der GesundheitsID aus? Kann die Referenzimplementierung auch ohne SMC-B erfolgen? Oder müssen Hersteller auch hier erst mit der Implementierung warten, bis sie erfolgreich gelistet sind?

Sie benötigen für die Integration der GesundheitsID keine SMC-B. Auf die Testumgebung zur Integration der GesundheitsID dürfen auch Anwendungen zugreifen, die noch nicht als DiGA gelistet sind. Eine Registrierung in der Produktivumgebung erfolgt allerdings erst nach der Listung. 

 Für weiterführende Informationen zur Testumgebung verweisen wir zusätzlich auf die IDP Wissensdatenbank/Fachdienste Test-Umgebungen.

2.1

Wie kann ein in Österreich ansässiges Unternehmen den Prozess zur Beantragung einer SMC-B und zur Anmeldung einer DiGA durchlaufen?

Hier eine kurze Übersicht der Schritte:

Identifikationsverfahren: Laut D-TRUST ist das deutsche Postident-Verfahren auch für Inhaber eines österreichischen Passes in deutschen Postfilialen möglich. Alternativ bietet sich das BotschaftsIdent-Verfahren an, das durch deutsche Botschaften und Konsulate durchgeführt wird. Nähere Informationen zum Ablauf erhalten Sie bei der deutschen Botschaften/Konsulaten.

Versand: Der Versand von Karten und PIN-Briefen per Kurier ist auch nach Österreich ohne zusätzliche Kosten möglich.

Antragsfelder: Bei der Angabe von Wohnanschrift und Meldeadresse im Antrag kann Österreich ausgewählt werden, was für die Identifizierung erforderlich ist. Die Voreinstellung "Deutschland" bei der Organisationsadresse im Antrag ist festgelegt und kann nicht geändert werden, aber dieser Umstand ist im Antragsprozess sowohl für uns als auch für D-TRUST handhabbar.

Rechnungsstellung: Die Rechnung kann Ihnen per E-Mail zugeschickt werden, bitte wählen Sie diese Option entsprechend aus. Vergewissern Sie sich, dass im Antragsformular auf der Seite der Organisationsdaten die Umsatzsteuer-Identifikationsnummer (UstID) eingetragen wird.

Zögern Sie nicht, uns bei weiteren Fragen bzgl. Kartenherausgaben unter kartenherausgabe@gematik.de zu kontaktieren (insb. Hersteller aus anderen Ländern).

2.2

Muss ein DiGA-Hersteller, der mehrere digitale Gesundheitsanwendungen (DiGAs) anbietet, für jede einzelne DiGA eine separate SMC-B Karte beantragen?

Ja, es muss für jede einzelne DiGA im Verzeichnis eine separate SMC-B bestellt werden. Dies hat im Wesentlichen zwei Gründe:

1. Der Nutzer muss die ePA-Schreib- (und perspektivisch auch Lese-)berechtigung jeder DiGA einzeln vergeben können.
2. Bei Bedarf (z.B. in dem Fall, dass eine einzelne DiGA des Herstellers aus dem Verzeichnis gestrichen wird) muss jede SMC-B einer DiGA separat gesperrt werden können.  

2.3

Wie verhält es sich mit der SMC-B Karte für DiGAs, die sich aktuell noch in der Entwicklung oder im Antragsverfahren befinden?

Ab wann im Antragsprozess kann man eine SMC-B bestellen?

Gemäß der aktuellen Abstimmung mit dem BfArM kann die Beantragung einer SMC-B Karte für die Produktivumgebung erst nach der offiziellen Aufnahme der DiGA in das DiGA-Verzeichnis erfolgen.  Für Testzwecke bietet die gematik jedoch spezielle Testkarten an, die über das Fachportal der gematik oder Ihren Enabler (RU-as-a-Service Anbieter) bestellt werden können - auch vor Listung als DiGA im verzeichnis. Weitere Informationen zu Testkarten und den Bestellprozess finden Sie auf der entsprechenden Seite des Fachportals der gematik.

2.4

Ist es möglich, die SMC-B Karte auch in der Referenzumgebung für Testzwecke einzusetzen?

Nein, die SMC-B Karte ist ausschließlich für den Einsatz im produktiven Betrieb vorgesehen und kann nicht in der Referenzumgebung für Testzwecke verwendet werden. Für Testzwecke bietet die gematik jedoch spezielle Testkarten an, die über das Fachportal der gematik oder Ihren Enabler (RU-as-a-Service Anbieter) bestellt werden können. Weitere Informationen zu Testkarten und den Bestellprozess finden Sie auf der entsprechenden Seite des Fachportals der gematik.

2.5

Ist für den Betrieb einer DiGA ein physisches Kartenterminal zur Nutzung der SMC-B erforderlich?

Ja, für den regulären Betrieb ist ein Kartenterminal notwendig, um die SMC-B Karte zu nutzen. Alternativ können DiGA-Hersteller auch auf die Dienste eines spezialisierten Dienstleisters, eines sogenannten Enablers, zurückgreifen, der einen TIaaS (Telematikinfrastruktur-as-a-Service) anbietet und die Einbindung des Kartenterminals in Ihre Infrastruktur mit Ihnen individuell bespricht.

2.6

Nein, es ist nicht notwendig, bereits eingereichte Anträge für eine SMC-B-Karte neu zu stellen. Sollten im ursprünglichen Antrag Informationen, wie beispielsweise der Name der DiGA, gefehlt haben, werden die Antragstellenden von uns kontaktiert, um die erforderlichen Daten zu ergänzen.

3.1

Welche Kriterien müssen mTLS Client-Zertifikate erfüllen, einschließlich Gültigkeitsdauer und Subject-Angaben, und ist der Einsatz einer Zertifikatskette möglich?

Die beim TLS-Handshake verwendeten Zertifikate müssen durch den sektoralen IDP validiert werden können. 

Konkret bedeutet das, Authorization-Server müssen sicherstellen, dass die für die TLS Client Authentisierung gegenüber sektoralen IDPs verwendeten Schlüssel über das Entity Statement validiert werden können, indem für diese Zertifikate im Schlüsselsatz (jwks) des Fachdienstes abgelegt werden ("use = sig", x5c Objekt gesetzt).

Nach [RFC8705-section 2.2 (https://www.rfc-editor.org/rfc/rfc8705.html#name-self-signed-certificate-mut)] ist der Authorization-Server erfolgreich authentifiziert, wenn das Zertifikat, das er während des Handshakes vorgelegt hat, mit einem der für diesen bestimmten Client registrierten Zertifikate übereinstimmt.

Die TLS Authentisierungsschlüssel sind maximal 398 Tage gültig.

3.2

Wie ist das Vorgehen für einen Schlüsseltausch (use=sig)?

Die Signaturschlüssel, mit denen das Entity Statement des Fachdienstes signiert wird, müssen beim Federation Master (Vertrauensanker) über einen organisatorischen Prozess bekanntgegeben werden. Mehrere parallel existierende Schlüssel sind möglich. Details zum organisatorischen Prozess werden noch ergänzt. 

3.3

Wie ist der Zusammenhang von JWKS URL und JWKS im Entity Statement? 

Die Signaturschlüssel für das Entity Statement müssen im jwks-Claim des Entity Statements bekannt gegeben werden. Die Entschlüsselungsschlüssel (use=enc) und die mTLS Authentisierungsschlüssel (use=sig) befinden sich in den Metadaten der Relaying Party, entweder direkt unter dem jwks-Claimoder als Set unter einer URL (jwks-Url).

3.4

Kann die Gültigkeit des Entity Statement (claim exp) im Testsystem auf z.B. auf 30 Minuten gesetzt werden?

Prinzipiell kann im Testsystem nach Belieben konfiguriert werden. Allerdings muss die Interoperabilität berücksichtigt werden. Der sektorale IDP erneuert das Entity Statement zu einem Fachdienst derzeit alle zwei Stunden. Wenn Sie bei Ihren Integrationstests Probleme feststellen, dann sollten Sie auf jeden Fall diese abweichende Konfiguration im Hinterkopf behalten.

3.5

Ist die Regelung eines automatischen Logouts nach 10 Minuten Inaktivität auch dann anzuwenden, wenn das Authentifizierungstoken von unserem internen Identity Provider für die DiGA stammt? Gibt es eine Instanz, die die Einhaltung dieser Vorgabe prüft, und besteht das Risiko rechtlicher Konsequenzen durch Mitbewerber, falls wir uns nicht strikt an die Spezifikation halten?

Es besteht keine rechtliche Verpflichtung zur Implementierung eines automatischen Logouts nach 10 Minuten Inaktivität, wenn das Token von Ihrem internen IdP stammt; dies ist lediglich eine Empfehlung. Die Spezifikationen zum Logout-Intervall gelten primär für die Integration der GesundheitsID. Für DiGAs sind hauptsächlich die Datenschutzkriterien des BfArM ausschlaggebend. 

Bitte stellen Sie sicher, dass Ihre Datenschutzpraktiken diesen Kriterien entsprechen, um die Konformität mit den geltenden Vorschriften zu gewährleisten.

 3.6

Muss ein Nutzer, der sich für die Registrierung in der App mit dem eID-Login über die Krankenkassen-App entschieden hat, bei jedem App-Start eine erneute Authentifizierung über die eID vornehmen, oder gibt es alternative Methoden für die Wiederanmeldung?

Nein, nach der Erstregistrierung über das eID-Login muss der Nutzer nicht bei jedem Start der App erneut das eID-Verfahren durchführen. Es stehen auch andere zulässige Authentifizierungsmethoden zur Verfügung. Die GesundheitsID kann dabei als eines der möglichen Verfahren für eine solche wiederkehrende Authentifizierung genutzt werden.

3.7

Ist die Nutzung der GesundheitsID nur zur Erlangung der KVNR erforderlich, oder sind DiGA-Hersteller gesetzlich dazu verpflichtet, diese generell zu unterstützen?

DiGA-Hersteller sind gesetzlich dazu verpflichtet, die GesundheitsID ab dem 1. Januar 2024 zu unterstützen. Der Nutzer muss die Möglichkeit bekommen, sich über die GesundheitsID an der DiGA anzumelden. Es ist nicht verboten, weitere Authentisierungsverfahren anzubieten, solange Sie den Anforderungen des BfArMs genügen. 

Für das Einstellen der Daten in die ePA des Nutzers ist die GesundheitsID allerdings zwingende Voraussetzung, da die KVNR nur so sicher bezogen werden kann. 

3.8

Muss jede DiGA einzeln registriert werden oder muss die Registrierung separat für Android und iOS erfolgen?

Jede DiGA ist im Sinne der TI-Föderation eine Fachanwendung (Relying Party) und muss in der Föderation als eigener Fachdienst mit eigener client_id (iss), Schlüssel und scopes registriert werden.

Die Registrierung bezieht sich auf den Authorization-Server des Fachdienstes. Die Clients des Fachdiensten - also Android-App, iOS-App oder Web-App - sind selbst nicht Teil der TI-Föderation und müssen auch nicht registriert werden.

3.9

Wie lange können vom Authorization-Server bereitgestellte Zugriffstoken gültig sein?

Es existiert keine feste Vorgabe bezüglich der Gültigkeitsdauer von Zugriffstoken für DiGAs. Empfohlen wird, dass die vom Authorization-Server ausgestellten Zugriffstoken eine maximale Gültigkeitsdauer von 10 Minuten haben sollten.

3.10

Können Authorization-Server Refresh-Token verwenden?

Authorization-Server können einen OAuth 2.0 Token Endpunkt anbieten um dort das Abrufen von Refresh-Token entsprechend https://datatracker.ietf.org/doc/html/rfc6749#section-1.5 zu ermöglichen.

 33.11

Verifikation der Certificate Transparency für TLS Verbindungen in die VAU - Ist alternativ auch eine CT Prüfung möglich?

Ja, eine CT Prüfung ist möglich. Diese Funktionalität wird durch aktuelle Standard Bibliotheken für TLS Verbindungen unterstützt kann dahingehend umgesetzt werden, dass im Pool der Vertrauenswürdigen CAs nur solche aufgenommen werden, welche dem CAB-Forum zugehören.

3.12

Kann ein Nutzer scopes, welche eine DiGA bei einem sektoralen IDP zu ihm anfragt, abwählen.

Der Nutzer kann seine Zustimmung zur Weitergabe der Daten einzelner scopes verweigern. Konkret lautet die Anforderung in der gemSpec_IDP_Sek dazu:

"A_22939 - Widerspruch zur Weitergabe einzelner Scopes
Authenticator-Module des sektoralen IDP MÜSSEN dem Nutzer die Möglichkeit geben, einem Dienst einzelne scopes nicht zu übermitteln. Auch auf das Risiko hin, dass dieser Dienst dann nicht verwendet werden kann"

4.1

Ist der Login eines Versicherten über die GesundheitsID eine zwingende Voraussetzung dafür, dass DiGA-Betreiber Informationen in die ePA des Versicherten schreiben können, da nur so die Krankenversichertennummer (KVNR) zur Adressierung der ePA des Versicherten ermittelt werden kann?

Ja, derzeit ist der Login über die GesundheitsID eine zwingende Voraussetzung dafür, dass DiGA-Betreiber Daten in die ePA eines Versicherten schreiben können. Durch den Login mit der GesundheitsID wird die KVNR des Versicherten abgefragt, die unerlässlich ist, um auf die entsprechende ePA des Versicherten zuzugreifen und dort Daten eintragen zu können. Diese Vorgabe ist standardisiert und betrifft alle Anwendungen, die einen schreibenden Zugriff auf die ePA anstreben, nicht nur DiGAs.