DEMIS Wissensdatenbank

Allgemein

Für Softwarehersteller steht für Integrationstests eine Testumgebung mit verschiedenen Ausprägungen unter https://test.demis.rki.de/{TYPE}/ (siehe Tabelle unten) zur Verfügung. Die Umgebung unterstützt das Senden und Empfangen der eigenen gesendeten Meldungen. (Details siehe unten)

 

DEMIS Testumgebung

Bitte verwenden Sie ausschließlich Testdaten (keine personenbezogenen Daten!) in den DEMIS-Testumgebungen (test.demis.rki.de).












(Bild mit KI erzeugt)

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.


ServiceBeschreibungToken EndpunkteClient ID, Passwort
idp.tokenendpoint für GesundheitsämterTokenabruf für Meldungsabruf an der Gesundheitsamtschnittstelledemis-importer, secret_client_secret
idp.tokenendpoint für LaboreTokenabruf für Labore mit Zertifikatdemis-adapter, secret_client_secret
idp.tokenendpoint für KrankenhäuserTokenabruf für Krankenhäuser mit Zertifikatdemis-test, secret_client_secret
idp.tokenendpoint für das GesundheitswesenTokenabruf mittels SMC-B Identität
  • Scope: openid gmtik-demis-ru-test
  • Client-ID: token-exchange-client
  • Client Secret: secret_client_secret


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 IfSGhttps://test.demis.rki.de/qs/notifications/disease/v6/fhir/$process-notificationhttps://test.demis.rki.de/prod-test/notification-api/fhir/$process-notification
Reports melden, z.B. Bettenmeldungen für Krankenhäuserhttps://test.demis.rki.de/qs/reports/bedoccupancy/v6/fhir/$process-reporthttps://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 RKIhttps://test.demis.rki.de/qs/notifications/v1/fhir/Bundle?...https://test.demis.rki.de/prod-test/notification-clearing-api/fhir/Bundle?...

Grafische Oberfläche

Meldeportalhttps://meldung.test.demis.rki.de/qs/https://meldung.test.demis.rki.de/prod-test/



NutzergruppeAlleAlle
Aktualisierungszeitstempel

Verfügbarkeit (tick)  (tick) 
Testresult Schnittstellen

Testresult Frontend

Release NotesRelease-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-FlagDescription

Umgebungstyp

 "preview"

Umgebungstyp

 "production"

FEATURE_FLAG_DISEASE_TITLEShows the title of a questiontrue
FEATURE_FLAG_COMMON_CODE_SYSTEM_TERMINOLOGY_ENABLEDif 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_ENABLEDdetermines wheter the IGS notification is validated against the corresponding FHIR profilestrue
FEATURE_FLAG_LV_DISEASE
true
FEATURE_FLAG_CONTEXT_ENRICHMENT_SERVICEdetermines whether the IGS notification should be enriched with context information about the notifying entitytrue
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_V2The message sender is also the receivertrue
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 enabledtrue
FEATURE_FLAG_FUTS_VALUESETS_SNOMED
 true
FEATURE_FLAG_HAPI
Use the additional HAPI server for message storagefalse
FEATURE_FLAG_SNAPSHOT_5_3_0_ACTIVE
activate profile snapshot 5.3false
FEATURE_FLAG_COPY_CHECKBOX_FOR_NOTIFIER_DATA
new checkbox on submittingFacility for copying all data from notifiertrue

Konfiguration

Diese Übersicht zeigt welche Konfigurationen neben den Feature-Flags auf den einzelnen Umgebungen vorgenommen wurden.



Umgebungstyp

"quality assurance"

Umgebungstyp

"production"

IGS FHIR-Profile3.0.23.0.2
Allgemeine FHIR-Profile6.1.25.3.5
ARS (Antibiotika-Resistenz-Surveillance)-Profile1.1.0N/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


BeschreibungEndpunktversion ALT/OBSOLETEndpunktversion NEUHinweise
idp.tokenendpoint für Gesundheitsämterhttps://test.demis.rki.de/auth/realms/OEGD/protocol/openid-connect/token
keine Änderung
idp.lab.tokenendpoint für Laborehttps://test.demis.rki.de/auth/realms/LAB/protocol/openid-connect/token
keine Änderung
idp.tokenendpoint für Krankenhäuserkeine Ä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/v5/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äuserhttps://test.demis.rki.de/{TYPE}/hospitalization/fhir/$process-notification

https://test.demis.rki.de/{TYPE}/notifications/disease/v5/fhir/$process-notification

https://test.demis.rki.de/{TYPE}/notifications/disease/v6/fhir/$process-notification

https://test.demis.rki.de/{TYPE}/notifications/pathogen/v5/fhir/$process-notification

https://test.demis.rki.de/{TYPE}/notifications/pathogen/v6/fhir/$process-notification

Reports melden, z.B. Bettenmeldungen für Krankenhäuserhttps://test.demis.rki.de/{TYPE}/reports/fhir/$process-report

https://test.demis.rki.de/{TYPE}/reports/bedoccupancy/v5/fhir/$process-report

https://test.demis.rki.de/{TYPE}/reports/bedoccupancy/v6/fhir/$process-report

Übermittlung von Antibiotika-Resistenzenhttps://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 Surveillancehttps://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ämterhttps://test.demis.rki.de/{TYPE}/notification-clearing-api/fhir/Binary?...https://test.demis.rki.de/{TYPE}/notifications/v1/fhir/Binary?...
Meldungen abholen für RKIhttps://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




Migration von der "alten" Livetestumgebung zur neuen Testumgebung


Für alle die vorher schon die Livetestumgebung genutzt haben, hier eine Änderungsübersicht:


BeschreibungEndpunktversion ALTEndpunktversion NEUHinweise
idp.tokenendpoint für Gesundheitsämterhttps://test.demis.rki.de/live-test/auth/realms/OEGD/protocol/openid-connect/tokenhttps://test.demis.rki.de/auth/realms/OEGD/protocol/openid-connect/token
idp.lab.tokenendpoint für Laborehttps://test.demis.rki.de/live-test/auth/realms/LAB/protocol/openid-connect/tokenhttps://test.demis.rki.de/auth/realms/LAB/protocol/openid-connect/token
idp.tokenendpoint für Krankenhäuserhttps://test.demis.rki.de/live-test/auth/realms/HOSPITAL/protocol/openid-connect/token
Meldungen senden für Laborehttps://test.demis.rki.de/live-test/notification-api/fhir/$process-notification

https://test.demis.rki.de/{TYPE}/notification-api/fhir/$process-notification

{TYPE} Wert ergibt sich aus der Zielumgebung 
Meldungen senden für Krankenhäuserhttps://test.demis.rki.de/live-test/hospitalization/fhir/$process-notificationhttps://test.demis.rki.de/{TYPE}/hospitalization/fhir/$process-notification{TYPE} Wert ergibt sich aus der Zielumgebung 
Reports melden, z.B. Bettenmeldungen für Krankenhäuserhttps://test.demis.rki.de/live-test/reports/fhir/$process-reporthttps://test.demis.rki.de/{TYPE}/reports/fhir/$process-report{TYPE} Wert ergibt sich aus der Zielumgebung 
Meldungen abholen für Gesundheitsämter--https://test.demis.rki.de/{TYPE}/notification-clearing-api/fhir/Binary?...{TYPE} Wert ergibt sich aus der Zielumgebung 


NEU: Des Weiteren kann mit demselben Zertifikat ein Token für die Senden- und Empfangenschnittstelle vom IDP geholt werden.