ILF:ENDS 2
 |
Dieses Dokument gibt wieder:
Implementierungsleitfaden Leitfaden Export-Normdatensatz (1.0.0+20210601), OID: 1.2.40.0.34.7.25.1, Datum: 01.06.2021, Status: Normativ. Die Teilmaterialien gehören der Kategorie elga-ends an. |
CDA Implementierungsleitfäden
HL7 Implementation Guide for CDA® R2:
Export-Normdatensatz 2
Export-Normdatensatz 2
Zur Anwendung im österreichischen
Gesundheitswesen [1.2.40.0.34.7.25.1]
Gesundheitswesen [1.2.40.0.34.7.25.1]
01.06.2021
1.0.0+20210601
Normativ
Inhaltsverzeichnis
- 1 Zusammenfassung
- 2 Informationen über dieses Dokument
- 3 Einleitung
- 4 Harmonisierung
- 5 Anwendungsfälle
- 6 Technischer Hintergrund
- 7 Spezifikationen abseits von CDA
- 8 Dokumenten Spezifikation
- 8.1 Dokumenten Ebene
- 8.2 Administrative Daten (CDA Header)
- 8.2.1 Document Realm
- 8.2.2 Document TypeId
- 8.2.3 Document TerminologyDate
- 8.2.4 Document PracticeSettingCode
- 8.2.5 Document Effective Time
- 8.2.6 Document Confidentiality Code
- 8.2.7 Document Language
- 8.2.8 Document Set Id and Version Number
- 8.2.9 Record Target
- 8.2.10 Author
- 8.2.11 Custodian
- 8.2.12 Information Recipient
- 8.2.13 Legal Authenticator
- 8.2.14 Authenticator
- 8.2.15 Participant Fachlicher Ansprechpartner
- 8.2.16 Participant Hausarzt
- 8.2.17 Participant Auskunftsberechtigte Person (Notfallkontakt)
- 8.2.18 Participant Angehoerige
- 8.2.19 Participant Versicherung
- 8.2.20 Participant Betreuungsorganisation
- 8.2.21 Participant Weitere Behandler
- 8.2.22 Component Of - Encompassing Encounter
- 8.2.23 Encounter Location
- 8.2.24 AssignedEntityElements
- 8.2.25 PersonElements
- 8.2.26 OrganizationElements
- 8.2.27 Laboratory Performer 2
- 8.2.28 AuthorElements
- 8.3 Fachlicher Inhalte (CDA Body)
- 8.3.1 Section-Templates Übersicht
- 8.3.1.1 Weitere Patienteninformation - Administrativ
- 8.3.1.2 Weitere Patienteninformation - Medizinisch
- 8.3.1.3 Vitalparameter - kodiert
- 8.3.1.4 Übersetzung
- 8.3.1.5 Weitere Merkmale
- 8.3.1.6 EXNDS Cave - kodiert
- 8.3.1.7 Diagnose - kodiert
- 8.3.1.8 EXNDS Familienanamnese
- 8.3.1.9 EXNDS Behandlungsschein
- 8.3.1.10 EXNDS Behandlungen
- 8.3.1.11 EXNDS Karteineintragungen
- 8.3.1.12 EXNDS Laborparameter
- 8.3.1.13 EXNDS Speciality-Section Container
- 8.3.1.14 Speciality-Section
- 8.3.1.15 EXNDS Verordnungen
- 8.3.1.16 Impfungen - kodiert
- 8.3.1.17 Impfempfehlungen - kodiert
- 8.3.1.18 EXNDS Befund
- 8.3.1.19 EXNDS eCard Konsultationsdaten
- 8.3.1.20 EXNDS ABS-Daten
- 8.3.1.21 EXNDS Attachments
- 8.3.1.22 EXNDS Krankenstand
- 8.3.2 Entry-templates
- 8.3.2.1 Weitere Patienteninformation Administrativ
- 8.3.2.2 EXNDS Patient Versichertenkategorie Entry
- 8.3.2.3 EXNDS Patient Beruf Entry
- 8.3.2.4 EXNDS Patient Rezeptgebührenbefreit Entry
- 8.3.2.5 EXNDS Patient Entfernung Entry
- 8.3.2.6 EXNDS Patient Bundesland Code Entry
- 8.3.2.7 EXNDS Patient Erstzuweiser Entry
- 8.3.2.8 EXNDS Patient Weitere Merkmale
- 8.3.2.9 Vitalparameter Gruppe Entry
- 8.3.2.10 Vitalparameter Entry
- 8.3.2.11 Serienmessung Vitalparameter Entry
- 8.3.2.12 Serienmessungs-Gruppe Entry
- 8.3.2.13 Serienmessungs-Werte Entry
- 8.3.2.14 Serienmessungs-Periode Entry
- 8.3.2.15 Eingebettetes Objekt Entry
- 8.3.2.16 Weitere Patienteninformation Medizinisch
- 8.3.2.17 EXNDS Patient Blutgruppe Entry
- 8.3.2.18 EXNDS Rhesusfaktor Entry
- 8.3.2.19 EXNDS Patient Besondere Kennzeichen Entry
- 8.3.2.20 EXNDS CaveInformation Entry
- 8.3.2.21 Problem Concern Entry
- 8.3.2.22 Problem Entry
- 8.3.2.23 Laterality Qualifier
- 8.3.2.24 Comment Entry
- 8.3.2.25 Severity Observation
- 8.3.2.26 Certainty Observation
- 8.3.2.27 Problem Status Observation
- 8.3.2.28 External Document Entry
- 8.3.2.29 EXNDS Familienanamnese Problem Concern Entry
- 8.3.2.30 EXNDS Behandlungsschein Act
- 8.3.2.31 EXNDS Zuweiser Body
- 8.3.2.32 EXNDS Dienstgeber
- 8.3.2.33 EXNDS Grund für Behandlungsschein
- 8.3.2.34 EXNDS Saldo
- 8.3.2.35 EXNDS Fremdstaatenkennzeichen
- 8.3.2.36 EXNDS Behandlungen Organizer
- 8.3.2.37 EXNDS Behandlung
- 8.3.2.38 EXNDS Menge Therapie
- 8.3.2.39 EXNDS Kassenleistung
- 8.3.2.40 EXNDS Therapie
- 8.3.2.41 EXNDS Tarif Act
- 8.3.2.42 EXNDS Regiezuschlag
- 8.3.2.43 EXNDS Abrechnungskennzeichen
- 8.3.2.44 EXNDS Chefarztkennzeichen
- 8.3.2.45 EXNDS Visiteninformation
- 8.3.2.46 EXNDS Visitenadresse
- 8.3.2.47 EXNDS Visitenkilometer
- 8.3.2.48 EXNDS Tarif Menge
- 8.3.2.49 EXNDS Tarif Zusatzkennzeichen
- 8.3.2.50 EXNDS Karteieintragungen Organizer
- 8.3.2.51 EXNDS Karteineintrag
- 8.3.2.52 ELGA Spezimen-Act-Entry Allgemein
- 8.3.2.53 Abnahmeinformationen (Specimen Collection)
- 8.3.2.54 Annahmeinformationen (Specimen Received)
- 8.3.2.55 Befundtext (Anmerkungen und Kommentare)
- 8.3.2.56 Befundgruppen (Laboratory Battery Organizer)
- 8.3.2.57 Laborergebnisse (Laboratory Observation)
- 8.3.2.58 Laborergebnisse aktiv (Laboratory Observation Active)
- 8.3.2.59 Eingebettetes Objekt Entry
- 8.3.2.60 Kultureller Keimnachweis (Laboratory Isolate Organzier)
- 8.3.2.61 Antibiogram (Laboratory Isolate Organzier)
- 8.3.2.62 Medikation Verordnung Entry eMedikation
- 8.3.2.63 Sbadm TemplateId Options
- 8.3.2.64 Einnahmedauer
- 8.3.2.65 Dosierungsvariante 1: Tagesdosierung effectiveTime
- 8.3.2.66 Dosierungsvariante 2: Einzeldosierung
- 8.3.2.67 Dosierungsvariante 3: Tagesdosierung mit Einnahmepause
- 8.3.2.68 Dosierungsvariante 4: Einzeldosierung mit Einnahmepause
- 8.3.2.69 Dosierungsvariante 1: Tagesdosierung doseQuantity
- 8.3.2.70 Dosierungsvariante 2: Einzeldosierung doseQuantity
- 8.3.2.71 Dosierungsvariante 3: Tagesdosierung mit Einnahmepause doseQuantity
- 8.3.2.72 Dosierungsvariante 4: Einzeldosierung mit Einnahmepause doseQuantity
- 8.3.2.73 Arznei Entry
- 8.3.2.74 Dosierungsvariante 2: Einzeldosierung entryRelationship
- 8.3.2.75 Splitdose-Einnahmezeitpunkte 1
- 8.3.2.76 Dosierungsvariante 4: Einzeldosierung mit Einnahmepause entryRelationship
- 8.3.2.77 Splitdose-Einnahmezeitpunkte 2
- 8.3.2.78 Patient Instructions
- 8.3.2.79 Pharmacist Instructions
- 8.3.2.80 Therapieart
- 8.3.2.81 ID des Containers
- 8.3.2.82 Laboratory Observation Entry
- 8.3.2.83 EXNDS Arzneimittel-Organizer
- 8.3.2.84 EXNDS Preis Arzneimittel TAX
- 8.3.2.85 EXNDS Preis Mehrwertsteuersatz
- 8.3.2.86 EXNDS Preis Arzneimittel Apotheke
- 8.3.2.87 EXNDS Arzneimittel Packungsart
- 8.3.2.88 EXNDS Laboratory Battery Organizer
- 8.3.2.89 EXNDS Magistralzubereitung-Organizer
- 8.3.2.90 EXNDS Arzneimittel Magistraler Bestandteil
- 8.3.2.91 EXNDS Arzneimittel Bezahlt
- 8.3.2.92 EXNDS Arzneimittel Rezeptgebührenbefreit
- 8.3.2.93 Immunization Entry
- 8.3.2.94 Immunization Target Entry
- 8.3.2.95 Immunization Billability Entry
- 8.3.2.96 Immunization Schedule Entry
- 8.3.2.97 Immunization Entry Impfung nicht angegeben
- 8.3.2.98 Immunization Recommendation Entry
- 8.3.2.99 Impfplan Entry
- 8.3.2.100 EXNDS Befund Act
- 8.3.2.101 EXNDS ExternalDocument
- 8.3.2.102 EXNDS eCardKonsDatenAct
- 8.3.2.103 EXNDS ExternalAct
- 8.3.2.104 EXNDS ABS-Daten Act
- 8.3.2.105 EXNDS Attachment Act
- 8.3.2.106 EXNDS Befunderstellungsdatum
- 8.3.2.107 EXNDS Krankenstand Act
- 8.3.2.108 EXNDS Krankenstand Grund
- 8.3.2.109 EXNDS Krankenstand voraussichtliches Ende
- 8.3.3 Compilations und allgemeine Body Templates
- 8.3.3.1 Address Compilation
- 8.3.3.2 Person Name Compilation G2 M
- 8.3.3.3 Person Name Compilation G1 M
- 8.3.3.4 Organization Name Compilation
- 8.3.3.5 Address Compilation Minimal
- 8.3.3.6 Device Compilation
- 8.3.3.7 Organization Compilation with id, name
- 8.3.3.8 Assigned Entity
- 8.3.3.9 Organization Compilation with name
- 8.3.3.10 Time Interval Information minimal
- 8.3.3.11 Original Text Reference
- 8.3.3.12 Author Body
- 8.3.3.13 Person Name Compilation G2
- 8.3.3.14 Informant Body
- 8.3.3.15 Assigned Entity Body
- 8.3.3.16 Organization Compilation with name, addr minimal
- 8.3.3.17 Performer Body
- 8.3.3.18 Participant Body
- 8.3.3.19 Narrative Text Reference
- 8.3.3.20 EXNDS Familienanamnese Subject
- 8.3.3.21 Vaccine Product
- 8.3.3.22 Vaccine Product nicht angegeben
- 8.3.3.23 Performer Body - Impfende Person
- 8.3.3.24 Author Body - eImpfpass
- 8.3.3.25 Participant Body - Transcriber
- 8.3.1 Section-Templates Übersicht
- 9 Liste der verwendeten Terminologien
- 10 Abkürzungsverzeichnis
1 Zusammenfassung
Der gegenständliche Implementierungsleitfaden beschreibt und spezifiziert die Dokumentenstruktur als auch das Export-Format im Allgemeinen, welches für den österreichischen Exportnormdatensatz angewendet werden soll. Ziel ist es ein gemeinsames Format zu definieren welches es den Ärzten erlaubt die Informationen im Arztpraxisinformationssystem im Rahmen einer
- Patientenauskunft,
- eines anstehenden Wechsels des Arztpraxisinformationssystems, oder
- zum Zwecke der Archivierung der Patientendaten nach Ende der ärztlichen Tätigkeit,
zu exportieren. Das Export-Format basiert auf dem IHE Profil XDM. Dieses Profil definiert eine Ordnerstruktur als auch die notwendigen Dateien für die Abspeicherung der Metadaten (maschinen- als auch menschenlesbar). Hinsichtlich der Dateiformate, welche für die Kommunikation der weiteren Informationen (medizinische Daten, Personendaten, Terminologien, etc.) ist dieses IHE Profil agnostisch. Somit wird im gegenständlichen Leitfaden festgehalten welche Dateiformate (HL7 CDA, IHE SVS, JSON, etc.) für die zu exportierenden Arztpraxissystemdaten genutzt werden soll. Die Harmonisierung und die Ergebnisse in Form dieses Leitfadens basierend auf Projektworkshops, zu denen die österreichische Ärztekammer geladen hat. Als Basis für die Spezifikationsarbeiten diente der bestehende Export-NormDatenSatz der österreichischen Ärztekammer in Version IX, Stand 6.5.2008.
Auf der Diskussionsseite werden die Fehler und Änderungswünsche an dieser Version dokumentiert.
Hier kommen Sie zu der Section-Templates Übersicht
2 Informationen über dieses Dokument
2.1 Haftungsausschluss
Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht und über ein öffentliches Kommentierungsverfahren kontrolliert. Die Nutzung des vorliegenden Leitfadens erfolgt in ausschließlicher Verantwortung der Anwender. Aus der Verwendung des vorliegenden Leitfadens können keinerlei Rechtsansprüche gegen die Autoren, Herausgeber oder Mitwirkenden erhoben und/oder abgeleitet werden. Ein allfälliger Widerspruch zum geltenden Recht ist jedenfalls nicht beabsichtigt und von den Erstellern des Dokumentes nicht gewünscht.
2.2 Sprachliche Gleichbehandlung
Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer, Frauen und andere Geschlechtsidentitäten in gleicher Weise. Unter dem Begriff "Patient" werden sowohl Bürger, Kunden und Klienten zusammengefasst, welche an einem Behandlungs- oder Pflegeprozess teilnehmen als auch gesunde Bürger, die derzeit nicht an einem solchen teilnehmen. Es wird ebenso darauf hingewiesen, dass umgekehrt der Begriff Bürger auch Patienten, Kunden und Klienten mit einbezieht.
2.3 Lizenzinformationen
Die von HL7 Austria erarbeiteten Standards und die Bearbeitungen der Standards von HL7 International stellen Werke im Sinne des österreichischen Urheberrechtsgesetzes dar und unterliegen daher urheberrechtlichem Schutz.
HL7 Austria genehmigt die Verwendung dieser Standards für die Zwecke der Erstellung, des Verkaufs und des Betriebs von Computerprogrammen, sofern nicht anders angegeben oder sich die Standards auf andere urheberrechtlich oder lizenzrechtlich geschützte Werke beziehen.
Die vollständige oder teilweise Veröffentlichung der Standards (zum Beispiel in Spezifikationen, Publikationen oder Schulungsunterlagen) ist nur mit einer ausdrücklichen Genehmigung der HL7 Austria gestattet. Mitglieder von HL7 Austria sind berechtigt, die Standards vollständig oder in Auszügen ausschließlich organisationsintern zu publizieren, zu vervielfältigen oder zu verteilen. Die Veröffentlichung eigener Anpassungen der HL7-Spezifikationen (im Sinne von Lokalisierungen) oder eigener Leitfäden erfordert eine formale Vereinbarung mit der HL7 Austria.
HL7® und CDA® sind die eingetragenen Marken von Health Level Seven International. Die vollständigen Lizenzinformationen finden sich unter https://hl7.at/nutzungsbedingungen-und-lizenzinformationen/. Die Lizenzbedingungen von HL7 International finden sich unter http://www.HL7.org/legal/ippolicy.cfm
2.3.1 Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")
Third Party Intellectual Property
Der Nutzer dieses Dokuments (bzw. der Lizenznehmer) stimmt zu und erkennt an, dass HL7 Austria nicht alle Rechte und Ansprüche in und an den Materialien besitzt und dass die Materialien geistiges Eigentum von Dritten enthalten und / oder darauf verweisen können ("Third Party Intellectual Property (IP)").
Die Anerkennung dieser Lizenzbestimmungen gewährt dem Lizenznehmer keine Rechte in Bezug auf Third Party IP. Der Lizenznehmer allein ist für die Identifizierung und den Erhalt von notwendigen Lizenzen oder Genehmigungen zur Nutzung von Third Party IP im Zusammenhang mit den Materialien oder anderweitig verantwortlich.
Jegliche Handlungen, Ansprüche oder Klagen eines Dritten, die sich aus einer Verletzung eines Third Party IP-Rechts durch den Lizenznehmer ergeben, bleiben die Haftung des Lizenznehmers.
2.3.2 SNOMED CT
Dieser Leitfaden enthält Material, das durch SNOMED International urheberrechtlich geschützt ist. Jede Verwendung von SNOMED CT in Österreich erfordert eine aufrechte Affiliate Lizenz oder eine Sublizenz. Die entsprechende Lizenz ist kostenlos, vorausgesetzt die Verwendung findet nur in Österreich statt und erfüllt die Bedingungen des Affiliate License Agreements. Affiliate Lizenzen können über das Member Licensing and Distribution Service (MLDS) direkt beim jeweiligen NRC beantragt werden: MLDS für Österreich.
2.3.3 Weitere Terminologien
Im Folgenden finden Sie eine nicht-exhaustive Liste von weiteren Terminologien, die eine solche separate Lizenz erfordern können:
| Terminologie | Eigentümer, Kontaktinformation |
|---|---|
| Logical Observation Identifiers Names & Codes (LOINC) [1] | Regenstrief Institute, Inc. [2] |
| Unified Code for Units of Measure (UCUM) [3] | Regenstrief Institute, Inc. [2] |
| International Classification of Diseases (ICD) [4] | World Health Organization (WHO) [5] |
| ICD-10 BM*G*[6] | Für Gesundheit zuständiges Bundesministerium www.sozialministerium.at |
| Anatomical Therapeutic Chemical Classification System (ATC) [7] | World Health Organization (WHO)[5] |
| Pharmazentralnummer (PZN) | ARGE Pharma im Fachverband der chemischen Industrie Österreichs (FCIO) der Wirtschaftskammern Österreichs (WKO) [8] |
| EDQM-Codes | Europäisches Direktorat für die Qualität von Arzneimitteln [9] |
| Medical Device Communications (MDC) vom ISO/IEEE 11073 Standard | MDC wird als Substandard 10101 "Nomenclature" in "Health informatics - Medical / health device communication standards", kurz 11073, geführt und werden mit einem Copyright bei IEEE SA am österreichischen Termserver bereitgestellt. [10], [11] |
Die Terminologien werden am österreichischen Terminologieserver zur Verfügung gestellt.
2.4 Verwendete Grundlagen und Bezug zu anderen Standards
Grundlage dieses Implementierungsleitfadens ist der internationale Standard "HL7 Clinical Document Architecture, Release 2.0" (CDA ©), für die das Copyright © von Health Level Seven International[12] gilt. 2009 wurde die Release 2.0 als ISO-Standard ISO/HL7 27932:2009 publiziert[13].
CDA definiert die Struktur und Semantik von "medizinischen Dokumenten" zum Austausch zwischen Gesundheitsdiensteanbietern und Patienten. Es enthält alle Metadaten zur Weiterverarbeitung und einen lesbaren textuellen Inhalt und kann diese Informationen auch maschinenlesbar tragen. Das Datenmodell von CDA und seine Abbildung in XML[14] folgen dem Basisstandard HL7 Version 3[15] mit seinem Referenz-Informationsmodell (RIM). Dieser Leitfaden verwendet das HL7-Template-Austauschformat zur Definition der "Bausteine" (Templates) und ART-DECOR® [16] als Spezifikationsplattform.
- HL7 Clinical Document Architecture (CDA) [17]
- HL7 Referenz-Informationsmodell (RIM)[18]
- HL7 V3 Datentypen [19]
- HL7 Template-Austauschformat Specification and Use of Reusable Information Constraint Templates, Release 1[20]
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)[21], die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden (www.HL7.at). Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
2.5 Bedienungshinweise
Nutzen Sie die bereitgestellten Links im Dokument (z.B. im Inhaltsverzeichnis), um direkt in der PDF-Version dieses Dokuments zu navigieren. Folgende Tastenkombinationen können Ihnen die Nutzung des Leitfadens erleichtern:
- Rücksprung: Alt + Pfeil links und Retour: Alt + Pfeil rechts
- Seitenweise blättern: "Bild" Tasten
- Scrollen: Pfeil nach oben bzw. unten
- Zoomen: Strg + Mouserad drehen
- Suchen im Dokument: Strg + F
3 Einleitung
3.1 Ausgangslage und Motivation
Die Daten welche Ärzte in ihren Arztpraxisinformationssystemen generieren, sind in den Datenformaten und Strukturen des jeweiligen Arztpraxisinformationssystems in Datenbanken abgelegt. Diese Datenformate und Strukturen, welche von einem Arztsoftwarehersteller Anwendung finden, entsprechen im Regelfall nicht den Formaten und Strukturen eines anderen Arztsoftwareherstellers. Möchte nun ein Arzt sein bestehendes Arztpraxisinformationssystem gegen ein anderes tauschen besteht die Notwendigkeit die historischen Daten aus dem Altsystem in das neue System zu migrieren. Ein gemeinsames Exportformat (für Export und anschließenden Import) wäre wünschenswert. Hierzu gibt es die Definition eines Exportdatensets der österreichischen Ärztekammer, in welchem die häufigsten Datenarten und deren Qualität (Datentyp, Codeliste) definiert sind. Die letzten Jahre haben gezeigt, dass diese Spezifikation nicht mehr zeitgemäß ist und daher ein neuer Exportnormdatensatz spezifiziert werden müsste. Unter Berücksichtigung der gegenwärtigen Arbeiten im Rahmen der ELGA an HL7 CDA Dokumenten, sollte der neue Exportnormdatensatz ebenfalls auf HL7 CDA basieren. Dies soll es den Arztsoftwareherstellern ermöglichen strukturelle bzw. funktionale Inhalten, welche für ELGA schon umzusetzen sind/waren auch im Kontext des Exportnormdatensatzes wieder zu verwenden.
4 Harmonisierung
4.1 Autoren
Das Redaktionsteam bestand aus folgenden Personen:
| Name | Organisation | Rolle |
|---|---|---|
| FH-Prof. Matthias Frohner PhD, MSc | Fachhochschule Technikum Wien | Autor |
| FH-Prof. DI Dr. Stefan Sauermann | Fachhochschule Technikum Wien | Moderation |
| Nikolaus Krondraf, BSc | Technikum Wien GmbH | Autor |
| Mag. Dr. Stefan Sabutsch | ELGA GmbH, HL7 Austria | Moderation |
4.2 Mitwirkende
Teilnehmer der Arbeitsgruppe ENDS21: Baumgartner Michael, Bayer Dietmar, Beiglböck Friedrich, Brieger Jens, Burkhard Walla, Determann Claudius, Gal Güter, Hagenbichler Edgar, Heuschmann David, Kelin Johannes, Keplinger Martin, Keprt Berhard, Klein Dominik, Klemen Silke, Kornfeil Harald Kristoffer, Kornfeind Milan, Kressnik Paul, Loidl Herwig, Marvillo Adnam, Michalek Susane, Moussa Amir, Muigg Domenik, Nicolics Jan, Nöhammer Michael, Petzer Christian, Prünster Egon, Rath Leopold, Rinner Christoph, Romirer Roland, Sabutsch Stefan, Schneider Gerald, Schriefl Michael, Schwaiger Jürgen, Sodeyfi Hamayoun, Stekel Herbert, Stimac Gerhard, Unfried Christoph, Woisetschläger Thomas, Wutscher Edgar, Ziegler Wolfgang
1 Personen sind ohne Titel angegeben
5 Anwendungsfälle
Die folgenden Anwendungsfälle wurden von Seiten des Auftraggebers definiert und zusätzlich in den Workshops noch diskutiert bzw. konkretisiert. In den folgenden Kapiteln sind zuerst die ‚‘High Level Use Cases‘‘ angeführt. Diese sollen die Anwendungsfälle aus User-sicht skizzieren, welche die Basis für den gegenständlichen Implementierungsleitfanden bildeten. In dem nachfolgenden Kapitel ‚‘Detail Use Case‘‘ werden die notwendigen einzelnen Schritte der Exportnormdatensatzerstellung dargestellt und mit den jeweiligen Kapiteln in dieser Spezifikation verknüpft
5.1 High Level Use Case
5.1.1 Ende der ärztlichen Tätigkeit (z.B. Pension)
Aus derzeitiger Sicht kann mit dem gegenständlichen Normdatensatz keine vollständige Backup-Möglichkeit geliefert werden. Auf Grund der Tatsache, dass sich die Softwarelösungen der einzelnen Hersteller in den einzelnen Details stark unterscheiden (Qualität als auch Quantität der genutzten und gespeicherten Daten), kann somit keine vollständige Abbildung der Daten angestrebt werden. Es ist möglich den Exportdatensatz somit zur Archivierung von den hier definierten Daten zu nutzen. Des Weiteren besteht die Möglichkeit, eigene Datenstrukturen zu definieren und für den Export zu nutzen. Es empfiehlt sich, dass der Aufbau der eigenen Datenstrukturen in einem zusätzlichen Dokument beschrieben wird um zu einem beliebigen Zeitpunkt Hilfestellung bei der Rekonstruktion der Daten zu erhalten.
Schritte
- Auswahl der zu exportierenden Patient*innendaten. Im Regelfall wird man im Zuge dieses Use Cases sämtliche Daten aller Patient*innen exportieren
- Auswahl der softwarespezifischen oder praxisspezifischen verwendeten Codes und Abkürzungen welche exportiert werden sollen. Im Regelfall wird man im Zuge dieses Use Cases alle software- oder praxisspezifischen Codes und Abkürzungen exportieren
- Auswahl der Systemdaten (Daten welche nicht einem Patienten zugeordnet werden, wie z.B. Formulare) welche exportiert werden sollen
- Erstellung des Exportdatensatzes
5.1.2 Systemwechsel zu einer anderen Arztsoftware
Der im ersten Schritt notwendige Export basiert auf dem Use Case Ende der ärztlichen Tätigkeit (z.B. Pension). Der erstellte Exportnormdatensatz kann dann in das neue Zielsystem eingespielt/importiert werden. Sollten im Zuge des Exports eigene zusätzliche Datenstrukturen, welche nicht in diesem Implementierungsleitfaden spezifiziert wurden, Anwendung gefunden haben ist dies ebenfalls im Zuge des Imports zu berücksichtigen
Schritte
- Use Case Schritte aus Ende der ärztlichen Tätigkeit (z.B. Pension)
- Einspielen des zuvor erstellten Exportnormdatensatzes in das neue System
5.1.3 Auskunft an PatientInnen (lt. DSGVO) oder Arztwechsel
Sollte ein Patient/eine Patientin Auskunft über seine/ihre gespeicherten Daten erfragen, kann ein Datensatz mit patient*innenspezifischen Daten generiert werden. Es mag hilfreich sein, dass diese generierten Daten vor der Übergabe auf einem physikalischen Medium noch gezippt und verschlüsselt werden. Das Passwort zum Entschlüsseln ist dem Patienten/der Patientin zu übergeben.
Schritte
- Auswahl des Patienten/der Patientin
- Auswahl der softwarespezifischen oder praxisspezifischen verwendeten Codes und Abkürzungen welche bei den Patientendaten vorkommen
- Datensatz erstellen.
- Datensatz auf ein geeignetes Medium spielen (USB-Stick, CD, DVD). Hierbei ist ein Formatierungsformat zu wählen welches aktuell verbreitet in Verwendung ist.
- EMPFEHLUNG: Die Daten auf dem Trägermedium sollten noch mit einem symmetrischen Schlüssel verschlüsselt werden. Der Schlüssel wird dem Patienten/der Patientin zusätzlich ausgehändigt (z.B. Ausdruck)
5.2 Detail Use Case
Der folgende Ablauf stellt die einzelnen Schritte dar, welche im Zuge eines Exports vollzogen werden. Diese Schritte sind Teil des oben angeführten High Level Use Cases. Der Fokus wird in diesem Fall auf den Export von Patientendaten gelegt. Die folgenden Schritte unterscheiden sich nicht ob Daten von nur einem oder von mehreren Patienten exportiert werden.
Schritte
- Benutzer (meist der Arzt) wählt die zu exportierenden Daten aus. Dies inkludiert primär die Entscheidung ob Patientendaten oder Systemdaten exportiert werden sollen. Im Falle eines Exports von Patientendaten muss der oder die zu exportierenden Patienten gewählt werden.
- Patientendaten, welche primär medizinischer Natur sind oder medizinische Dienstleistungen beschreiben, werden in ein CDA Dokument übergeführt. Die Spezifikation für dieses Dokument ist in dem Kapitel Dokumenten Spezifikation ersichtlich.
- Patientendaten, welche nicht medizinischer Natur sind, werden in verschiedenen Dateiformaten erfasst. Termindaten von einem Patienten werden zum Beispiel im iCalendar Format abgelegt.
- EMPFEHLUNG: Im Falle einer Beauskunftung im Sinne der DSGVO, eines Wechsels des Patienten zu einem anderen Arzt oder im Falle des Endes der ärztlichen Tätigkeit wird empfohlen, dass eine zusätzliche Darstellung der exportierten Daten in PDF-Form erstellt wird. Dies bedeutet, dass das CDA mittels Transformation in ein PDF übergeführt wird, als auch eine einfache Darstellung der in z.B. iCal oder JSON erfassten Daten in PDF. Dies soll es dem Patienten oder einem etwaigen Betrachter der Daten erleichtern, die Informationen zu erlangen.
- Sollte im CDA oder in den anderen Dateiformaten Abkürzungen oder Codes verwendet werden, welche nicht in diesem Leitfaden aufgelistet sind (siehe Kapitel Liste der verwendeten Terminologien), müssen diese in einer eigenständigen Codeliste hinterlegt und dem XDM Datenpaket hinzugefügt werden. Information hierzu ist in Kapitel Eigene Codesysteme zu finden.
- Die generierten Dateien (CDA, andere Dateiformate, Codelisten) müssen basierend auf der in Kapitel IHE XDM Struktur für den Exportnormdatensatz ersichtlichen Ordnerstruktur in ein Zip Archiv eingebunden werden.
- Für jeden Patientenordner (Submission Set) ist eine Metadata.xml zu erstellen. Allgemeine Informationen zu den IHE XD* - Metadaten sind in dem Leitfaden zum Metadaten-Mapping von ELGA ersichtlich (XDS Metadaten), spezielle Anforderungen im Falle der XDM Metadaten für den Exportnormdatensatz sind in Kapitel IHE XDM angeführt.
- Für jeden Patientenordner ist eine INDEX.HTM Datei anzulegen, welche als Einstiegspunkt für eine manuelle Recherche auf Patientenebene dienen soll. Informationen hierzu sind in Kapitel INDEX.HTM eines Patientenverzeichnisses ersichtlich.
- Im Wurzelverzeichnis ist eine INDEX.HTM Datei anzulegen, welche als Einstiegspunkt für eine manuelle Recherche dient. Informationen hierzu sind in Kapitel INDEX.HTM im Wurzelverzeichnis ersichtlich.
- Im Wurzelverzeichnis wird eine README.TXT angelegt, welche Informationen zu den am Export beteiligten Personen und Softwareprodukten beinhaltet. Informationen hierzu sind in Kapitel README.TXT ersichtlich.
- Das XDM Datenpaket wird gezippt auf ein Trägermedium überspielt (z.B. USB Datenstick, CD, DVD).
- EMPFEHLUNG: Sollte das XDM Datenpaket dem Patienten ausgehändigt werden (Beauskunftung laut DSGVO, oder Arztwechsel), so wird empfohlen, das XDM Datenpaket mit einem symmetrischen Schlüssel zu verschlüsseln und den Schlüssel dem Patienten gesondert zu überreichen (z.B. Ausdruck).
6 Technischer Hintergrund
6.1 IHE XDM
Vorgeschriebene Verzeichnisstruktur laut IHE-ITI Vol2b, Transaction ITI-32[22]
Für den Export der beschlossenen Normdaten wird als Basis das IHE XDM (Cross-Enterprise Document Media Interchange) Profile herangezogen. Dieses Profile ist in den IHE Technical Frameworks IT-Infrastructur definiert (IHE-ITI Vol1[23] und IHE-ITI Vol2b[22]). Das XDM Profil definiert wie Daten abseits einer technischen Infrastruktur geteilt werden können, es definiert also den Austausch von Daten über Datenträger (z.B. USB-Speicherstick, CD/DVD). Hierzu wird in XDM eine Verzeichnisstruktur vorgegeben. Betreffend der verspeicherten Fileformate ist das Profil jedoch agnostisch. Das bedeutet, dass mithilfe von XDM nicht nur CDA (XML) Dokumente übertragen werden können, sondern auch die anderen geforderten Dokumentenklassen wie z.B.: iCalender, .json. Anzumerken ist, dass IHE XDM für die Datei- und Ordnerbezeichnungen den ISO9660 Standard vorschreibt. Dies bedeutet, dass für die Benennung die "8.3" Konvention zu verwenden ist. Im Zuge dieses Leitfadens und basierend auf der Anforderung, dass .json Dateien verwendet werden können, wird bewusst gegen die ISO9660 und somit IHE XDM verstoßen (es gibt keine Dateiextension für .json mit nur 3 Zeichen).
In der nachfolgenden Tabelle werden die einzelnen Inhaltselemente des METADATA.XML-Files aufgelistet. Hinsichtlich des Konformanzkriteriums wird zwischen Stable Documents (SD) und On-Demand Documents (ODD) unterschieden. Erstere sind Dokumente, welche im klassischen Sinne von einem Autor erzeugt wurden. Als Beispiel hierzu zählen im Kontext des Exportnormdatensatzes die ELGA eBefunde. On-Demand Documents sind Dokumente, welche im Zuge der Generierung des Exportnormdatensatzes automatisch erstellt werden. Beispiele hierzu sind das „Datenbankexport“-CDA selbst oder auch JSON-Files welche Abrechnungsdaten beinhalten.
Die Konformanzkriterien basieren auf den Anforderungen der IHE und weichen bei manchen Elementen von den Anforderungen der ELGA-XDS Metadaten ab. Dies ist Aufgrund der Tatsache erklärbar, dass ELGA den Fokus auf den ungerichteten Dokumentenaustausch mittels IHE XDS legt und der gegenständliche Leitfaden den trägermediumgebundenen (CDA, USB Speicherstick) Austausch auf Basis von IHE XDM beschreibt. Zudem werden in ELGA nur CDA Dokumente mittels IHE XDS verfügbar gemacht und im Kontext des Exportnormdatensatzes können auch andere Dateiformate inkludiert sein. Hinsichtlich der Vorschriften des Mappings von CDA-Headerelementen zu den XDS-Metadaten werden die Spezifikationen von ELGA angewendet. Diese Vorschriften betreffen die einzelnen DocumentEntries. Informationen zum übergeordneten SubmissionSet sind in der Tabelle ersichtlich.
| Code | Bedeutung |
|---|---|
| M | Das Element MUSS mit einem korrekten "echten" Wert angegeben werden.
"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ("required"). |
| R | Das Element SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ("required if known"). |
| O | Optional |
| NP | Das Element ist NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] ("prohibited") |
| Ebene | Element | Konformanz | Kommentar | |
|---|---|---|---|---|
| SD | ODD | |||
| SubmissionSet | author | R [1..1] | Angaben des Authors (Mensch oder Maschine) | |
| SubmissionSet | availabilityStatus | O [0..1] | fixer Wert: "Approved" | |
| SubmissionSet | comments | O [0..1] | Kommentare zum SubmissionSet | |
| SubmissionSet | contentTypeCode | NP [0..0] | contentTypeCode beschreibt die medizische Dienstleistung welche der Generierung des XDM Datensatzes zu Grunde liegt. Aufgrund der Tatsache, dass der Export NICHT auf einer medizischen Dienstleistung beruht, wird der contentTypeCode NICHT im Kontext von EXNDS verwendet. | |
| SubmissionSet | entryUUID | R [1..1] | UUID des SubmissionSets in den Metadaten | |
| SubmissionSet | homeCommunityId | O [0..0] | Laut ELGA wäre dieser Eintrag verpflichtend. Laut IHE für XDM optional. Weil nicht jeder (Fach)Arzt an einer Community teilnehmen muss, ist hier die Verpflichtung abgeändert. | |
| SubmissionSet | intendedRecipient | R [0..1] | Sollte der Patient Auskunft darüber geben für wen der Export gemacht wird (Patient, anderer Arzt) soll dies in diesem Element vermerkt werden | |
| SubmissionSet | patientId | R [0..1] | ID des Patienten innerhalb der Affinity Domain. Sollte diese nicht vorhanden sein, kann auch die lokale PatientenId angegeben werden | |
| SubmissionSet | sourceId | R [1..1] | ID des Systems welches das SubmissionSet erstellt hat | |
| SubmissionSet | submissionTime | R [1..1] | Zeitstempel wann das SubmissionSet erstellt wurde | |
| SubmissionSet | title | O [0..1] | Title des SubmissionSets | |
| SubmissionSet | uniqueId | R [1..1] | ID des SubmissionSets | |
| Die folgenden Einträge beschreiben die XDS Metadaten für das DocumentEntry. Diese sind auch von ELGA für CDA Dokumente definert worden. Wenn möglich sollen die ELGA Spezifikationen übernommen werden (für CDA und nicht-CDA-Dokumente) | ||||
| DocumentEntry | author | R [0..1] | R [0..1] | siehe ELGA Metadaten |
| DocumentEntry | classCode | R [0..1] | R [0..1] | wird nur für CDA-Dokumente verwendet, ansonsten weggelassen |
| DocumentEntry | confidentialityCode | R [1..1] | R [0..1] | Value Set "ELGA_Confidentiality", empfohlener Wert "normal" |
| DocumentEntry | creationTime | R [1..1] | R [0..1] | Zeitpunkt der Dokumentenerstellung |
| DocumentEntry | entryUUID | R [1..1] | R [1..1] | ID des Metadateneintrages für das Dokument |
| DocumentEntry | eventCodeList | O [0..1] | O [0..1] | für das Datenbankexport-CDA wird dieser Eintrag weggelassen, da hier keine medizinischen Dienstleistungen (sondern der Export) stattgefunden haben. Für andere CDA siehe ELGA Leitfaden zu den Metadaten |
| DocumentEntry | formatCode | R [0..1] | R [0..1] | Value Set "exnds_FormatCodes_VS" (für nicht CDA Dokumente) oder "ELGA_FormatCodes_VS" (für CDA Dokumente). Sollte kein passender Code gefunden werden kann auch ein Code aus einer eigenen Codeliste verwendet werden. |
| DocumentEntry | hash | R [1..1] | R [1..1] | Hash Wert des Dokuments |
| DocumentEntry | healthcareFacilityTypeCode | R [0..1] | R [0..1] | Value Set "ELGA_ HealthcareFacilityTypeCode" |
| DocumentEntry | homeCommunityId | O [0..1] | O [0..1] | Angabe der HomeCommunityId (kann ELGA Bereich entsprechen). Nachdem nicht jeder Arzt einem ELGA Bereich zugeordnet sein muss, ist dieses Feld optional |
| DocumentEntry | languageCode | R [0..1] | R [0..1] | Value Set, empfohlener Wert für Deutsch "de-AT" |
| DocumentEntry | legalAuthenticator | R [0..1] | O [0..1] | Person welche das Dokument rechtlich unterzeichnet. Fällt in der Regel bei ODD weg |
| DocumentEntry | mimeType | R [1..1] | R [1..1] | Value Set "IANA Mime Type" (Teilmenge), weitere Werte siehe RFC 2045 bis RFC 2049. Beispiele: DICOM "application/dicom", für JSON "application/json", für iCal "text/calendar" ... |
| DocumentEntry | objectType | R [1..1] | R [1..1] | Unterscheidung zwischen "Stable Document" und "On-Demand Document". Das "Datenbankexport"-CDA wäre als ODD zu führen, andere CDA-Reports (eBefunde) wären als SD zu führen. |
| DocumentEntry | patientId | R [0..1] | R [0..1] | ID des Patienten innerhalb der Affinity Domain. Sollte diese nicht vorhanden sein, kann auch die lokale PatientenId angegeben werden |
| DocumentEntry | practiceSettingCode | R [0..1] | R [0..1] | Value Set "ELGA_PracticeSetting_VS" |
| DocumentEntry | referenceIdList | O [0..1] | O [0..1] | siehe ELGA Spezifikation |
| DocumentEntry | serviceStartTime | R [0..1] | R [0..1] | Beginn-Datum der Gesundheitsdienstleistung. Bei dem Datenbankexport-CDA wäre hier der Exportzeitpunkt anzugeben |
| DocumentEntry | serviceStopTime | R [0..1] | R [0..1] | End-Datum der Gesundheitsdienstleistung. Bei dem Datenbankexport-CDA wäre hier der Exportzeitpunkt anzugeben |
| DocumentEntry | size | R [1..1] | R [1..1] | Größe des Dokuments in byte |
| DocumentEntry | sourcePatientId | R [0..1] | R [0..1] | Patienten-ID des lokalen Systems |
| DocumentEntry | sourcePatientInfo | R [0..1] | R [0..1] | Demographische Daten des Patienten |
| DocumentEntry | title | O [0..1] | O [0..1] | Titel des Dokuments |
| DocumentEntry | typeCode | R [0..1] | R [0..1] | wird nur für CDA-Dokumente verwendet, ansonsten weggelassen |
| DocumentEntry | uniqueId | R [1..1] | R [1..1] | ID des Dokuments |
| DocumentEntry | URI | R [1..1] | R [1..1] | relativer Pfad zu dem Dokument |
6.1.1 IHE XDM Struktur für den Exportnormdatensatz
Die nachfolgende Tabelle zeigt die Struktur welche von XDM gefordert wird. Die Elemente in der ersten Spalte sind hinsichtlich ihrer Verschachtelung nach rechts eingerückt. Die Tabelle zeigt die notwendigen Inhalte (siehe Spalte Verpflichtung), nutzt jedoch gleichzeitig Beispieldaten um die Struktur zu verdeutlichen.
| Elementname | Datei/Ordner | Verpflichtung | Hinweis | Verweise | ||
|---|---|---|---|---|---|---|
| README.TXT | Datei | M | Die Readme Datei muss Hinweise zu den am Export beteiligten Akteuren (Software, Arzt) enthalten | Link | ||
| INDEX.HTM | Datei | M | Die INDEX.HTM muss eine Übersicht über die exportierten Patienten ermöglichen | Link | ||
| IHE_XDM | Ordner | M | Dies ist der root-Ordner für XDM Anwendungen. Er kann eine unbestimmte Anzahl an Submission Sets enthalten.
Im Kontext des Exportnormdatensatzes wird für jeden exportierten Patienten ein Submission Set erstellt. Zudem soll es ein übergreifendes Submission Set geben, welches z.B. die benötigten Codelisten enthält |
|||
| PAT0001 | Ordner | M (Name beispielhaft) | Submission Set für den ersten Patienten. Als Ordnername soll der systeminterne Patientenidentifier genutzt werden | |||
| INDEX.HTM | Datei | M | Die INDEX.HTM auf Patientenebene ermöglicht eine Übersicht über die patientenspezifischen Dokumente | Link | ||
| METADATA.XML | Datei | M | Das METADATA.XML enthält die maschinenlesbaren Metainformationen zu den enthaltenen Dokumenten | Link | ||
| PAT0001.XML | Datei | M (Name beispielhaft) | Dies ist das Datenbankexport CDA für den ersten Patienten. Die Spezifikation dieses CDA Dokuments ist Gegenstand dieses Leitfadens | Link | ||
| CDAStylesheet.XSL | Datei | M (Name beispielhaft) | Ein Stylesheet um das Datenbankexport CDA anzuzeigen. Das ELGA Referenzstylesheet kann genutzt werden | |||
| TERMIN001.ICS | Datei | Beispiel | Beispieldatei: Ein patientenspezifischer Termineintrag | Link | ||
| PAT0002 | Ordner | M (Name beispielhaft) | Submission Set für den zweiten Patienten. Als Ordnername soll der systeminterne Patientenidentifier genutzt werden | |||
| INDEX.HTM | Datei | M | Die INDEX.HTM auf Patientenebene ermöglicht eine Übersicht über die patientenspezifischen Dokumente | Link | ||
| METADATA.XML | Datei | M | Das METADATA.XML enthält die maschinenlesbaren Metainformationen zu den enthaltenen Dokumenten | Link | ||
| PAT0002.XML | Datei | M (Name beispielhaft) | Dies ist das Datenbankexport CDA für den zweiten Patienten. Die Spezifikation dieses CDA Dokuments ist Gegenstand dieses Leitfadens | Link | ||
| Labbef01.XML | Datei | Beispiel | Beispieldatei: ein CDA Laborbefund | |||
| CDAStylesheet.XSL | Datei | M (Name beispielhaft) | Ein Stylesheet um das Datenbankexport CDA anzuzeigen. Das ELGA Referenzstylesheet kann genutzt werden | |||
| BERICHT01.PDF | Datei | Beispiel | Beispieldatei: ein Bericht in PDF Form | |||
| PAT0002.PDF | Datei | R (Name beispielhaft) | Beispieldatei: ein PDF rendering des Datenbankexport CDAs. Dieses PDF wird empfohlen, wenn der Export an den Patienten übergeben wird. | |||
| ALLGEMEIN | Ordner | R | Submission Set für allgemeine Daten | |||
| METADATA.XML | Datei | M | Das METADATA.XML enthält die maschinenlesbaren Metainformationen zu den enthaltenen Dokumenten | Link | ||
| Codeliste1.XML | Datei | R (Name beispielhaft) | Beispieldatei: Codeliste mit systeminternen Codes | Link | ||
| Abkürzungen1.XML | Datei | R (Name beispielhaft) | Beispieldatei: Codeliste mit systeminternen Abkürzungen | Link | ||
6.1.2 README.TXT
Laut IHE Profile XDM ist zwingend eine README.TXT Datei in der Ordnerstruktur zu führen. Nach [22] MUSS diese Datei folgende Informationen beinhalten:
- Kontaktinformationen über das dokumenterstellende Institut
- Informationen über das Softwareprodukt welches an der Erstellung beteiligt war
- Name und Version
- Kontaktinformationen zum Softwareprodukthersteller
- Information über die Struktur des XDM Datenset
Es ist anzumerken, dass das README.TXT File von der transportierten klinischen Information unabhängig ist. Somit kann die gleiche README.TXT in verschiedenen Exporten vorkommen.
Erzeugt von: Arztpraxis Dr. Meier Mozartgasse 1-7 5350 St.Wolfgang, Salzburg Für Unterstützung: Arztpraxis Dr. Meier (stellt Kontakt her) +43 6138 3453446 122 Erzeugt durch xy GmbH - Arztsoftware (Version 8.123, www.xy-arztsoftware.at), basierend auf der Spezifikation des Exportnormdatensatzes mit der OID 1.2.40.0.34.7.25.1 Der IHE_XDM Ordner enhält für jeden Patienten/jede Patientin einen eigenen Unterordner. Der Name des Unterordners ist die PatientenID aus dem Quellsystem. Zur Darstellung der Inhalte können folgende Softwareprodukte genutzt werden: - Für CDA Dokumente (.XML): Browser und ELGA-Referenzstylesheet, bzw. ENDS2-Importtool - Für iCalender Dateien (.ICS): Kalenderapplikation, bzw. ENDS2-Importtool - Für JSON Dateien (.JSON): Texteditor, bzw. ENDS2-Importtool
6.1.3 INDEX.HTM im Wurzelverzeichnis
Die folgende INDEX.HTM liegt im Wurzelverzeichnis der IHE Daten und dient zur Übersicht aller vorhandenen Patienten. Sie stellt dabei die folgenden Informationen dar:
- Kontaktinformationen über den Ersteller der Dokumente
- Pro Patient
- Name
- Vorname
- Geburtsdatum
- Link zu dessen Dokumentenübersicht
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.1//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic11.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<title>XDM</title>
<style type="text/css">
table, th, td {
border: 1px solid black;
}
</style>
</head>
<body>
<h1>XDM Patientenübersicht:</h1>
<p>
Erzeugt von:<br />
Amadeus Spital - Urologische Ambulanz<br />
Mozartgasse 1-7<br />
5350 St. Wolfgang
</p>
<table>
<tr>
<th>Name</th>
<th>Vorname</th>
<th>Geburtsdatum</th>
<th>Dokumentenübersicht</th>
</tr>
<tr>
<td>TEST0000000036</td>
<td>Maximilian</td>
<td>26.08.2001</td>
<td><a href="00000036/INDEX.HTM">00000036/INDEX.HTM</a></td>
</tr>
</table>
</body>
</html>
6.1.4 INDEX.HTM eines Patientenverzeichnisses
Die folgende INDEX.HTM dient als Übersicht der vorhandenen Patientendaten. Eine entsprechend angepasste Version befindet sich in jedem Patientenverzeichnis und stellt dabei die folgenden Informationen dar:
- Kontaktdaten zum Ersteller der Dokumente
- Patientendaten
- Name
- ID im System
- Geschlecht
- Geburtsdatum
- Postadresse
- Dokumentendaten
- Art/Bezeichnung des Dokuments
- Datum
- Link zur Datei
- MIME Type
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.1//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic11.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<title>XDM - klinische Dokumente für Maximilian TEST0000000036</title>
<style type="text/css">
table, th, td {
border: 1px solid black;
}
</style>
</head>
<body>
<h1>XDM Dokumente:</h1>
<p>
Erzeugt von:<br />
Amadeus Spital - Urologische Ambulanz<br />
Mozartgasse 1-7<br />
5350 St. Wolfgang
</p>
<p>
Name des Patienten: Maximilian TEST0000000036<br />
Pat-ID: 36<br />
Geschlecht: M<br />
Geburtsdatum: 26.08.2001<br />
STR0000000036<br />
0036 WIEN0000000036
</p>
<h2>Dokumente:</h2>
<table>
<tr>
<th>Dokumentart</th>
<th>Datum</th>
<th>Link</th>
<th>MIME Type</th>
</tr>
<tr>
<td>NDS (CDA)</td>
<td>12.12.2018</td>
<td><a href="00000036.XML">Exportdaten</a></td>
<td>text/xml</td>
</tr>
<tr>
<td>Termin</td>
<td>08.10.2018</td>
<td><a href="TERMIN001.ICS">Termin Verbandswechsel</a></td>
<td>text/calendar</td>
</tr>
<tr>
<td>Laborbefund</td>
<td>15.4.2018</td>
<td><a href="LAB01.XML">Allgemeiner Laborbefund</a></td>
<td>text/xml</td>
</tr>
</body>
</html>
7 Spezifikationen abseits von CDA
Neben dem CDA Dokument, welches primär medizinische Daten des zu exportierenden Patienten oder der zu exportierenden Patienten beinhaltet, gibt es noch weitere Dateiformate. Die Daten, welche in diesen Dateien enthalten sind, könnten nicht ohne weiteres in einem HL7 CDA Dokument codiert werden. Daher fiel die Entscheidung für nicht-medizinische Daten andere, besser geeignete Dateiformate zu nutzen. Die folgenden Kapitel stellen diese vor und legen Einschränkungen fest.
Aus derzeitiger Sicht wird die korrekte Implementierung dieser Dateiformate nicht durch Prüfregeln automatisiert prüfbar sein. Die zur Verfügung gestellten Prüfregeln umfassen nur die Schematron-Regeln für das CDA Dokument.
7.1 iCalendar
Um Termine abbilden zu können, wird das iCalendar Format verwendet. Das folgende Beispiel basiert dabei auf den Spezifikationen RFC 5545 und RFC 7986. Es wurde mit einem Validator geprüft und deckt die definierten Anforderungen ab.
BEGIN:VCALENDAR VERSION:2.0 PRODID:http://www.example.com/calendarapplication/ METHOD:PUBLISH BEGIN:VEVENT UID:461092315540@example.com ORGANIZER;CN="Dr. Max Mustermann":MAILTO:max.mustermann@example.com CONTACT:Herr Theodor Test, Patient ID 012345 LOCATION:Praxis Dr. Mustermann, Raum 01 SUMMARY:Verbandswechsel DESCRIPTION:Verbandswechsel Hr. Tester RESOURCES:Dr. Mustermann, Assistent CATEGORIES:Nachbehandlung CLASS:PUBLIC COLOR:green DTSTART:20190910T090000Z DTEND:20190910T091500Z DTSTAMP:20190903T130000Z END:VEVENT END:VCALENDAR
7.2 JSON
Daten, für die die Darstellung als CDA nicht geeignet ist, werden im JSON-Format dargestellt. Dies gilt für
- Geldflussdaten,
- Formulare,
- Stammdaten und
- Lagerstände.
Die unten angegebenen Strukturbeispiele sind informativ zu verstehen und können je nach Bedarf flexibel erweitert werden. Daher sind nicht alle Beispiele vollständig angeführt (z.B. "Stammdaten"), da sie lediglich als Grundlage für die individuelle Entwicklung dienen sollen.
Die folgenden Tabellen listen die benötigten Elemente sowie deren Eigenschaften auf. In den Strukturbeispielen werden die zu verwendeten Datentypen wie folgt dargestellt:
- String: "" (Leerstring)
- Numerisch: 0
- Datum: String im ISO-8601-Format
- Code: dabei handelt es sich um keinen JSON Datentyp. Diese Angabe soll verdeutlichen, dass bei diesen Werten aus einem eingeschränkten Wertevorrat gewählt werden muss. Technisch gesehen wird der Wert in der Regel als Datentyp "String" behandelt, in gewissen Fällen wäre auch "Numerisch" denkbar.
7.2.1 Geldflussdaten
Die angegebenen Element- und Attribute Namen sind verpflichtend einzuhalten.
| Attribut | Kardinalität | Datentyp | Hinweis |
|---|---|---|---|
| Geldflussdaten | 1..1 | Array | fasst die folgenden Attribute als JSON-Objekte zusammen |
| Text | 0..1 | String | |
| Betrag | 1..1 | Numerisch | |
| Mehrwertsteuer-Satz | 1..1 | Numerisch | |
| Zahlungsart | 0..1 | Code | Zulässige Werte: "Bar", "Scheck", "Kreditkarte", "Bankomat" |
Strukturbeispiel:
{
"Geldflussdaten": [
{
"Text": "Erstbehandlung",
"Betrag": 120,
"Mehrwertsteuer-Satz": 20,
"Zahlungsart": "Kreditkarte"
}
]
}
7.2.2 Formulardaten
Die angegebenen Element- und Attribute Name sind verpflichtend einzuhalten.
| Attribut | Kardinalität | Datentyp | Hinweis |
|---|---|---|---|
| Formular | 1..1 | Array | fasst die folgenden Attribute als JSON-Objekte zusammen |
| Klasse | 1..1 | String/Code | Im Falle, dass Codes verwendet werden müssen diese in einer Codeliste, welche dem XDM inkludiert wird, angeführt werden. |
| Erstellungsdatum | 0..1 | Datum | |
| Formular/Feld | 1..1 | Array | fasst die folgenden Attribute als JSON-Objekte zusammen |
| Name | 1..1 | String | |
| Typ | 1..1 | String/Code | Im Falle, dass Codes verwendet werden müssen diese in einer Codeliste, welche dem XDM inkludiert wird, angeführt werden. |
| Inhalt | 0..1 | String | |
| Reihenfolge | 0..1 | Numerisch |
Strukturbeispiel:
{
"Formular": [
{
"Klasse": 1,
"Erstellungsdatum": "2020-10-08T07:17:51.876Z",
"Feld": [
{
"Name": "Sozialversicherungsnummer",
"Typ": "numerisch",
"Inhalt": "",
"Reihenfolge": 4
}
]
}
]
}
7.2.3 Stammdaten
Die angegebenen Element- und Attribute Namen sind verpflichtend einzuhalten. Weitere Attribute, die nicht in dieser Tabelle aufgeführt sind, können nach Bedarf ergänzt werden (siehe Strukturbeispiel).
| Attribut | Kardinalität | Datentyp | Hinweis |
|---|---|---|---|
| Stammdaten | 1..1 | Array | fasst die folgenden Attribute als JSON-Objekte zusammen |
| Leistungen | 1..1 | Array | fasst die folgenden Attribute als JSON-Objekte zusammen |
| Code | 1..1 | Code | Die verwendeten Codes müssen in einer Codeliste, welche im XDM inkludiert wird, angeführt werden. |
| Bezeichnung | 1..1 | String | |
| Einzelpreis brutto | 1..1 | Numerisch | |
| Einzelpreis netto | 1..1 | Numerisch | |
| Umsatzsteuer Prozent | 1..1 | Numerisch | |
| Krankenkasse | 0..1 | String | |
| Diagnosen | 1..1 | Array | fasst die folgenden Attribute als JSON-Objekte zusammen |
| Bezeichnung | 1..1 | String/Code | Im Falle, dass Codes verwendet werden, müssen diese in einer Codeliste, welche dem XDM inkludiert wird, angeführt werden. |
| Beschreibung | 0..1 | String |
Strukturbeispiel:
{
"Stammdaten": [
{
"Leistungen": [
{
"Code": 1,
"Bezeichnung": "Erstbehandlung",
"Einzelpreis brutto": 144,
"Einzelpreis netto": 120,
"Umsatzsteuer Prozent": 20,
"Krankenkasse": ""
}
],
"Diagnosen": [
{
"Bezeichnung": "Myokardinfarkt",
"Beschreibung": "Einengung oder Verlegung der Koronararterie oder einer ihrer Nebenäste"
}
],
"Medikamente": [],
"Allergien": [],
"Textblöcke": [],
"Zuweiser": "",
"Terminarten": []
}
]
}
7.2.4 Lagerstand
| Attribut | Kardinalität | Datentyp | Hinweis |
|---|---|---|---|
| Lager | 1..1 | Array | fasst die folgenden Attribute als JSON-Objekte zusammen |
| Medikamente | 1..1 | Array | fasst die folgenden Attribute als JSON-Objekte zusammen |
| Pharmazentralnummer | 1..1 | Numerisch | |
| Lagerstand | 1..1 | Numerisch | |
| Meldung ab | 0..1 | Datum | |
| Nachbestellen bis | 0..1 | Datum | |
| Zusatzartikel | 1..1 | Array | fasst die folgenden Attribute als JSON-Objekte zusammen |
| Bezeichnung | 1..1 | String | |
| Lagerstand | 1..1 | Numerisch |
Strukturbeispiel:
{
"Lager": [
{
"Medikamente": [
{
"Pharmazentralnummer": 533363,
"Lagerstand": 90,
"Meldung ab": "2020-10-08T07:38:13.700Z",
"Nachbestellen bis": "2020-10-08T07:38:13.700Z"
}
],
"Zusatzartikel": [
{
"Bezeichnung": "Einmalhandschuhe",
"Lagerstand": 200
}
]
}
]
}
7.3 Verrechnungsdaten
7.3.1 Rechnungen
Prinzipiell werden nur patientenbezogene Rechnungen exportiert. Je nach Anwendungsfall kommen die folgenden Formate dafür in Frage:
- Pan-European Public Procurement OnLine (PEPPOL, siehe https://www.erechnung.gv.at/erb)
- Rechnungsformat der Sozialversicherungen (siehe https://www.elda.at/cdscontent/?contentid=10007.755331&viewmode=content)
- Rechnungsformat des Versicherungsverbandes der Privatversicherungen (VVO, siehe EDIVKA-Datenaustausch: https://www.vvo.at/vvo/vvo.nsf/sysUNID/xDED4A249481F0851C1257D7F00435EBA)
7.3.2 Registrierkassendaten
- Datenerfassungsprotokoll (DEP)
7.3.3 Buchhaltungsdaten
- Formate der DATEV GmbH
7.4 Eigene Codesysteme
Es ist davon auszugehen, dass Informationen über Patienten oder Systemparameter in Arztpraxissystemen benutzerspezifische Abkürzungen oder Codes enthalten. Diese benutzerspezifischen Abkürzungen oder Codes könnten vom Arzt vergeben worden sein, für ein spezifisches Arztpraxisinformationsystem vom Hersteller im Zuge einer Konfiguration vergeben worden sein oder für alle Arztpraxisinformationssysteme von einem Hersteller gelten. In allen Fällen MUSS im Zuge des Exports auch die Bedeutung der benutzerspezifischen Abkürzungen und Codes exportiert werden um die Bedeutung dieser auch erfassbar zu machen. Hierzu MUSS dem XDM Datenpaket zumindest ein Codesystem hinzugefügt werden, welches die verwendeten Abkürzungen auflöst. Dem Hersteller bzw. Arzt soll es überlassen sein, ob im Zuge eines Exports von Patientendaten sämtliche Abkürzungen und Codes, welche in dem Arztpraxissystem Verwendung finden, exportiert werden oder nur diejenigen, welche tatsächlich in den exportierten Daten verwendet werden. Das Exportformat für die Codes und Abkürzungen ist IHE Sharing Value Sets (SVS). Dieses wird auch vom österreichischen Terminologieserver als Dateiformat für Codelisten und Valuesets genutzt. Dieses XML-basierte Format für den Austausch von Terminologien basiert auf einer flachen Liste der einzelnen Konzepte (entspricht einer Abkürzung oder einem Code). Die nachfolgenden Tabellen zeigen die notwendigen Strukturen in einer minimalen Variante.
Dem Hersteller ist es überlassen ob es mehrere SVS Dateien gibt (z.B. thematisch separiert) oder ob es nur eine SVS Datei gibt, in der sämtliche Konzepte enthalten sind (unabhängig vom Verwendungszweck). In jedem Fall muss sichergestellt werden, dass innerhalb einer SVS Datei die Konzepte eindeutig auf eine Beschreibung mappen und dass die Zuordnung von Abkürzungen und Codes zwischen Verwendungsort und Codeliste eindeutig ist. Zwei gesonderte Codelisten sind dann zu empfehlen, wenn zwischen eigens definierten Codes und Abkürzungen sowie Codes und Abkürzungen, welche aus einem bestehenden Codesystem entliehen wurden, unterschieden werden soll.
Der Struktur dieser XML-Datei sieht wie folgt aus:
<!-- Dieses Element beinhaltet Attribute, welche das Valueset/Codeliste beschreiben.
Weiters enthält diese Element genau ein conceptList-Element -->
<valueSet name='ASW_HerstellerX_WeitereDaten' displayName='Weitere Daten von Hersteller X' effectiveDate='2017-01-26' id='1.2.40.0.34.99.111' statusCode='final' beschreibung=''>
<!-- Dieses Element beinhaltet eine unbestimmte Menge an concept-Elementen -->
<conceptList>
<!-- Jedes dieser Elemente beinhaltet die Informationen zu einem Konzept -->
<concept code='ImpfSch' codeSystem='1.2.40.0.34.99.111' displayName='Impfschaden' level='0' type='L' conceptStatusDate='2017-01-26'/>
<concept code='BevOrth' codeSystem='1.2.40.0.34.99.111' displayName='Bevorzugter Orthopäde' level='0' type='L' conceptStatusDate='2017-01-26'/>
</conceptList>
</valueSet>
Nachfolgende Tabelle zeigt die Attribute des valueSet-Elements
| Name des Attributes | Beschreibung |
|---|---|
| name | Name der Codeliste, der sich auch in dem Dateinamen der Codeliste widerspiegeln soll |
| displayName | Klartextbezeichnung des Codesystems |
| effectiveDate | Relevantes Datum der Terminologien
Es sollte das Datum des Exports gewählt werden. Die Darstellung soll dem Format YYYY-MM-DD entsprechen. |
| id | Die OID des Codesystems
Es wird empfohlen, dass die OID des Gesundheitsdienstanbieters als Basis genutzt und um einen weiteren Knotenpunkt erweitert wird |
| statusCode | Status des Codesystems
fixer Wert "final" |
| beschreibung | Beschreibung des Codesystems
Es wird empfohlen, dass in diesem Element festgehalten wird, dass dieses Codesystem im Zuge des Exportnormdatensatzes erstellt wurde. Beispiel hierzu wäre: beschreibung="Konzepte von Arztpraxis XXX, erstellt im Zuge eines Datenexports" |
Nachfolgende Tabelle zeigt die Attribute des concept-Elements
| Name des Attributes | Beschreibung |
|---|---|
| code | Verwendeter Code oder Abkürzung |
| codeSystem | gleicher Code wie valueSet@id
ODER OID des Parent Code Systems (wenn der Code oder die Abkürzung aus einem vorhandenen Codesystem entliehen wurde |
| displayName | Klartextrepräsentation des Codes oder der Abkürzung |
| level | Angabe zur Hierarchiestufe des Codes (in einer flachen Liste können alle Konzepte den Wert level="0" haben) |
| type | Angabe zu Type des Codes im Hierarchiebaum (in einer flachen Liste können alle Konzepte den Wert type="L" haben |
| conceptStatusDate | Angabe des Datums ab wann dieser Code gültig wurde. Im Kontext des Exportnormdatensatzes kann hier das Exportdatum gewählt werden. |
8 Dokumenten Spezifikation
Information über die Inhalte des CDA-Headers (Administrative Information) kann direkt aus der Spezifikation auf Dokumenten Ebene im nachfolgenden Kapitel gewonnen werden. Informationen über die Inhalte des CDA-Bodies (Medizinische Information) kann aus der Übersichtstabelle in Kapitel Section-Templates Übersicht gewonnen werden.
8.1 Dokumenten Ebene
| Id | 1.2.40.0.34.6.0.11.0.6 | Gültigkeit | 2019‑06‑12 09:18:44 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Status |  Aktiv | Versions-Label | 1.0.0+20210310 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Name | exnds_document_exportNormdatensatz | Bezeichnung | Export-Normdatensatz | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Kontext | Pfadname / | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Klassifikation | CDA Document Level Template | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Offen/Geschlossen | Geschlossen (nur definierte Elemente sind erlaubt) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Benutzt |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
