Dies ist die Testsuite, mit welcher die Konformitätsbestätigung der gematik für EPA 3.1.3 erreicht werden kann.
|
Important
|
Stellen Sie sicher, dass keine anderen Testsuites oder Mock-Services parallel laufen, die die gleichen Ports verwenden (siehe Port-Tabelle unten). Dies kann zu Portkonflikten führen und die Testausführung verhindern. |
| Service | Port | Protokoll |
|---|---|---|
Tiger Testsuite (WorkflowUI) |
9020 |
http |
Tiger-Proxy Admin Port |
9021 |
http |
Tiger-Proxy Proxy Port |
443 |
http / https |
Die grundsätzlichen technischen Voraussetzungen sehen wie folgt aus:
-
Die Testsuite wird auf einem Tester-PC ausgeführt.
-
Auf diesem läuft auch das Primärsystem.
-
Der Konnektor ist korrekt konfiguriert und erreichbar.
-
Auf diesem Testrechner kann nun die KOB-Testsuite gestartet werden, ebenso wie der Tiger-Proxy.
-
Die Kommunikation zwischen Primärsystem und der TI muss nun über den Tiger-Proxy geleitet werden.
-
Dieser kann die Kommunikation aufzeichnen und analysieren.
-
Die Testsuite kann Artefakte von Maven Central aus dem Internet beziehen.
Die grundsätzlichen fachlichen Voraussetzungen sehen wie folgt aus:
-
Die Aktenkonten bei beiden Aktensystemen sind eingerichtet worden.
-
Die Aktenlokalisierung der Aktenkonten kann bei beiden Aktensystemen erfolgreich durchgeführt werden.
-
Für die genutzte LEI (SMCB) kann eine Befugnis (Entitlement) für die Aktenkonten bei den beiden Aktensystemen eingestellt werden.
-
In Nicht-PU-Umgebungen muss der Client (das Primärsystem) die verwendeten Schlüssel (K2_c2s_app_data und K2_s2c_app_data) Base64 kodiert im Header "VAU-nonPU-Tracing" übertragen. Dies ist nur für die Testumgebungen (z.B. KOB-Testfall) vorgesehen und MUSS für die produktive Umgebung (PU) zwingend wieder entfernt und dürfen dort NICHT übertragen werden. (siehe A_24477)
|
Warning
|
Für eine ordnungsgemäße Ausführung der KOB-Testsuite dürfen nur bestimmte Dateien angepasst werden. Diese sind:
Alle übrigen Dateien dürfen nicht verändert werden! |
Die folgenden, relevanten Konfigurationen der KOB-Testsuite müssen wie folgt in kob.yaml vorgenommen werden:
-
kvnrIbm- die für die KOB gegen das IBM Aktensystem verwendete KVNR -
kvnrRise- die für die KOB gegen das RISE Aktensystem verwendete KVNR
Der Tiger-Proxy unterstützt TLSv1.2 und gibt Server Zertifikate zurück, welche den Zertifikaten der Aktensysteme entsprechen. Zusätzlich wurden die unterstützen CipherSuiten wie folgt eingeschränkt (GS-A_4384-*):
-
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 -
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Bei dem Checkout für eine lokale Kopie von dem Repository ist darauf zu achten, dass die Dateien nicht verändert werden durch ein Checkout selbst.
Hierzu ist zu prüfen, dass folgenden Git Einstellungen (.gitconfig) für den Checkout des Repos genutzt werden:
[core]
autocrlf = falseDies kann mit folgenden Befehlen erreicht werden, je nachdem auf welcher Ebene die Einstellung getroffen werden soll:
git config --system core.autocrlf false # per-system solution
git config --global core.autocrlf false # per-user solution
git config --local core.autocrlf false # per-project solutionDa der KOB-Testsuite Container während der Ausführung Maven-Artefakte bezieht, muss das Internet für den Container erreichbar sein.
Sollte das Internet nur über einen Proxy-Server erreichbar sein, müssen die Einstellungen in der [./settings.xml](./settings.xml) für die Ausführung des PS-Testsuite Containers angepasst werden.
Bitte beachten Sie, dass der Parameter <active>true</active> gesetzt werden muss, um die Einstellungen zu aktivieren und das Docker-Volume kob-testsuite-maven gelöscht werden muss, um die Änderungen zu übernehmen.
Dazu müssen die folgenden Einträge angepasst werden:
<proxy>
<id>optional</id>
<active>true</active>
<protocol>https</protocol>
<host>proxy.example.com</host>
<port>8080</port>
<username>user</username>
<password>password</password>
<nonProxyHosts>localhost|127.0.0.1</nonProxyHosts>
</proxy>Es muss das Routing der Nachrichten über Tiger-Proxy der KOB-Testsuite erfolgen, um eine Auswertung dieser zu ermöglichen. Der Tiger-Proxy leitet die Anfragen an die korrekten Aktensysteme weiter. Wichtig ist hierbei auch, dass in dem äußeren HTTP-Request auch der HTTP-Header "Host" für die Anfrage an das entsprechende Aktensystem gesetzt ist, damit Tiger-Proxy die Anfrage entsprechend nach dem Mitschnitt weiterleiten kann.
Beispiel für den HTTP-Header, damit Tiger-Proxy korrekt routen kann.
Host: epa-as-1.ref.epa4all.deEs gibt keine Vorgabe WIE diese Umleitung erfolgen muss, zwei Wege scheinen jedoch sinnvoll:
In dieser Konfiguration kann die KOB-Testsuite als Forward-Proxy für das Primärsystem eingerichtet werden. Die Routen sind entsprechend konfiguriert, damit der Verkehr hier an die korrekten Aktensysteme weitergeleitet wird.
Hierbei sind folgende Punkte zu beachten:
-
Primärsystem seitig wird die KOB-Testsuite als Proxy konfiguriert (e.g.
localhost:443). Hiermit werden die Requests über die KOB-Testsuite an die Aktensysteme gesendet. Ein Request anhttps://epa-as-1.ref.epa4all.de/foobar, via KOB-Testsuite mitlocalhost:443entspricht somitcurl -x localhost:443 epa-as-1.ref.epa4all.de/foobar) -
Dabei ist darauf zu achten, dass der HTTP Header im (äußeren) HTTP Request dennoch den FQDN des Aktensystems enthält (e.g
Host: epa-as-1.ref.epa4all.de), damit das Routing an das gewünschte Aktensystem erfolgen kann. -
Eine zusätzliche Manipulation der DNS Auflösung (Variante 2) in der
hostsDatei ist nicht notwendig.
Alternativ kann die DNS-Auflösung beeinflusst werden, z.B. über das Editieren der Host-Einträge im Testsystem selbst (e.g. /etc/hosts). Hier werden die Hostnamen der Aktensysteme auf die IP-Adresse des Testrechners, wo der Tiger-Proxy mit dem Port 443 läuft, umgeleitet.
Beispiel, wenn das Primärsystem auf dem gleichen Rechner läuft, wie die Testsuite mit dem Tiger-Proxy.
# Zur Durchfuehrung der KOB und/oder optionalen Testfällen
127.0.0.1 epa-as-1.ref.epa4all.de
127.0.0.1 epa-as-2.ref.epa4all.de|
Important
|
Diese Einträge sollten nach der Durchführung der KOB-Testsuite wieder entfernt werden, da es ansonsten zu einem unbeabsichtigten Fehlverhalten führt, wenn die KOB-Testsuite nicht mehr aktiv läuft und somit die Nachrichten nicht mehr an die Aktensysteme weitergeleitet werden. |
Sollten sich die Aktensysteme nicht direkt erreichen lassen, sondern nur über einen (Forward) Proxy (z.B. in einem unternehmensinternen VPN), dann müssen in der Datei tiger.yml folgende Zeilen entsprechen aktiviert und angepasst werden:
# proxy configuration
forwardToProxy:
hostname: <PROXY_IP_OR_FQDN>
port: <PROXY_PORT>In der Datei .env (Root-Verzeichnis) ist über die Variable TESTSUITE_TESTS festgelegt, dass die KOB-Testsuite standardmäßig alle verpflichtenden Testfälle einbezieht, die mit dem Tag @KOB versehen sind.
Der Testumfang richtet sich nach dem Berechtigungsumfang des Primärsystems gemäß § 352 SGB V:
| Zielgruppe | Testfälle | Berechtigungsumfang |
|---|---|---|
PVS, ZPVS, KIS |
TF 1–12 |
Vollständige Verarbeitungsrechte |
AVS |
TF 1–11 |
Ohne automatische eML-eMP-Verknüpfung über das E-Rezept |
Pflegesysteme |
TF 3, 4, 5 und 7 |
Nur lesende Zugriffe |
Für spezifische Funktionsbereiche können zusätzliche Tags kombiniert werden:
-
@login– Aufbau einer User-Session -
@information-record-status– Aktenkontolokalisierung -
@information-consent-decisions– Abfrage der Zustimmung -
@entitlement– Einstellen einer Befugnis -
@eml_download– Download der eML
TESTSUITE_TESTS=@KOB and @loginDie KOB-Testsuite kann entweder lokal per Maven oder in einem Docker-Container ausgeführt werden.
Für die lokale Ausführung werden folgende Software-Versionen empfohlen:
-
Maven Version >= 3.9
-
JAVA Version >= 21
Ist dies gegeben, reicht ein einfaches Kommando mvn clean verify im Root-Verzeichnis des Projekts.
Die Testdurchführung erfolgt über eine webbasierte Benutzeroberfläche (WorkflowUI), die sich automatisch im Browser öffnet.
Maven-Start:
-
Die WorkflowUI öffnet sich automatisch im Standard-Browser unter http://localhost:9020
-
Falls das automatische Öffnen fehlschlägt, rufen Sie die URL manuell auf
Docker-Start:
-
Die WorkflowUI öffnet sich nicht automatisch
-
Der aufrufbare Link wird im Log ausgegeben, sobald die Oberfläche bereit ist:
========================================================================================================================
____ _____ _ ____ _____ ___ _ _ ____ __ _____ ____ _ _______ _ _____ __ _ _ ___
/ ___|_ _|/ \ | _ \_ _|_ _| \ | |/ ___| \ \ / / _ \| _ \| |/ / ___| | / _ \ \ / / | | | |_ _|
\___ \ | | / _ \ | |_) || | | || \| | | _ \ \ /\ / / | | | |_) | ' /| |_ | | | | | \ \ /\ / / | | | || |
___) || |/ ___ \| _ < | | | || |\ | |_| | \ V V /| |_| | _ <| . \| _| | |__| |_| |\ V V / | |_| || | _ _ _
|____/ |_/_/ \_\_| \_\|_| |___|_| \_|\____| \_/\_/ \___/|_| \_\_|\_\_| |_____\___/ \_/\_/ \___/|___| (_|_|_)
========================================================================================================================
09:21:12.065 [main ] INFO d.g.t.t.l.TigerDirector - Waiting for workflow Ui to fetch status...
09:21:12.065 [main ] INFO d.g.t.t.l.TigerDirector - Workflow UI http://localhost:9020-
Öffnen Sie den angezeigten Link manuell im Browser (hier: http://localhost:9020)
Zeitüberschreitung in der Workflow UI
Ein gestarteter und nicht weiter bedienter Testlauf wird von der Workflow UI nach fünf Stunden automatisch beendet. Die Ausführung endet dabei mit einer ConditionTimeoutException. Bei einem solchen Timeout werden keine Testberichte und kein Prüfnachweis-ZIP generiert. Um verwertbare Prüfnachweise zu erhalten, muss der Workflow daher innerhalb des Zeitlimits vollständig durchgeführt und regulär abgeschlossen werden.
-
Testfall auswählen: In der WorkflowUI auf der linken Seite ganz oben auf das Tiger-Icon klicken und in der Übersicht den gewünschten Testfall auswählen
-
Aktensystem wählen: IBM oder RISE Aktensystem als Testumgebung festlegen
-
Test starten: Die Testsuite zeigt ein Dialogfenster mit der Testaufgabe und den erforderlichen Testdaten an (z.B. "Fügen Sie für den Patienten mit der KVNR <kvnr> einen neuen eMP-Eintrag im Aktensystem IBM hinzu: …")
-
Aktion im Primärsystem ausführen: Führen Sie die angeforderte Operation in Ihrem Primärsystem aus – die konkrete Bedienung ist systemabhängig
-
Continue: Erst nachdem die Aktion vollständig ausgeführt wurde, klicken Sie auf "Continue"
-
Automatische Validierung: Die Testsuite wertet nun die aufgezeichneten Requests aus und validiert diese gegen die KOB-Anforderungen
|
Important
|
Klicken Sie erst auf "Continue", wenn die angeforderte Aktion vollständig ausgeführt wurde. Die Testsuite prüft dann alle für den Test relevanten zwischenzeitlich aufgezeichneten Nachrichten. |
Für die Beantragung des KOB Zertifikates bei der gematik benötigen Sie als Prüfnachweis den Testreport (zip file).
|
Note
|
Sollten ihr Primärsystem oder Middleware keine Verordnung oder abweichende Verordnungen ausstellen können, so ist bei der Beauftragung in TITUS über die Kommentarfunktion Bemerkung eine Begründung beizufügen. |
Die Testergebnisse selbst sind unter target/site/serenity/index.html zu finden und können somit im Browser verifiziert werden.
Der Testreport wird automatisch nach der Ausführung im target/kob-testsuite.*-test-report.zip abgelegt, wenn die Ausführung über den Quit Button in der WorkflowUI beendet wird.
Um diese Datei aus dem Docker Container in das lokale System zu kopieren, kann folgender Befehl genutzt werden:
docker cp kob-testsuite:/app/report/kob-testsuite-test-report.zip .Eine weitere Möglichkeit ist, die Report ZIP Datei über die Anwendung DockerDesktop herunterzuladen.
Loggen Sie sich in Ihren Account auf dem Titus Bestätigungsportal (https://titus.gematik.solutions) und öffnen Sie den Dialog „Neue Bestätigung“. Wählen Sie dort:
-
als Bestätigungsmodul: ePA,
-
die passende Modulausprägung für den ePA Medication Service,
-
die zugehörige Version.
Klicken Sie anschließend auf „Bestätigungsauftrag anlegen“. Der Testreport soll als ZIP-Datei hochgeladen werden.
Weitere Hinweise zur Handlungsanweisung für die Konformitätsbewertung (KOB) können im Service Desk nachgelesen werden: https://service.gematik.de/servicedesk/customer/kb/view/459882847
Fragen zum Titus-Bestätigungsportal und zur Durchführung des KOB Verfahrens können Sie ebenfalls über unseren Service Desk einstellen: https://service.gematik.de/servicedesk/customer/portal/26/group/36
Die FHIR-Strukturen, die in den KOB-Testfällen verwendet werden, basieren auf dem Implementation Guide ePA Medication Service in Version 1.3.4:
|
Note
|
Die nachfolgenden Abschnitte und Tabellen dienen als Hilfestellung zur Implementierung und zum Mapping der Testdaten. Maßgeblich sind stets die FHIR-Profile des oben verlinkten Implementation Guide ePA Medication Service Version 1.3.4. |
Die FHIR-Profile legen die Struktur des Request-Bodys der jeweiligen FHIR-Operation fest.
| Anwendungsfall | FHIR-Operation | FHIR-Profil |
|---|---|---|
eML-Eintrag hinzufügen |
|
|
eMP-Eintrag hinzufügen |
|
|
eMP-Eintrag aktualisieren |
|
|
eML-eMP-Verknüpfung hinzufügen |
|
|
eML-eMP-Verknüpfung entfernen |
|
|
eML-Eintrag stornieren |
|
|
eMP-Eintrag stornieren |
|
Folgende Inhalte müssen im Request-Body der Operation $add-eml-entry gesetzt werden:
-
medicationStatement -
medication -
organization -
format
Am Beispiel der Operation $add-eml-entry zeigt die folgende Tabelle, in welchen FHIR-Elementen die vorgegebenen Testdaten abzubilden sind.
| Element | FHIRPath innerhalb der Ressource | Wert |
|---|---|---|
Dosierung (strukturiert) |
|
|
Dosierung (Freitext) |
|
|
Gerenderte Dosierung |
|
|
| Element | FHIRPath innerhalb der Ressource | Wert |
|---|---|---|
Handelsname |
|
|
Handelsname (PZN) |
|
|
Wirkstoff (ASK) |
|
|
Wirkstoff |
|
|
Wirkstärke (strukturiert) |
|
|
Wirkstärke (Freitext) |
|
|
Darreichungsform |
|
|
Packungsgröße |
|
|
Folgende Inhalte müssen im Request-Body der Operation $add-emp-entry gesetzt werden:
-
medicationRequest -
medication -
organization -
format -
chronologyId(kann weggelassen werden, wenn es sich um initialen eMP-Eintrag handelt.)
Am Beispiel der Operation $add-emp-entry zeigt die folgende Tabelle, in welchen FHIR-Elementen die vorgegebenen Testdaten abzubilden sind.
| Element | FHIRPath innerhalb der Ressource | Wert |
|---|---|---|
Indikation (ICD-10-GM) |
|
|
Grund |
|
|
Dosierung (strukturiert) |
|
|
Dosierung (Freitext) |
|
|
Gerenderte Dosierung |
|
|
Hinweis für Versicherte |
|
|
Hinweis für Mitbehandelnde |
|
|
Status des eMP-Eintrags |
|
|
Anwendungszeitraum (Start) |
|
|
Anwendungszeitraum (Ende) |
|
|
| Element | FHIRPath innerhalb der Ressource | Wert |
|---|---|---|
Handelsname |
|
|
Handelsname (PZN) |
|
|
ATC-Code |
|
|
Wirkstoff (ASK) |
|
|
Wirkstoff |
|
|
Wirkstärke (strukturiert) |
|
|
Wirkstärke (Freitext) |
|
|
Darreichungsform |
|
|
Packungsgröße |
|
|
|
Note
|
Der zu aktualisierende eMP-Eintrag bzw. die dafür erforderlichen IDs müssen zuvor beispielsweise über |
Folgende Inhalte müssen im Request-Body der Operation $update-emp-entry gesetzt werden:
-
medicationRequest -
medicationPlanId -
chronologyId -
organization -
format
Am Beispiel der Operation $update-emp-entry zeigt die folgende Tabelle, in welchen FHIR-Elementen die vorgegebenen Testdaten abzubilden sind.
| Element | FHIRPath innerhalb der Ressource | Wert |
|---|---|---|
Dosierung (strukturiert) |
|
|
Dosierung (Freitext) |
|
|
Gerenderte Dosierung |
|
|
Status des eMP-Eintrags |
|
|
|
Note
|
Für das Hinzufügen einer eML-eMP-Verknüpfung müssen vorab über lesende Operationen (GET-Abfragen) die notwendigen IDs und Ressourcen ermittelt werden:
|
Folgende Inhalte müssen im Request-Body der Operation $link-emp gesetzt werden:
-
medicationPlanId -
chronologyId -
organization -
format
Der Request wird an den jeweiligen eML-Eintrag unter Verwendung der zuvor ermittelten medicationStatementId gesendet (auf FHIR-Ebene als Operation MedicationStatement/{medicationStatementId}/$link-emp).
Am Beispiel der Operation $link-emp zeigt die folgende Tabelle die Zuordnung der Parameter:
| Parameter / Element | Bedeutung / FHIRPath | Wert / Quelle |
|---|---|---|
|
ID des zu verknüpfenden |
|
|
Identifier des Ziel-Eintrags im eMP |
|
|
ID der aktuellen eMP-Chronologie |
|
|
Note
|
Für das Entfernen einer eML-eMP-Verknüpfung müssen vorab die erforderlichen IDs ermittelt werden:
|
Folgende Inhalte müssen im Request-Body der Operation $unlink-emp gesetzt werden:
-
medicationPlanId -
chronologyId -
organization -
format
Der Request wird an den jeweiligen eML-Eintrag unter Verwendung der zuvor ermittelten medicationStatementId gesendet (auf FHIR-Ebene als Operation MedicationStatement/{medicationStatementId}/$unlink-emp).
Am Beispiel der Operation $unlink-emp zeigt die folgende Tabelle die Zuordnung der Parameter:
| Parameter / Element | Bedeutung / FHIRPath | Wert / Quelle |
|---|---|---|
|
ID des verknüpften |
|
|
Identifier des zu entknüpfenden Eintrags im eMP |
|
|
ID der aktuellen eMP-Chronologie |
|
|
Note
|
Für das Stornieren eines eML-Eintrags muss vorab die ID des zu stornierenden Eintrags ermittelt werden:
|
Folgende Inhalte müssen im Request-Body der Operation $cancel-eml gesetzt werden:
-
organization -
format
Der Request wird an den jeweiligen eML-Eintrag unter Verwendung der zuvor ermittelten medicationStatementId gesendet (auf FHIR-Ebene als Operation MedicationStatement/{medicationStatementId}/$cancel-eml-entry bzw. MedicationStatement/{medicationStatementId}/$cancel-eml).
Am Beispiel der Operation $cancel-eml zeigt die folgende Tabelle die Zuordnung der Parameter:
| Parameter / Element | Bedeutung / FHIRPath | Wert / Quelle |
|---|---|---|
|
ID des zu stornierenden |
|
|
Note
|
Das Stornieren eines eMP-Eintrags erfolgt über die Operation
|
Folgende Inhalte müssen im Request-Body der Operation zum Stornieren eines eMP-Eintrags ($update-emp-entry) gesetzt werden:
-
medicationRequest(mitstatus: "entered-in-error") -
medicationPlanId -
chronologyId -
organization -
format
Am Beispiel des Stornierens eines eMP-Eintrags zeigt die folgende Tabelle die Zuordnung der Parameter:
| Parameter / Element | Bedeutung / FHIRPath | Wert / Quelle |
|---|---|---|
Status des eMP-Eintrags |
|
|
|
Identifier des zu stornierenden Eintrags im eMP |
|
|
ID der aktuellen eMP-Chronologie |
|
Problem: Beim erneuten Ausführen von mvn clean install erscheint die Fehlermeldung:
Failed to delete ...\kob-testsuite\target\kob-testsuite.jar
Ursache: Die Testsuite läuft noch im Hintergrund und blockiert die Datei.
Lösung:
-
Öffnen Sie im Browser: http://localhost:9020
-
Klicken Sie auf den roten "Quit Test Run" Button
-
Warten Sie, bis die Testsuite vollständig beendet ist
-
Führen Sie
mvn clean installerneut aus
|
Tip
|
Beenden Sie die Testsuite immer über den "Quit Test Run" Button, bevor Sie einen neuen Maven-Lauf starten. |
Der Zugriff auf das Docker Volume schlägt fehl.
Variante 1
Das Volume mit der gleichen Bezeichnung schon existiert und wurde von einer anderen, möglicherweise älteren, Version der KOB-Testsuite erstellt wurde. Man muss das Volume einmal löschen und bei Start der neuen Testsuite wird es wieder angelegt.
$> docker compose -f dc-testsuite.yml rm
$> docker volume rm -f kob-testsuite-maven
$> docker compose -f dc-testsuite.yml upVariante 2 (Linux)
Bitte prüfen Sie vor dem Start der Testsuite, ob Sie das .docker Verzeichnis löschen können und starten sie die Testsuite im Anschluss noch einmal.
Variante 3 (ohne Docker Volume)
Eine weitere Möglichkeit ist auf die Nutzung des Docker Volume zu verzichten.
Der Nachteil hierbei ist, dass die Maven Artefakte bei jedem Start der Testsuite erneut heruntergeladen werden müssen, was mehr Zeit in Anspruch nimmt.
Hierzu wird die Zeile - kob-testsuite-maven:/.m2 wie folgt mit einem Hash (#) auskommentiert.
volumes:
- ./tiger.yaml:/app/tiger.yaml
- ./kob.yaml:/app/kob.yaml
#- kob-testsuite-maven:/.m2
# has to be 'copied' AFTER the volume is mounted
- ./settings.xml:/.m2/settings.xmlIm Falle eines fehlgeschlagenen Testlaufs und dem Schreiben eines Support-Tickets im gematik Service Desk ist es sinnvoll, die *.tgr-Datei mit den aufgezeichneten Nachrichten anzuhängen. Damit ist es möglich, die Traces in eine lokale Tiger-Anwendung zu importieren, um die Kommunikation und deren Meldungsdetails anzuzeigen.
Dazu müssen Sie den folgenden Befehl ausführen, um die *.tgr aus dem ps-testsuite Container in das lokale Verzeichnis zu kopieren.
docker cp ps-testsuite:/app/tiger-proxy.tgr .Wenn Sie ein Fehlerticket eröffnen wollen für dieses Repository, nutzen Sie bitte den gematik Service Desk unter https://service.gematik.de/servicedesk/customer/portal/26.
Wenn Sie zu diesem Repository beitragen wollen, schauen Sie sich bitte die Datei CONTRIBUTING.MD an.
Copyright 2024-2026 gematik GmbH
Apache License, Version 2.0
See the LICENSE for the specific language governing permissions and limitations under the License.
-
Copyright notice: Each published work result is accompanied by an explicit statement of the license conditions for use. These are regularly typical conditions in connection with open source or free software. Programs described/provided/linked here are free software, unless otherwise stated.
-
Permission notice: Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
-
The copyright notice (Item 1) and the permission notice (Item 2) shall be included in all copies or substantial portions of the Software.
-
The software is provided "as is" without warranty of any kind, either express or implied, including, but not limited to, the warranties of fitness for a particular purpose, merchantability, and/or non-infringement. The authors or copyright holders shall not be liable in any manner whatsoever for any damages or other claims arising from, out of or in connection with the software or the use or other dealings with the software, whether in an action of contract, tort, or otherwise.
-
The software is the result of research and development activities, therefore not necessarily quality assured and without the character of a liable product. For this reason, gematik does not provide any support or other user assistance (unless otherwise stated in individual cases and without justification of a legal obligation). Furthermore, there is no claim to further development and adaptation of the results to a more current state of the art.
-
-
Gematik may remove published results temporarily or permanently from the place of publication at any time without prior notice or justification.
-
Parts of this software and - in isolated cases - content such as text or images may have been developed using the support of AI tools. They are subject to the same reviews, tests, and security checks as any other contribution. The functionality of the software itself is not based on AI decisions.
-
Please note: Parts of this code may have been generated using AI-supported technology. Please take this into account, especially when troubleshooting, for security analyses and possible adjustments.
gematik GmbH: [OSPO@gematik.de](mailto:OSPO@gematik.de)