aktuellste Version der Spezifikation

Datenmodell ePA

Urheber: gematik GmbH
Version: 1.5.0
Veröffentlichungsdatum: 08.06.2020
Referenzen:
Ist Nachfolger von: Datenmodell ePA (1.3.0)
Schlagworte: Festlegung der gematik  // Telematikinfrastruktur
Stellungnahmen: 1
Bewertungen der gematik: 1

Beschreibung

Dieses Dokument spezifiziert das Datenmodell der Anwendung ePA. Das umfasst alle im Zusammenhang mit der Anwendung ePA benötigten fachlichen Datenstrukturen einschließlich der IHE-Value Sets und -Metadaten.
Das Dokument ist ein Bestandteil des Dokumentenpakets der gematik und enthält technische und semantische Anforderungen zur Nutzung in Anwendungen nach den §§ 291 und 291a Absatz 1 SGB V. Die enthaltenen Anforderungen werden entsprechend der über die Dokumentenlandkarte und Produkttypsteckbriefe auf der Webseite der gematik (www.gematik.de) geregelten Verbindlichkeit in Zulassungs- und Bestätigungsverfahren der gematik geprüft.

Mit dem Release 4.0.0 werden folgende wesentliche Erweiterungen der TI eingeführt:
- Erweiterung der Fachanwendung ePA (Stufe 2),
- Erweiterung der Fachanwendung KIM (Stufe 1.5),
- Einführung der Fachanwendung E-Rezept.

Weiterhin wurden im Dokumentenpaket Korrekturen und Optimierungen (außerhalb von Hotfixes für R3.1.3) durchgeführt, die sich aus den Entwicklungs- und Zulassungsprozessen ergeben haben. Diese Änderungen (Wartungsthemen) werden über die Änderungsliste P22.1 adressiert und sind ebenfalls in den angepassten Dokumenten enthalten. Hierbei handelt es sich um notwendige Änderungen, die die Funktionsfähigkeit, Sicherheit, Kompatibilität und Interoperabilität der Komponenten, Dienste und Betriebsleistungen der TI sicherstellen und die laufenden Entwicklungs- bzw. Zulassungsprozesse bestmöglich unterstützen sollen.

Bewertungen der gematik

  • Die gematik beabsichtigt diese Festlegung in vesta aufzunehmen.
    Im Releaseprozess der gematik wurde die vorliegende Festlegung auf Interoperabilität zu gematik Dokumenten sowie zu weiteren, zum Stand 08.11.2019, bereits in vesta enthaltenen Interoperabilitätsfestlegungen geprüft. Aus Sicht der gematik ist die vorliegende Festlegung mit den bereits in vesta eingetragenen Interoperabilitätsfestlegungen interoperabel.

Stellungnahmen

  • gemSpec_DM_ePA (Datenmodell)

    A_14761-01/ Tabelle 3 

    confidentialityCode: Durch die aktuelle Definition ist es nicht mehr möglich die Einschätzung des Patienten über die Vertraulichkeit eines Dokumentes zu erfassen. Es würde immer die Einschätzung des Einstellenden überschrieben werden, was die Nachvollziehbarkeit negativ beeinflusst. Die ValueSets aus der AG IHE-D ValueSets geben hier entsprechende Möglichkeiten vor.

    A_14761-01/ Tabelle 1 

    Für den Impfpass, Mutterpass, das Kinderuntersuchungsheft und das Zahnbonusheft wird der mimeType „pkcs7-mime“ (bei verschlüsselten und signierten Dokumenten) bzw. ein Leerzeichen „ “ (bei nicht-signierten Dokumenten) gefordert. Beides sind weder valide mimeTypes aus IHE XDS/RFC2046 Sicht, noch laut Tabelle 3 (unter A_14760-01) auf Seite 32 als valide mimeTypes in der ePA erlaubt. Der mimeType für verschlüsselte Dokumente sollte „application/pkcs7-mime“ lauten, wie auch auf Seite 32 geführt. Der mimeType für XML-basierte FHIR Ressourcen sollte „application/fhir+xml“ sein. Dieser mimeType muss auf Seite 32 noch hinzugefügt werden. Zudem wird für das Rezept der mimeType „fhir+xml“ oder ein Leerzeichen „ “ gefordert. Beides sind weder valide mimeTypes aus IHE XDS/RFC2046 Sicht, noch laut Tabelle 3 (unter A_14760-01) auf Seite 32 als valide mimeTypes in der ePA erlaubt. Der mimeType für XML-basierte FHIR Ressourcen sollte „application/fhir+xml“ sein. Dieser mimeType muss auf Seite 32 noch hinzugefügt werden.
    In einer aktualisierten Version der Spezifikation sollte übrigens unbedingt auf die Lesbarkeit in Tabellen geachtet werden, da durch die geringe Spaltenbreite die Inhalte kaum nachvollziehbar sind.

    A_19388 

    Kategorie 1c Notfalldaten: Bei Dokumenten unterschiedlichen Formats sollte klar beschrieben sein, wann welcher FormatCode zu verwenden ist, da dieser das inhaltliche Format eines Dokuments festlegt und für den Konsumenten eine Möglichkeit der Validierung des Dokuments bietet.

    2.1.4.9/ Tabelle 7

    Tab_DM_ePA_KTR_Metadatenkennzeichnungen: Der Wert „DocumentEntry.contentTypeCode“ existiert in den XDS Metadaten nicht! Hier ist wahrscheinlich „SubmissionSet.contentTypeCode“ gemeint. 
    Kodierte Werte sollten aus Gründen der Eindeutigkeit unbedingt in Kombination mit dem zugehörigen Code System, hier vermutlich 1.3.6.1.4.1.19376.3.276.1.5.12, angegeben werden.

    A_20075

    Codes und Code-System für ReferenceIdList: Kennzeichnung eines Dokumentes als „EGA“ sollte nicht über die „DocumentEntry.referenceIDList“ erfolgen. Die Werte dieser Liste unterliegen strengeren Vorschriften (siehe IHE ITI TF-3 Kapitel 4.2.3.2.28 DocumentEntry.referenceIdList) und dienen zum Verweis auf andere Dokumente. Eine solche Kennzeichnung könnte im Attribut „DocumentEntry.eventCodeList“ vorgenommen werden.

     

Entscheidung der gematik

30.10.2020

Aufgrund der bis zum 28.06.2020 eingegangenen Stellungnahme wurde eine erneute Prüfung der Interoperabilitätsbewertung durch die gematik vorgenommen.

Die eingereichten Verbesserungsvorschläge und gegebenen Hinweise werden in die weiteren Arbeiten der Spezifikation einfließen bzw. sind bereits in Folgeversionen eingeflossen.

Der vorliegende Bewertungsentwurf bleibt unverändert und die beantragte Festlegung wird mit dem Attribut „interoperabel mit den gematik-Spezifikationen/ Interoperabilitätsfestlegungen“ in vesta aufgenommen.