Elektronische Gesundheitskarte und Telematikinfrastruktur

Datenmodell ePA

    

     

      
Version
      
1.53.1
     
     

      
Revision
      
1043567
     
     

      
Stand
      
26.05.2023
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_DM_ePA
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert Anforderungen an Daten, die über Schnittstellen zwischen Produkttypen der Fachanwendung ePA ausgetauscht werden. Diese umfassen zum einen die Festlegung der Austauschformate von kryptografisch gesicherten Dokumenten und Schlüsseln. Zum anderen erfolgt in diesem Dokument die Festlegung des Wertebereichs der Metadaten medizinischer Dokumente, die in der ePA-Komponente Dokumentenverwaltung gespeichert werden.

1.2 Zielgruppe

Dieses Dokument richtet sich an Implementierer und Nutzer von Schnittstellen der Fachanwendung ePA. Dies sind insbesondere Hersteller und Anbieter des Produkttyps ePA-Aktensystem und Hersteller von Primärsystemen, sowie Hersteller von Konnektoren mit ePA-Fachmodul, von ePA-Frontends des Versicherten und von ePA-Fachmodulen KTR-Consumer.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

Spezifiziert wird in dem Dokument das Datenmodell von ePA-Produkttypen bereitgestellten (angebotenen) und genutzten Schnittstellen.

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps <Produkttyp> verzeichnet.

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und der Textmarke [<=] angeführten Inhalte.

2 Daten- und Informationsmodelle

2.1 Nutzung von IHE IT Infrastructure-Profilen für Speicherung und Abruf von Dokumenten

Zur Umsetzung der ePA-Fachanwendung ePA kommt das Registry-Repository-Designmuster zur Anwendung. Eine Document Registry verwaltet Metadaten, welche für die Suche und Navigation von Dokumenten notwendig sind. Die Dokumente werden in einem Document Repository gespeichert. Die Schnittstellen und Verarbeitungslogiken der Produkttypen der Fachanwendung ePA basieren z. T. auf den Spezifikationen von Integrating the Healthcare Enterprise (IHE), insbesondere dem Konzept Cross-Enterprise Document Sharing (XDS) zum Speichern und Abrufen von (medizinischen) Dokumenten, welches Teil des IHE ITI Technical Frameworks (IHE ITI TF) ist. IHE ist eine internationale Organisation, welche bestehende Industriestandards für die Umsetzung spezifischer Anwendungsszenarien im digitalisierten Gesundheitswesen profiliert. Es werden aus Sicht der dezentralen TI soweit wie möglich Cross-Community Access-Profile angewendet.

Der Profilierung von IHE ITI-Transaktionen als Umsetzungsvorgabe für die ePA-Produkttypen liegt die folgende Herangehensweise zugrunde:

1. Auswahl relevanter IHE ITI-Integrationsprofile
2. Logische Gruppierung zwischen den IHE ITI-Integrationsprofilen
3. Übergreifende Einschränkung von IHE ITI-Transaktionen
4. Festlegung spezieller Umsetzungsvorgaben bzgl. einzelner Transaktionen.

2.1.1 Implementierungsstrategie

Die übergreifende Dokumentenverwaltung der ePA-Fachanwendung basiert auf der IHE ITI-Implementierungsstrategie, wie sie in der nachstehenden Abbildung skizziert ist: Das Primärsystem aus einer Leistungserbringerinstitution implementiert die IHE ITI-Akteure Document Consumer sowie Document Source, welche Dokumente aus einer/einem vorhandenen Document Registry/Document Repository des Aktenanbieters abrufen sowie neue Dokumente darin registrieren/einstellen. Das ePA- Frontend des Versicherten implementiert ebenso diese Akteure. Kostenträger stellen über das ePA-Fachmodul KTR-Consumer ebenfalls neue Dokumente ein, sodass auch hier ein IHE ITI-Akteur Document Source implementiert wird.

