Elektronische Gesundheitskarte und Telematikinfrastruktur
Datenmodell ePA
Version |
1. |
Revision |
548770 |
Stand |
|
Status |
|
Klassifizierung |
öffentlich |
Referenzierung |
gemSpec_DM_ePA |
Dokumentinformationen
Änderungen zur Vorversion
Es handelt sich um die Erstversion des Dokuments.Das Dokument wurde angepasst gemäß Änderungsliste P18.1
Dokumentenhistorie
Version |
Stand |
Kap./ Seite |
Grund der Änderung, besondere Hinweise |
Bearbeitung |
|||||
|
|
|
|
|
|||||
1.0.0 |
18.12.18 |
|
freigegeben |
gematik |
|||||
|
|
|
Einarbeitung Änderungsliste P18.1 |
|
|||||
1.1.0 |
15.05.19 |
|
freigegeben |
gematik |
|||||
Inhaltsverzeichnis
DokumentinformationenDokumentinformationen
InhaltsverzeichnisInhaltsverzeichnis
2 Daten- und Informationsmodelle
2.1 Nutzung von IHE IT Infrastructure-Profilen für Speicherung und Abruf von Dokumenten
2.1.1 Implementierungsstrategie
2.1.2 Relevante IHE ITI-Integrationsprofile
2.1.3 Überblick über IHE ITI-Akteure und assoziierte Transaktionen
2.1.4 Nutzungsvorgaben für IHE ITI XDS-Metadaten
2.1.4.1 Code-Systeme und Value Sets
2.1.4.1.2 ePA-spezifische Werte für DocumentEntry.authorSpecialty und SubmissionSet.authorSpecialty
2.1.4.1.3 ePA-spezifische Werte für DocumentEntry.practiceSettingCode
2.1.4.2 Überblick über Metadatenattribute
2.1.4.3 authorPerson (DocumentEntry.author und SubmissionSet.author)
2.1.4.4 authorInstitution (DocumentEntry.author und SubmissionSet.author)
2.1.4.5 DocumentEntry.patientId und SubmissionSet.patientId
2.1.4.6 DocumentEntry.homeCommunityId und SubmissionSet.homeCommunityId
2.2 RecordIdentifier2.1.4.8 Gesonderte Kennzeichnung eines Dokuments als Versicherteninformation
2.3 Protokollierung2.2 Record Identifier
2.4 Verschlüsselung von Dokumenten2.3 Protokollierung
2.4.1 Verschlüsselung2.4 Verschlüsselung von Dokumenten
2.4.2 Entschlüsselung2.4.1 Verschlüsselung
2.5 Verschlüsselung von Akten- und Kontextschlüssel2.4.2 Entschlüsselung
2.5.1 Verschlüsselung2.5 Überblick über verwendete Identifikatoren
2.5.2 Entschlüsselung3 Anhang A – Verzeichnisse
2.6 Überblick über verwendete Identifikatoren3.1 Abkürzungen
2.7 Aktenkonfiguration zur Kontoaktivierung3.2 Glossar
3 Anhang A – Verzeichnisse3.3 Abbildungsverzeichnis
3.1 Abkürzungen3.4 Tabellenverzeichnis
3.2 Glossar3.5 Referenzierte Dokumente
3.3 Abbildungsverzeichnis3.5.1 Dokumente der gematik
3.4 Tabellenverzeichnis3.5.2 Weitere Dokumente
3.5 Referenzierte Dokumente4 Anhang B – Allgemeine Erläuterungen
3.5.1 Dokumente der gematik4.1 Vorschläge zur verkürzten Ansicht der Auswahl von Werten aus Value Sets
3.5.2 Weitere Dokumente4.2 Container-Struktur für einen Arztbrief
4 Anhang B – Allgemeine Erläuterungen
4.1 Vorschläge zur verkürzten Ansicht der Auswahl von Werten aus Value Sets
4.2 Container-Struktur für einen Arztbrief
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, undvon 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:
- Auswahl relevanter IHE ITI-Integrationsprofile
- Logische Gruppierung zwischen den IHE ITI-Integrationsprofilen
- Übergreifende Einschränkung von IHE ITI-Transaktionen
- 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
Hinweis: Das von vielen IHE ITI-Integrationsprofilen abhängige Audit Trail and Node Authentication (ATNA) Profile wird explizit nicht für die ePA-Fachanwendung eingesetzt, da separate Anforderungen an die ePA-Produkttypen hinsichtlich der Protokollierung und den Aufbau sicherer Verbindungen gestellt werden.
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 produktprodukttyp- 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:
- 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".
- 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.
- Provide & Register [ITI-41]: Es erfolgt das akteninterne Registrieren und Speichern der Dokumente. Diese Transaktion wird nicht spezifiziert.
- Registry Stored Query [ITI-18]: Das ePA-Frontend des Versicherten als XDS-Akteur "Document Consumer" führt eine Suchanfrage auf Metadaten zu Dokumenten durch.
- 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
Metadaten für die in der ePA-Fachanwendung verwendeten IHE ITI XDS.b-Objekte SubmissionSet und DocumentEntry werden u.a. mittels Vokabularen bzw. Codes repräsentiert (z.B. die Kodierung eines Dokumententyps). Jeder Code entstammt einem Code-System und ist darin eindeutig. Ein Code kann durch einen lokalisierten Anzeigenamen ergänzt werden. Weiterhin können Referenzen auf Codes aus verschiedenen Code-Systemen in sogenannten Value Sets domänenspezifisch organisiert werden.
2.1.4.1 Code-Systeme und Value Sets
Für die ePA-Fachanwendung wird soweit möglich auf von IHE Deutschland e.V. empfohlene Value Sets zurückgegriffen. Einige davon (z. B. diejenigen für XDS formatCode und authorRole) werden von IHE Deutschland als erweiterbar gekennzeichnet und auch durch die ePA-Fachanwendung um eigene Codes und wo notwendig ergänzt.
Hinweis: Diese in dieser Spezifikation dargestellten Codes als Erweiterung der von IHE Deutschland vorgeschlagenen Value Sets sind noch nicht abschließend mit IHE Deutschlang abgestimmt. Es ist zu erwarten, dass sich diese Code-Werte im kommenden ePA-Release ändern werden.
2.1.4.1.1 ePA-spezifische Werte für DocumentEntry.formatCode
Das folgende Value Set nebst Codes wird abweichend von Definitionen durch IHE Deutschland für den XDS DocumentEntry.formatCode definiert, um strukturierte Dokumente gesondert zu kennzeichnen:
Tabelle 1: Tab_DM_100: gematik-spezifische Erweiterung für Werte im Value Set "formatCode"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
Hinweis: "ig" steht analog zu [IHE-ITI-VS] für die feste Abkürzung zu Implementierungsleitfäden (eng. implementation guide).
Das von IHE Deutschland definierte Value Set für XDS DocumentEntry.formatCodes [IHE-ITI-VS] wird um die o.g. Codes erweitert:
A_15602 - Zusätzliche Codes für XDS Document Entry Format Codes
Das Primärsystem, ePA-Fachmodul, die ePA-Dokumentenverwaltung und das ePA-Frontend des Versicherten, welche IHE ITI XDS-Metadaten verarbeiten, MÜSSEN neben dem Value Set für XDS DocumentEntry.formatCodes nach [IHE-ITI-VS] die Codes aus Tabelle Tab_DM_100 verarbeiten können. [<=]2.1.4.1.1 Metadatenkombinationen für strukturierte Dokumente
Die nachstehende Tabelle listet erlaubte Kombinationen von DocumentEntry.classCode, DocumenEntry.typeCode, DocumentEnry.formatCode und DocumentEntry.mimeType für strukturierte Dokumente:
A_14761 - Nutzungsvorgaben für die Verwendung von IHE ITI XDS-Metadaten bei strukturierten Dokumenten
Das Primärsystem, ePA-Fachmodul, ePA-Dokumentenverwaltung und das ePA-Frontend des Versicherten, welche IHE ITI XDS-Metadaten verarbeiten, MÜSSEN die folgenden Nutzungsvorgaben für strukturiertedie folgenden strukturierten Dokumente berücksichtigen.
Tabelle 21: Nutzungsvorgaben für XDS-Metadaten bei strukturierten Dokumenten
Strukturiertes Dokument |
DocumentEntry |
|||
classCode |
typeCode |
formatCode |
mimeType |
|
Arztbrief gemäß der XML-Struktur in Anhang B 4.2. |
Der Wert MUSS dem Code "BRI" (Brief) des in [IHE-ITI-VS] definierten Value Sets für DocumentEntry.classCode entsprechen. |
Der Wert MUSS dem Code "BERI" (Arztberichte) des in [IHE-ITI-VS] definierten Value Sets für DocumentEntry.typeCode entsprechen. |
Der Wert MUSS dem Code "urn:gematik:ig:Arztbrief:r3.1"(Arztbrief § 291f SGB V) des |
Der Wert MUSS "application/xml" entsprechen. |
Medikationsplan gemäß [gemSpec_Info_AMTS] |
Der Wert MUSS dem Code "PLA" (Planungsdokument) des in [IHE-ITI-VS] definierten Value Sets für DocumentEntry.classCode entsprechen. |
Der Wert MUSS dem Code "MEDI" (Medikamentöse Therapien) des in [IHE-ITI-VS] definierten Value Sets für DocumentEntry.typeCode entsprechen. |
Der Wert MUSS dem Code "urn:gematik:ig:Medikationsplan:r3.1" |
Der Wert MUSS "application/xml" entsprechen. |
Notfalldatensatz gemäß [gemSpec_Info_NFDM] |
Der Wert MUSS dem Code "AUS" (Medizinischer Ausweis) des in [IHE-ITI-VS] definierten Value Sets für DocumentEntry.classCode entsprechen. |
Der Wert MUSS dem Code "BESC" (Ärztliche Bescheinigungen) des in [IHE-ITI-VS] definierten Value Sets für DocumentEntry.typeCode entsprechen. |
Der Wert MUSS dem Code "urn:gematik:ig:Notfalldatensatz:r3.1" |
Der Wert MUSS "application/xml" entsprechen. |
[<=]
2.1.4.1.2 ePA-spezifische Werte für DocumentEntry.authorSpecialty und SubmissionSet.authorSpecialty
Das folgende von IHE Deutschland definierte Value Set nebst Codes für die XDS DocumentEntry.authorSpecialty und SubmissionSet.authorSpecialty wird um folgende Codes erweitert. Die Erweiterung ist unter dem Link in [IHE-ITI-VS-Live] einsehbar, aber derzeit noch nicht in [IHE-ITI-VS] aufgenommen. Dies erfolgt in der Nachfolgeversion.
Tabelle 3: Tab_DM_110: Erweiterung für Werte im Value Set "authorSpecialty"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
A_15744 - Zusätzliche Codes für XDS Author Specialty
Das Primärsystem, ePA-Fachmodul, ePA-Dokumentenverwaltung und das ePA-Frontend des Versicherten, welche IHE ITI XDS-Metadaten verarbeiten, MÜSSEN neben dem Value Set für XDS authorSpecialityAuthor Speciality (als Subattribut von DocumentEntry.author und SubmissionSet.author) nach [IHE-ITI-VS] die Codes ausder nachstehenden Tabelle Tab_DM_110 verarbeiten können.
[<=]
2.1.4.1.3 ePA-spezifische Werte für DocumentEntry.practiceSettingCode
Das folgende von IHE Deutschland definierte Value Set nebst Codes für den XDS DocumentEntry.practiceSettingCode wird um folgende Codes erweitert. Die Erweiterung ist unter dem Link in [IHE-ITI-VS-Live] einsehbar, aber derzeit noch nicht in [IHE-ITI-VS] aufgenommen. Dies erfolgt in der Nachfolgeversion, welche auch unter [IHE-ITI-VS-Live] einzusehen sind .
Tabelle 4:2 Tab_DM_111110: Erweiterung für Werte im Value Set "practiceSettingCode"authorSpecialty"
Code |
Code-System |
Anzeigename |
Beschreibung |
|||||
|
Qualifikationen nicht ärztlicher Autoren |
Pharmazieingenieur |
|
|||||
|
Qualifikationen nicht ärztlicher Autoren |
Apothekerassistent |
|
|||||
|
Qualifikationen nicht ärztlicher Autoren |
Apothekenassistent |
|
|||||
1 |
|
|
|
|
|
|
||
|
Qualifikationen zahnärztlicher Autoren |
|
|
|
|
|||
3 |
Qualifikationen zahnärztlicher Autoren |
FZA Parodontologie |
|
Fachzahnarzt für Parodontologie |
|
|||
4 |
Qualifikationen zahnärztlicher Autoren |
FZA Oralchirurgie |
Fachzahnarzt für Oralchirurgie |
|||||
5 |
Qualifikationen zahnärztlicher Autoren |
FZA Kieferorthopädie |
Fachzahnarzt für Kieferorthopädie |
|||||
6 |
Qualifikationen zahnärztlicher Autoren |
FZA öffentliches Gesundheitswesen |
Fachzahnarzt öffentliches Gesundheitswesen |
|||||
1 |
Ärztliche Berufsvarianten |
Arzt in Facharztausbildung |
Arzt, der noch keinen Facharzttitel hat, sich jedoch momentan in der Weiterbildung befindet |
|||||
2 |
Ärztliche Berufsvarianten |
Hausarzt |
Dieser Code kann additiv zu einer vorhanden Spezialisierung oder Weiterbildung eines Autors hinzugefügt werden, um auszudrücken, dass sich der Autor in einer hausärztlichen Tätigkeit befindet. |
|||||
3 |
Ärztliche Berufsvarianten |
Praktischer Arzt |
|
|||||
[<=]
2.1.4.1.3 ePA-spezifische Werte für DocumentEntry.practiceSettingCode
A_16944 - Zusätzliche Codes für XDS Practice Setting Code
Das Primärsystem, ePA-Fachmodul, ePA-Dokumentenverwaltung und das ePA-Frontend des Versicherten, welche IHE ITI XDS-Metadaten verarbeiten, MÜSSEN neben dem Value Set für XDS Practice Setting Code nach [IHE-ITI-VS] die Codes aus der nachstehenden Tabelle Tab_DM_111 als Unterkonzept des Codes MZKH (Zahnmedizin) verarbeiten können.
Code |
Code-System |
Anzeigename |
Beschreibung |
MZAH |
|
Allgemeine Zahnheilkunde |
Das Fachgebiet Allgemeine Zahnheilkunde stellt eine Weiterbildung innerhalb der Zahnmedizin im Kammergebiet Brandenburg dar. Es beinhaltet die Erkennung, Verhütung und Behandlung von Erkrankungen und Erscheinungsformen des orofacialen Systems. |
PARO |
Ärztliche Fachrichtungen |
Parodontologie |
Das Fachgebiet Parodontologie stellt eine Weiterbildung innerhalb der Zahnmedizin im Kammergebiet Westfalen-Lippe dar. Das Fachgebiet beinhaltet die Prävention, die Diagnostik, die Therapie und Nachsorge von Erkrankungen parodontaler und periimplantärer Gewebe und Strukturen. |
ZGES |
|
Öffentliches Gesundheitswesen |
Das Fachgebiet Öffentliches Gesundheitswesen stellt eine Weiterbildung innerhalb der Zahnmedizin dar. Das Gebiet beinhaltet die Bewertung des Gesundheitszustandes der Bevölkerung, Organisation und Durchführung gruppenprophylaktischer Maßnahmen, Maßnahmen der Gesundheitsförderung, der Gesundheitserziehung und der präventiven Zahngesundheitspflege bei unterschiedlichen Alters- und Bevölkerungsgruppen. |
[<=]
2.1.4.2 Überblick über Metadatenattribute
Die Spalten der unten dargestellten, tabellarischen ÜbersichtÜ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. FM" (Multiplizität "Fachmodul ePA"),"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.
A_14760 - Nutzungsvorgaben für die Verwendung von XDS-Metadaten
Das Primärsystem sowie, das ePA-Frontend des Versicherten sowie das Fachmodul ePA KTR-Consumer als XDS-Akteur "Document Source" MÜSSEN zur Registrierung von Dokumenten in der ePA-Dokumentenverwaltung die nachstehenden Nutzungsvorgaben für Metadaten berücksichtigen. Der Produkttyp ePA-Fachmodul Diese Systeme sowie die Komponente ePA-Dokumentenverwaltung MÜSSEN diese Metadaten verarbeiten können und ergänzen diese Metadaten ggf. während des Registriervorgangs. Metadaten können über die Operationen
- I_Document_Management::CrossGatewayDocumentProvide,
- I_Document_Management_Insurance::ProvideAndRegisterDocumentSet-b sowie
- I_Document_Management_Insurant::ProvideAndRegisterDocumentSet-b
registriert oder über die Operation I_Document_Management::RestrictedUpdateDocumentSet (ausschließlich DocumentEntry.confidentialityCode) geändert werden.
Die Produkttypen ePA-Fachmodul sowie ePA-Frontend des Versicherten sind von den nachstehenden Nutzungsvorgaben ausgenommen, sofern ein Policy Document (Advanced Patient Privacy Consent) gemäß [IHE-ITI-APPC] erzeugt und registriert werden soll. Hierzu ist die gesonderte Anforderung A_14961 zu beachten.
Tabelle 53: Nutzungsvorgaben für Metadatenattribute XDS.b
Metadatenattribut XDS.b |
Mult. |
|
Mult. |
Mult. |
Mult. |
Kurzbeschreibung |
Nutzungsvorgabe |
|
Metadatenelement Document Entry |
||||||||
author |
[1..*] |
|
[ |
[0..0] |
[1..*] |
Person oder System, welche(s) das Dokument erstellt hat |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.1] genügen. |
|
|
authorPerson |
[1..1] |
|
[0..0] |
[0..0] |
[1..1] |
Name des Autors |
Der Wert MUSS den Inhalts- und Formatvorgaben aus Abschnitt 2.1.4.3 genügen. |
|
authorInstitution |
[1..*] |
|
[ |
[0..0] |
[0..*] |
Institution, die dem Autor zugeordnet ist |
Der Wert MUSS den Inhalts- und Formatvorgaben aus Abschnitt 2.1.4.4 genügen. |
|
authorRole |
[1..*] |
|
[ |
[0..0] |
[1..*] |
Rolle des Autors |
Der Wert MUSS einem Code des in [IHE-ITI-VS] definierten Value Sets für DocumentEntry.authorRole entsprechen. |
|
authorSpecialty |
[0..*] |
|
[0..0] |
[0..0] |
[0..*] |
Fachliche Spezialisierung des Autors |
Der Wert MUSS einem Code des in [IHE-ITI-VS] |
|
authorTelecommunication |
[0..*] |
|
[0..0] |
[0..0] |
[0..*] |
Telekommunikationsdaten des Autors |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.1.4.5] genügen. |
availabilityStatus |
[0..0] |
|
[0..0] |
[1..1] |
[0..0] |
Status des Dokuments ("Approved" oder "Deprecated") |
Der Wert MUSS "urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" entsprechen. |
|
classCode |
[1..1] |
|
[ |
[0..0] |
[1..1] |
Grobe Klassifizierung des Dokuments |
Der Wert MUSS einem Code des in [IHE-ITI-VS] definierten Value Sets für DocumentEntry.classCode entsprechen. |
|
comments |
[0..1] |
|
[0.. |
[0..0] |
[0..1] |
Ergänzende Hinweise in Freitext |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.4] genügen. |
|
confidentialityCode |
[1..*] |
|
[ |
[0..0] |
[1..*] |
Vertraulichkeitskennzeichnung des Dokuments |
Das Primärsystem MUSS den Code "LEI" verwenden. Die Verwendung der Codes "PAT" und "KTR" ist für das Primärsystem nicht erlaubt. Das Primärsystem KANN zusätzlich den Code "LEÄ" verwenden. |
|
creationTime |
[1..1] |
|
[ |
[0..0] |
[1..1] |
Erstellungszeitpunkt des Dokuments |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.6] genügen. |
|
|
|
|
|
|
|
|
|
|
entryUUID |
[1..1] |
|
[ |
[0.. |
[1..1] |
Intern verwendete, aktenweit eindeutige Kennung des Dokuments |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.7] genügen. |
|
eventCodeList |
[0..*] |
|
[0..0] |
[0..0] |
[0..*] |
Ereignisse, die zur Erstellung des Dokuments geführt haben. |
|
|
formatCode |
[1..*] |
|
[ |
[0..0] |
[1..*] |
Global eindeutiger Code für das Dokumentenformat. |
|
|
hash |
[0..0] |
|
[0..0] |
[1..1] |
[0..1] |
Kryptographische Prüfsumme des Dokuments |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.10] genügen. |
|
healthcareFacilityTypeCode |
[1..1] |
|
[ |
[0..0] |
[1..1] |
Art der Einrichtung, in der das dokumentierte Ereignis stattgefunden hat. |
Der Wert MUSS einem Code des in [IHE-ITI-VS] definierten Value Sets für DocumentEntry.healthcareFacilityTypeCode entsprechen. |
|
homeCommunityId |
[1..1] |
|
[ |
[1..1] |
[0..1] |
Bei unterschiedlichen Aktensystemen ("Cross-Community") Kommunikation wird hier die Kennung des adressierten Aktensystems hinterlegt. |
Der Wert MUSS der Kennung des Aktenanbieters entsprechen und den Vorgaben aus Abschnitt 2.1.4.6 genügen. |
|
languageCode |
[1..1] |
|
[ |
[0..0] |
[1..1] |
Sprache, in der das Dokument abgefasst ist. |
Der Wert MUSS einem Code des in [IHE-ITI-VS] definierten Value Sets für DocumentEntry.languageCode entsprechen. |
|
legalAuthenticator |
[0..1] |
|
[0..0] |
[0..0] |
[0..1] |
Rechtlich Verantwortlicher für das Dokument |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.14] genügen. |
|
limitedMetadata |
[0..0] |
|
[0..0] |
[0..0] |
[0..0] |
Markierungsattribut, dass das Metadatenelement DocumentEntry nicht den vollständigen Satz an Metadaten enthält. |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.29] genügen. |
|
|
|
|
|
|
|
|
|
|
mimeType |
[1..1] |
|
[ |
[0..0] |
[1..1] |
MIME-Type des Dokuments |
Ein Wert aus der folgenden Liste MUSS als MIME-Type verwendet werden: |
|
objectType |
[1..1] |
|
[ |
[0..0] |
[1..1] |
Typ des Dokuments |
Der Wert MUSS immer "urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" betragen. Dieser Wert steht für stabile Dokumente im IHE ITI XDS.b-Profil [IHE-ITI-TF3#4.2.5.2]. |
|
patientId |
[1..1] |
|
[ |
[0..0] |
[1..1] |
Systemweit eindeutige Kennung des Patienten |
Der Wert MUSS den Inhalts- und Formatvorgaben aus Abschnitt 2.1.4.5 genügen. |
|
practiceSettingCode |
[1..1] |
|
[0..0] |
[0..0] |
[1..1] |
Art der Fachrichtung der erstellenden Einrichtung, in der das dokumentiere Ereignis stattgefunden hat. |
Der Wert MUSS einem Code des in [IHE-ITI-VS] definierten Value Sets für DocumentEntry.practiceSettingCode oder aus der Tabelle in der Anforderung A_16944 entsprechen. |
|
referenceIdList |
[0..*] |
|
[0..0] |
[0..0] |
[0.. |
Liste von IDs, mit denen das Dokument assoziiert wird. |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.28] genügen. |
|
repositoryUniqueId |
[0..1] |
|
[0.. |
[1..1] |
[0..1] |
Kennung des Document Repository, in welches das Dokument eingestellt wird/wurde. |
Wenn ein Wert vorhanden ist, MUSS er identisch mit dem Wert für DocumentEntry.homeCommunityId sein, da ein Anbieter ePA-Aktensystem immer nur über ein logisches Repository verfügt. |
|
serviceStartTime |
[0..1] |
|
[0.. |
[0..0] |
[0..1] |
Zeitpunkt, an dem das im Dokument dokumentierte |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.19] genügen. |
|
serviceStopTime |
[0..1] |
|
[0.. |
[0..0] |
[0..1] |
Zeitpunkt, an dem das im Dokument dokumentierte |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.20] genügen. |
|
size |
[0..0] |
|
[0..0] |
[1..1] |
[0..1] |
Größe des Dokuments in Bytes |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.21] genügen. |
|
sourcePatientId |
[0..1] |
|
[0..0] |
[0..0] |
[0..0] |
Kennung des Patienten im Quellsystem |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.22] genügen. |
|
sourcePatientInfo |
[0..*] |
|
[0..0] |
[0..0] |
[0..0] |
Demographische Daten zum Patienten im Quellsystem |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.23] genügen. |
|
title |
[0..1] |
|
[0.. |
[0..0] |
[0..1] |
Titel des Dokuments |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.24] genügen. |
|
typeCode |
[1..1] |
|
[ |
[0..0] |
[1..1] |
Art des Dokuments |
Der Wert MUSS einem Code des in [IHE-ITI-VS] definierten Value Sets für DocumentEntry.typeCode entsprechen. |
|
uniqueId |
[1..1] |
|
[ |
[0..0] |
[1..1] |
Eindeutige, aktenweite Kennung des Dokuments |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.26] genügen. |
|
URI |
[1..1] |
|
[ |
[0..0] |
[1..1] |
URI für das Dokument |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.27] genügen |
|
|
|
|
|
|
|
|
|
|
Metadatenelement Submission Set |
||||||||
author |
[1..*] |
|
[ |
[0..0] |
[1..1] |
Person oder System, welche(s) das Submission Set erstellt hat. |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.3.1] genügen. |
|
|
authorPerson |
[0..1] |
|
[0.. |
[0..0] |
[0..1] |
Name der einstellenden Person oder des einstellenden Systems |
Der Wert MUSS den Formatvorgaben aus Abschnitt 2.1.4.3 genügen. |
|
authorInstitution |
[1..*] |
|
[ |
[0..0] |
[0..1] |
Institution, welcher die einstellende Person oder das einstellende System zugeordnet ist. |
Der Wert MUSS den Formatvorgaben aus Abschnitt 2.1.4.4 genügen. |
|
authorRole |
[1..*] |
|
[ |
[0..0] |
[1..1] |
Rolle der einstellenden Person oder des einstellenden Systems |
Der Wert MUSS einem Code des in [IHE-ITI-VS] definierten Value Sets für DocumentEntry.authorRole entsprechen. |
|
authorSpecialty |
[0..*] |
|
[0..0] |
[0..0] |
[0..*] |
Fachliche Spezialisierung der einstellenden Person oder des einstellenden Systems |
Der Wert MUSS einem Code des in [IHE-ITI-VS] definierten Value Sets für DocumentEntry.authorSpecialty oder aus der Tabelle in der Anforderung A_15744 entsprechen. |
|
authorTelecommunication |
[0..*] |
|
[0..0] |
[0..0] |
[0..*] |
Telekommunikationsdaten der einstellenden Person oder des einstellenden Systems |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.1.4.5] genügen. |
availabilityStatus |
[0..0] |
|
[0..0] |
[1..1] |
[0..0] |
Status des Submission Sets ("Approved") |
Der Wert MUSS "urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" entsprechen. |
|
comments |
[0..1] |
|
[0.. |
[0..0] |
[0..1] |
Ergänzende Hinweise zum Submission Set in Freitext |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.3.3] genügen. |
|
contentTypeCode |
[0..1] |
|
[0.. |
[0..0] |
[0..1] |
Klinische Aktivität, die zum Einstellen des Submission Set geführt hat. |
Der Wert MUSS einem Code des in [IHE-ITI-VS] definierten Value Sets für SubmissionSet.contentTypeCode entsprechen. |
|
entryUUID |
[1..1] |
|
[ |
[0.. |
[1..1] |
Intern verwendete, aktenweit eindeutige Kennung des Submission Sets |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.3.5] genügen. |
|
homeCommunityId |
[1..1] |
|
[ |
[1..1] |
[0..1] |
Zur Cross-Community-Kommunikation die Kennung des adressierten Aktensystems |
Der Wert MUSS identisch mit dem Wert für DocumentEntry.homeCommunityId sein. |
|
intendedRecipient |
[0..*] |
|
[0..0] |
[0..0] |
[0..*] |
Vorgesehener Adressat des Submission Set |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.3.7] genügen. |
|
limitedMetadata |
[0..0] |
|
[0..0] |
[0..0] |
[0..0] |
Markierung, welche anzeigt, dass das Submission Set nicht den durch das IHE ITI TF vorgegebenen Satz an Metadaten enthält. |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.3.13] genügen. |
|
patientId |
[1..1] |
|
[ |
[0..0] |
[1..1] |
Patienten-ID, zu der das Submission Set gehört |
Der Wert MUSS den Inhalts- und Formatvorgaben aus Abschnitt 2.1.4.5 genügen. |
|
sourceId |
[0..0] |
|
[0..0] |
[0..0] |
[0..0] |
Weltweit eindeutige, unveränderliche Kennung des einstellenden Systems |
Die ePA-Dokumentenverwaltung DARF ein Submission Set NICHT ablehnen, wenn keine sourceId gesetzt wurde. |
|
submissionTime |
[1..1] |
|
[ |
[0..0] |
[1..1] |
Zeit, zu der das Submission Set zusammengestellt wurde. |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.3.10] genügen. |
|
title |
[0..1] |
|
[0.. |
[0..0] |
[0..1] |
Titel des Submission Sets |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.3.11] genügen. |
|
uniqueId |
[1..1] |
|
[ |
[0..0] |
[1..1] |
Eindeutige Kennung des Submission Sets |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.3.12] genügen. |
|
[<=]
Die in [IHE-ITI-VS] 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 B 4.1 abgebildetdargestellt. Es steht den Herstellern der Frontends frei, die Tabellen nach eigenen Erfahrungswerten zu ergänzen oder einzukürzen.
A_14961 - Nutzungsvorgaben für die Verwendung von XDS-Metadaten bei Policy Documents
Das ePA-Fachmodul sowie das ePA-Frontend des Versicherten MÜSSEN bei Registrierung von Policy Documents (Advanced Patient Privacy Consents) gemäß [IHE-ITI-APPC] in der ePA-Dokumentenverwaltung die folgenden Nutzungsvorgaben für XDS-Metadaten berücksichtigen:
Tabelle 64: Nutzungsvorgaben für Metadatenattribute bei Policy Documents
Metadatenattribut XDS.b |
Mult. |
Mult. |
Mult. |
Kurzbeschreibung |
Nutzungsvorgabe |
|
Metadatenelement Document Entry |
||||||
author |
[1..1] |
[0..0] |
[1..1] |
Person oder System, welche(s) das Dokuments erstellt hat. |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.1] genügen. |
|
|
authorPerson |
[1..1] |
[0..0] |
[1..1] |
Name des Autors |
Der Wert MUSS "^^EPA_FM" entsprechen, falls das ePA-Fachmodul das Policy Document erzeugt hat. |
authorInstitution |
[0..0] |
[0..0] |
[0..0] |
Institution, die dem Autor zugeordnet ist. |
|
|
authorRole |
[1..1] |
[0..0] |
[1..1] |
Rolle des Autors |
Der Wert MUSS dem Code |
|
authorSpecialty |
[0..0] |
[0..0] |
[0..0] |
Fachliche Spezialisierung des Autors |
|
|
authorTelecommunication |
[0..0] |
[0..0] |
[0..0] |
Telekommunikationsdaten des Autors |
|
|
availabilityStatus |
[0..0] |
[1..1] |
[0..0] |
Status des Dokuments ("Approved" oder "Deprecated") |
Der Wert MUSS "urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" entsprechen. |
|
classCode |
[1..1] |
[0..0] |
[1..1] |
Grobe Klassifizierung des Dokuments |
Der Wert MUSS dem Code "57016-8" (Patienteneinverständniserklärung) des in [IHE-ITI-VS] definierten Value Sets für DocumentEntry.classCode entsprechen. |
|
comments |
[0..0] |
[0..0] |
[0..0] |
Ergänzende Hinweise in Freitext |
|
|
confidentialityCode |
[1..1] |
[0..0] |
[1..1] |
Vertraulichkeitskennzeichnung des Dokuments |
|
|
creationTime |
[1..1] |
[0..0] |
[1..1] |
Erstellungszeitpunkt des Dokuments |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.6] genügen. |
|
|
|
|
|
|
|
|
entryUUID |
[1..1] |
[0.. |
[1..1] |
Intern verwendete, aktenweit eindeutige Kennung des Dokuments |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.7] genügen. |
|
eventCodeList |
[0..0] |
[0..0] |
[0..0] |
Ereignisse, die zur Erstellung des Dokuments geführt haben. |
|
|
formatCode |
[1..1] |
[0..0] |
[1..1] |
Global eindeutiger Code für das Dokumentenformat. |
Der Wert MUSS dem Code "urn:ihe:iti:appc:2016:consent" sowie dem |
|
hash |
[0..0] |
[1..1] |
[0..1] |
Kryptographische Prüfsumme des Dokuments |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.10] genügen. |
|
healthcareFacilityTypeCode |
[1..1] |
[0..0] |
[1..1] |
Art der Einrichtung, in der das dokumentierte Ereignis stattgefunden hat. |
Das ePA-Fachmodul MUSS einen Code aus dem in [IHE-ITI-VS] definierten Value Set für DocumentEntry.healthcareFacilityTypeCode verwenden. |
|
homeCommunityId |
[1..1] |
[1..1] |
[0..1] |
Bei unterschiedlichen Aktensystemen ("Cross-Community") Kommunikation wird hier die Kennung des adressierten Aktensystems hinterlegt. |
Der Wert MUSS der Kennung des Aktenanbieters entsprechen und den Vorgaben aus Abschnitt 2.1.4.6 genügen. |
|
languageCode |
[0..0] |
[0..0] |
[0..0] |
Sprache, in der das Dokument abgefasst ist. |
|
|
legalAuthenticator |
[0..0] |
[0..0] |
[0..0] |
Rechtlich Verantwortlicher für das Dokument |
|
|
limitedMetadata |
[0..0] |
[0..0] |
[0..0] |
Markierungsattribut, dass das Metadatenelement DocumentEntry nicht den vollständigen Satz an Metadaten enthält. |
|
|
|
|
|
|
|
|
|
mimeType |
[1..1] |
[0..0] |
[1..1] |
MIME-Type des Dokuments |
Der Wert MUSS "application/xacml+xml" gemäß [RFC7061] entsprechen. |
|
objectType |
[1..1] |
[0..0] |
[1..1] |
Typ des Dokuments |
Der Wert MUSS immer "urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" betragen. Dieser Wert steht für stabile Dokumente im IHE ITI XDS.b-Profil [IHE-ITI-TF3#4.2.5.2]. |
|
patientId |
[1..1] |
[0..0] |
[1..1] |
Systemweit eindeutige Kennung des Patienten |
Der Wert MUSS den Inhalts- und Formatvorgaben aus Abschnitt 2.1.4.5 genügen. |
|
practiceSettingCode |
[0..0] |
[0..0] |
[0..0] |
Art der Einrichtung, in der das dokumentierte Ereignis stattgefunden hat. |
|
|
referenceIdList |
[1..*] |
[0..0] |
[1..*] |
Liste von IDs, mit denen das Dokument assoziiert wird. |
Die Liste MUSS mindestens die Policy Set ID Reference des Policy Documents (Advanced Patient Privacy Consent) gemäß [IHE-ITI-APPC] enthalten. |
|
repositoryUniqueId |
[0..1] |
[1..1] |
[0..1] |
Kennung des Document Repository, in welches das Dokument eingestellt wird/wurde. |
Der Wert MUSS dem Wert von DocumentEntry.homeCommunityId entsprechen. |
|
serviceStartTime |
[0..0] |
[0..0] |
[0..0] |
Zeitpunkt, an dem das im Dokument dokumentierte Ereignis begonnen wurde. |
|
|
serviceStopTime |
[0..0] |
[0..0] |
[0..0] |
Zeitpunkt, an dem das im Dokument dokumentierte Ereignis beendet wurde. |
|
|
size |
[0..0] |
[1..1] |
[0..0] |
Größe des Dokuments in Bytes |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.21] genügen. |
|
sourcePatientId |
[0..0] |
[0..0] |
[0..0] |
Kennung des Patienten im Quellsystem |
|
|
sourcePatientInfo |
[0..0] |
[0..0] |
[0..0] |
Demographische Daten zum Patienten im Quellsystem |
|
|
title |
[1..1] |
[0..0] |
[1..1] |
Titel des Dokuments |
|
|
typeCode |
[1..1] |
[0..0] |
[1..1] |
Art des Dokuments |
Der Wert MUSS dem Code "57016-8" sowie dem |
|
uniqueId |
[1..1] |
[0..0] |
[1..1] |
Eindeutige, aktenweite Kennung des Dokuments |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.26] genügen und gleichzeitig der Policy Set ID des Dokuments gemäß [IHE-ITI-APPC#5.6.2.2.1.4] entsprechen. |
|
URI |
[1..1] |
[0..0] |
[1..1] |
URI für das Dokument |
|
|
|
|
|
|
|
|
|
Metadatenelement Submission Set |
||||||
author |
[1..1] |
[0..0] |
[1..1] |
Person oder System, welche(s) das Submission Set erstellt hat . |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.2.1] genügen. |
|
|
authorPerson |
[1..1] |
[0..0] |
[1..1] |
Name der einstellenden Person oder des einstellenden Systems |
Der Wert MUSS dem Wert von DocumentEntry.authorPerson entsprechen. |
authorInstitution |
[0..0] |
[0..0] |
[0..0] |
Institution, welcher die einstellende Person oder das einstellende System zugeordnet ist. |
|
|
authorRole |
[0..0] |
[0..0] |
[0..0] |
Rolle der einstellenden Person oder des einstellenden Systems |
|
|
authorSpecialty |
[0..0] |
[0..0] |
[0..0] |
Fachliche Spezialisierung der einstellenden Person oder des einstellenden Systems |
|
|
authorTelecommunication |
[0..0] |
[0..0] |
[0..0] |
Telekommunikationsdaten der einstellenden Person oder des einstellenden Systems |
|
|
availabilityStatus |
[0..0] |
[0..0] |
[0..0] |
Status des Submission Sets ("Approved") |
Wenn ein Wert angegeben ist, MUSS er "urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" entsprechen. |
|
comments |
[0..0] |
[0..0] |
[0..0] |
Ergänzende Hinweise in Freitext |
|
|
contentTypeCode |
[0..0] |
[0..0] |
[0..0] |
Klinische Aktivität, die zum Einstellen des Submission Sets geführt hat |
|
|
entryUUID |
[1..1] |
[0.. |
[1..1] |
Intern verwendete, aktenweit eindeutige Kennung des Submission Sets |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.3.5] genügen. |
|
homeCommunityId |
[1..1] |
[1..1] |
[0..1] |
Zur Cross-Community-Kommunikation die Kennung des adressierten Aktensystems |
Der Wert MUSS identisch mit dem Wert für DocumentEntry.homeCommunityId sein. |
|
intendedRecipient |
[0..0] |
[0..0] |
[0..0] |
Vorgesehener Adressat des Submission Sets |
|
|
limitedMetadata |
[0..0] |
[0..0] |
[0..0] |
Markierung, welche anzeigt, dass das Submission Set nicht den durch das IHE ITI TF vorgegebenen Satz an Metadaten enthält |
|
|
patientId |
[1..1] |
[0..0] |
[1..1] |
Patienten-ID, zu der das Submission Set gehört |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.3.8] genügen und inhaltlich identisch zur DocumentEntry.patientId sein. |
|
sourceId |
[0..0] |
[0..0] |
[0..0] |
Weltweit eindeutige, unveränderliche Kennung des einstellenden Systems |
|
|
submissionTime |
[1..1] |
[0..0] |
[1..1] |
Zeit, zu der das Submission Set zusammengestellt wurde |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.3.10] genügen. |
|
title |
[0..0] |
[0..0] |
[0..0] |
Titel des Submission Sets |
|
|
uniqueId |
[1..1] |
[0..0] |
[1..1] |
Eindeutige Kennung des Submission Sets |
Der Wert MUSS den Formatvorgaben aus [IHE-ITI-TF3#4.2.3.3.12] genügen. |
|
[<=]
A_16175 - Konfigurierbarkeit der Dateitypen
Die ePA-Dokumentenverwaltung MUSS eine Schnittstelle bereitstellenKonfigurierbarkeit unterstützen , die es erlaubt, die initiale Liste im IHE ITI XDS-Metadatenattribut DocumentEntry.mimeType sowie den erlaubten korrespondierenden Dateiendungen im Metadatenattribut DocumentEntry.URI zu verändern. Eine Änderung der Listeninhalte MUSS in einer adaptierten Prüflogik resultieren. zu erweitern. Eine Änderung des Listeninhalts MUSS in einer adaptierten Prüflogik während des Registrierens von neuen Dokumenten resultieren.
[<=]
A_17546 - Konfigurierbarkeit von Value Sets
Die ePA-Dokumentenverwaltung MUSS eine Konfigurierbarkeit unterstützen, die Value Sets der IHE ITI XDS-Metadatenattribute DocumentEntry.classCode, DocumentEntry.typeCode sowie DocumentEntry.formatCode erweitert. Eine Änderung dieser Value-Set-Inhalte MUSS in einer adaptierten Prüflogik während des Registrierens von neuen Dokumenten resultieren, sodass auch Metadaten mit neu hinzugefügten Codes akzeptiert werden.
[<=]
A_17551 - Prüfanforderungen zur Konfigurierbarkeit von Value Sets
Der Anbieter des ePA-Aktensystems MUSS sicherstellen, dass die zu konfigurierenden Value Sets gemäß der Anforderung A_17546 den folgenden Prüfkriterien unterliegen, bevor bestehende, in der ePA-Dokumentenverwaltung verarbeitete Value Sets verändert werden:
- Es DÜRFEN keine Codes der Value Sets gelöscht werden, lediglich das Hinzufügen von Codes zu existierenden Value Sets ist aus Kompatibilitätsgründen erlaubt.
- Neue Codes MÜSSEN den Formatvorgaben gemäß Tabelle 4.2.3.1.7-2 in [IHE-ITI-TF3#4.2.3.1.7] entsprechen und gegenüber einer herstellerindividuellen Whitelist validiert werden. Dies schließt auch Prüfungen zur Zeichenkodierung, der Datentypen als auch zu den Längenbeschränkungen ein.
[<=]
2.1.4.3 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 Dokumentenbündels Ü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.
A_14762 - Nutzungsvorgabe für authorPerson als Teil von DocumentEntry.author und SubmissionSet.author
Das Primärsystem sowie die ePA-Produkttypen, welche IHE ITI XDS-Metadaten verarbeiten, MÜSSEN die folgenden Nutzungsvorgaben für das Metadatenattribut authorPerson unterhalb von DocumentEntry.author und SubmissionSet.author berücksichtigen. Der Wert dieses Attributs MUSS den Vorgaben aus [IHE-ITI-TF3#4.2.3.1.4.2] genügen und ist inhaltlich nach den folgenden Vorschriften zusammenzufügen bzw. zu belegen.
Leistungserbringer als Autor
- Lebenslange Identifikationsnummer eines Arztes (Lebenslange Arztnummer - LANR 9 Stellen) - sofern bekannt
- "^"
- Nachname
- "^"
- Vorname
- "^"
- Weiterer Vorname
- "^"
- Namenszusatz
- "^"
- Titel
- "^^^&" - sofern LANR angegeben, ansonsten "^^^"
- "1.2.276.0.76.4.16" - sofern LANR angegeben
- "&ISO" - sofern LANR angegeben
Beispiele:
165746304^Weber^Thilo^^^Dr.^^^&1.2.276.0.76.4.16&ISO
^Weber^Thilo^^^Dr.^^^
Versicherter als Autor
- Der unveränderbare Teil der KVNR (10 Stellen)
- "^"
- Nachname
- "^"
- Vorname
- "^"
- Weiterer Vorname
- "^"
- Namenszusatz
- "^"
- Titel
- "^^^&"
- "1.2.276.0.76.4.8"
- "&ISO"
Beispiel: G995030566^Gundlach^Monika^^^^^^&1.2.276.0.76.4.8&ISO
Software-Komponente bzw. Gerät als Autor
Beim (automatisierten) Einstellen von Dokumenten MUSS der max. 256-Zeichen lange Name der Software-Komponente bzw. des Geräts als Nachname und ggf. als Vorname(n) eingetragen werden.
Beispiel: ^PHR-Gerät-XY^PHR-Software-XY [<=]
2.1.4.4 authorInstitution (DocumentEntry.author und SubmissionSet.author)
A_14763 - Nutzungsvorgabe für DocumentEntry.authorInstitution
Das Primärsystem sowie die ePA-Produkttypen, welche IHE ITI XDS-Metadaten verarbeiten, MÜSSEN die folgenden Nutzungsvorgaben für das Metadatenattribut authorInstitution berücksichtigen. Der Wert MUSS den Vorgaben aus [IHE-ITI-TF3#4.2.3.1.4.1] genügen und ist inhaltlich nach der folgenden Vorschrift zusammenzufügen bzw. zu belegen.
- Name der Leistungserbringerinstitution oder Name des Kostenträgers
- "^^^^^&"
- "1.2.276.0.76.4.5" (OID zur Kennzeichnung
eines Institutionskennzeichen) - "&ISO^^^^"
- Institutionskennzeichen der Leistungserbringerinstitution oder Betriebsnummer des Kostenträgers
Beispiel: Beispiele:
Arztpraxis Dr. Thilo Weber^^^^^&1.2.276.0.76.4.5&ISO^^^^12345 [<=] 5&ISO^^^^1-2c47sd-e518
gematik Betriebskrankenkasse^^^^^&1.2.276.0.76.4.5&ISO^^^^81231936
[<=]
2.1.4.5 DocumentEntry.patientId und SubmissionSet.patientId
A_14974 - Nutzungsvorgabe für DocumentEntry.patientId und SubmissionSet.patientId
Das Primärsystem sowie die ePA-Produkttypen, welche IHE ITI XDS-Metadaten verarbeiten, MÜSSEN die folgenden Nutzungsvorgaben für das Metadatenattribut DocumentEntry.patientId und SubmissionSet.patientId berücksichtigen. Der Wert MUSS den Vorgaben aus [IHE-ITI-TF3#4.2.3.2.16] bzw. [IHE-ITI-TF3#4.2.3.3.8] genügen und ist inhaltlich nach der folgenden Vorschrift zusammenzufügen bzw. zu belegen.
- Der unveränderbare Teil der KVNR des Akteninhabers (10 Stellen)
- "^^^&"
- "1.2.276.0.76.4.8" (OID zur Kennzeichnung einer unveränderbaren KVNR)
- "&ISO"
Beispiel: G995030566^^^&1.2.276.0.76.4.8&ISO [<=]
2.1.4.6 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-AktensystemAktensystems 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 eineneinem 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.
A_14839 - Home Community ID als OID URN
Der Anbieter ePA-Aktensystem MUSS die Vorgaben aus [IHE-ITI-TF3#4.2.3.2.12] für die Bildung der Home Community ID befolgen.
[<=]
2.1.4.7 DocumentEntry.eventCodeList
Das Metadatenattribut DocumentEntry.eventCodeList kann verwendet werden, um medizinische Bilder gemäß ihrem Typ gesondert zu kennzeichnen.
A_17547 - Nutzungsvorgabe für DocumentEntry.eventCodeList
Das Primärsystem sowie die ePA-Produkttypen, welche IHE ITI XDS-Metadaten verarbeiten, MÜSSEN die Nutzungsvorgaben für das Metadatenattribut DocumentEntry. eventCodeList gemäß des in [IHE-ITI-VS] definierten Value Sets für DocumentEntry.eventCodeList berücksichtigen.
[<=]
A_17540 - Kennzeichnung von medizinischen Bildern
Das Primärsystem sowie die ePA-Produkttypen, welche IHE ITI XDS-Metadaten verarbeiten, SOLLEN, wenn das Metadatenattribut DocumentEntry.mimeType den Wert "image/jpeg" oder "image/tiff" besitzt sowie der Dokumenteninhalt ein medizinisches Bild repräsentiert, das Metadatenattribut DocumentEntry.eventCodeList mit dem passenden Code aus folgender Liste belegt werden:
Tabelle: 5 Nutzungsvorgaben für die Kennzeichnung von medizinischen Bildern
Code-System |
Code-Wert |
Anzeigename |
1.2.840.10008.2.16.4 |
BDUS |
Ultrasound Bone Densitometry |
BMD |
Bone Mineral Densitometry |
|
CR |
Computed Radiography |
|
CT |
Computed Tomography |
|
DX |
Digital Radiography |
|
ES |
Endoscopy |
|
GM |
General Microscopy |
|
IO |
Intra-oral Radiography |
|
IVOCT |
Intravascular Optical Coherence Tomography |
|
IVUS |
Intravascular Ultrasound |
|
MG |
Mammography |
|
MR |
Magnetic Resonance MR |
|
NM |
Nuclear Medicine |
|
OCT |
Optical Coherence Thomography |
|
OP |
Ophthalmic Photography |
|
OPT |
Ophthalmic Tomography |
|
OPTENF |
Ophthalmic Tomography En Face |
|
PT |
Positron Emission Tomography |
|
PX |
Panoramic X-Ray |
|
RF |
Radiofluoroscopy |
|
RG |
Radiographic Imaging |
|
SM |
Slide Microscopy |
|
US |
Ultrasound |
|
XA |
X-Ray Angiography |
|
XC |
External-camera Photography |
[<=]
Diese soeben gelisteten Codes stammen aus DICOM Teil 16, Context Group 29 "Acquisition Modality" (Value Set 1.2.840.10008.6.1.19, Version "20180605", gekürzt um Nichtbildverfahren).
2.1.4.8 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:
A_14986 - Kennzeichnung eines Dokuments als Versicherteninformation
Das Primärsystem MUSS zur Kennzeichnung eines Dokuments als Information für den Versicherten den DocumentEntry.classCode "DOK" (Dokumente ohne besondere Form (Notizen)) aus [IHE-ITI-VS] verwenden. Weiterhin MUSS der DocumentEntry.typeCode "PATI" (Patienteninformationen) aus [IHE-ITI-VS] verwendet werden. [<=]
2.2 RecordIdentifierRecord Identifier
Der RecordIdentifierRecord 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:II" minOccurs="1" maxOccurs="1"/> <xs:element name="HomeCommunityId" type="tns:LongName" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
Das Element "InsurantId" ist vom Typ "Instance Identifier" (II) und 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 2.1.4.6). 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.
A_14471 - Objektstruktur Eintrag für Protokoll
Produkttypen und Komponenten, die Ereignisse in einem Protokoll hinzufügen, MÜSSEN Einträge für einen RecordIdentifier als AuditMessage gemäß der XML-Schemafestlegung für http://ws.gematik.de/fa/phr/PHR/v1.0 gemäß [healthcare-security-audit.xsd] mit folgendem Inhalt hinzufügen:
Tabelle 76: Logische Objektstruktur des Protokolls nach § 291a SGB V inkl. Verwaltungsprotokoll für PHR:ProtocolEntryType
Protokollattribut |
Inhalt der Audit Message |
Aufgerufene |
EventID -> |
DisplayName -> |
|
Datum und Uhrzeit |
phr:AuditMessage/phr:EventIdentification/@EventDateTime |
Ergebnis der |
phr:AuditMessage/phr:EventIdentification/@EventOutcomeIndicator |
User-ID |
phr:AuditMessage/phr:ActiveParticipant/@UserID |
User Name |
phr:AuditMessage/phr:ActiveParticipant/@UserName |
Object-ID |
phr:AuditMessage/phr:ParticipantObjectIdentification/@ParticipantObjectID |
Object Name |
phr:AuditMessage/phr:ParticipantObjectIdentification/phr:ParticipantObjectName |
für Zugriff durch |
phr:AuditMessage/phr:ActiveParticipant/@NetworkAccessPointID |
Home-Community-ID |
phr:AuditMessage/phr:AuditSourceIdentification/@AuditSourceID |
Name des |
phr:AuditMessage/phr:AuditSourceIdentification/@AuditEnterpriseSiteID |
[<=]
A_14505 - Event Codes für Protokollereignisse
ePA-Produkttypen und Komponenten, die Ereignisse in einem Protokoll hinzufügen, MÜSSEN im Protokolleintrag für die jeweils aufgerufene Operation die Event Codes und den Display Name gemäß der folgenden Tabelle verwenden:
Tabelle 87: Event Codes für Protokollereignisse
Operation |
EventID.code |
EventID.displayName |
|||
I_Authentication_Insurant::loginCreateToken |
PHR-110 |
Authentifizierung eines Versicherten mit eGK und PIN |
|||
I_Authentication_Insurant::renewToken |
PHR-111 |
Aktualisierung einer Authentifizierungsbestätigung für einen Versicherten |
|||
I_Authentication_Insurant::logoutToken |
PHR-112 |
Abmelden einer Authentifizierungsbestätigung für einen Versicherten |
|||
I_Authentication_Insurant::getAuditEvents |
PHR-120 |
Abruf des Verwaltungsprotokolls aus der privaten Umgebung |
|||
I_Authorization_Insurant::getAuthorizationKey |
PHR-220 |
Abruf eines Aktenzugriffs aus der privaten Umgebung |
|||
I_Authorization_Management::putAuthorizationKey |
PHR-310 |
Erteilung eines Aktenzugriffs aus der ärztlichen Umgebung |
|||
|
|
|
|||
|
|
|
|||
I_Authorization_Management_Insurant::putAuthorizationKey |
PHR-410 |
Erteilung eines Aktenzugriffs aus der privaten Umgebung |
|||
I_Authorization_Management_Insurant::deleteAuthorizationKey |
PHR-420 |
Löschen eines Aktenzugriffs aus der privaten Umgebung |
|||
I_Authorization_Management_Insurant::replaceAuthorizationKey |
PHR-430 |
Aktualisierung eines Aktenzugriffs aus der privaten Umgebung |
|||
I_Authorization_Management_Insurant::getAuditEvents |
PHR-440 |
Abruf des Verwaltungsprotokolls aus der privaten Umgebung |
|||
I_Authorization_Management_Insurant::putNotificationInfo |
PHR-450 |
Aktualisierung der Benachrichtigungsadresse aus der privaten Umgebung |
|||
I_Authorization_Management_Insurant:: |
PHR-460 |
|
|||
I_Document_Management::CrossGatewayDocumentProvide |
PHR-510 |
Hinzufügen eines Dokuments aus der ärztlichen Umgebung |
|||
I_Document_Management::CrossGatewayQuery |
PHR-520 |
Suchanfrage aus der ärztlichen Umgebung |
|||
I_Document_Management::RemoveDocuments |
PHR-530 |
Löschen eines Dokuments aus der ärztlichen Umgebung |
|||
I_Document_Management::CrossGatewayRetrieve |
PHR-540 |
Abruf eines Dokuments aus der ärztlichen Umgebung |
|||
I_Document_Management::RestrictedUpdateDocumentSet |
PHR-550 |
Markierung eines Dokuments als leistungserbringeräquivalent aus der ärztlichen Umgebung |
|||
I_Document_Management_Insurant::ProvideAndRegisterDocumentSet-b |
PHR-610 |
Hinzufügen eines Dokuments aus der privaten Umgebung |
|||
I_Document_Management_Insurant::RegistryStoredQuery |
PHR-620 |
Suchanfrage aus der privaten Umgebung |
|||
I_Document_Management_Insurant::RemoveDocuments |
PHR-630 |
Löschen eines Dokuments aus der privaten Umgebung |
|||
I_Document_Management_Insurant::RetrieveDocumentSet |
PHR-640 |
Abruf eines Dokuments aus der privaten Umgebung |
|||
I_Account_Management_Insurant::SuspendAccount |
PHR-650 |
Schließung des Aktenkontos aus der privaten Umgebung |
|||
I_Account_Management_Insurant::ResumeAccount |
PHR-660 |
Datenübernahme aus Altsystem aus der privaten Umgebung |
|||
I_Document_Management_Insurance::ProvideAndRegisterDocumentSet-b |
PHR-710 |
Hinzufügen eines Dokuments aus der Kostenträger-Umgebung |
|||
[<=]
2.4 Verschlüsselung von Dokumenten
Dokumente, die in der Dokumentenverwaltung gespeichert werden, müssen je nach Typ vor dem Hochladen verschlüsselt werden. Dabei wird wie folgt vorgegangen (siehe auch [gemSpecAutorisierunggemSpec_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
mit dem asymmetrischen Schlüssel (von eGK oder SMC-B) des Berechtigtenmittels Schlüsselableitung gemäß [gemSpec_SGD_ePA] verschlüsselt.
VerschlüsseltesDas 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
A_14975 - Verschlüsselung des Dokuments mit dem DocumentKey
Das ePA-Fachmodul Zur Entschlüsselung werden die Schritte in umgekehrter Reihenfolge durchgeführt.
2.4.1 Verschlüsselung
A_14975 - Verschlüsselung des Dokuments mit dem DocumentKey
Das ePA-Fachmodul, das ePA-Fachmodul KTR-Consumer und das ePA-Frontend des Versicherten MÜSSEN den dokumentenindividuellen DocumentKey gemäß [gemSpec_Krypt#3.1.4] erzeugen und das zu verschlüsselnde Dokument symmetrisch mit dem dokumentenindividuellen DocumentKey verschlüsseln.
[<=]
A_14976 - Verschlüsselung des DocumentKey mit dem RecordKey
Das ePA-Fachmodul, das ePA-Fachmodul KTR-Consumer und das ePA-Frontend des Versicherten MÜSSEN den DocumentKey des einzustellenden Dokuments symmetrisch mit dem RecordKey gemäß [gemSpec_Krypt#3.1.4] verschlüsseln.
[<=]
A_14977 - Dokumentenverschlüsselung gemäß XML Encryption
Das ePA-Fachmodul, das ePA-Fachmodul KTR-Consumer und das ePA-Frontend des Versicherten MÜSSEN das verschlüsselte Dokument, den zu dessen Verschlüsselung verwendeten DocumentKey und den RecordIdentifier gemäß KapitelAbschnitt 2.2 in folgende XML-Struktur als xenc:EncryptedData gemäß [XMLEnc] verpacken:
<?xml version="1.0" encoding="UTF-8"?>
<xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#http://www.w3.org/2001/04/xmlenc#"
Type="http://www.w3.org/2001/04/xmlenc#Contenthttp://www.w3.org/2001/04/xmlenc#Content">
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#aes256-gcmhttp://www.w3.org/2009/xmlenc11#aes256-gcm"/>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#http://www.w3.org/2000/09/xmldsig#">
<xenc:EncryptedKey>
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#aes256-gcmhttp://www.w3.org/2009/xmlenc11#aes256-gcm"/>
<ds:KeyInfo>
<!-- <ds:KeyName> enthält RecordIdentifier des Aktenkontos,
um bei späterer Entschlüsselung den richtigen Aktenschlüssel
wählen zu können -->
<ds:KeyName>...</ds:KeyName>
</ds:KeyInfo>
<xenc:CipherData>
<!-- <xenc:CipherValue> enthält mit Aktenschlüssel
symmetrisch verschlüsselten DokumentenschlüsselDokumentenschlüsselin der Formatierung
gemäß Festlegung in -->
<xenc:CipherValue>...</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedKey>
</ds:KeyInfo>
<xenc:CipherData>
<!-- <xenc:CipherValue> enthält mit Dokumentenschlüssel
symmetrisch verschlüsseltes Dokument in der Formatierung gemäß Festlegung
in -->
<xenc:CipherValue>...</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData> [<=]
Der für XML Encryption im XML angegebene Verschlüsselungsalgorithmus (http://www.w3.org/2009/xmlenc11#aes256-gcmhttp://www.w3.org/2009/xmlenc11#aes256-gcm) ist konform zu den Vorgaben in [gemSpec_Krypt#3.1.4].
[<=]
2.4.2 Entschlüsselung
Dokumente, die aus der Dokumentenverwaltung heruntergeladen werden, müssen abhängig vom Dokumententyp entschlüsselt werden. Dabei wird die Verschlüsselung aus Kapitel 2.4.1Abschnitt 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.
A_14682 - Entschlüsselung eines Dokuments beim Herunterladen aus der Dokumentenverwaltung
Das ePA-Fachmodul und das ePA-Frontend des Versicherten MÜSSEN das gemäß der Anforderung A_14977 verschlüsselte Dokument durch Entschlüsselung gemäß [XMLEnc] unter Verwendung des RecordKey des dazugehörigen Aktenkontos in das unverschlüsselte Dokument überführen.
[<=]
Nach Entschlüsselung gemäß obigerder obigen Anforderung liegt das Dokument im Klartext vor.
2.5 Verschlüsselung von Akten- und Kontextschlüssel
Um auf Dokumente in der Komponente Dokumentenverwaltung zuzugreifen, müssen ePA-Fachmodul und ePA-Frontend des Versicherten mit einem Kontextschlüssel (ContextKey) die Vertrauenswürdige Ausführungsumgebung (VAU) öffnen. Beim Hoch- bzw. Herunterladen eines Dokuments muss dieses mithilfe eines Aktenschlüssels (RecordKey) des Aktenkontos eines Versicherten ver- bzw. entschlüsselt werden.
Den ContextKey und RecordKey beziehen beide Produkttypen von der Komponente Autorisierung über den Rückgabewert AuthorizationKey der Operation getAuthorizationKey(). Alle Schlüssel sind hybrid empfängerverschlüsselt, d.h. der Berechtigte muss den jeweiligen Schlüssel vor der Verwendung mittels des privaten Schlüssels der SM-B oder eGK hybrid entschlüsseln.
Um den ContextKey und RecordKey hybrid mittels XML Encryption ver- und entschlüsseln zu können, werden diese mit einem XML-Tag <Key> geklammert, wobei nur der innere Teil den Klartextschlüssel darstellt.
A_15553 - Klartextrepräsentation für Akten- und Kontextschlüssel für XML Encryption
Das ePA-Fachmodul und das ePA-Frontend des Versicherten MÜSSEN den Klartext des ContextKey und RecordKey jeweils als XML-Fragment der folgenden Struktur für die Ver- und Entschlüsselung mittels XML Encryption verwenden.<!-- Für die [OwnerKVNR] wird beim Erstellen des Schlüssels der unveränderliche Teil der KVNR des Versicherten (Versicherten-ID) verwendet --><epa:Key insurant="[OwnerKVNR]" Algorithm="http://www.w3.org/2009/xmlenc11#aes256-gcm"> <!-- im Folgenden steht ein Beispiel für einen Schlüssel --!> RWluQUVTLTI1Ni1TY2hsdWVzc2VsZnVlckFFUy9HQ00=</epa:Key> [<=]
Hinweis: Vergleiche auch [gemSpec_Krypt#A_15705] "Vorgaben Aktenschlüssel (RecordKey) und Kontextschlüssel (ContextKey)".
2.5.1 Verschlüsselung
Mit der Verschlüsselung von RecordKey und ContextKey erfolgt die kryptografische Berechtigung eines Nutzers, in dem diese Schlüssel für den Empfänger verschlüsselt weitergegeben werden.
A_14991 - Schlüsselverschlüsselung gemäß XML Encryption
Das ePA-Fachmodul und das ePA-Frontend des Versicherten MÜSSEN die hybride Verschlüsselung des symmetrischen RecordKey und symmetrischen ContextKey für jede kryptografische Empfängeridentität (SM-B, eGK) jeweils als xenc:EncryptedData gemäß [XMLEnc] vornehmen. Damit ergibt sich folgende, beispielhafte XML-Struktur (hier für EncryptedRecordKey, analog für EncryptedContextKey):<?xml version="1.0" encoding="UTF-8"?><xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Content"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#aes256-gcm"/> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <xenc:EncryptedKey> <xenc:EncryptionMethod Algorithm="..."/> <ds:KeyInfo> <!-- <ds:KeyName> enthält die serialNumber gemäß [RFC5280#4.1.2.2.] des Empfängerzertifikats --> <ds:KeyName>...</ds:KeyName> </ds:KeyInfo> <xenc:CipherData> <!-- <xenc:CipherValue> enthält einen mit dem öffentl. Schlüssel der kartenbasierten, kryptografischen Empfängeridentität verschlüsselten zufälligen symmetrischen Schlüssel--> <xenc:CipherValue>...</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedKey> </ds:KeyInfo> <xenc:CipherData> <!-- <xenc:CipherValue> enthält den mit zufälligem symmetrischen Schlüssel verschlüsselten Aktenschlüssel bzw. Kontextschlüssel --> <xenc:CipherValue>...</xenc:CipherValue> </xenc:CipherData></xenc:EncryptedData>Das ePA-Fachmodul und das ePA-Frontend des Versicherten MÜSSEN die zusätzlichen Elemente von <xenc:EncryptionMethod> und <ds:KeyInfo > entsprechend den Angaben im verwendeten Verschlüsselungszertifikat C.*.ENC des jeweiligen Empfängers befüllen. [<=]
A_15555 - Schlüsselverschlüsselung - Transportinformationen
Das ePA-Fachmodul und das ePA-Frontend des Versicherten MÜSSEN in der XML Encryption-Struktur der verschlüsselten RecordKey und ContextKey die Zertifikatsinformationen des Empfängers als base64-codiertes X.509-Zertifikat in das Element <ds:X509Certificate>...</ds:X509Certificate> einbetten. [<=]
Die Karten der Empfänger von verschlüsseltem Schlüsselmaterial können sich in der Kartengeneration unterscheiden, woraus sich eine Option in der Anwendbarkeit kryptografischer Verfahren ergibt. Das in der Verschlüsselung verwendete kryptografische Verfahren wird in den Metainformationen <xenc:EncryptionMethod> und <ds:KeyInfo > des verschlüsselten Schlüssels transportiert und wird von der Empfängerkarte entsprechend unterstützt. Die Anwendbarkeit für einen Empfänger zeigt sich in der Definition des öffentlichen Schlüssels des Zertifikats der Verschlüsselungsidentität C.*.ENC.
2.5.2 Entschlüsselung
RecordKey und ContextKey, die von der Komponente Autorisierung heruntergeladen werden, müssen vom Empfänger (ePA-Fachmodul oder ePA-Frontend des Versicherten) zur weiteren Verwendung entschlüsselt werden. Aus der XML-Struktur <xenc:EncryptedKey> wird mithilfe des privaten Empfängerschlüssels der SM-B oder eGK der jeweilige Schlüssel als Entschlüsselung des <xenc:CipherValue> in den Klartext überführt.
Die für das kryptografische Verfahren erforderlichen Metainformationen sind in den Elementen <xenc:EncryptionMethod> und <ds:KeyInfo > enthalten, welche gemäß den Festlegungen in [gemSpec_Krypt#Tab_KRYPT_002] und [gemSpec_Krypt#Tab_KRYPT_002a]ausgewählt wurden. Mithilfe dieser Angaben erfolgt die Ansteuerung und Parametrisierung der Empfängerkarte (SM-B oder eGK) für die korrekte Entschlüsselung mittels des privaten Schlüssels auf der Karte.
A_14992 - Entschlüsselung eines Dokuments beim Herunterladen aus der Komponente Autorisierung
Das ePA-Fachmodul und das ePA-Frontend des Versicherten MÜSSEN den asymmetrischen Anteil des je gemäß [XMLEnc] hybrid verschlüsselten ContextKey und RecordKey von der Empfängerkarte entschlüsseln lassen und diese für diesen Zweck gemäß den Metainformationen in <xenc:EncryptionMethod> und <ds:KeyInfo > und Festlegungen in [gemSpec_Krypt#Tab_KRYPT_002] und [gemSpec_Krypt#Tab_KRYPT_002a] für die Entschlüsselung parameterisieren. [<=]
2.6 Ü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 2.1.4.6 ).
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 siehein Abschnitt 2.2).
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.7 Aktenkonfiguration zur Kontoaktivierung
Die Aktenkonfiguration ist ein strukturierter Datensatz, der vom Anbieter des Aktensystems anhand der Auswahl von Optionen und Daten des Versicherten im Rahmen der Kontoinitialisierung erstellt wird. Dieser Datensatz wird für die Aktivierung des Kontos durch den Versicherten in der Umgebung der Leistungserbringer bzw. in der Personal Zone des Versicherten benötigt.
Der Anbieter des Aktensystems stellt diesen in der Komponente Autorisierung zum Abruf durch das Fachmodul ePA oder das ePA-Frontend des Versicherten bereit.
A_15836 - Strukturierung der RecordConfiguration für die Kontoaktivierung
Der Ersteller des strukturierten Datensatzes RecordConfiguration MUSS diesen gemäß der Festlegung des RecordConfigurationType in [AuthorizationService.xsd] strukturieren:
Abbildung 5: Schemadefinition RecordConfiguration
[<=]
3 Anhang A – Verzeichnisse
3.1 Abkürzungen
Kürzel |
Erläuterung |
APPC |
Advanced Patient Privacy Consents |
ATNA |
Audit Trail and Node Authentication Profile |
BPPC |
Basic Patient Privacy Consents |
CDA |
Clinical Document Architecture |
DICOM |
Digital Imaging and Communications in Medicine |
FQDN |
Fully-Qualified Domain Name |
HL7 |
Health Level Seven |
IHE |
Integrating the Healthcare Enterprise |
IHE ITI TF |
IHE IT Infrastructure Technical Framework |
PHR |
Personal Health Record |
PIX |
Patient Identifier Cross-referencing Profile |
RMU |
Restricted Metadata Update Profile |
SAML |
Security Assertion Markup Language |
VAU |
Vertrauenswürdige Ausführungsumgebung |
WS-I |
Web-Services Interoperability Consortium |
XCA |
Cross-Community Access Profile |
XDR |
Cross-Enterprise Document Reliable Interchange Profile |
XDS |
Cross-Enterprise Document Sharing Profile |
XDW |
Cross-Enterprise Document Workflow Profile |
XCDR |
Cross-Community Document Reliable Interchange Profile |
XACML |
eXtensible Access Control Markup Language |
XUA |
Cross-Enterprise User Assertion Profile |
3.2 Glossar
Begriff |
Erläuterung |
Funktionsmerkmal |
Der Begriff beschreibt eine Funktion oder auch einzelne, eine logische Einheit bildende Teilfunktionen der TI im Rahmen der funktionalen Zerlegung des Systems. |
Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.
3.3 Abbildungsverzeichnis
Abbildung 1: Implementierungsstrategie mit zentraler Registry und RepositoryAbbildung 1: Implementierungsstrategie mit zentraler Registry und Repository
Abbildung 2: Überblick über IHE ITI-Akteure und assoziierte TransaktionenAbbildung 2: Überblick über IHE ITI-Akteure und assoziierte Transaktionen
Abbildung 3: XCDR-föderierte Communities mit XCA-ProzessablaufdiagrammAbbildung 3: XCDR-föderierte Communities mit XCA-Prozessablaufdiagramm zum Registrieren und Abrufen von Dokumenten
Abbildung 4: Überblick über Identifikatoren in der ePA-FachanwendungAbbildung 4: Überblick über Identifikatoren in der ePA-Fachanwendung
Abbildung 5: Schemadefinition RecordConfiguration
3.4 Tabellenverzeichnis
Tabelle 1: Tab_DM_100: gematik-spezifische Erweiterung für Werte im Value Set "formatCode"Tabelle 1: Nutzungsvorgaben für XDS-Metadaten bei strukturierten Dokumenten
Tabelle 2: Nutzungsvorgaben für XDS-Metadaten bei strukturierten DokumentenTabelle 2 Tab_DM_110: Erweiterung für Werte im Value Set "authorSpecialty"
Tabelle 3: Tab_DM_110: Erweiterung für Werte im Value Set "authorSpecialty"Tabelle 3: Nutzungsvorgaben für Metadatenattribute XDS.b
Tabelle 4: Tab_DM_111: Erweiterung für Werte im Value Set "practiceSettingCode"Tabelle 4: Nutzungsvorgaben für Metadatenattribute bei Policy Documents
Tabelle 5: Nutzungsvorgaben für Metadatenattribute XDS.bTabelle: 5 Nutzungsvorgaben für die Kennzeichnung von medizinischen Bildern
Tabelle 6: Nutzungsvorgaben für Metadatenattribute bei Policy DocumentsTabelle 6: Logische Objektstruktur des Protokolls nach § 291a SGB V inkl. Verwaltungsprotokoll für PHR:ProtocolEntryType
Tabelle 7: Logische Objektstruktur des Protokolls nach § 291a SGB V inkl. Verwaltungsprotokoll für PHR:ProtocolEntryTypeTabelle 7: Event Codes für Protokollereignisse
Tabelle 8: Event Codes für ProtokollereignisseTabelle 8: Value Set authorRole
Tabelle 9: Value Set authorRoleTabelle 9: Value Set authorSpeciality
Tabelle 10: Value Set authorSpecialityTabelle 10: Value Set classCode
Tabelle 11: Value Set classCodeconfidentialityCode
Tabelle 12: Value Set eventCodeList
Tabelle 13: Value Set healthcareFacilityTypeCodeTabelle 13: Value Set healthcareFacilityTypeCode
Tabelle 14: Value Set practiceSettingCodeTabelle 14: Value Set practiceSettingCode
Tabelle 15: Value Set typeCodeTabelle 15: Value Set typeCode
Tabelle 16: XML-Struktur für Arztbrief nach § 291f SGB VTabelle 16: XML-Struktur für Arztbrief nach § 291f SGB V
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.
[Quelle] |
Herausgeber: Titel |
||
[ |
Schemadefinition für Datentypen der Komponente Autorisierung |
||
[gemGlossar] |
gematik: Einführung der Gesundheitskarte - Glossar |
||
[gemSpec_Aktensystem] |
gematik: Spezifikation Aktensystem ePA |
||
|
|
||
|
|
||
[gemSpec_Autorisierung] |
gematik: Spezifikation Autorisierung ePA |
||
[gemSpec_Dokumentenverwaltung] |
gematik: Dokumentenverwaltung ePA |
||
|
|
||
[gemSpec_Frontend_Vers] |
gematik: Spezifikation ePA-Frontend des Versicherten |
||
[gemSpec_Info_AMTS] |
gematik: Spezifikation Informationsmodell eMP/AMTS-Datenmanagement |
||
[gemSpec_Info_NFDM] |
gematik: Spezifikation Informationsmodell Notfalldaten-Management (NFDM) |
||
|
|
||
[gemSpec_ |
gematik: Spezifikation |
||
|
|
||
[healthcare-security-audit.xsd] |
Schemadefinition für Audit-Eintrag |
||
[PHR_Common.xsd] |
Schemadefinition für Record Identifier und Container für einen Arztbrief nach § 291f SGB V |
||
3.5.2 Weitere Dokumente
[Quelle] |
Herausgeber (Erscheinungsdatum): Titel |
[IHE-ITI-APPC] |
IHE International (2018): IHE IT Infrastructure (ITI) Technical Framework Supplement, Advanced Patient Privacy Consents (APPC), Revision 1.2 – Trial Implementation, |
|
|
[IHE-ITI-TF1] |
IHE International (2018): IHE IT Infrastructure (ITI) Technical Framework, Volume 1 (ITI TF-1) – Integration Profiles, Revision 15.0, |
[IHE-ITI-TF3] |
IHE International (2018): IHE IT Infrastructure (ITI) Technical Framework, Volume 3 (ITI TF-3) – Cross-Transaction Specifications and Content Specifications, Revision 15.0, |
[IHE-ITI-VS] |
IHE Deutschland (2018): Value Sets für Aktenprojekte im deutschen Gesundheitswesen, Implementierungsleitfaden,Version 2.0, |
[IHE-ITI-VS-Live] |
IHE Deutschland ( |
[IHE-ITI-XCDR] |
IHE International (2017): IHE IT Infrastructure (ITI) Technical Framework Supplement, Cross-Community Document Reliable Interchange (XCDR), Revision 1.4 – Trial Implementation, |
[KBV-AB] |
Kassenärztliche Bundesvereinigung (2017): Richtlinie über die Übermittlung elektronischer Briefe in der vertragsärztlichen Versorgung gemäß § 291f SGB V, Richtlinie Elektronischer Brief, Version: 10.0, |
[RFC2119] |
IETF (1997): Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, |
[RFC7061] |
IETF (2013): eXtensible Access Control Markup Language (XACML) XML Media Type, RFC 7061, |
[VHITG_AB] |
VHTIG (2006), Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2 für das Deutsche Gesundheitswesen, Implementierungsleitfaden, Version 1.50, |
[XMLEnc] |
W3C (2013): XML Encryption Syntax and Processing, W3C Recommendation, http://www.w3.org/TR/xmlenc-core1/ |
4 Anhang B – Allgemeine Erläuterungen
4.1 Vorschläge zur verkürzten Ansicht der Auswahl von Werten aus Value Sets
Die in [IHE-ITI-VS] sowie in Abschnitt 2.1.4.1 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_Frontend_Vers] und im Implementierungsleitfaden Primärsysteme ePA [gemILF_PS_ePA] enthalten.
Tabelle 98: Value Set authorRole
Code |
Anzeigename |
|
Arzt |
Zahnarzt |
Krankenhaus |
Apotheke |
Versicherter |
1 |
Einweiser |
|
x |
x |
|
|
x |
2 |
Entlassender |
|
|
x |
|
x |
|
3 |
Überweiser |
x |
x |
|
|
x |
|
4 |
Durchführender |
x |
x |
x |
x |
x |
|
5 |
durchführendes Gerät |
|
|
|
|
|
|
6 |
Betreuer |
|
|
|
|
|
|
7 |
Pflegender |
|
|
|
|
|
|
17 |
Begutachtender |
|
|
|
|
|
|
8 |
Behandler |
x |
x |
x |
|
x |
|
9 |
Erstbehandler außerhalb einer Einrichtung |
x |
x |
|
|
x |
|
10 |
Bereitstellender |
|
|
|
|
|
|
11 |
Dokumentierender |
x |
x |
x |
x |
x |
|
12 |
dokumentierendes Gerät |
|
|
|
|
|
|
13 |
Validierer |
|
|
|
|
|
|
14 |
Gesetzlich Verantwortlicher |
|
|
|
|
|
|
15 |
Beratender |
|
|
|
|
|
|
16 |
Informierender |
|
|
|
|
|
|
101 |
Hausarzt |
|
x |
|
|
|
x |
102 |
Patient |
|
|
|
|
x |
|
103 |
Arbeitgebervertreter |
|
|
|
|
|
|
104 |
Primärbetreuer (langfristig) |
x |
x |
|
x |
x |
|
105 |
Kostenträgervertreter |
|
|
|
|
x |
Tabelle 109: Value Set authorSpeciality
Code |
Anzeigename |
|
Arzt |
Zahnarzt |
Krankenhaus |
Apotheke |
Versicherter |
10 |
FA Allgemeinmedizin |
S_BAR2_WBO |
x |
|
x |
|
x |
20 |
FA Anästhesiologie |
|
|
x |
|
x |
|
30 |
FA Augenheilkunde |
x |
|
x |
|
x |
|
50 |
FA Frauenheilkunde und Geburtshilfe |
x |
|
x |
|
x |
|
60 |
FA Hals-, Nasen-, Ohrenheilkunde |
x |
|
x |
|
x |
|
70 |
FA Haut- und Geschlechtskrankheiten |
x |
|
x |
|
x |
|
80 |
FA Innere Medizin |
x |
|
x |
|
x |
|
91 |
SP Kinderkardiologie |
|
|
|
|
|
|
93 |
SP Neonatologie |
|
|
|
|
|
|
102 |
FA Kinder- und Jugendpsychiatrie und -psychotherapie |
|
|
|
|
|
|
110 |
FA Laboratoriumsmedizin |
x |
x |
x |
|
x |
|
130 |
FA Mund-Kiefer-Gesichts-Chirurgie |
x |
x |
x |
|
x |
|
142 |
FA Neurologie |
x |
|
x |
|
x |
|
147 |
FA Psychiatrie und Psychotherapie |
x |
|
x |
|
x |
|
150 |
FA Neurochirurgie |
x |
|
x |
|
x |
|
170 |
FA Pathologie |
|
|
|
|
|
|
180 |
FA Pharmakologie und Toxikologie |
|
|
|
|
|
|
196 |
SP Kinderradiologie |
|
|
|
|
|
|
197 |
SP Neuroradiologie |
|
|
|
|
|
|
200 |
FA Urologie |
x |
|
|
|
x |
|
210 |
FA Arbeitsmedizin |
|
|
|
|
|
|
220 |
FA Nuklearmedizin |
|
|
|
|
|
|
230 |
FA Öffentliches Gesundheitswesen |
|
x |
|
|
x |
|
240 |
FA Rechtsmedizin |
|
|
|
|
|
|
250 |
FA Hygiene und Umweltmedizin |
|
|
|
|
|
|
271 |
FA Neuropathologie |
|
|
|
|
|
|
281 |
FA Klinische Pharmakologie |
|
|
|
|
|
|
291 |
FA Strahlentherapie |
|
|
|
|
|
|
301 |
FA Anatomie |
|
|
|
|
|
|
302 |
FA Biochemie |
|
|
|
|
|
|
303 |
FA Transfusionsmedizin |
|
|
|
|
|
|
304 |
FA Kinderchirurgie |
x |
|
x |
|
x |
|
308 |
FA Physiologie |
|
|
|
|
|
|
313 |
FA Herzchirurgie |
x |
|
x |
|
x |
|
314 |
FA Humangenetik |
|
|
|
|
|
|
330 |
FA Physikalische und Rehabilitative Medizin |
|
|
|
|
|
|
341 |
FA Kinder-und Jugendmedizin |
x |
|
|
|
x |
|
359 |
Fachzahnarzt für Mikrobiologie |
|
|
|
|
|
|
360 |
Fachzahnarzt für Kieferchirurgie (§ 6 Abs. 1 BMV) |
|
x |
x |
|
x |
|
361 |
Fachzahnarzt für theoretisch-experimentelle Medizin |
|
|
|
|
|
|
511 |
FA Gefäßchirurgie |
|
|
x |
|
x |
|
512 |
FA Orthopädie und Unfallchirurgie |
|
|
x |
|
x |
|
513 |
FA Thoraxchirurgie |
|
|
x |
|
x |
|
514 |
FA Visceralchirurgie |
|
|
x |
|
x |
|
515 |
SP Gynäkologische Onkologie |
|
|
|
|
|
|
516 |
SP Gynäkologische Endokrinologie und Reproduktionsmedizin |
|
|
|
|
|
|
517 |
SP Spezielle Geburtshilfe und Perinatalmedizin |
|
|
|
|
|
|
518 |
FA Sprach-, Stimm- und kindliche Hörstörungen |
|
|
|
|
|
|
521 |
FA Innere Medizin und (SP) Angiologie |
|
|
|
|
|
|
522 |
FA Innere Medizin und (SP) Endokrinologie und Diabetologie |
|
|
|
|
|
|
523 |
FA Innere Medizin und (SP) Gastroenterologie |
|
|
|
|
|
|
524 |
FA Innere Medizin und (SP) Hämatologie und Onkologie |
|
|
|
|
|
|
525 |
FA Innere Medizin und (SP) Kardiologie |
|
|
|
|
|
|
526 |
FA Innere Medizin und (SP) Nephrologie |
|
|
|
|
|
|
527 |
FA Innere Medizin und (SP) Pneumologie |
|
|
|
|
|
|
528 |
FA Innere Medizin und (SP) Rheumatologie |
|
|
|
|
|
|
530 |
SP Kinder-Hämatologie und -Onkologie |
|
|
|
|
|
|
531 |
SP Neuropädiatrie |
|
|
|
|
|
|
532 |
FA Mikrobiologie, Virologie und Infektionsepidemiologie |
|
|
|
|
|
|
533 |
SP Forensische Psychiatrie |
|
|
|
|
|
|
534 |
FA Psychosomatische Medizin und Psychotherapie |
|
|
|
|
|
|
535 |
FA Radiologie (neue (M-)WBO) |
|
|
|
|
|
|
542 |
FA Plastische und Ästhetische Chirurgie |
|
|
x |
|
x |
|
544 |
FA Allgemeinchirurgie |
x |
|
x |
|
x |
|
1 |
Zahnärztin/Zahnarzt |
Qualifikationen zahnärztlicher Autoren |
|
x |
|
|
x |
2 |
FZA |
|
x |
|
|
x |
|
|
FZA |
|
x |
|
|
x |
|
|
FZA |
|
x |
|
|
x |
|
|
FZA |
|
x |
|
|
x |
|
6 |
|
|
x |
|
|
x |
|
|
|
Qualifikationen nicht ärztlicher Autoren |
|
|
|
|
|
|
|
x |
x |
|
|
x |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x |
x |
|
x |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x |
|
x |
|
x |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x |
x |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Tabelle 1110: Value Set classCode
Code |
Anzeigename |
|
Arzt |
Zahnarzt |
Krankenhaus |
Apotheke |
Versicherter |
ADM |
Administratives Dokument |
|
x |
x |
x |
x |
x |
ANF |
Anforderung |
|
|
|
|
|
|
ASM |
Assessment |
|
|
|
|
|
|
BEF |
Befundbericht |
x |
x |
x |
x |
x |
|
BIL |
Bilddaten |
x |
x |
x |
x |
x |
|
BRI |
Brief |
x |
x |
x |
x |
x |
|
DOK |
Dokumente ohne besondere Form (Notizen) |
x |
x |
x |
x |
x |
|
DUR |
Durchführungsprotokoll |
x |
x |
x |
|
x |
|
FOR |
Forschung |
|
|
|
|
|
|
GUT |
Gutachten und Qualitätsmanagement |
|
|
|
|
|
|
LAB |
Laborergebnisse |
x |
x |
x |
x |
x |
|
AUS |
Medizinischer Ausweis |
x |
x |
x |
x |
x |
|
PLA |
Planungsdokument |
x |
x |
x |
x |
x |
|
57016-8 |
Patienteneinverständniserklärung |
Logical Observation Identifier |
x |
x |
x |
x |
x |
VER |
Verordnung |
|
x |
x |
x |
x |
x |
VID |
Videodaten |
x |
x |
x |
x |
x |
Tabelle 11 Value Set confidentialityCode
Code |
Anzeigename |
Code-System |
Arzt |
Zahnarzt |
Krankenhaus |
Apotheke |
Versicherter |
LEI |
Dokument einer Leistungserbringerinstitution |
ePA-Vertraulichkeit |
x |
x |
x |
x |
x |
KTR |
Dokument eines Kostenträgers |
x |
x |
x |
x |
x |
|
PAT |
Dokument eines Versicherten |
x |
x |
x |
x |
x |
|
LEÄ |
Leistungserbringeräquivalentes Dokument eines Versicherten oder Kostenträgers |
x |
x |
x |
x |
x |
|
PV |
gesperrt |
Betroffeneneinschätzung der Vertraulichkeitsstufe |
|
|
|
|
|
PR |
erhöhte |
|
|
|
|
|
|
PN |
übliche |
|
|
|
|
|
|
N |
normal |
Confidentiality |
|
|
|
|
|
R |
restricted |
|
|
|
|
|
|
V |
very restricted |
|
|
|
|
|
Tabelle 12: Value Set eventCodeList
Code |
Anzeigename |
|
Arzt |
Zahnarzt |
Kranken- |
Apotheke |
Versicherter |
|
Workflow offen |
|
|
|
|
|
|
|
Workflow abgeschlossen |
|
|
|
|
|
|
H1 |
vom Patienten mitgebracht |
|
x |
x |
x |
x |
x |
H2 |
noch nicht mit Patient besprochen |
|
|
|
|
|
|
H3 |
eventuell veraltete Daten |
|
|
|
|
|
|
H4 |
vorläufiges Dokument |
|
|
|
|
|
|
E100 |
ambulanter Kontakt |
|
x |
x |
x |
x |
x |
E110 |
ambulante OP |
x |
x |
x |
|
x |
|
E200 |
stationärer Aufenthalt |
|
|
x |
|
x |
|
E210 |
stationäre Aufnahme |
|
|
|
|
|
|
E211 |
Aufnahme vollstationär |
|
|
|
|
|
|
E212 |
Aufnahme/Wiederaufnahme teilstationär |
|
|
|
|
|
|
E213 |
Aufnahme Entbindung stationär |
|
|
|
|
|
|
E214 |
Aufnahme eines Neugeborenen |
|
|
|
|
|
|
E215 |
Aufnahme des Spenders zur Organentnahme |
|
|
|
|
|
|
E230 |
stationäre Entlassung |
|
|
|
|
|
|
E231 |
stationäre Entlassung nach Hause |
|
|
|
|
|
|
E232 |
stationäre Entlassung in eine Rehabilitationseinrichtung |
|
|
|
|
|
|
E233 |
stationäre Entlassung in eine Pflegeeinrichtung/Hospiz |
|
|
|
|
|
|
E234 |
Entlassung zur nachstationären Behandlung |
|
|
|
|
|
|
E235 |
Patient während stationärem Aufenthalt verstorben |
|
|
|
|
|
|
E250 |
stationäre Verlegung |
|
|
|
|
|
|
E251 |
Verlegung innerhalb eines Krankenhauses |
|
|
|
|
|
|
E252 |
Verlegung in ein anderes Krankenhaus |
|
|
|
|
|
|
E253 |
externe Verlegung in Psychiatrie |
|
|
|
|
|
|
E270 |
kurzzeitige Unterbrechung einer stationären Behandlung |
|
|
|
|
|
|
E280 |
Konsil |
x |
x |
x |
|
x |
|
E300 |
Behandlung im häuslichen Umfeld |
x |
x |
|
|
x |
|
E400 |
Virtual Encounter |
x |
x |
x |
|
x |
Tabelle 13: Value Set healthcareFacilityTypeCode
Code |
Anzeigename |
|
Arzt |
Zahnarzt |
Kranken- |
Apotheke |
Versicherter |
APD |
Ambulanter Pflegedienst |
Einrichtungsarten der |
|
|
|
|
x |
APO |
Apotheke |
|
|
|
x |
x |
|
BER |
Ärztlicher Bereitschaftsdienst |
x |
|
|
|
|
|
PRA |
Arztpraxis |
x |
x |
|
|
x |
|
BAA |
Betriebsärztliche Abteilung |
x |
|
|
|
|
|
BHR |
Gesundheitsbehörde |
|
|
|
|
|
|
HEB |
Hebamme/Geburtshaus |
x |
|
x |
|
|
|
HOS |
Hospiz |
|
|
x |
|
x |
|
KHS |
Krankenhaus |
|
|
x |
|
x |
|
MVZ |
Medizinisches Versorgungszentrum |
x |
x |
|
x |
x |
|
HAN |
Medizinisch-technisches Handwerk |
|
|
|
|
|
|
REH |
Medizinische Rehabilitation |
|
|
|
|
|
|
HEI |
Nicht-ärztliche Heilberufs-Praxis |
|
|
|
|
x |
|
PFL |
Pflegeheim |
|
|
|
|
x |
|
RTN |
Rettungsdienst |
|
|
|
|
x |
|
SEL |
Selbsthilfe |
|
|
|
|
|
|
TMZ |
Telemedizinisches Zentrum |
x |
|
|
|
|
|
BIL |
Bildungseinrichtung |
Einrichtungsarten |
|
|
|
|
|
FOR |
Forschungseinrichtung |
|
|
|
|
|
|
GEN |
Gen-Analysedienste |
|
|
|
|
|
|
MDK |
Medizinischer Dienst der Krankenversicherung |
|
|
|
|
x |
|
PAT |
Patient außerhalb der Betreuung |
|
|
|
|
x |
|
SPE |
Spendedienste |
|
|
|
|
|
|
VER |
Versicherungsträger |
|
|
|
|
x |
Tabelle 14: Value Set practiceSettingCode
Code |
Anzeigename |
|
Arzt |
Zahnarzt |
Kranken |
Apotheke |
Versicherter |
ALLG |
Allgemeinmedizin |
|
x |
|
|
|
x |
ANAE |
Anästhesiologie |
x |
x |
x |
|
x |
|
ARBE |
Arbeitsmedizin |
x |
|
|
|
x |
|
AUGE |
Augenheilkunde |
x |
|
x |
|
x |
|
CHIR |
Chirurgie |
x |
|
x |
|
x |
|
ALCH |
Allgemeinchirurgie |
|
|
|
|
|
|
GFCH |
Gefäßchirurgie |
|
|
|
|
|
|
HZCH |
Herzchirurgie |
|
|
|
|
|
|
KDCH |
Kinderchirurgie |
|
|
|
|
|
|
ORTH |
Orthopädie |
|
|
|
|
|
|
PLCH |
Plastische und Ästhetische Chirurgie |
|
|
|
|
|
|
THCH |
Thoraxchirurgie |
|
|
|
|
|
|
UNFC |
Unfallchirurgie |
|
|
|
|
|
|
VICH |
Viszeralchirurgie |
|
|
|
|
|
|
FRAU |
Frauenheilkunde und Geburtshilfe |
x |
|
x |
|
x |
|
GEND |
Gynäkologische Endokrinologie und Reproduktionsmedizin |
|
|
|
|
|
|
GONK |
Gynäkologische Onkologie |
|
|
|
|
|
|
PERI |
Perinatalmedizin |
|
|
|
|
|
|
GERI |
Geriatrie |
x |
|
x |
|
x |
|
HNOH |
Hals-Nasen-Ohrenheilkunde |
x |
|
x |
|
x |
|
HRST |
Sprach-, Stimm- und kindliche Hörstörungen |
|
|
|
|
|
|
HAUT |
Haut- und Geschlechtskrankheiten |
x |
|
x |
|
x |
|
HUMA |
Humangenetik |
x |
|
x |
|
x |
|
HYGI |
Hygiene und Umweltmedizin |
x |
|
x |
|
x |
|
INNE |
Innere Medizin |
x |
|
x |
|
x |
|
ANGI |
Angiologie |
|
|
|
|
|
|
ENDO |
Endokrinologie und Diabetologie |
|
|
|
|
|
|
GAST |
Gastroenterologie |
|
|
|
|
|
|
HAEM |
Hämatologie und internistische Onkologie |
|
|
|
|
|
|
KARD |
Kardiologie |
|
|
|
|
|
|
NEPH |
Nephrologie |
|
|
|
|
|
|
PNEU |
Pneumologie |
|
|
|
|
|
|
RHEU |
Rheumatologie |
|
|
|
|
|
|
INTM |
Intensivmedizin |
x |
|
x |
|
x |
|
INTO |
Interdisziplinäre Onkologie |
x |
|
x |
|
x |
|
INTS |
Interdisziplinäre Schmerzmedizin |
x |
|
x |
|
x |
|
KIJU |
Kinder- und Jugendmedizin |
x |
|
x |
|
x |
|
KONK |
Kinder-Hämatologie und -Onkologie |
|
|
|
|
|
|
KKAR |
Kinder-Kardiologie |
|
|
|
|
|
|
NNAT |
Neonatologie |
|
|
|
|
|
|
NPAE |
Neuropädiatrie |
|
|
|
|
|
|
KPSY |
Kinder- und Jugendpsychiatrie und -psychotherapie |
x |
|
x |
|
x |
|
LABO |
Laboratoriumsmedizin |
x |
x |
x |
|
x |
|
MIKR |
Mikrobiologie, Virologie und Infektionsepidemiologie |
x |
|
x |
|
x |
|
MKGC |
Mund-Kiefer-Gesichtschirurgie |
x |
x |
x |
|
x |
|
NATU |
Naturheilverfahren und alternative Heilmethoden |
x |
|
x |
|
x |
|
NOTF |
Notfallmedizin |
x |
x |
x |
|
x |
|
NRCH |
Neurochirurgie |
x |
|
x |
|
x |
|
NEUR |
Neurologie |
x |
|
x |
|
x |
|
NUKL |
Nuklearmedizin |
x |
|
x |
|
x |
|
GESU |
Öffentliches Gesundheitswesen |
x |
x |
x |
x |
x |
|
PALL |
Palliativmedizin |
x |
|
x |
|
x |
|
PATH |
Pathologie |
x |
|
x |
|
x |
|
NPAT |
Neuropathologie |
|
|
|
|
|
|
PHAR |
Pharmakologie |
x |
x |
x |
x |
x |
|
TOXI |
Toxikologie |
|
|
|
|
|
|
REHA |
Physikalische und Rehabilitative Medizin |
x |
|
x |
|
x |
|
PSYC |
Psychiatrie und Psychotherapie |
x |
|
x |
|
x |
|
FPSY |
Forensische Psychiatrie |
|
|
|
|
|
|
PSYM |
Psychosomatische Medizin und Psychotherapie |
x |
|
x |
|
x |
|
RADI |
Radiologie |
x |
|
x |
|
x |
|
KRAD |
Kinderradiologie |
|
|
|
|
|
|
NRAD |
Neuroradiologie |
|
|
|
|
|
|
RECH |
Rechtsmedizin |
x |
x |
x |
|
x |
|
SCHL |
Schlafmedizin |
x |
|
x |
|
x |
|
SPOR |
Sport- und Bewegungsmedizin |
x |
|
x |
|
x |
|
STRA |
Strahlentherapie |
x |
|
x |
|
x |
|
TRAN |
Transfusionsmedizin |
x |
|
x |
|
x |
|
TROP |
Tropen-/Reisemedizin |
x |
|
x |
|
x |
|
UROL |
Urologie |
x |
|
x |
|
x |
|
MZKH |
Zahnmedizin |
|
x |
x |
|
x |
|
ORAL |
Oralchirurgie |
|
x |
x |
|
x |
|
KIEF |
Kieferorthopädie |
|
x |
|
|
x |
|
MZAH |
Allgemeine Zahnheilkunde |
Zahnärztliche Fachrichtungen |
|
x |
|
|
x |
|
|
|
|
x |
|
|
x |
|
|
|
|
|
|
|
x |
|
|
|
|
|
x |
|
x |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x |
|
|
|
|
|
|
x |
x |
|
|
|
|
|
|
|
x |
|
|
|
|
|
|
|
x |
|
|
|
|
|
|
|
x |
|
|
|
|
|
|
|
x |
|
|
|
|
|
|
|
x |
|
|
|
|
|
|
|
x |
Tabelle 15: Value Set typeCode
Code |
Anzeigename |
|
Arzt |
Zahnarzt |
Kranken- |
Apotheke |
Versicherter |
ABRE |
Abrechnungsdokumente |
|
x |
x |
x |
x |
x |
ADCH |
Administrative Checklisten |
|
|
x |
|
x |
|
ANTR |
Anträge und deren Bescheide |
x |
x |
x |
x |
x |
|
ANAE |
Anästhesiedokumente |
x |
x |
x |
|
x |
|
BERI |
Arztberichte |
x |
x |
x |
|
x |
|
BESC |
Ärztliche Bescheinigungen |
x |
x |
x |
x |
x |
|
BEFU |
Ergebnisse Diagnostik |
x |
x |
x |
|
x |
|
BSTR |
Bestrahlungsdokumentation |
|
|
x |
|
x |
|
AUFN |
Einweisungs- und Aufnahmedokumente |
|
|
x |
|
x |
|
EINW |
Einwilligungen/Aufklärungen |
x |
x |
x |
x |
x |
|
FUNK |
Ergebnisse Funktionsdiagnostik |
x |
|
x |
|
x |
|
BILD |
Ergebnisse bildgebender Diagnostik |
x |
x |
x |
x |
x |
|
FALL |
Fallbesprechungen |
x |
x |
x |
|
x |
|
FOTO |
Fotodokumentation |
x |
x |
x |
|
x |
|
FPRO |
Therapiedokumentation |
x |
x |
x |
|
x |
|
IMMU |
Ergebnisse Immunologie |
x |
|
x |
|
x |
|
INTS |
Intensivmedizinische Dokumente |
x |
|
x |
|
x |
|
KOMP |
Komplexbehandlungsbögen |
x |
|
x |
|
x |
|
MEDI |
Medikamentöse Therapien |
x |
x |
x |
x |
x |
|
MKRO |
Ergebnisse Mikrobiologie |
x |
x |
x |
x |
x |
|
OPDK |
OP-Dokumente |
x |
x |
x |
|
x |
|
ONKO |
Onkologische Dokumente |
x |
|
x |
|
x |
|
PATH |
Pathologiebefundberichte |
x |
|
x |
|
x |
|
PATD |
Patienteneigene Dokumente |
|
|
|
|
x |
|
PATI |
Patienteninformationen |
x |
x |
x |
x |
x |
|
PFLG |
Pflegedokumentation |
x |
|
x |
|
x |
|
57016-8 |
Patienteneinverständniserklärung |
Logical Observation |
|
|
|
|
x |
QUAL |
Qualitätssicherung |
|
x |
x |
x |
x |
x |
RETT |
Rettungsdienstliche Dokumente |
x |
|
x |
|
x |
|
SCHR |
Schriftwechsel (administrativ) |
x |
x |
x |
x |
x |
|
GEBU |
Schwangerschafts- und Geburtsdokumentation |
x |
|
x |
|
x |
|
SOZI |
Sozialdienstdokumente |
|
|
|
|
x |
|
STUD |
Studiendokumente |
x |
x |
x |
x |
x |
|
TRFU |
Transfusionsdokumente |
x |
x |
x |
|
x |
|
TRPL |
Transplantationsdokumente |
x |
x |
x |
|
x |
|
VERO |
Verordnungen |
x |
x |
x |
x |
x |
|
VERT |
Verträge |
x |
x |
x |
|
|
|
VIRO |
Ergebnisse Virologie |
x |
x |
x |
|
x |
|
WUND |
Wunddokumentation |
x |
x |
|
|
|
Für das Value Set "languageCode" wird keine Auswahlmöglichkeit vorgeschlagen, da dieses Value Set nur wenige Codes enthält. Es können somit alle verfügbaren Codes angezeigt werden.
4.2 Container-Struktur für einen Arztbrief
Die folgende XML-Struktur für einen Container mit Arztbrief nach § 291f SGB V wird festgelegt (vgl. [PHR_Common.xsd]):
Tabelle 16: XML-Struktur für Arztbrief nach § 291f SGB V
Element-, Attribut- oder Textknoten |
Opt. |
Nutzungsvorgabe |
||
DischargeLetterContainer |
R |
|
||
|
R |
Base64-kodierter Arztbrief in PDF-Repräsentation gemäß [KBV-AB] |
||
|
CDA |
R |
|
|
|
|
@level |
O |
Der Wert "1", "2" oder "3" MUSS gesetzt werden, um den CDA-Level des Dokuments zu kennzeichnen. |
|
|
text() |
R |
Base64-kodierter Arztbrief in CDA-Repräsentation gemäß [VHITG_AB] |