Einführung
Das HÄVG Prüfmodul (HPM) ist eine Software, die von Leistungserbringern und Partnern im Rahmen der HZV- und FAV-Verträge eingesetzt wird. Das Modul bietet vielseitige Funktionen, wie z.B. die Prüfung der Versichertenberechtigung, die Erfassung der HZV-/FAV-spezifischen Leistungen oder den sicheren Transfer von Abrechnungsdaten.
Das HPM wird von Vertragssoftware (VSW)-Herstellern in eigenen Produkten integriert. Eine Übersicht zugelassener VSW-Produkte befindet sich unter VSW-Produkte.
Wichtig: Der Zugriff auf das HÄVG AKA-Portal ist den Herstellern von Praxissoftware vorbehalten, die ihre Software für HZV-Verträge zertifizieren. Als Praxisangehörige oder IT-Betreuende von Praxen beziehen Sie das HÄVG-Prüfmodul daher direkt über den Hersteller Ihrer Praxissoftware.
Bitte beachten Sie, dass dies eine technische Anleitung des HPMs ist und insbesondere Hinweise
- zur Installation
- zur HTTP-Authentifizierung
- zur technischen Konfiguration
- zum Aufbau der Software und der verfügbaren Schnittstellen enthält.
Bezeichnungen und Abkürzungen
Zum besseren Verständnis dieser Anleitung werden nachfolgend gängige Abkürzungen erläutert.
- HPM: Die aktuelle Version des HÄVG-Prüfmoduls (HPM), für alle Lizenznehmer und Geschäftspartner. Sie erhält regelmäßig Updates zum Funktions- und zum Datenstand.
- HPM Legacy: Die vormalige Version des HÄVG-Prüfmoduls. Sie wurde letztmalig zu Q4-2023 als Download angeboten und erhält keine weiteren Updates.
- Shell: Komponente innerhalb des HPM, maßgeblich für Kommunikation, Schnittstellen, Installation/Updates, Sicherheit bei online Übertragungen.
- Fachservices: Komponenten innerhalb des HPM. Ein Fachservice ist zuständig für fachbezogene Dienste und Prüfungen (HZV-, AMM-, EAV-Fachservices) Sowohl Shell als auch Fachservices können als Windows-Dienst oder Daemon (Hintergrundprozess) betrieben werden.
- HOK: Der HZV-Online-Key (HOK) ist ein hardwaregebundenes Zertifikat, das die Online-Anbindung des HPMs absichert. Der HOK wird als USB-Stick an Partner/Kunden verteilt. Technisch nutzt das HPM den HOK, um eine TLS-Verbindung zu Servern aufzubauen und den Client zu authentifizieren.
- AKA-Portal: Das AKA-Portal der HÄVG ist eine Online-Plattform, die Dienste und Downloads rund um den Anforderungskatalog (AKA) zur Verfügung stellt. Für zertifizierte Hersteller von Praxissoftware bietet die Plattform den quartalsweise veröffentlichten AKA, die aktuelle Version des HPMs, anstehende Termine und Releasenotes an.
Die folgende Grafik stellt die Architektur und grundlegenden Komponenten des HPM dar.
Abrufort, Download des HPM
Für zertifizierte Hersteller von Praxissoftware steht das HPM über das AKA-Portal zum Abruf bereit. Sollten Sie Fragen zum Zugang oder zur Installation haben, melden Sie sich bitte per E-Mail an support@haevg-rz.de.
Wichtig: Der Zugriff auf das HÄVG AKA-Portal ist den Herstellern von Praxissoftware vorbehalten, die ihre Software für HZV-Verträge zertifizieren. Als Praxisangehörige oder IT-Betreuende von Praxen beziehen Sie das HÄVG-Prüfmodul daher direkt über den Hersteller Ihrer Praxissoftware.
Inhalte
- installer.executable - z.B. HAEVG_Pruefmodul_2023Q3_Installer_Windows_x64.exe
- HPM_Anleitung.pdf – Die Anleitung zum HPM
Installation
WICHTIG!
Bei der Verwendung von Flags muss darauf geachtet werden, dass diese immer in folgendem Format aufgerufen werden:
-flagName (für Boolesche Werte) -flagName=flagWert (für Boolesche und Integer Werte) -flagName="flagWert" (für String Werte) Nicht erlaubt: -flagName flagWert
Standardinstallation - Schneller Start
Windows
Aufruf des Installers (HAEVG_Pruefmodul_2023Q3_Installer_Windows_x64.exe) mit Administratorrechten:
.\HAEVG_Pruefmodul_2023Q3_Installer_Windows_x64.exe -silent
Linux
Aufruf des Installers (HAEVG_Pruefmodul_2023Q3_Installer_Linux_x64.bin) mit Administratorrechten:
./sudo HAEVG_Pruefmodul_2023Q3_Installer_Linux_x64.bin -silent
macOS
Aufruf des Installers (HAEVG_Pruefmodul_2023Q3_Installer_macOS_x64.app) mit Administratorrechten:
./sudo HAEVG_Pruefmodul_2023Q3_Installer_macOS_x64.app -silent
Installationsverhalten
Bei Aufruf des Installers wird das System nach einem bereits installierten HPM untersucht:
a) Sollte ein zuvor installiertes HPM erkannt werden
- werden die HPM-Dateien entfernt
- werden existierende Systemdienste des HPM gestoppt und nach Installation gestartet
- wird die HPM-Konfiguration (Ports und Flags usw.) übernommen
- wird das HPM als Dienst/Service im System installiert
- Flags mit Konfigurationsdaten, z.B.
-frontendPort
oder-online
, können verwendet werden, um vorhandene Werte in der Konfiguration zu überschreiben.
b) Sollte kein installiertes HPM erkannt werden
- wird das HPM mit einer Standardkonfiguration
- oder wahlweise, sofern per Flag angegeben, mit der mitgegebenen Konfiguration installiert
- wird das HPM als Dienst/Service im System installiert
Hinweise zu fehlschlagenden Installationen
Das Setzen der Berechtigungen des Konfigurationsordners führt in manchen Fällen zum Abbruch der Installation. In solchen Fällen empfehlen wir, den ganzen Konfigurationsordner manuell zu löschen und anschließend die Installation erneut zu starten. Achtung: Wenn Sie keine Standardkonfiguration verwenden, sollten Sie die Konfigurationsdatei vorher sichern.
Besonderheiten
Ausgabe des interaktiven Installers bei alten Windows-Servern
Die Ausgabe in der Konsole kann verzerrt/unleserlich ausfallen. Dies verhindert nicht die erfolgreiche Installation, am besten per Flag -silent Installationen starten.
Mac/Linux Installer und Ausführungsrechte
Nach Download des Mac/Linux-Installers müssen der Installerdatei Ausführungsrechte erteilt werden (chmod +x), damit die Installation gestartet werden kann.
Code Signing
Unter Windows und macOS sind alle Installationsdateien signiert (bzw. notarisiert unter macOS).
Festplatten-Vollzugriff bei macOS nach Neuinstallation
Auf macOS muss dem HPM nach einer Neuinstallation der Festplatten-Vollzugriff gewährt werden.
Installationsmodi
Wichtig: Testsysteme/-installationen übermitteln keine Echtdaten
Wird bei der Installation das “-test”-Flag verwendet oder “IstTestsystem” in der Konfigurationsdatei auf “true” gesetzt, so handelt es sich um eine Testinstallation (o. Testsystem). Das bedeutet, dass sämtliche Daten als Testdaten interpretiert werden und keine Übertragung von Echtdaten an das HÄVG-Rechenzentrum erfolgt.
Interaktiver Modus
Im interaktiven Modus werden die Parameter bei dem User erfragt. Standardwerte können mit übernommen werden.
Jegliche weitere Konfiguration kann nach der Installation über die Konfigurationsdatei vorgenommen werden.
Silent-Modus
Über das Flag -silent kann die Installationsanwendung im nicht interaktiven Modus gestartet werden. Silent bedeutet nicht, dass eine reduzierte Ausgabe stattfindet. Es werden trotzdem minimalistisch Informationen zum Installationsvorgang ausgegeben. In diesem Modus können gleichzeitig andere Flags wie -port oder -installPath gesetzt werden. Ist nur das -silent-Flag gesetzt, wird für die restlichen Optionen ein Standardwert verwendet.
Liste der möglichen Installer Flags:
Flag-Name | Form | Standard | Datentyp |
---|---|---|---|
Cargo-Paket nur extrahieren | -extract | "" | String |
Configfile | -configFile | "" | String |
Frontendport | -port | 22220 | Interger |
Installationsort | -installPath | "" | String |
IstOnline | -online | true | Boolean |
IstTest | -test | false | Boolean |
Konvertieren | -convert | "" | String |
Portabler Modus | -portable | false | Boolean |
Silent Installation | -silent | false | Boolean |
Umgebungsvariablen | -env | "" | String |
Version | -v | false | Boolean |
Telemetrieenddatum | -telemetryEndDate | "" | String |
Erläuterungen zu Installationsflags
-
-configFile
: Im Silent-Modus kann eine spezifische Konfigurationsdatei (hpm_config.json) angegeben werden. Dadurch wird es unnötig, die Parameter -port, -installPath, -online und -test zu verwenden. Bei der Verwendung von-extract
und-portable
wird-configFile
ignoriert, weil eine Standard-Konfiguration verwendet wird. -
-convert
: erwartet den Pfad zu einer InstallConfig.xml. Diese wird dann in das Konfigurationsdateiformat des HPM konvertiert und als hpm_config.json im gleichen Ordner abgelegt. -
-extract
: erwartet einen Ordnerpfad, welcher ggfs. angelegt wird, und extrahiert alle Dateien des HPM in das Verzeichnis. Das HPM kann dann nach Bedarf von Hand gestartet werden. Kann in Kombination mit dem Flag-env
verwendet werden. Aufgrund von deaktivierten Updates ist diese Funktionalität nur für den Testmodus geeignet. Verwenden Sie somit-extract
immer in Kombination mit dem Flag-test
. -
-portable
: erstellt einen temporären Systemordner, in welchen die HPM-Dateien extrahiert werden. Darüber hinaus wird ein Satz freier Ports gesucht (Frontend-Port, Backend-Port, HZV, AMM, EAV) und eine hpm_config.json generiert. Die Konfigurationsdatei wird dann mit den gefundenen freien Ports angereichert und für den Start des HPM verwendet. Da das HPM im portablen Modus keine Updates durchführen kann, wird es hier so gestartet, dass alle Update-Funktionen deaktiviert sind. Aus diesem Grund wird dieser Modus nur im Testmodus, d.h. in Kombination mit dem Flag-test
unterstützt. Kann in Kombination mit dem Flag-env
verwendet werden. -
-env
kann in jedem Installationsmodus genutzt werden, um Umgebungsvariablen anzugeben, welche im Zuge der Installation in die Konfigurationsdatei geschrieben werden. Das Format sieht vor, dass Name und Wert einer Umgebungsvariable durch ein Gleichzeichen getrennt werden. Die Werte selbst dürfen ebenfalls Gleichzeichen enthalten. Mehrere Umgebungsvariablen werden durch Semikola getrennt.Beispiel:
./installer.exe -env="name=wert;variable2=ganz_anderer_wert"
Anwendungsbeispiele für Silent-Modus und Sonderflags
Installer mit allen Infos starten
.\hpm-installer.exe -silent -installPath="C:\Programme\HPM" -port=24445 -online
Alternativ mit einer bestehenden Konfigurationsdatei starten (die nicht im Standardverzeichnis liegen muss):
./hpm-installer-linux -silent -configFile="/tmp/hpm_config.json"
Den Installer mit einer vorhandenen Konfiguration starten und spezifische Werte überschreiben:
./hpm-installer-linux -silent -configFile="/tmp/hpm_config.json" -port=7777 -online=false
Return Codes bei Installation
Return Code | Beschreibung |
---|---|
0 | Erfolgreiche Installation |
1 | Installation wurde von User abgebrochen |
2 | Ungültige Konfiguration |
16 | Fehler bei Installation aufgetreten |
Deinstallation
Die Deinstallation kann auf mehrere Arten durchgeführt werden:
- Über den Installer:
.\HAEVG_Pruefmodul_2023Q3_Installer_Windows_x64.exe -uninstall
- Über die installierte HPM-Datei:
.\hpm.exe -uninstall
Unter Windows besteht zusätzlich die Möglichkeit, das HPM über die Windows-Systemeinstellung “Apps und Features” zu deinstallieren:
Update
Das HPM besitzt einen eigenen Update-Mechanismus, der es dem HPM erlaubt, die eigenen Komponenten der Anwendung zu aktualisieren.
Dies ist immer nur innerhalb einer Quartalsversion möglich.
Für das Aktualisieren der Quartalsversion muss der HPM Installer benutzt werden.
Das HPM umfasst dabei die Komponenten Datenbanken
, Fachservices
und die HPM Executable (hpm.exe|hpm.app|hpm.bin)
.
Updates der Datenbanken werden regelmäßig zur Verfügung gestellt. Die anderen Komponenten werden nur bei Bedarf aktualisiert.
Trigger
Es gibt drei Wege, wie die Updatesuche und das Update startet: beim Start des HPM, nächtlich einmalig zwischen 1-4 Uhr und mittels SOAP oder REST Request.
Das HPM wird bei jedem Start einmal nach Updates suchen. Ist ein Update verfügbar, wird dieses heruntergeladen und vorbereitet.
Nach der erstmaligen Updatesuche wird die Updatesuche jede Nacht maximal einmal im Zeitfenster von 1-4 Uhr durchgeführt.
Zusätzlich kann ein Update auch per Request an das HPM angefordert werden
REST: http:localhost:22220/api/update
SOAP: http:localhost:22220/Service.asmxRequest Body für SOAP:
<?xml version="1.0" encoding="utf-8"?> <soap12:Envelope xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"> <soap12:Body> <Update xmlns="http://haevg-rz.de/hpm" /> </soap12:Body> </soap12:Envelope>
Downtime
Das HPM ist solange voll funktionsfähig, bis alle Updatedateien heruntergeladen und für das Update vorbereitet sind.
Nur zum Zeitpunkt des Updates sind die sonstigen Funktionen des HPMs nicht verfügbar. Die Downtime ist somit so kurz wie möglich gehalten.
Erfolgreiche Updates
Während des Downloads der Updatedateien bleibt das HPM erreichbar. Für die Dauer des Updateprozesses selbst hingegen sind die Fachservices nicht erreichbar. Bei Aktualisierung der HPM Executable wird das HPM neu gestartet. Das Log enthält nach einem erfolgreichen Update den Eintrag
“Update erfolgreich! ‘[
Komponente
]’ [Aktuelle Version
] -> [Neue Version
].”
Fehlgeschlagene Updates
Sollte ein Update während des Updates oder nach einer Update-Erfolgsprüfung fehlschlagen, wird versucht, das HPM auf die ursprüngliche Version zurückzusetzen.
Das Log enthält in diesem Fall den folgenden Eintrag:
“Fehler erkannt: [
Fehlermeldung
] Versuche auf Version[Ursprungsversion]
zurückzusetzen.”
Sollte es beim Zurücksetzen des HPMs zu einem unvorhergesehenen Fehler kommen, wenden Sie sich bitte an unseren Support.
Sicherheit
Alle Updates sind signiert und werden vor der Anwendung geprüft.
Voraussetzungen
Es wird bei jedem Start des HPM sowie täglich in der Nacht zwischen 1:00 Uhr und 4:00 Uhr auf Updates geprüft. Damit Updates ausgeführt werden können, muss
- die Erreichbarkeit des Update-Servers gewährleistet sein (https://hpm-prod-update.az.haevg-rz.net/update/)
- unter macOS “Full Disk Access” für das HPM aktiviert sein (siehe Abschnitt ‘Festplatten-Vollzugriff bei macOS nach Neuinstallation’).
Konfiguration
Es existiert eine zentrale Konfigurations-Datei (hpm_config.json), welche zur Steuerung der Anwendung, Festlegung der Ports, der zu startenden Fachservices sowie weiterer Einstellungen dient.
hpm_config.json, wie sie nach einer Standardinstallation auf einem Windowssystem aussieht:
{
"AppInstallPath":"C:\\Program Files\\HÄVG Rechenzentrum AG\\HÄVG-Prüfmodul",
"IstOnline":true,
"IstTestsystem":true,
"BackendPort":22230,
"FrontendPort":22220,
"FrontendTLSPort":22225,
"BackendTimeoutSeconds":600,
"LogLevel":0,
"LogDirectory":"C:\\ProgramData\\HÄVG Rechenzentrum AG\\HÄVG-Prüfmodul",
"DatabaseDirectory": "C:\\Program Files\\HÄVG Rechenzentrum AG\\HÄVG-Prüfmodul\\Database",
"TelemetryEndDate": "2023-10-20T00:00:00",
"Proxy": "http://localhost:999",
"ServiceMetaInfos":[
{
"Name": "HZV",
"ExecutableName": "HaevgRZ.HPM.HZV.Service",
"Port": 22240,
"Path": ""
},
{
"Name": "AMM",
"ExecutableName": "HaevgRZ.HPM.AMM.Service",
"Port": 22250,
"Path": ""
},
{
"Name": "EAV",
"ExecutableName": "HaevgRZ.HPM.EAV.Service",
"Port": 22260,
"Path": ""
}
]
}
Diese Konfiguration kann um Entwicklungsschalter erweitert werden, die nur auf Testsystemen funktionieren
[...]
"DevSettings": {
"HPM_VerwendeEingebettetesEntwicklungsZertifikat": "false",
"HPM_SkipFachserviceStart": "false",
"HPM_Maintenance": "true",
"HPM_DateTimeNow":"2023-06-20T10:00:00",
}
[...]
Konfigurationsdatei mit Konfigurationsschema validieren
Mit dem Konfigurationsschema können angepasste oder manuell erstellte Konfigurationsdateien validiert werden.
Validierung in Visual Studio Code aktivieren
In der /.vscode/settings.json Datei kann diese Einstellung hinzugefügt werden und somit die Validierung der Konfigurationsdatei mit der Schema-Datei aktiviert werden.
"json.schemas": [ {
"fileMatch": [ "*/*hpm_config.json"],
"url": "./hpm_config.schema.json"
}]
Validierung mit Powershell (ab 7.4.0)
Test-Json -Path hpm_config.json -SchemaFile hpm_config.schema.json
Konfigurationsschema herunterladen
Info: Diese Datei wird beim Installieren neben die hpm_config.json ins Konfigurationsverzeichnis gelegt.
Flag-Beschreibung
Flag | Beschreibung |
---|---|
BackendPort | Dient der internen Kommunikation im HPM. |
BackendTimeoutSeconds | Der Standard-Timeout für Requests vom HPM in Richtung Rechenzentrum in Sekunden. |
DatabaseDirectory | Beschreibt, in welchem Verzeichnis die Datenbanken des HPMs liegen. Kann mit einer absoluten Pfadangabe überschrieben werden. |
FrontendPort | Beschreibt, über welchen Port das HPM erreichbar ist. |
FrontendTLSPort | Beschreibt, über welchen TLS-Port das HPM erreichbar ist. |
IstOnline | Beschreibt, ob es sich um eine Online-Installation handelt. |
IstTestsystem | Beschreibt, ob es sich um eine Test-Installation handelt. |
LogDirectory | Durch die Angabe eines absoluten Pfades kann das Verzeichnis für Logs geändert werden. Siehe auch den Abschnitt “Logging”. |
LogLevel | Das Standard-Loglevel ist 0, es werden hiermit nur Fehler geloggt. Mit 1 werden zusätzliche Informationen geloggt, mit 2 ausführliche Informationen ausgegeben. |
ServiceMetaInfos | Beschreibt die Konfiguration der zu startenden Fachservices. - Name: Beschreibt den Ordnernamen des Fachservices sowie den Namen der Logdate - ExecutableName: Ausführbare Datei des Fachservices - Port: Port, auf dem der Fachservice innerhalb des HPMs verwendet wird - Path: Pfadangabe zur ausführbaren Datei |
TelemetryEndDate | Sofern gesetzt, versendet das HPM bis zum gesetzten Datum nicht-personenbezogene Telemetrie-Daten. Wenn die Zeitspanne länger als ein Monat ist, wird der Eintrag ignoriert und die Funktion ist deaktiviert. |
Proxy | Setzt einen Proxy, über welchen alle HTTP-Requests geleitet werden. |
DevSettings | Beschreibt diverse Einstellungen, die vorrangig für die Verwendung durch Entwickler gedacht sind. Namen besitzen das Präfix “HPM_”. Auch sind die bisher in der .env-Datei untergebrachten Umgebungsvariablen jetzt in den DevSettings untergebracht. |
Umgebungsschalter und DevSettings zur Steuerung des Verhaltens
Es existieren weitere Umgebungsvariablen und Einstellungen, welche das Verhalten des HPM beeinflussen. Nehmen Sie daher Änderungen mit Bedacht vor und bitte nur, wenn Sie sich der Folgen der Änderungen bewusst sind. Beachten Sie, dass Sie das HPM neustarten müssen, damit die Änderungen wirksam werden.
Folgende Werte sind verfügbar:
Variable/Einstellung | Auswirkung |
---|---|
HPM_VerwendeEingebettetesEntwicklungsZertifikat = true | Verwendung des Embedded-Test-Zertifikats. Ein HZV-Online-Key ist für den Betrieb auf Test-Ebene nicht notwendig. |
HPM_SkipFachserviceStart | Wenn auf den Wert “true” gesetzt, verhindert diese Einstellung den Start der Fachservices. |
HPM_Maintenance | Wenn auf den Wert “true” gesetzt, wird vom HPM simuliert, dass sich die RZ-Server in einem Wartungsgenster befinden. |
HPM_DateTimeNow | Erlaubt die Verwendung eines selbst gewählten aktuellen Datums (analog zum HPM Legacy, um Simulationen durchführen). |
Im HPM Legacy bestand die Möglichkeit der Verwendung einer .env-Datei, um Umgebungsvariablen sammeln und applikationsspezifisch setzen zu können. Diese Datei wird vom HPM nicht mehr verwendet.
Schnittstellenübersicht HPM
Das HPM stellt Kommunikationsmethoden über die Schnittstellen SOAP und REST bereit. Beide Schnittstellen verfügen über die dieselben Funktionalitäten. Beachten Sie bitte einzelne Ausnahmen unter [Breaking changes](#Breaking changes).
Testfälle
Zum Testen der Schnittstelle bieten wir eine Sammlung von Testfällen an, die mit Postman ausgeführt werden können. Diese stehen im AKA-Portal zum Download bereit.
Außerdem können Test-Requests auch über die Swagger-Seiten ausgeführt werden. Die Swagger-Seiten dokumentieren die einzelnen Endpunkte und bieten jeweils einen Testfall an, der ohne Authentifizierung beim HPM ausgeführt werden kann.
Die Swagger-Seiten sind auf der HPM-Infoseite verlinkt.
REST
Jeder Fachservice verfügt über eine eigene OpenAPI-Spezifikation, welche als Swagger-Datei betrachtet werden kann:
-
HZV: http://localhost:22240/swagger/index.html
-
AMM: http://localhost:22250/swagger/index.html
-
EAV: http://localhost:22260/swagger/index.html
Über die Swagger-Seite können direkt auch Test-Requests an das HPM geschickt werden.
Die Pfade, die in Swagger angezeigt werden, müssen für einen Aufruf vom PVS oder Postman heraus angepasst werden:
- Der Port muss auf den FrontendPort des HPMs geändert werden (siehe Konfiguration)
- Der Pfad muss um latest/{Name des Fachservices} angepasst werden.
Als Beispiel vom HZV-Service:
http://localhost:22240/api/versichertenteilnahmen/erklaerungen → verfügbar über HPM mit http://localhost:22220/api/latest/hzv/versichertenteilnahmen/erklaerungen
Die Swaggerseiten sind nur in Testinstallationen erreichbar, nicht in produktiven Installationen.
Übertragung von XML-Inhalten
XML Dokumente müssen bei Verwendung der REST-Schnittstelle URL über ein String Property übertragen werden.
SOAP
Die WSDL für SOAP kann über http://{{HPM_HOST}}:{{HPM_PORT}}/Service.asmx?wsdl (Beispiel: http://localhost:22220/Service.asmx?wsdl) erreicht werden.
Bitte beachten: Der Endpunkt ist “case-sensitive”, die Großschreibung von “Service” ist für den Abruf der wsdl, aber auch für die generelle Nutzung essenziell.
HTTP-Authentifizierung
Die Beschreibung zur HTTP-Authentifizierung finden Sie in der HPM-Anleitung (PDF), die aus dem AKA-Portal bezogen werden kann.
Breaking changes
- Es gibt bei der SOAP-Schnittstelle wenige Änderungen im Vergleich zum HPM Legacy. Diese betreffen nur das XML-Choice Attribut der WSDL. Hieraus resultiert folgende Liste mit Änderungen:
Methode: ErzeugeZertifikatArzt
Bisher:
<s:complexType name="ArztIdentifikationType">
<s:choice>
<s:element minOccurs="1" maxOccurs="1" name="ArztIdentifikationscode" type="s:string"/>
<s:element minOccurs="1" maxOccurs="1" name="ArztIdentifikationZertifikat" type="tns:ArztIdentifikationZertifikatType"/>
</s:choice>
</s:complexType>
Jetzt:
<s:complexType name="ArztIdentifikationType">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="ArztIdentifikationscode" type="s:string"/>
<s:element minOccurs="0" maxOccurs="1" name="ArztIdentifikationZertifikat" type="tns:ArztIdentifikationZertifikatType"/>
</s:sequence>
</s:complexType>
Methode: SendeArztbrief
Bisher:
<s:complexType name="ArztbriefEmpfaenger">
<s:choice>
<s:element minOccurs="1" maxOccurs="1" name="Bsnr" type="s:string"/>
<s:element minOccurs="1" maxOccurs="1" name="EmpfaengergruppeIdentifikator" type="s:int"/>
</s:choice>
</s:complexType>
Jetzt:
<s:complexType name="ArztbriefEmpfaenger">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="Bsnr" type="s:string"/>
<s:element minOccurs="0" maxOccurs="1" name="EmpfaengergruppeIdentifikator" type="s:int"/>
</s:sequence>
</s:complexType>
Methode: SendeTelekonsil
Bisher:
<s:complexType name="TelekonsilEmpfaenger">
<s:choice>
<s:element minOccurs="1" maxOccurs="1" name="Lanr" type="s:string"/>
<s:element minOccurs="1" maxOccurs="1" name="EmpfaengergruppeIdentifikator" type="s:int"/
</s:choice>
</s:complexType>
Jetzt:
<s:complexType name="TelekonsilEmpfaenger">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="Lanr" type="s:string"/>
<s:element minOccurs="0" maxOccurs="1" name="EmpfaengergruppeIdentifikator" type="s:int"/>
</s:sequence>
</s:complexType>
Methode: SendeEinweisungsbrief
Bisher:
<s:complexType name="EinweisungsbriefEmpfaenger">
<s:choice>
<s:element minOccurs="1" maxOccurs="1" name="Institutionskennzeichen" type="s:string"/>
<s:element minOccurs="1" maxOccurs="1" name="EmpfaengergruppeIdentifikator" type="s:int"/>
</s:choice>
</s:complexType>
Jetzt:
<s:complexType name="EinweisungsbriefEmpfaenger">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="Institutionskennzeichen" type="s:string"/>
<s:element minOccurs="0" maxOccurs="1" name="EmpfaengergruppeIdentifikator" type="s:int"/>
</s:sequence>
</s:complexType>
-
Die SOAP-Schnittstelle unterstützt keine custom Namespaces mehr
-
Die Rückgabeinhalte der SOAP-Methode LiefereHpmInformation und der REST Endpunkt /api/hpminformation weichen vom HPM Legacy ab
a) Die Version im Format YYYY-Q-NNNN (Beispiel: 2022-4-0337) und nicht mehr QX-YYYY.Z
b) Die Auflistung der Vertragsidentifikatoren ist entfallen
HPM-Erreichbarkeit
Öffentliches Internet
Da über das HPM u. A. besonders schützenswerte Daten übermittelt werden, ist es von besonderer Wichtigkeit, dass die laufenden HPM-Dienste/-Programme NICHT über das Internet bzw. NUR in Ihrem lokalen Netzwerk erreichbar sind.
HPM-Ports und Prozesse im internen Netzwerk
Damit das HPM (und die dazugehörigen Fachservices) für andere Programme in Ihrem Netzwerk erreichbar ist, benötigt das HPM mehrere Ports, unter welchen es aufgerufen werden kann. Diese Ports sind über die Konfigurationsdatei änderbar. Folgende Ports werden vom HPM und von den Fachservices standardmäßig verwendet:
- 22220 und 22225 (TLS) HPM aus Sicht des PVS
- Interne Ports (nur über localhost erreichbar, nicht für Fremdbenutzung gedacht):
- 22230 Interne Kommunikation der Fachservices
- 22240 Fachservice HZV
- 22250 Fachservice AMM
- 22260 Fachservice eAV
Um einen reibungslosen Betrieb zu gewährleisten, stellen Sie bitte vor Start des HPM sicher, dass die eingestellten Ports nicht belegt sind.
Vom Haupt-Prozess des HPM ausgehend wird automatisch dafür gesorgt, dass die Fachservices als Kind-Prozesse gestartet und im Falle eines Absturzes auch automatisch neu gestartet werden.
HPM-Verfügbarkeit im internen Netzwerk testen
Ob das HPM und die Fachservices ordnungsgemäß gestartet gewerden konnten und erreichbar sind, kann über die “Health”-Schnittstelle (/api/health) abgefragt werden.
Dieser Endpunkt benötigt keine Authentifizierung.
Das globale Datenfeld “Verfügbar” hat nur dann den Wert true
, wenn alle Endpunkte verfügbar sind. Soll die Verfügbarkeit eines bestimmten Services oder Proxys abgefragt werden, können die jeweiligen Datenfelder der Endpunkt-Objekte abgefragt werden.
Ein Beispiel findet sich dazu auch in der OpenAPI-Spezifikation des HPMs.
Installation als Service
Zusätzlich zur Gesamtinstallation des HPM (s. Abschnitt “Installation”) bietet die HPM-Executable die Möglichkeit, per Parameter explizit die Installation als Daemon oder Service durchzuführen, entsprechende Berechtigungen des ausführenden Benutzers vorausgesetzt.
Windows
Die HPM-Executable ist zu diesem Zweck um folgende Eingabeparameter erweitert:
- -svc=install - installiert das HPM als Service
- -svc=uninstall - deinstalliert den HPM-Service
- -svc=start - startet den HPM-Service
- -svc=stop - stoppt den HPM-Service
Eine beispielhafte Ausführung wäre “.\hpm.exe -svc=install”.
Linux
Eine beispielhafte Ausführung wäre “./hpm.bin -svc=install”.
macOS
Eine beispielhafte Ausführung wäre “./hpm.app -svc=install”
Dateiintegrität
Die Dateiintegrität ist mit einer Ed25519-Signatur gewährleistet, zum Überprüfen der Signatur nutzen Sie das Tool minisign.
Beispielhaft das Überprüfen des Archives mit der Datenbank:
minisign.exe -V -m Database.tar -P RWTKQPJTILubVJRZkRf50ToJxQfcTlPnW40t+iJN2ceh9G10lW0wPBES
Erwartete Ausgabe: “Signature and comment signature verified”
HÄVG RZ Public Ed25519 Schlüssel:
RWTKQPJTILubVJRZkRf50ToJxQfcTlPnW40t+iJN2ceh9G10lW0wPBES
TLS in der Praxis
Auf den EDV-Systemen der Ärzte werden sensible, schützenswerte Daten von Patienten verarbeitet. Da das HÄVG-Prüfmodul als Datenvermittler auch Teil der Übermittlungsstrecke ist, kann der Datenfluss zwischen den PVS-Systemen und dem HPM innerhalb der Arztpraxis verschlüsselt stattfinden.
Es sind beide Modi (HTTP und HTTPS) parallel verfügbar.
Angelehnt ist die TLS-Implementierung des HPM an die Telematik-Infrastruktur 1.0 der Gematik.
Abrufen des Fingerabdrucks
Es steht ein Endpunkt unter dem Pfad /fingerprint zur Verfügung, um den Fingerabdruck des HPM-Zertifikats abzurufen. Dieser wird sich auf lange Sicht nicht ändern und kann zwischengespeichert werden.
Technischer Rahmen
- minimale TLS-Version: v1.2
- Algorithmus zur Schlüsselgenerierung: ECDSA
- Zertifikat-Signaturalgorithmus: ECDSAWithSHA256
Liste der Cipher Suites
Die untenstehende Liste stellt eine erschöpfende Aufzählung aller verwendeten Cipher Suites für TLS-Version 1.2 dar. Diese unterstützen bei TLS-Version 1.2 Perfect Forward Secrecy.
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Bei TLS-Version 1.3 sind die verwendetet Cipher Suites unveränderlich festgelegt und Perfect Forward Secrecy ist in jedem Fall aktiv.
Referenzimplementierungen
Es besteht die Möglichkeit, dem Zertifikat des HPM bedingungslos zu vertrauen, dies wird jedoch nicht empfohlen. Stattdessen kann der Fingerabdruck des HPM-Zertifikats mit ebendem Fingerabdruck verglichen werden, welcher unter /fingerprint abrufbar ist.
Java
Ein Möglichkeit stellt eine benutzerdefinierte SSLSocketFactory mit einer eingenen Implementierung der Methode checkServerTrusted()
der TrustManager-Klasse dar.
public class MyCustomSSLSocketFactory extends SSLSocketFactory {
SSLContext sslContext = SSLContext.getInstance("TLS");
public MyCustomSSLSocketFactory(KeyStore truststore) throws NoSuchAlgorithmException, KeyManagementException, KeyStoreException, UnrecoverableKeyException {
super(truststore);
TrustManager tm = new X509TrustManager() {
public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {
}
public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
// hier Fingerprint des Server-Zertifikats mit zuvor
// abgerufenem Wert vergleichen und ggfs. Exception werfen
}
public X509Certificate[] getAcceptedIssuers() {
return null;
}
};
sslContext.init(null, new TrustManager[] { tm }, null);
}
//hier den initial erstellten SSLContext verwenden
@Override
public Socket createSocket(Socket socket, String host, int port, boolean autoClose) throws IOException, UnknownHostException {
return sslContext.getSocketFactory().createSocket(socket, host, port, autoClose);
}
@Override
public Socket createSocket() throws IOException {
return sslContext.getSocketFactory().createSocket();
}
}
Verwendet werden kann es so:
KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType());
trustStore.load(null, null);
MyCustomSSLSocketFactory sf = new MyCustomSSLSocketFactory(trustStore);
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER); // ggfs. anpassen
// ggfs. anpassen
HttpParams params = new BasicHttpParams();
HttpProtocolParams.setVersion(params, HttpVersion.HTTP_1_1);
HttpProtocolParams.setContentCharset(params, HTTP.UTF_8);
// ggfs. anpassen
SchemeRegistry registry = new SchemeRegistry();
registry.register(new Scheme("http", PlainSocketFactory.getSocketFactory(), 80));
registry.register(new Scheme("https", sf, 443));
ClientConnectionManager ccm = new ThreadSafeClientConnManager(params, registry);
HttpClient client = DefaultHttpClient(ccm, params);
C#
static async Task MyMethod(string[] args)
{
using var handler = new HttpClientHandler();
handler.ServerCertificateCustomValidationCallback = CheckCert;
using var client = new HttpClient(handler);
// ...
}
private static bool CheckCert(HttpRequestMessage requestMessage, X509Certificate2 cert, X509Chain chain, SslPolicyErrors errors)
{
Console.WriteLine($"Cert Thumbprint: {cert.Thumbprint}");
return true;
}
Go
var fingerprint string
func main() {
client := &http.Client{
Timeout: 10 * time.Second,
Transport: &http.Transport{
TLSClientConfig: &tls.Config{
InsecureSkipVerify: true,
VerifyConnection: func(state tls.ConnectionState) error {
if len(state.PeerCertificates) == 0 {
return fmt.Errorf("Server hat kein Zertifikat gesendet")
}
cert := state.PeerCertificates[0]
if GetCertificateFingerprint(cert) != fingerprint {
return fmt.Errorf("Fingerprint passt nicht")
}
// prüfen, ob das Zertifikat zeitlich noch gültig ist
now := time.Now()
if cert.NotBefore.After(now) || cert.NotAfter.Before(now) {
return fmt.Errorf("Zertifikat ist zeitlich nicht mehr gültig")
}
return nil
},
},
},
}
resp, err := client.Get("http://localhost:22220/fingerprint")
if err != nil {
panic(err)
}
fp, err := io.ReadAll(resp.Body)
if err != nil {
panic(err)
}
if len(fp) > 0 {
fingerprint = string(fp)
}
resp, err = client.Post("https://localhost:22225/api/hpminformation", "application/json", nil)
if err != nil {
panic(err)
}
hpmInfo, err := io.ReadAll(resp.Body)
if err != nil {
panic(err)
}
defer resp.Body.Close()
fmt.Println(string(hpmInfo))
}
func GetCertificateFingerprint(x509Cert *x509.Certificate) string {
sum := sha256.Sum256(x509Cert.Raw)
return strings.ToLower(hex.EncodeToString(sum[:]))
}
Betrieb des HPM mit alternativem Zeitstempel
Für Zulassungen oder andere Szenarien kann es notwendig sein, das HPM in der Zukunft zu betreiben. Hierfür ist die Einstellung in der hpm_config.json “HPM_DateTimeNow” auf das gewünschte Datum zu setzen.
Es ist für das HPM nicht notwendig, dass die Systemzeit geändert wird. Sollte dies allerdings für den Client des HPMs notwendig sein, gibt es zwei mögliche Verfahren:
- Zusätzliche Angleichung der Systemzeit des HPM-Servers an den Client
- Anpassung des X-DateTime-Headers bei Requests an das HPM. Die Zeitangabe muss mit der Systemzeit des HPMs übereinstimmen. Der angepasste Header muss dann auch für die Berechnung des BasicAuth-Headers verwendet werden.
HPM-Zeit
Über die REST-Schnittstelle /api/timestamp kann die aktuelle Systemzeit des HPMs abgerufen werden. Diese wird beim Setzem des altenativen Zeitstempels “HPM_DateTimeNow” nicht überschrieben. Es wird die tatsächliche Systemzeit zurückgegeben.