Zugangsdaten
Wenden Sie sich bitte an die DEMIS-Geschäftsstelle unter demis-support@rki.de zur Beantragung des Zertifikates für die Produktiv- oder Testumgebung.
FHIR-Schnittstelle der Testumgebung
Einleitung
Zum Test sowie zur (Weiter-)Entwicklung von softwareseitigen Anbindungen an DEMIS stehen die DEMIS-Testumgebungen zur Verfügung. In allen DEMIS-Testumgebungen sind ausschließlich Testdaten zu verwenden. Die Authentisierung erfolgt zentral für alle Testumgebungen. Dies bedingt technisch, dass die gleiche Authentisierung für alle Umgebungen verwertet wird. Die Authentisierung wurde üblicherweise so angepasst, dass Nutzer fast alle Berechtigungen besitzen. Dies bedeutet, dass auf den Testumgebungen Aktionen erlaubt sein können, die in der Echtumgebung mit einem Nutzer dieser Art nicht erlaubt sind. Auch können sich die verfügbaren Methoden zur Authentisierung auf der produktionsnahen Testumgebung hierdurch bezüglich der verfügbaren Features (z.B. Benutzername+Passwort erlaubt) und der konkreten Konfiguration der Features von der Echtumgebung unterscheiden.
Sender=Empfänger Konzept
Für die Testsysteme ist ein Mechanismus etabliert, der bei der Integration des Testsystems helfen soll. Dabei werden die gesendeten Daten mit dem Zertifikat des Senders verschlüsselt und abgelegt.
In allen TEST-Umgebungen ist das Test-Feature "Sender=Empfänger" aktiv. Hersteller haben somit die Möglichkeit anstelle des Gesundheitsamt ihre gesendeten Meldungen herunterzuladen. Dies betrifft ausschließlich den Teil der Erregernachweismeldungen (gemäß § 7 Ab. 1 IfSG) und Erkrankungsmeldungen (gemäß § 6 Abs. 1 Nr. 1 und 1a IfSG, sowie § 6 Abs. 2 IfSG), der normalerweise an das Gesundheitsamt gehen würde. Bei Sendungen und Meldungen, die (nur) an das RKI übermittelt werden (z.B. Meldungen gemäß § 7 Abs. 4 IfSG), ist das Herunterladen nicht möglich. Standardmäßig können nur Sendungen, die mit einem DEMIS-Testzertifikat abgesendet wurden, wieder empfangen werden.
Weitere Informationen zum Abholen der Meldungen finden Sie hier: Nutzung der FHIR-Schnittstelle als Empfänger
Preview-QS Testumgebung
Der Stand der Preview-Umgebung spiegelt den qualitätsgesicherten (QS) Entwicklungsstand wider. Hier sind zukünftige Features bereits aktiviert und testbar. Üblicherweise kann diese Umgebung dazu verwendet werden, sich auf zukünftige Änderungen vorzubereiten. Der Stand dieser Umgebung wird zukünftig auf der Produktivumgebung verfügbar sein. Je nach Art der Features werden die Stände wenige Tage oder Wochen vor offiziellem Livegang auf der Preview-Umgebung zur Verfügung gestellt. In speziellen Situationen (insbesondere bei Breaking Changes) kann der Zeitraum auch Monate umfassen. Bitte beachten Sie, dass sich der Stand der Features bis zur Veröffentlichung noch ändern kann. Durch Feedback und geplante Weiterentwicklungen ist teilweise noch mit Änderungen zu rechnen. Unter Umständen kann es auch vorkommen, dass Features vorläufig oder gänzlich abgebrochen bzw. zurückgerollt werden.
Produktionsnahe-PROD-TEST Testumgebung
Der Stand der produktionsnahen Testumgebung spiegelt den produktiven (PROD) Anwendungsstand wider. Hier sind grundsätzlich nur produktive Features aktiviert. Üblicherweise kann diese Umgebung dazu verwendet werden, die Kompatibilität der eigene Implementierung zu testen. Der Stand dieser Umgebung wird immer mit der Aktualisierung der Produktivumgebung aktualisiert. Bitte beachten Sie, dass sich der Stand im Bezug auf die Authentisierung von der Produktivumgebung (z.B. Benutzername+Passwort erlaubt) unterscheiden kann.
Diese Umgebung kann beispielsweise auch für Tests im Meldeportal oder interne Schulungen verwendet werden.
Token Endpunkte
Die Authentifizierung und Token-Endpunkte sind für alle Ausprägungen der Testumgebung gleich und müssen für jeden Service-Endpunkt der unterschiedlichen Testumgebungen genutzt werden.
| Service | Beschreibung | Token Endpunkte | Client ID, Passwort |
|---|---|---|---|
| idp.tokenendpoint für Gesundheitsämter | Tokenabruf für Meldungsabruf an der Gesundheitsamtschnittstelle | demis-importer, secret_client_secret | |
| idp.tokenendpoint für Labore | Tokenabruf für Labore mit Zertifikat | demis-adapter, secret_client_secret | |
| idp.tokenendpoint für Krankenhäuser | Tokenabruf für Krankenhäuser mit Zertifikat | demis-test, secret_client_secret | |
| idp.tokenendpoint für das Gesundheitswesen | Tokenabruf mittels SMC-B Identität |
|
Service Endpunkte
Diese Übersicht zeigt die einzelnen API-Schnittstellen der Umgebungen, die für Tests verfügbar sind. Es wird auch dargestellt, wie der Status der internen Testläufe gegen die Umgebungen ist.
| Service | Umgebungstyp "preview" (qs) | Umgebungstyp "produktionsnah" prod-test |
|---|---|---|
| API | ||
| Senden von Erregernachweismeldungen ( § 7 IfSG ) | https://test.demis.rki.de/qs/notifications/pathogen/v6/fhir/$process-notification | https://test.demis.rki.de/prod-test/notification-api/fhir/$process-notification |
| Senden von Erkrankungsmeldungen ( § 6 IfSG ) | https://test.demis.rki.de/qs/notifications/disease/v6/fhir/$process-notification | https://test.demis.rki.de/prod-test/notification-api/fhir/$process-notification |
| Reports melden, z.B. Bettenmeldungen für Krankenhäuser | https://test.demis.rki.de/qs/reports/bedoccupancy/v6/fhir/$process-report | https://test.demis.rki.de/prod-test/reports/fhir/$process-report |
ARS: Übermittlung von Antibiotika-Resistenzen | https://test.demis.rki.de/qs/surveillance/antibiotic-resistance/v1/fhir/$process-notification | N/A |
IGS: Übermittlung von Integrierte Genomische Surveillance | https://test.demis.rki.de/qs/surveillance/notification-sequence/v3/... | https://test.demis.rki.de/prod-test/surveillance/notification-sequence/... |
| Meldungen abholen für Gesundheitsämter | https://test.demis.rki.de/qs/notifications/v1/fhir/Binary?... | https://test.demis.rki.de/prod-test/notification-clearing-api/fhir/Binary?... |
| Meldungen abholen für RKI | https://test.demis.rki.de/qs/notifications/v1/fhir/Bundle?... | https://test.demis.rki.de/prod-test/notification-clearing-api/fhir/Bundle?... |
Grafische Oberfläche | ||
| Meldeportal | https://meldung.test.demis.rki.de/qs/ | https://meldung.test.demis.rki.de/prod-test/ |
| Nutzergruppe | Alle | Alle |
| Aktualisierungszeitstempel | ||
| Verfügbarkeit | | |
| Testresult Schnittstellen | ||
| Testresult Frontend | ||
| Release Notes | Release-Notes "quality assurance" | DEMIS-Release Notes |
Zertifikate, User und Passwörter
Der Username ergibt sich aus dem Zertifikat, z.B.
z.B. Zertifikat | username | Kommentar | |
|---|---|---|---|
Laborseite | DEMIS-test-lab999_*.p12 | test-lab999 | |
Krankenhausseite | demis-test-hosp01_CSM031204266.p12 | test-hosp01 | jeweils zugeordnete IK Nummer 987654321 Dieser IK ist der folgende Test-Standort zugewiesen: <IK>987654321</IK> <Bezeichnung>Testkrankenhaus - gematik GmbH</Bezeichnung> <PLZ>10117</PLZ> <Ort>Berlin</Ort> <Straße>Friedrichstraße</Straße> <Hausnummer>136</Hausnummer> <BSNR>987654321</BSNR> <StandortId>987654</StandortId> |
Konfigurationsübersicht
Feature-Flags
Diese Übersicht zeigt, welche neuen Features auf welcher Umgebung aktiviert oder deaktiviert sind. Damit können die Unterschiede der einzelnen Umgebungen auf einem Blick erkannt werden.
| Feature-Flag | Description | Umgebungstyp "preview" | Umgebungstyp "production" |
|---|---|---|---|
| FEATURE_FLAG_DISEASE_TITLE | Shows the title of a question | true | |
| FEATURE_FLAG_COMMON_CODE_SYSTEM_TERMINOLOGY_ENABLED | if true, activates the support module to validate codes against common CodeSystems that are commonly used, but are not distributed with the FHIR specification for various reasons (size, complexity, etc.) | true | |
| FEATURE_FLAG_VALIDATION_ENABLED | determines wheter the IGS notification is validated against the corresponding FHIR profiles | true | |
| FEATURE_FLAG_LV_DISEASE | true | ||
| FEATURE_FLAG_CONTEXT_ENRICHMENT_SERVICE | determines whether the IGS notification should be enriched with context information about the notifying entity | true | |
| FEATURE_FLAG_DISEASE_GROUP_TITLE | true | ||
| FEATURE_FLAG_HOSP_REASON_MOVE | true | ||
| FEATURE_FLAG_ACCEPTING_ANONYMOUS_NOTIFICATIONS | true | ||
FEATURE_FLAG_NOTIFICATIONS_7_4 | true | ||
| FEATURE_FLAG_TEST_ROUTING_V2 | The message sender is also the receiver | true | |
FEATURE_FLAG_HOSP_COPY_CHECKBOXES | Shows a checkbox in the hospitalization question to copy hospital address data to the question. | true | |
FEATURE_FLAG_NEW_STARTPAGE_DESIGN | new design of start page is enabled | true | |
FEATURE_FLAG_FUTS_VALUESETS_SNOMED | true | ||
FEATURE_FLAG_HAPI | Use the additional HAPI server for message storage | false | |
FEATURE_FLAG_SNAPSHOT_5_3_0_ACTIVE | activate profile snapshot 5.3 | false | |
FEATURE_FLAG_COPY_CHECKBOX_FOR_NOTIFIER_DATA | new checkbox on submittingFacility for copying all data from notifier | true |
Konfiguration
Diese Übersicht zeigt welche Konfigurationen neben den Feature-Flags auf den einzelnen Umgebungen vorgenommen wurden.
Umgebungstyp "quality assurance" | Umgebungstyp "production" | |
|---|---|---|
| IGS FHIR-Profile | 3.0.2 | 3.0.2 |
| Allgemeine FHIR-Profile | 6.1.2 | 5.3.5 |
| ARS (Antibiotika-Resistenz-Surveillance)-Profile | 1.1.0 | N/A |
Migration auf die neuen API Endpunkte
Warum neue API Endpunkte?
Um den zukünftigen Anforderungen an eine moderne, wartbare und erweiterbare Schnittstelle gerecht zu werden, passen wir die DEMIS-API-Endpunkte an. Die bisherigen Endpunkte waren stark an internen Service-Namen orientiert und nicht an den tatsächlichen fachlichen Funktionalitäten. Das erschwert die Nutzung und Erweiterung der API für Entwickler und Integratoren. Künftig richten wir die Endpunkte klar an den angebotenen Funktionen aus, z. B. an Prozessen wie „Meldung übermitteln“ oder „Bericht abrufen“ statt an technischen Servicebezeichnungen.
Ein weiterer zentraler Grund ist die Einführung einer API-Versionierung. Damit können wir zukünftige Änderungen oder Erweiterungen der Schnittstelle ohne Brüche und mit klarer Rückwärtskompatibilität umsetzen. Für Sie als Nutzer bedeutet das: Sie können neue Features gezielt nutzen, während bestehende Integrationen weiterhin stabil funktionieren. Es liegen dann zwei Endpunkte vor, die die PROD und die neue Profilierung ansteuern.
Die neue Struktur verbessert zudem die Erweiterbarkeit und Lesbarkeit der API. Funktionale Gruppierung, sprechende Pfade und ein konsistentes Namensschema erleichtern die Integration und reduzieren Fehlerquellen. Darüber hinaus werden Best Practices moderner API-Entwicklung umgesetzt: bessere Dokumentierbarkeit, klarere Verantwortlichkeiten und eine zukunftssichere Basis für weitere Anwendungen.
Beide Endpunkt-Versionen werden für eine Übergangszeit parallel bereitgestellt, um Ihnen ausreichend Zeit für die Umstellung zu geben.
Der Wert des Platzhalters {TYPE} in der folgenden Tabelle ist mit dem Kürzel des Umgebungstyps zu befüllen. Folgende Kürzel sind derzeit verfügbar:
- qs
- prod-test
| Beschreibung | Endpunktversion ALT/OBSOLET | Endpunktversion NEU | Hinweise |
|---|---|---|---|
| idp.tokenendpoint für Gesundheitsämter | https://test.demis.rki.de/auth/realms/OEGD/protocol/openid-connect/token | keine Änderung | |
| idp.lab.tokenendpoint für Labore | https://test.demis.rki.de/auth/realms/LAB/protocol/openid-connect/token | keine Änderung | |
| idp.tokenendpoint für Krankenhäuser | keine Änderung | ||
https://test.demis.rki.de/auth/realms/INSTITUTIONS-TI/protocol/openid-connect/token | keine Änderung | ||
| Meldungen senden für Labore | https://test.demis.rki.de/{TYPE}/notification-api/fhir/$process-notification |
https://test.demis.rki.de/{TYPE}/notifications/pathogen/v6/fhir/$process-notification | v5: aktuellen FHIR-Profile auf PROD (nicht für TYPE=qs) v6: strikten FHIR-Profile |
| Meldungen senden für Krankenhäuser | https://test.demis.rki.de/{TYPE}/hospitalization/fhir/$process-notification |
https://test.demis.rki.de/{TYPE}/notifications/disease/v6/fhir/$process-notification
https://test.demis.rki.de/{TYPE}/notifications/pathogen/v6/fhir/$process-notification | |
| Reports melden, z.B. Bettenmeldungen für Krankenhäuser | https://test.demis.rki.de/{TYPE}/reports/fhir/$process-report |
https://test.demis.rki.de/{TYPE}/reports/bedoccupancy/v6/fhir/$process-report | |
| Übermittlung von Antibiotika-Resistenzen | https://test.demis.rki.de/{TYPE}/surveillance/antibiotic-resistance/fhir/$process-notification | https://test.demis.rki.de/{TYPE}/surveillance/antibiotic-resistance/v1/fhir/$process-notification | |
| Übermittlung von Integrierte Genomische Surveillance | https://test.demis.rki.de/{TYPE}/surveillance/antibiotic-resistance/fhir/$process-notification | https://test.demis.rki.de/{TYPE}/surveillance/notification-sequence/v3/fhir/$process-notification | |
| Meldungen abholen für Gesundheitsämter | https://test.demis.rki.de/{TYPE}/notification-clearing-api/fhir/Binary?... | https://test.demis.rki.de/{TYPE}/notifications/v1/fhir/Binary?... | |
| Meldungen abholen für RKI | https://test.demis.rki.de/{TYPE}/notification-clearing-api/fhir/Bundle?... | https://test.demis.rki.de/{TYPE}/notifications/v1/fhir/Bundle?... | |
Doppelvalidierung
Im Falle der Nutzung des allgemeinen Endpunktes funktioniert die Validierung wie folgt, wenn beide Profilversionen in der Doppelvalidierung aktiv sind:
- zuerst Validierung gegen neueste Version (striktes Profil): valide Meldung -> Warnungen sind wirklich nur Warnungen
- wenn Meldung invalide, erfolgt die Validierung gegen die ältere Version: valide Meldung -> Es gibt den Validierungsoutput der neuesten strikten Profile zurück, wobei Errors auf Warnings herabgesetzt werden. Eine Unterscheidung gibt es nicht.
- Mit beiden Profilen ungültig -> Output mit Errors und Warnings von den strikten/neuen Profilen