Implementierungshinweise für Primärsystemhersteller

Generelle Implementierungshinweise finden Sie weiter unten auf dieser Webseite.

Aktuelle Hinweise

TLS 1.1 wird abgekündigt (ab PTV 3 Konnektoren)

PTV3-Konnektoren werden TLS 1.1 nicht mehr unterstützen, weil der Standard veraltet ist. Beim Aufbau einer TLS-gesicherten Verbindung zwischen Primärsystem und Konnektor ab PTV3 muss TLS 1.2 verwendet werden. Der Konnektor kann nur noch in den Produkttypversionen 1 und 2 die TLS-Version 1.1 anbieten. Nur mit diesen Produkttypversionen kann das Primärsystem auch TLS-Version 1.1 verwenden. Ab  der  Konnektor-Produkttypversion 3 bietet der Konnektor TLS nur noch gemäß TLS-Version 1.2 oder 1.3 an. Ab PTV3 MUSS das Primärsystem für TLS-gesicherte Verbindungen TLS Version 1.2 verwenden, es KANN auch TLS Version 1.3 verwenden.

Tokenbasierte Authentisierung optional (ab PTV 3 Konnektoren)

Nicht jeder Konnektorhersteller muss den Dienst Tokenbasierte Authentisierung ("TBAuth", s. gemILF_PS, Kapitel 4.4.5.2) anbieten. Die Verfügbarkeit des Dienstes kann am Dienstverzeichnisdienst (DVD) abgefragt werden. Ob der Dienst TBAuth vom Konnektor angeboten wird ist herstellerabhängig.

Automatische Aktualisierung Konnektor 

Bisher ist eine Administratoraktion (bzw. DVO-Einsatz) notwendig, um ein Firmewareupdate des Konnektors zu aktivieren. Dieses führt dazu, dass es viele Monate dauert, bis eine neue Konnektor-Firmewareversion flächenendeckend im Einsatz ist. Um diesen Zustand zu verbessern, wird standardmäßig eine automatische Firmewareaktualisierung des Konnektors eingeführt. Um dem Nutzer darüber zu informieren, in welcher Firmware-Version er seinen Konnektor nutzt, soll das Primärsystem an geeigneter Stelle dem Nutzer die Firmwareversion des Konnektors anzeigen, der an das Primärsystem angebunden ist. Die Konnektorversion wird über den Dienstverzeichnisdienst ausgelesen. Zur Anzeige kommen dabei die DVD-Informationen ProductVendorName, ProductName und ProductVersion/Local/FWVersion.

Drittes Geschlecht "divers"

Gemäß Änderung des Personenstandsgesetzes (PStG) können Einträge in das Geburtenregister ohne Angabe des Geschlechts erfolgen oder für Personen mit Varianten der Geschlechtsentwicklung den Wert "D" = divers enthalten. Diese Werte können im VSDM Verwendung finden, sowie ähnlich auch in eMP und NFDM:

Element „Geschlecht“, Erweiterung Wertebereich:
X = unbestimmt
D = divers

Identifizierendes Merkmal für Zahnärzte im eMP

Die Primärsystem-Anforderung AMTS-A_2272 verlangt das Befüllen eines der Attribute "LANR", "IDF" oder "KH-IK". Primärsysteme der Zahnärzte sollen eine zahnarztspezifische Bildungsregel verwenden, um über eine Nummer zu verfügen, die sie in das Attribut "MP/A/@lanr" eintragen. Diese Nutzung von MP/A/@lanr wird in gemSpec_INFO_AMTS übernommen.

Details entnehmen Sie bitte dem Dokument gemErrata_2_Kon_PTV3, ID C_6835 bzw. dem Implementierungsleitfaden gemILF_PS_AMTS AMTS-A_2272.

AMTS-Schema ohne feste Verweise auf eine BMP-Version