Abbildung 1: Implementierungsstrategie mit zentraler Registry und Repository

2.1.2 Relevante IHE ITI-Integrationsprofile

Die ePA-Fachanwendung nutzt die folgenden Integrationsprofile des IHE ITI TF:

• Advanced Patient Privacy Consents (APPC) Profile
• Cross-Community Access (XCA) Profile
• Cross-Community Document Reliable Interchange (XCDR) Profile
• Cross-Enterprise Document Media Interchange (XDM) Profile
• Cross-Enterprise Document Reliable Interchange (XDR) Profile
• Cross-Enterprise Document Sharing (XDS.b) Profile
• Cross-Enterprise User Assertion (XUA) Profile
• Remove Metadata and Documents (RMD) Profile
• Restricted Metadata Update (RMU) Profile

2.1.3 Überblick über IHE ITI-Akteure und assoziierte Transaktionen

In der nachstehenden Abbildung wird gezeigt, welche IHE ITI-Akteure insgesamt in der ePA-Fachanwendung wie gruppiert und welche zugehörigen Transaktionen angewendet werden. Akteure unterschiedlicher Integrationsprofile sind in der ePA-Dokumentenverwaltung über zusammengefasste Außenschnittstellen nutzbar, d.h. sie agieren nach außen hin nicht als eigenständige Dienste, sondern sind über feste Pfade und ein FQDN adressiert (siehe [gemSpec_Aktensystem#A_17969-*]).

Hinweis: Gestrichelt dargestellte IHE ITI-Akteure und Transaktionen sind als produkttyp- bzw. komponentenintern anzusehen und müssen lediglich die jeweilige Semantik des Akteurs umsetzen.

Abbildung 2: Überblick über IHE ITI-Akteure und assoziierte Transaktionen

Gemäß der Nutzung von Cross-Community-Profilen, ist die IHE ITI-basierte Nachrichtenübermittlung in der nachstehenden Abbildung durch folgende Transaktionen gekennzeichnet, um ein Dokument durch den Mitarbeiter einer Leistungserbringerinstitution in die elektronische Patientenakte eines Versicherten zu speichern. Der Ablauf zum Einstellen eines Dokuments durch den Versicherten in die elektronische Patientenakte bzw. der Abruf eines Dokuments aus einer Leistungserbringerinstitution erfolgt analog in umgekehrter Ablauflogik ohne Verwendung von Cross-Community-Profilen und ist – wie auch der Zugang eines Kostenträgers – nicht in der nachstehenden Abbildung dargestellt.

Hinweis: Schraffiert dargestellte IHE ITI-Akteure und kursiv dargestellte Transaktionen sind als intern anzusehen und aus Sicht der ePA-Fachanwendung nicht normativ.

Abbildung 3: XCDR-föderierte Communities mit XCA-Prozessablaufdiagramm zum Registrieren und Abrufen von Dokumenten

Ein Primärsystem in der Consumer Zone erzeugt durch den XDR-Akteur "Document Source" ein Dokument, welches in die elektronische Patientenakte eines Versicherten gespeichert werden soll. Zum Speichern und Abrufen, kommen anschließend die folgenden IHE ITI-Transaktionen zum Tragen:

1. Provide & Register Document Set-b [ITI-41]: Das Primärsystem als XDR-Akteur "Document Source" sendet eine Nachricht zum Speichern ein oder mehrerer Dokumente an das ePA-Fachmodul als XDR-Akteur "Document Recipient" bzw. den gruppierten XCDR-Akteur "Initiating Gateway".
2. Cross-Gateway Document Provide [ITI-80]: Durch die Präsenz der Home Community ID in der vorliegenden Nachricht, erfolgt eine Weiterleitung an die ePA-Dokumentenverwaltung als XCDR-Akteur "Responding Gateway" des ePA-Aktensystems.
3. Provide & Register [ITI-41]: Es erfolgt das akteninterne Registrieren und Speichern der Dokumente. Diese Transaktion wird nicht spezifiziert.
4. Registry Stored Query [ITI-18]: Das ePA-Frontend des Versicherten als XDS-Akteur "Document Consumer" führt eine Suchanfrage auf Metadaten zu Dokumenten durch.
5. Retrieve Document Set [ITI-43]: Anhand der Document Unique IDs aus den Metadaten ruft das ePA-Frontend des Versicherten als XDS-Akteur "Document Consumer" ein oder mehrere Dokumente ab.

2.1.4 Nutzungsvorgaben für IHE ITI XDS-Metadaten

Für die ePA-Fachanwendung werden Vorgaben bezüglich zu verwendender IHE XDS-Metadatenattribute auf Ebene von Submission Set, Document Entry sowie Folder vorgenommen. Diese Nutzungsvorgaben referenzieren größtenteils Value Sets der IHE Deutschland Arbeitsgruppe "XDS Value Sets" [IHE-ITI-VS] und sind für die ePA-Fachanwendung verbindlich. Diese XDS-Value Sets sind teilweise von IHE-Deutschland als "offen" gekennzeichnet, um Erweiterungen flexibel einbringen zu können. Für die ePA-Fachanwendung gelten jedoch definierte Vorgaben, wie neue Codes und Value Sets sicher über eine Konfigurationsschnittstelle eingebracht werden können. Daher sind die in dieser Spezifikation beschriebenen Nutzungsvorgaben für Value Sets als fest anzusehen bzw. die Offenheit der XDS Value Sets wird nicht unterstützt. 

2.1.4.1 Allgemeine Metadatenvorgaben

Die Spalten der unten dargestellten, tabellarischen Übersichten für die Metadaten von Dokumenten und Policy Documents (IHE XDS.b Document Entry) und Übertragungspaketen (IHE XDS.b Submission Set) haben die folgenden Bedeutungen:

• Die Spalte "Metadatenattribut XDS.b" listet alle aus dem IHE ITI TF vorgesehenen Metadaten für Document Entry- und Submission Set-Elemente auf.
• Die Spalten "Mult. PS" (Multiplizität Primärsystem),"Mult. KTR" (Multiplizität "Kostenträger"), "Mult. DV" (Multiplizität "ePA-Dokumentenverwaltung"), "Mult. FV" (Multiplizität "ePA-Frontend des Versicherten") kennzeichnen die Multiplizität des Metadatenattributs beim Erzeugen oder Verarbeiten durch das jeweilige System.
• Die Spalte "Kurzbeschreibung" beschreibt kurz die Bedeutung des Metadatenattributs.
• Die Spalte "Nutzungsvorgabe" macht Bedingungen für die Verwendung eines Metadatenattributs (z.B. erlaubte Wertebereiche und Formatangaben), welche über die im IHE ITI TF definierten Vorgaben hinausgehen.
• Die Spalte "FV Edit" beschreibt, ob ein bestimmtes Metadatenattribut beim Einstellen eines Dokuments über das ePA-FdV durch den Versicherten veränderbar gestaltet werden muss. Es sollten dabei immer nur die für den aktuellen Workflow relevanten Metadatenattribute angezeigt werden, um die Komplexität für den Versicherten gering zu halten. Veränderbar gestaltete Metadatenattribute müssen mit sinnvollen Default-Werten vor belegt werden.

Die in [gemSpec_Voc_ePA] vorgegebenen Value Sets beinhalten in der Regel eine hohe Anzahl von Werten, die nicht für jeden Sektor oder jede Berufsgruppe gleichermaßen relevant sind. Um dem Anwender die Nutzung zu erleichtern, wird für die Auswahl der Werte die Anzeige einer gefilterten Ansicht der Tabellen empfohlen. Eine beispielhafte Auswahl von Werten in den Value Set-Tabellen der für die Benutzer relevanten Metadaten ist als Vorschlag in Anhang C dargestellt. Es steht den Herstellern der Frontends frei, die Tabellen nach eigenen Erfahrungswerten zu ergänzen oder einzukürzen.

2.1.4.2 Metadatenvorgaben für Policy-Dokumente

2.1.4.3 Weitere Metadatenvorgaben

Hinweis zur Migration von ePA 1 zu ePA 2: Die Migration der Dokumente kann durchgeführt werden, auch wenn die professionOID in ePA 1-Dokumenten nicht abgelegt wurde.  

• Patienten- und KTR-Docs sind 1:1 in die entsprechenden Ordner überführbar. 
• Bei Leistungserbringer-Dokumenten kann das AS die Migration durchführen, ohne dass es die OID kennt. An ePA 1 nehmen ausschließlich Berufsgruppen teil ( aufgrund nicht verfügbarer nichtärztlicher SMC-Bs), die identische Lese- und Löschrechte haben: oid_praxis_arzt, oid_krankenhaus und oid_zahnarztpraxis. Die Einordnung von ePA 1- Bestandsdokumenten in die ePA 2 - Folder erfolgt aufgrund der weiteren Vorgaben.

Neue strukturierte Datenformate können eingeführt werden, wenn sie den Vorgaben der ePA nicht widersprechen, und unter die oben genannte Dokumentenkategorien fallen und somit Gegenstand einer kategorienbasierten Zugriffsberechtigung werden können.

Grundlage für die Berechnung der Dokumentengröße ist das Dokument ohne Verschlüsselung durch den Dokumentenschlüssel und ohne Transportcodierung.

Beispiel für die Ermittlung der Dokumentengröße:

1. Ermittle verschlüsseltes und base64 kodiertes Dokument, welches dem Inhalt von <xenc:CipherValue> entspricht.
2. Base64 Dekodierung des Ergebnisses aus 1.
3. Von der Länge des Ergebnisses aus 2. ziehe die Länge 12 Bytes und des Authentication Tags von 16 Bytes gemäß A_14977-* ab.

Falls möglich soll der Titel des Dokumentes eine fachliche Beschreibung des Dokumentes enthalten. Ein Leerstring DocumentEntry.title="" ist nicht erlaubt.

2.1.4.3.1 authorPerson (DocumentEntry.author und SubmissionSet.author)

Der Autor des Dokuments wird im Metadatenattribut DocumentEntry.author festgehalten. Er hat das Dokument inhaltlich erstellt. Zudem muss der Einsteller des Dokuments bzw. des dazugehörigen Übertragungspakets (Submission Set) in SubmissionSet.author dokumentiert werden. In beiden Fällen ist die Angabe mehrerer Autoren in separaten Metadatenattributen möglich. Dieser und der nachfolgende Abschnitt beschreiben Einschränkungen für die author-Unterfelder authorPerson und authorInstitution.

2.1.4.3.2 authorInstitution (DocumentEntry.author und SubmissionSet.author)

2.1.4.3.3 DocumentEntry.patientId und SubmissionSet.patientId

2.1.4.3.4 DocumentEntry.homeCommunityId und SubmissionSet.homeCommunityId

Gemäß des IHE ITI XCA-Profils [IHE-ITI-TF1] und des IHE ITI XCDR-Profils [IHE-ITI-XCDR] fordern bestimmte Anfragen an das ePA-Aktensystem das Metadatenattribut „homeCommunityId“. Dieses wird im IHE-Kontext verwendet, um verschiedene miteinander über IHE ITI-Gateways vernetzte IHE ITI XDS-Aktensysteme voneinander zu unterscheiden und zu adressieren.

Innerhalb der ePA-Fachanwendung können verschiedene Anbieter ePA-Aktensysteme bereitstellen, die jeweils eigene Document Registry- und Document Repository-Adressen anbieten. Um dieser Tatsache Rechnung zu tragen, werden Anbieter eines ePA-Aktensystems unter einer eindeutigen Home Community ID adressiert.

Es gibt einen wichtigen Unterschied zu geläufigen Home Community-Umsetzungen gegenüber der ePA-Fachanwendung: In der Regel besitzt ein einzelner Patient (d.h. Versicherter) in verschiedenen Home Communities unterschiedliche Kennungen, um ihn eindeutig zu identifizieren. In der ePA-Fachanwendung hingegen unterhält jeder Versicherte lediglich bei einem einzigen Anbieter sein Aktenkonto, das alle Dokumente des Versicherten verwaltet. Das heißt, jeder Patient (d.h. Versicherter) ist somit auch nur in einer einzigen Home Community aktiv. Deshalb ist eine Abbildung von lokalen Kennungen zu Patienten zwischen verschiedenen Home Communities nicht notwendig.

In der ePA-Fachanwendung wird das Aktenkonto des Versicherten über den sogenannten Record Identifier identifiziert. Dieser strukturierte Datentyp enthält zum einen die Versicherten-ID aus dem unveränderbaren Teil der KVNR sowie die Home Community ID des Anbieters (siehe Details zum Datentyp in Abschnitt 2.2). Primärsysteme erhalten die Home Community ID eines Versicherten per Operation PHRManagementService::GetHomeCommunityID. Das ePA-Frontend des Versicherten kann die Home Community ID über eine Namensdienstabfrage ermitteln.

2.1.4.3.5 Gesonderte Kennzeichnung eines Dokuments als Versicherteninformation

Für die Kenntlichmachung von Dokumenten von Leistungserbringern, die vorrangig der Information von Versicherten dienen, ermöglicht die ePA-Fachanwendung dem Leistungserbringer, Dokumente dieser Art mit der Kennzeichnung "Versicherteninformation" zu versehen. Dies erfolgt durch das Belegen von Metadaten wie folgt:

2.1.4.3.6 Gesonderte Kennzeichnung eines Dokumentes als Kostenträgerinformation

Kostenträger stellen ihren Versicherten bei Bedarf Dokumente über die in Anspruch genommenen Leistungen der Versicherten (Quittungen) zur Verfügung.

Für die Kenntlichmachung dieser Dokumente, die vom Kostenträger in die ePA exportiert werden, ermöglicht die ePA-Fachanwendung dem Kostenträger, Dokumente dieser Art entsprechend zu kennzeichnen.

2.1.4.4 Strukturierte Dokumente

Die elektronische Patientenakte unterstützt unterschiedliche sogenannte "strukturierte Dokumente", deren Aufbau über Implementation Guides genau vorgegeben ist. Der Umfang der unterstützten strukturierten Dokumente wird durch den Umfang der veröffentlichten Implementation Guides festgelegt (siehe Abschnitt 2.1.4.4.2). Für alle strukturierten Dokumente gelten spezifische Metadatenvorgaben, um sie eindeutig zu identifizieren und gezielt verarbeiten zu können.

2.1.4.4.1 Sammlungstypen

Je nach Art ihrer Zusammensetzung und ihrer Handhabung existieren unterschiedliche Typen strukturierter Dokumente, sogenannte medizinische Informationsobjekte. Ein medizinisches Informationsobjekt (MIO) ist eine Sammlung von Informationen zu medizinischen, strukturellen oder administrativen Sachverhalten, die in sich geschlossen oder entsprechend verschachtelt vorliegt. Zudem ist ein MIO eine klar definierte Vorgabe, wie diese Informationssammlung in der elektronischen Patientenakte gespeichert wird, damit semantische und syntaktische Interoperabilität gewährleistet werden. Die Festlegung dieser Vorgaben ist gemäß SGB V Aufgabe der KBV. Beispiele für medizinische Informationsobjekte sind der Impfpass, das Kinderuntersuchungsheft, der Mutterpass oder das zahnärztliche Bonusheft. MIOs werden über Sammlungen und Sammlungstypen umgesetzt.

Einige strukturierte Dokumente sind für sich genommen vollständig und schlüssig wie z.B. ein Elektronischer Arztbrief. Sie sind ohne Zuhilfenahme weiterer Dokumente in der ePA für einen Benutzer sinnvoll zu verwenden. Andere Typen strukturierter Dokumente müssen hingegen fast immer in Kombination betrachtet werden, z.B. Impfpassdokumente. Bei letzteren spiegelt jedes Impfpassdokument ein oder mehrere Impfungen wider. Ein Impfpass, wie er in der analogen Welt geläufig und als logisches Konstrukt sinnvoll ist, besteht immer aus der gemeinsamen Betrachtung aller Impfpassdokumente und somit aller vorhandenen Impfeinträge. Die Kombination ein oder mehrerer strukturierter Dokumente ergeben eine Sammlung.

Eine Sammlungsinstanz (z.B. der Mutterpass der ersten Schwangerschaft der Patientin Martha Mustermann) ist eine konkrete Ausprägung der Information, die zwischen den beteiligten Akteuren ausgetauscht wird. Nicht jede Sammlung besteht zwangsläufig aus Dokumenten desselben Formats: Ein Kinderuntersuchungsheft beispielsweise besteht aus Dokumenten mit drei verschiedenen strukturierten Dokumenttypen. Zentral für alle Sammlungstypen ist immer mindestens ein strukturiertes Dokument mit einem festgelegten Dokumentenformat. Für eine technische Umsetzung sind drei Sammlungstypen ("mixed", "uniform", "atomic") zu unterscheiden, die technisch unterschiedlich umgesetzt werden und zum Teil unterschiedliche Operationen erlauben. 

Der Sammlungstyp "mixed" fasst semantisch zusammengehörige, strukturierte Dokumente unterschiedlicher Struktur mittels Ordner zu einer Sammlung zusammen. Die Sammlungstypen "uniform" und "atomic" werden ebenfalls intern über Ordner abgebildet. Dies stellt sicher, dass zukünftige Versionen dieser strukturierten Dokumente/Pässe verlässlich verarbeitet werden können. Sämtliche Ordner gelten als "statische Ordner", bis auf diejenigen, die durch Clients angelegt werden ("dynamische Ordner"), weil es aus Gründen, die nur der Client kennt (Anzahl der Kinder/Schwangerschaften), mehrere Ordner dieses Typs geben kann ("nicht-statische Ordner", vgl. A_21610-*). Die Version der Struktur eines Dokuments ist am Format Code erkennbar.

2.1.4.4.2 Konfigurierbarkeit

Das Entfernen der Unterstützung von strukturierten Dokumenten oder Sammlungen bedeutet, dass diese zu einem früheren Zeitpunkt in das Aktensystem geschrieben werden konnten, aber durch Erreichen von "clientReadOnlyFromDate" nicht mehr geschrieben werden dürfen. Das Schreiben umfasst das Aktualisieren oder neu Anlegen. Das Lesen ist weiterhin erlaubt.

Bei Einführung neuer strukturierter Dokumente werden die beschriebenen Konfigurationsmöglichkeiten so verwendet, dass eine Erweiterung der Spezifikation und daraus resultierend eine Änderung des ePA-Aktensystems mit erneuter Zulassung nicht erforderlich sind. 

2.2 Record Identifier

Der Record Identifier identifiziert das Aktenkonto eines Versicherten eindeutig. Er wird als strukturierter Datentyp repräsentiert und ist folgendermaßen aufgebaut (vgl. [PHR_Common.xsd] im beiliegenden Spezifikationspaket).

 <xs:element name="RecordIdentifier" type="tns:RecordIdentifierType"/>
  <xs:complexType name="RecordIdentifierType">
  <xs:sequence>
    <xs:element name="InsurantId" type="tns:InsurantIdType" minOccurs="1" maxOccurs="1"/>
    <xs:element name="HomeCommunityId" type="tns:HomeCommunityIdType" minOccurs="0"
    maxOccurs="1"/>
  </xs:sequence>
</xs:complexType>

Das Element "InsurantId" trägt den unveränderlichen Teil der KVNR unter dem Attribut "extension". Um diesen Teil der KVNR als Versicherten-ID zu kennzeichnen, wird im weiteren Attribut "root" die OID "1.2.276.0.76.4.8" angegeben.

Das Element "HomeCommunityId" trägt die Kennung des Aktenanbieters (vgl. Abschnitt  ). In IHE-basierten Nachrichten ist die Versicherten-ID in die Patient-ID transformierbar (DocumentEntry.patientId und SubmissionSet.patientId). Die Home Community ID wird ebenfalls in den Metadaten eines Dokuments (DocumentEntry.homeCommunityId und SubmissionSet.homeCommunityId) hinterlegt.

2.3 Protokollierung

Produkttypen und Komponenten der ePA-Fachanwendung müssen Zugriffe auf Daten eines Versicherten im Aktenkonto des Versicherten protokollieren, damit dieser (oder dessen Vertreter) nachvollziehen kann, was wann mit seinen Daten geschehen ist.

Nicht vorbelegte Protokollattribute werden ggf. durch Anforderungen zu einzelnen Operationen gefüllt.

2.4 Verschlüsselung von Dokumenten

Dokumente (ausgenommen Policy Documents), die in der Dokumentenverwaltung gespeichert werden, müssen vor dem Hochladen verschlüsselt werden. Dabei wird wie folgt vorgegangen (siehe auch [gemSpec_Autorisierung]):

• Das Dokument wird mit einem für das Dokument spezifischen symmetrischen Dokumentenschlüssel (DocumentKey) verschlüsselt.
• Der DocumentKey wird mit einem für die Versichertenakte spezifischen symmetrischen Aktenschlüssel (RecordKey) verschlüsselt.
• Der RecordKey wird  mittels Schlüsselableitung gemäß [gemSpec_SGD_ePA] verschlüsselt.

Das verschlüsselte Dokument und der verschlüsselter DocumentKey werden als Paket anstelle des unverschlüsselten Dokuments hochgeladen. Zur Entschlüsselung werden die Schritte in umgekehrter Reihenfolge durchgeführt.

2.4.1 Verschlüsselung

2.4.2 Entschlüsselung

Dokumente, die aus der Dokumentenverwaltung heruntergeladen werden, müssen entschlüsselt werden. Dabei wird die Verschlüsselung aus Abschnitt  rückgängig gemacht:

• Aus der XML-Struktur wird mithilfe des Aktenschlüssels (RecordKey) der symmetrische Dokumentenschlüssel (DocumentKey) entschlüsselt.
• Aus der XML-Struktur wird mithilfe des DocumentKey das Dokument entschlüsselt.

Der im ersten Schritt notwendige RecordKey liegt nicht in der XML-Struktur vor, sondern muss anderweitig beschafft werden.

Nach Entschlüsselung gemäß der obigen Anforderung liegt das Dokument im Klartext vor.

2.5 Überblick über verwendete Identifikatoren

In der ePA-Fachanwendung kommen verschiedene Identifikatoren zum Einsatz. So müssen insbesondere Versicherte, ihre Akte, Anbieter von ePA-Aktensystemen sowie deren IHE ITI XDS Document Repositories eindeutig identifiziert werden. Dieser Abschnitt stellt die verwendeten Identifikatoren - Home Community ID, Repository Unique ID, Record Identifier und Patient ID - und ihre Zusammenhänge kurz dar.

Bei jedem Zugriff auf die Akte eines Versicherten müssen das ePA-Fachmodul, das ePA-Fachmodul KTR-Consumer sowie das ePA-Frontend des Versicherten zunächst den Anbieter des ePA-Aktensystems für den jeweiligen Versicherten ausfindig machen. Der Anbieter wird in der ePA-Fachanwendung über die sogenannte Home Community ID identifiziert (Details siehe Abschnitt ).

Jeder Versicherte, der über ein Aktenkonto verfügt, wird bei seinem Anbieter unter dem unveränderbaren Teil der KVNR geführt. Der strukturierte Datentyp Record Identifier vereint die KVNR und die Home Community ID (siehe Details in Abschnitt ).

Beim Suchen von Dokumenten erhalten ePA-Fachmodul und ePA-Frontend des Versicherten pro Dokument die Kennung des Document Repositorys zurück, von dem das jeweilige Dokument heruntergeladen werden kann. In der ePA-Fachanwendung verfügt jeder Anbieter über genau ein Document Repository, das die Dokumente der Versicherten verwaltet. Dies weicht von der Flexibilität ab, da über das Integrationsprofil XDS.b potentiell mehrere Document Repositories pro Anbieter eines Aktensystems möglich sind. Auf der anderen Seite vereinfacht es bspw. die Lokalisierung von Document Repositories. Da das Integrationsprofil XDS.b allerdings vorschreibt, jedem Document Repository eine Kennung als OID zuzuweisen, wird die Home Community ID als Document Repository Unique ID nachgenutzt. Das heißt, Home Community ID und Document Repository Unique ID desselben Anbieters eines ePA-Aktensystems sind in der ePA-Fachanwendung immer identisch. Die folgende Abbildung stellt die beschriebenen Zusammenhänge noch einmal graphisch dar.

Abbildung 4: Überblick über Identifikatoren in der ePA-Fachanwendung

2.6 Anwendungen der Aktensystemplattform

Der Produkttyp ePA-Aktensystem kann mehrere Anwendungen unterstützen (im Sinne einer Aktensystemplattform). Zur Unterscheidung dieser Anwendungen in Operationsaufrufen der Schnittstellen oder bei der Identifikation von Ergebnissen wird das Datum <ApplicationName> verwendet. Jede Anwendung verwendet für dieses Datum eine eigene, eindeutige Kennzeichnung.

2.7 UserAgent

3 Anhang A – Verzeichnisse

3.1 Abkürzungen

3.2 Glossar

Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.

3.3 Abbildungsverzeichnis

3.4 Tabellenverzeichnis

3.5 Referenzierte Dokumente

3.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummer ist in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

3.5.2 Weitere Dokumente

4 Anhang B – Container-Struktur für einen Arztbrief

Die folgende XML-Struktur für einen Container mit Arztbrief nach § 383 SGB V wird festgelegt (vgl. [PHR_Common.xsd]):

Tabelle 10: XML-Struktur für Arztbrief nach § 291f SGB V

5 Anhang C – Vorschläge zur verkürzten Ansicht der Auswahl von Werten aus Value Sets

Die in [gemSpec_Voc_ePA] vorgegebenen Value Sets beinhalten in der Regel eine hohe Anzahl von Werten, die nicht für jeden Sektor oder jede Berufsgruppe gleichermaßen relevant sind. Um dem Anwender die Nutzung zu erleichtern, wird für die Auswahl der Werte die Anzeige einer gefilterten Ansicht der Tabellen empfohlen. Ein Verweis auf die nachfolgenden Tabellen ist in der Spezifikation ePA-Frontend des Versicherten [gemSpec_ePA_FdV] und im Implementierungsleitfaden Primärsysteme ePA [gemILF_PS_ePA] enthalten. 

Hinweis: Neue Nutzergruppen, die im Folgenden noch nicht berücksichtigt sind, sollten sich nach Vorbild der vorliegenden Vorschläge eine verkürzte Ansicht bilden. Neue Nutzergruppen werden schrittweise auch explizit Berücksichtigung finden.

Tabelle 11: Value Set authorRole

Tabelle 12: Value Set authorSpecialty