Das Schema AMTS_Document_v1_5.xsd hat in dem Attribut "v" einen festen Verweis auf die aktuell verwendete BMP-Version. Bei jeder Änderung des BMP muss zurzeit auch das AMTS-Schema angepasst werden. Eine einfache Schemaanpassung ist zurzeit nicht möglich, daher soll diese feste Verknüpfung aufgelöst werden. Das Primärsystem soll die BMP-Version in den AMTS-Datensatz schreiben. Zurzeit besteht bereits eine Abweichung, da sich der BMP in der Version 2.6 befindet, aber in dem AMTS_Document_v1_5.xsd die Version fest auf 2.5 verblieben ist. 
Alle festen Verweise auf eine BMP Version werden im Schema AMTS_Document_v1_6.xsd aufgehoben, um Konflikte bei der Veröffentlichung neuer Versionen zu vermeiden.

Die konkreten Änderungen sind beschrieben in gemSpec_Info_AMTS (Kapitel 2.1 XML-Artefake/Versionsverwaltung: Tabelle 1: Tab_AMTS_Info_001 XML-Dokumente zum Info-Modell der Fachanwendung eMP/AMTS-Datenmanagement und Kapitel 2.3 eMP/AMTS-Daten: attribute MP/@v, attribute MP/@iv, attribute MP/S/M/@ps).

Die für die Umsetzung im Primärsystem entsprechende Anforderung "AMTS-A_2282 - Unterstützung unterschiedlicher Versionen des BMP" finden Sie im Implementierungsleitfaden gemILF_PS_AMTS.

Einfügen der OIDs für die Datensätze NFD, DPE und AMTS

Für jeden Datensatz (NFD, DPE und AMTS) gibt es jeweils eine eindeutige Identifikationsnummer die von der DIMDI vergeben wird. Dadurch lässt sich ein Datensatz als ein eindeutig von der gematik Spezifiziert NFD/DPE/AMTS-Datensatz identifizieren. Jede dieser Identifikationsnummer wird durch ein Attribut in dem jeweiligen Datensatz repräsentiert und erhält eine fest definierte OID. Bislang wurde nur ein Platzhalter für die OID als Wert eingetragen und soll nun durch die richtige OID ersetzt werden. Da eine Anpassung an den Schemata erfolgt wird die Versionsnummer der Schemadateien korrigiert.

Details entnehmen Sie bitte dem Dokument gemErrata_2_Kon_PTV3, ID C_6892 und den betroffenen Informationsmodellen Notfalldaten-Management und eMP/AMTS-Datenmanagement.

Korrektur Signaturrichtlinie QES NFDM

Es gibt drei Probleme, die im Zusammenhang mit der Adressierung von XML-Elementen bei der Platzierung von Signaturen in XML-Elementen auftreten:

1. Der XPath-Ausdruck in der NFDM-Signaturrichtlinie berücksichtigt nicht den Namespace der zu selektierenden Knoten. Da die Schnittstelle keine Möglichkeit vorsieht, einen Default-Namespace für den XPATH-Ausdruck vorzugeben, wird der Ausdruck angepasst, so dass der Namespacekontext ausgeblendet wird. Damit ist der Ausdruck auch robust gegenüber möglichen Namespace-Prefixes.
2. Die Spezifikation [OASIS-DSS] verlangt eine Möglichkeit zur Zuordnung von Namespace-Prefixes zu Namespaces, die nicht der üblichen Umsetzungspraxis in Frameworks entspricht.
3. Damit der Pfadausdruck im Ausdruck VerifyDocument dss:Signatur identifiziert muss er das Element Signatur umfassen.

Details zur den Anpassungen entnehmen Sie bitte dem Dokument gemErrata_2_Kon_PTV3, ID C_6754 und der Signaturrichtlinie QES Notfalldaten-Management gemRL_QES_NFD. 

Notfalldaten-Signaturrequest: Referenz auf den zu signierenden Teilbaum                                                                                  

Im NFD-Signaturrequest ist eine Referenz auf den zu signierenden Teilbaum anzugeben. Eine solche (Same-Document-) Referenz beginnt mit einem Hash (#). Die Quelle dieser Vorgabe befindet  sich in https://www.w3.org/TR/xmldsig-core1, 4.4.3.2: The Reference Processing Model URI="" Identifies the node-set (minus any comment nodes) of the XML resource containing the signature.

URI="#chapter1" Identifies a node-set containing the element with ID attribute value 'chapter1' of the XML resource containing the signature. XML Signature (and its applications) modify this node-set to include the element plus all descendants including namespaces and attributes -- but not comments.

QES-XAdES-Signatur nur mit Signaturrichtlinie

Die aktuell spezifizierte Funktion zur Signaturerstellung und -prüfung ist nach Einschätzung des BSI nicht zertifizierbar. Um den Zeitplan für die Zertifizierung und Zulassung des PTV3-Konnektors abzusichern, wird der Funktionsumfang der qualifizierten elektronischen Signatur von XML-Daten nach XAdES auf bekannte Signaturrichtlinien eingeschränkt.

Details entnehmen Sie bitte dem Dokument gemErrata_2_Kon_PTV3, ID C_6820 und der Anlage zu C_6820.

Profilierung der nonQES-Signatur

In der Spezifikation wird eine Profilierung der nonQES-Schnittstelle des Konnektors vorgenommen. Dabei handelt es sich im Einzelnen um:

- Verzicht auf PDF-Gegensignatur
- PDF-Signatur wird als Incremental Update des PDF-Dokuments festgelegt
- Verzicht auf eingebettete OCSP-Responses bei PDF-Signaturen
- Reduzierung auf eine Gegensignatur-Variante bei XAdES/CAdES: dokumentexkludierend
- Streichung von Teilbaum XML Signaturen (auch nonQES)

Details entnehmen Sie bitte dem Dokument gemErrata_2_Kon_PTV3, ID C_6890 und dem Anhang zu C_6890.

XML-Teilbaumverschlüsselung entfernt

Um Risiken für eine erfolgreiche Zertifizierung des Konnektors zu reduzieren wird die Funktionalität zur Ver- und Entschlüsselung von XML-Teilbäumen entfernt.

Details entnehmen Sie bitte dem Dokument gemErrata_2_Kon_PTV3, ID C_6844 und der Konnektor-Spezifikation gemSpec_Kon, TIP1-A_4621 und TIP1-A_4622

Bereitstellung von Anforderungslisten zur automatisierten Nachbearbeitung
Die gematik stellt hier im Fachportal Anforderungslisten und Übersicht über Änderungen die normativen Anforderungen aus den Konzepten und Spezifikationen sowie aus den Steckbriefen des jeweils aktuellen Releases in Tabellenform als *.xlsx zur Verfügung. So können Sie z.B. die Anforderungen automatisiert weiterverarbeiten. Beachten Sie, dass Änderungen durch Errata derzeit nicht berücksichtigt werden.

 

Neue DMP-Kennzeichen zum 01.01.2019

Auf Basis des Beschlusses des gemeinsamen Bundesausschusses (G-BA) wurde die technische Anlage zur Anlage 4a BMV-Ä um drei neue DMP-Kennzeichen erweitert. Die technische Anlage zur Anlage 4a BMV-Ä wurde am 01.07.2018 veröffentlicht und tritt am 01.01.2019 in Kraft. Aufgrund dieser Festlegungen wird die Schlüsseltabelle für die DMP-Kennzeichnung im VSD-Schema 5.2.0 wie folgt erweitert:

Feldname: DMP_Kennzeichnung, Erweiterung der Schlüsseltabelle um:

7 = Chronische Herzinsuffizienz

8 = Depression

9 = Rückenschmerz

eGK G1+ ungültig ab 01.01.2019

Eine C2C-Authentisierung ist ab 01.01.2019  nicht mehr mit der eGK G1+ möglich. Der Konnektor übermittelt an das Primärsystem den Fehlercode 4192: G1+ ungültig (kein gültiger Leistungsanspruchsnachweis). Der Versicherte soll gefragt werden, ob er nicht in der Zwischenzeit eine neuere eGK von der Kasse zugeschickt bekommen hat.  Nur wenn der Versicherte keine aktuellere eGK besitzt, soll er an seine Krankenkasse verwiesen werden. Mit der eGK G1+ werden die letzten eGKs aus dem Feld genommen, die noch das VSD-Schema 5.1 verwenden.

Neu eingeführt in 2018: TI-Komponenten SubCA3

In 2018 wurde neben der bekannten TI-Komponenten-SubCA1 die neue CA3 in Betrieb genommen, d.h. im Laufe des Jahres 2018 begann die Produktion von gSMC-K-Gerätekarten, deren End-Entity-Zertifikate von der SubCA3 abgeleitet werden und in Konnektoren eingebracht werden. Für Primärsysteme ist die Auswirkung ausschließlich in dem Fall relevant, bei dem zwischen Primärsystem und Konnektor TLS konfiguriert wird und zusätzlich eine CA-Prüfung des Konnektor-TLS-Serverzertifikates durchgeführt wird. Falls eine CA-Prüfung des Konnektor-TLS-Serverzertifikates am Primärsystem durchgeführt wird, muss diese Prüfung sowohl gegen die CA1 als auch gegen die CA3 durchgeführt werden. End-Entity-Zertifikate von Konnektoren können aus beiden CAs stammen. Die Komponenten-CAs sind in der aktuellen TSL enthalten.

Generelle Implementierungshinweise

  • Der Implementierungsleitfaden Primärsysteme – Telematikinfrastruktur (TI) (einschließlich VSDM, QES-Basisdienste, KOM-LE) beschreibt die für die Implementierung des Versichertenstammdatenmanagements (VSDM) in Primärsystemen erforderlichen Vorgaben und ihre praktische Anwendung durch Primärsystemhersteller.
  • Die aktuelle Version dieses Implementierungsleitfadens [gemILF_PS] kann zusammen mit den Spezifikationen für den Online-Produktivbetrieb im Fachportal in der Rubrik Konzepte und Spezifikationen als Dokumentenpaket abgerufen werden.
  • In diesem Dokumentenpaket finden Sie auch die Implementierungsleitfäden Primärsysteme für die Anwendungen Notfalldaten-Management (NFDM) [gemILF_PS_NFDM] und elektronischer Medikationsplan/AMTS- Datenmanagement (Stufe A) [gemILF_PS_AMTS]
  • Zusätzliche Erläuterungen zu diesen Dokumenten finden Sie auf der Webseite zum aktuellen Release für den Online-Produktivbetrieb im Abschnitt Klarstellungen zu Spezifikationen – FAQ. Die FAQ-Liste enthält u.a. Erläuterungen insbesondere zum Thema Versionierung der Konnektorschnittstelle und zur Kompatibilität zwischen unterschiedlichen Versionsständen von Diensten.
  • Die aktuellen Schnittstellendefinitionen des Konnektors im XSD- und WSDL-Format  finden Sie unter Schemata, WSDL- und andere Dateien.
  • Weitere Informationen zum Spezifikationsstand der aktuell für den Online-Produktivbetrieb zugelassenen Konnektoren können Sie den folgenden Dokumenten entnehmen:
  • Ältere Release-Stände sind hier im Fachportal der gematik abrufbar: https://fachportal.gematik.de/spezifikationen/historie/
  • Bereitstellung von Anforderungslisten zur automatisierten Nachbearbeitung:
    Die gematik stellt hier im Fachportal Anforderungslisten und Übersicht über Änderungen die normativen Anforderungen aus den Konzepten und Spezifikationen sowie aus den Steckbriefen des jeweils aktuellen Releases in Tabellenform als *.xlsx zur Verfügung. So können Sie z.B. die Anforderungen automatisiert weiterverarbeiten. Beachten Sie, dass Änderungen durch Errata derzeit nicht berücksichtigt werden.