e-Impfpass
 |
Dieses Dokument gibt wieder:
Implementierungsleitfaden e-Impfpass (1.3.1+20220719), OID: 1.2.40.0.34.7.19.1, Datum: 2022-07-19, Status: Finale Version (normative Nebenversion). Die Teilmaterialien gehören der Kategorie ILF an. |
e-Impfpass (Version 1)
Gesundheitswesen [1.2.40.0.34.7.19.1]
Inhaltsverzeichnis
- 1 Zusammenfassung
- 2 Einleitung
- 3 Informationen über dieses Dokument
- 4 Harmonisierung
- 5 Begriffsdefinitionen
- 6 Technischer Hintergrund
- 6.1 Allgemeine Richtlinien für die Implementierung des e-Impfpasses
- 7 Datentypen
- 7.1 Identifikations-Elemente
- 7.2 Codierungs-Elemente
- 7.2.1 code-Element CE CWE
- 7.2.1.1 Strukturbeispiele
- 7.2.1.1.1 Minimal-Variante um einen Code eindeutig darzustellen:
- 7.2.1.1.2 Gebräuchlichste Variante mit zusätzlichem Klartext für Code und Codesystem
- 7.2.1.1.3 Vollständige-Variante mit direkter Angabe des Textinhalts
- 7.2.1.1.4 Vollständige-Variante mit Referenz in den narrativen Textbereich
- 7.2.1.1.5 Vollständige-Variante mit Referenz in den narrativen Textbereich und Übersetzung in zwei andere Code-Systeme
- 7.2.1.2 Spezifikation
- 7.2.1.1 Strukturbeispiele
- 7.2.2 code-Element CS CNE
- 7.2.1 code-Element CE CWE
- 7.3 Zeit-Elemente
- 7.4 Kontaktdaten-Elemente
- 7.5 Namen-Elemente
- 7.6 Adress-Elemente
- 7.7 Komplexe (zusammengesetzte) Elemente
- 7.8 Weitere Informationen zu CDA
- 8 Funktionale Anforderungen
- 9 User Storys ("Anwendungsfälle")
- 10 Datenarten
- 11 Technische Spezifikation
- 11.1 Übersicht CDA Struktur "Kompletter Immunisierungsstatus"
- 11.2 Übersicht CDA Struktur "Update Immunisierungsstatus"
- 11.3 Übersicht der Strukturen mit Konformität und Kardinalität
- 11.4 CDA Templates
- 11.4.1 Document Level Templates
- 11.4.2 Header Level Templates
- 11.4.2.1 Document Realm
- 11.4.2.2 Document TypeId
- 11.4.2.3 Document Id
- 11.4.2.4 Document Effective Time
- 11.4.2.5 Document Confidentiality Code
- 11.4.2.6 Document Language
- 11.4.2.7 Document Set Id and Version Number
- 11.4.2.8 Record Target - e-Impfpass
- 11.4.2.9 Author
- 11.4.2.10 Data Enterer
- 11.4.2.11 Custodian
- 11.4.2.12 Legal Authenticator
- 11.4.2.13 Information Recipient
- 11.4.2.14 Participant
- 11.4.2.15 In Fulfillment Of
- 11.4.2.16 Documentation Of Service Event - e-Impfpass
- 11.4.2.17 Document Replacement - Related Document
- 11.4.2.18 Authorization
- 11.4.2.19 Component Of - Encompassing Encounter
- 11.4.2.20 Encounter Location
- 11.4.3 Section Level Templates
- 11.4.4 Entry Level Template
- 11.4.4.1 Antikörper-Bestimmung Battery Organizer
- 11.4.4.2 Antikörper-Bestimmung Data Processing Entry
- 11.4.4.3 Antikörper-Bestimmung Laboratory Observation Entry
- 11.4.4.4 Comment Entry
- 11.4.4.5 Eingebettetes Objekt Entry
- 11.4.4.6 Expositionsrisiko Problem Concern Entry
- 11.4.4.7 Expositionsrisiko Problem Entry
- 11.4.4.8 External Document Entry
- 11.4.4.9 Immunization Billability Entry
- 11.4.4.10 Immunization Entry
- 11.4.4.11 Immunization Entry Impfung nicht angegeben
- 11.4.4.12 Immunization Recommendation Entry
- 11.4.4.13 Immunization Schedule Entry
- 11.4.4.14 Immunization Target Entry
- 11.4.4.15 Impfplan Entry
- 11.4.4.16 Impfrelevante Erkrankungen Problem Concern Entry
- 11.4.4.17 Impfrelevante Erkrankungen Problem Entry
- 11.4.4.18 Vaccine Product
- 11.4.4.19 Vaccine Product nicht angegeben
- 11.4.4.20 Zusatzklassifikation (für Impfungen)
- 11.4.5 Weitere CDA Fragmente
- 11.4.5.1 Address Compilation
- 11.4.5.2 Address Compilation Minimal
- 11.4.5.3 Assigned Entity
- 11.4.5.4 Assigned Entity Body
- 11.4.5.5 Assigned Entity Body with name, addr and telecom
- 11.4.5.6 Author Body
- 11.4.5.7 Author Body - eImpfpass
- 11.4.5.8 Date Interval Information minimal
- 11.4.5.9 Device Compilation
- 11.4.5.10 Informant Body
- 11.4.5.11 Narrative Text Reference
- 11.4.5.12 Organization Compilation with id, name
- 11.4.5.13 Organization Compilation with id, name, tel, addr
- 11.4.5.14 Organization Compilation with name
- 11.4.5.15 Organization Compilation with name, addr minimal
- 11.4.5.16 Organization Name Compilation
- 11.4.5.17 Original Text Reference
- 11.4.5.18 Participant Body
- 11.4.5.19 Participant Body - Transcriber
- 11.4.5.20 Participant Body - Verifier
- 11.4.5.21 Participant Body - Authorized Editor
- 11.4.5.22 Participant Body - Data Enterer
- 11.4.5.23 Performer Body
- 11.4.5.24 Performer Body - Impfende Person
- 11.4.5.25 Performer Body - Laboratory
- 11.4.5.26 Person Name Compilation G1
- 11.4.5.27 Person Name Compilation G1 M
- 11.4.5.28 Person Name Compilation G2
- 11.4.5.29 Person Name Compilation G2 M
- 11.4.5.30 Time Interval Information minimal
- 11.5 Terminologien
- 12 Anhang
- 12.1 Abbildungen
- 12.2 Tabellen
- 12.3 Abkürzungsverzeichnis
- 12.4 Literaturverzeichnis
- 12.5 Revisionsliste
- 12.5.1 Nebenversionen
- 12.5.1.1 Nebenversion (Patch) 1.3.1+20220719
- 12.5.1.2 Nebenversion 1.3.0+20220127
- 12.5.1.3 Nebenversion 1.2.0+20220103
- 12.5.1.3.1 DLT Kompletter Immunisierungsstatus 1.2.40.0.34.6.0.11.0.4
- 12.5.1.3.2 DLT Update Immunisierungsstatus 1.2.40.0.34.6.0.11.0.2
- 12.5.1.3.3 Immunization Recommendation Entry 1.2.40.0.34.6.0.11.3.3
- 12.5.1.3.4 Performer Body - Impfende Person 1.2.40.0.34.6.0.11.9.21
- 12.5.1.3.5 Author 1.2.40.0.34.6.0.11.1.2
- 12.5.1.3.6 Participant Body - Verifier 1.2.40.0.34.6.0.11.9.44
- 12.5.1.3.7 Participant Body - Authorized Editor (1.2.40.0.34.6.0.11.9.46)
- 12.5.1.3.8 Participant Body - Transcriber 1.2.40.0.34.6.0.11.9.14
- 12.5.1.3.9 Informant Body 1.2.40.0.34.6.0.11.9.3
- 12.5.1.3.10 Vaccine Product 1.2.40.0.34.6.0.11.9.32
- 12.5.1.3.11 Impfrelevante Erkrankungen Problem Concern Entry 1.2.40.0.34.6.0.11.3.8
- 12.5.1.3.12 Impfrelevante Erkrankungen Problem Entry1.2.40.0.34.6.0.11.3.9
- 12.5.1.3.13 Immunization Entry 1.2.40.0.34.6.0.11.3.1
- 12.5.1.3.14 Immunization Recommendation Entry 1.2.40.0.34.6.0.11.3.3
- 12.5.1.3.15 Immunization Schedule Entry 1.2.40.0.34.6.0.11.3.10
- 12.5.1.3.16 Immunization Target Entry 1.2.40.0.34.6.0.11.3.2
- 12.5.1.3.17 Expositionsrisiko Problem Entry 1.2.40.0.34.6.0.11.3.21
- 12.5.1.3.18 Expositionsrisiko Problem Concern Entry 1.2.40.0.34.6.0.11.3.20
- 12.5.1.3.19 Antikörper-Bestimmung Laboratory Observation Entry 1.2.40.0.34.6.0.11.3.16
- 12.5.1.3.20 Beilagen 1.2.40.0.34.6.0.11.2.71
- 12.5.1.3.21 Leitfaden diverse Kapitel
- 12.5.1.4 Nebenversion 1.1.1+20210601
- 12.5.1.5 Nebenversion 1.1.0+20210512
- 12.5.1 Nebenversionen
1 Zusammenfassung
Dieser Leitfaden beschreibt die Datenaustauschformate für den e-Impfpass in Österreich.
Die Grundlage der Datenaustauschformate ist der internationale CDA-Standard, der sich in ELGA bereits bewährt hat. Er erlaubt es Sender und Empfänger, sich ohne vorherige Absprache zu verstehen. Als Basisspezifikation wurde das "Immunization Content (IC)" Inhaltsprofil aus dem IHE Technical Framework "Patient Care Coordination (PCC)" ausgewählt, das auch im Schweizerischen eImpfdossier [1] verwendet wird.
Als Datenaustauschformate dienen zwei unterschiedliche CDA-Dokument-Templates:
- Kompletter Immunisierungsstatus: Das von der zentralen Anwendung abrufbare Datenaustauschformat. Es enthält alle verfügbaren Informationen zum Immunisierungsstatus einer Person (Impfungen, impfrelevante Erkrankungen, Antikörper-Bestimmungen) und Impfempfehlungen.
- Update Immunisierungsstatus: Das Datenaustauschformat, das an die zentrale Anwendung gesendet wird, um Änderungen am Immunisierungsstatus einer Person zu dokumentieren (Impfungen, impfrelevante Erkrankungen, Antikörper-Bestimmungen) sowie individuell angepasste Impfempfehlungen, die durch den impfenden Arzt festgelegt werden.
Die Notation der Spezifikation der Datenaustauschformate folgt der "Art-Decor"-Schreibweise, die auf einer eigenen Seite (Art-Decor-Tabellen verstehen) erläutert wird.
Der vorgesehene Ablauf des Datenaustausches wird im Kapitel Anwendungsfälle beschrieben.
Die gesetzliche Grundlage für den e-Impfpass ist das Gesundheitstelematikgesetz (GTelG 5. Abschnitt: eHealth-Anwendungen, 2. Unterabschnitt: § 24b bis § 24g) und die zugehörige eHealth-Verordnung (eHealthV 2020).
Dieser Leitfaden ist ein nationaler HL7©-Standard, der technisch und inhaltlich im Rahmen des Abstimmungsverfahrens 2019-1 ("Ballot") normiert wurde.
Kommentare zu diesem Leitfaden können an cda@elga.gv.at gesendet werden.
1.1 Impressum
Medieneigentümer, Herausgeber, Hersteller, Verleger:
ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: 01. 2127050.
Internet: www.elga.gv.at
Email: cda@elga.gv.at.
Geschäftsführer: DI Dr. Günter Rauchegger, DI(FH) Dr. Franz Leisch
Redaktion, Projektleitung, Koordination:
Mag. Dr. Stefan Sabutsch, stefan.sabutsch@elga.gv.at
Abbildungen: © ELGA GmbH
Nutzung: Das Dokument enthält geistiges Eigentum der Health Level Seven® Int. und HL7® Austria, Franckstrasse 41/5/14, 8010 Graz; www.hl7.at.
Die Nutzung ist zum Zweck der Erstellung medizinischer Dokumente ohne Lizenz- und Nutzungsgebühren ausdrücklich erlaubt. Andere Arten der Nutzung und auch auszugsweise Wiedergabe bedürfen der Genehmigung des Medieneigentümers.
Download unter www.gesundheit.gv.at und www.elga.gv.at/cda
1.2 Haftungsausschluss
Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht. Die ELGA GmbH weist ausdrücklich darauf hin, dass es sich bei dem vorliegenden Leitfaden um unverbindliche Arbeitsergebnisse handelt, die zur Anwendung empfohlen werden. Ein allfälliger Widerspruch zum geltenden Recht ist jedenfalls unerwünscht und von den Erstellern des Dokumentes nicht beabsichtigt.
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 ELGA GmbH erhoben und/oder abgeleitet werden.
1.3 Sprachliche Gleichbehandlung
Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer und Frauen 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.
1.4 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
1.4.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.
1.4.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.
1.4.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) [2] | Regenstrief Institute, Inc. [3] |
| Unified Code for Units of Measure (UCUM) [4] | Regenstrief Institute, Inc. [3] |
| International Classification of Diseases (ICD) [5] | World Health Organization (WHO) [6] |
| ICD-10 BM*G*[7] | Für Gesundheit zuständiges Bundesministerium www.sozialministerium.at |
| Anatomical Therapeutic Chemical Classification System (ATC) [8] | World Health Organization (WHO)[6] |
| Pharmazentralnummer (PZN) | ARGE Pharma im Fachverband der chemischen Industrie Österreichs (FCIO) der Wirtschaftskammern Österreichs (WKO) [9] |
| EDQM-Codes | Europäisches Direktorat für die Qualität von Arzneimitteln [10] |
| 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. [11], [12] |
Die Terminologien werden am österreichischen Terminologieserver zur Verfügung gestellt.
1.5 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[13] gilt. 2009 wurde die Release 2.0 als ISO-Standard ISO/HL7 27932:2009 publiziert[14].
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[15] folgen dem Basisstandard HL7 Version 3[16] mit seinem Referenz-Informationsmodell (RIM). Dieser Leitfaden verwendet das HL7-Template-Austauschformat zur Definition der "Bausteine" (Templates) und ART-DECOR® [17] als Spezifikationsplattform.
- HL7 Clinical Document Architecture (CDA) [18]
- HL7 Referenz-Informationsmodell (RIM)[19]
- HL7 V3 Datentypen [20]
- HL7 Template-Austauschformat Specification and Use of Reusable Information Constraint Templates, Release 1[21]
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)[22], 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.
1.6 PDF-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
2 Einleitung
2.1 Ausgangslage und Motivation
Im österreichischen Impfwesen wird der papierbasierte Impfpass als zentrales Instrument für die Dokumentation und den Nachweis von Impfungen verwendet. Obwohl sich der papierbasierte Impfpass über viele Jahre bewährt hat, so erfüllt er nicht mehr die Anforderungen an ein modernes Gesundheitsvorsorgeinstrument. Der Papierimpfpass geht oft verloren, die teilweise handschriftlichen Aufzeichnungen sind schwierig zu entziffern und nicht vollständig bzw. über mehrere Impfpässe verteilt. Hier soll der e-Impfpass ansetzen und valide und übersichtliche Daten schaffen. Zudem sollen auf Basis des nationalen Impfplans persönliche Impfempfehlungen ausgegeben werden. Auf Beschluss der Bundeszielsteuerungskommission wurde daher die Umsetzung der Pilotierung des elektronischen Impfpasses (e-Impfpass) durch die ELGA GmbH beschlossen. Mit dem Ziel einer optimierten Impfversorgung der österreichischen Bevölkerung ist der Impfausweis der Zukunft ein elektronisches Dokument (e-Impfpass). Um den Austausch dieser Informationen zwischen allen beteiligten Institutionen und Personen zu unterstützen, muss ein einheitliches Austauschformat geschaffen und definiert werden, welches in diesem Dokument beschrieben wird.
2.2 Zweck des Dokuments
Das vorliegende Dokument beschreibt die einheitlichen Austauschformate und Inhalte für den Informationsaustausch für den "e-Impfpass" für das Österreichische Gesundheitswesen. Diese Spezifikation ist das Resultat einer Harmonisierungsarbeit mit dem Ziel, Impfeinträge innerhalb der österreichischen "Elektronischen Gesundheitsakte" (ELGA) als abgestimmte und einheitlich strukturierte Dokumente darzustellen. Der vorliegende Implementierungsleitfaden beinhaltet daher Spezifikationen für die semantische Interoperabilität von Systemen rund um den e-Impfpass inkl. der elektronische Anfragen von Impfempfehlungen. Die Grundlage der Datenaustauschformate ist der internationale CDA-Standard, der sich in ELGA bereits bewährt hat. Als Basisspezifikation wurde das "Immunization Content (IC)" Inhaltsprofil aus dem IHE Technical Framework "Patient Care Coordination (PCC)" ausgewählt, das auch im Schweizerischen eImpfdossier verwendet wird. Das vorliegende Dokument wurde von einer Arbeitsgruppe von Vertretern des Gesundheitswesens, der Wissenschaft und der Wirtschaft sowie von der Health Level 7 (HL7) Anwendergruppe Österreich erstellt. Der Leitfaden basiert auf den vorangegangenen Erfahrungen in der Erstellung von Implementierungsleitfäden für ELGA CDA Dokumente. Die Header enthalten zum einen administrative Daten (allgemeine Angaben zum Dokument, Daten zum Patienten, usw.) und dienen zum anderen auch als Quelle für die Metadaten, die bei der Registrierung des Dokuments in ELGA verwendet werden. Der Header orientiert sich am bestehenden "Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente", enthält aber Verallgemeinerungen, da es sich um ein e-Health-Dokument und nicht um ein ELGA-Dokument handelt. Die medizinisch relevanten Anteile zur Erfassung des Immunisierungsstatus sind im so genannten "Body" enthalten.
2.3 Zielgruppe
Anwender dieses Dokuments sind Softwareentwickler und Berater, die allgemein mit Implementierungen und Integrationen im e-Health-Umfeld, insbesondere des Projekts e-Impfpass, aber auch mit ELGA e-Befunden oder e-Medikation betraut sind. Weiters richtet sich der Leitfaden an alle an der Erstellung von Gesundheitsdaten und Gesundheitsdokumenten beteiligten Personen, einschließlich der Endbenutzer der medizinischen Softwaresysteme und der Angehörigen von Gesundheitsberufen.
3 Informationen über dieses Dokument
3.1 Verbindlichkeit
Ziel dieses Implementierungsleitfadens ist die Beschreibung von Struktur, Format und Standards von medizinischen Dokumenten für den Elektronischen Impfpass gem. Gesundheitstelematikgesetz 2012, BGBl.I Nr.111/2012 (GTelG 2012) sowie den darauf fußenden Novellen und Verordnungen. Die im Implementierungsleitfaden getroffenen Festlegungen für Inhalt, Struktur, Format und Codierung sind somit verbindlich.
Der Leitfaden in seiner jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind vom zuständigen Minister auf www.gesundheit.gv.at zu veröffentlichen. Der Zeitplan zur Bereitstellung der Datenaustauschformate wird durch das Gesundheitstelematikgesetz 2012 (GTelG 2012) und darauf basierenden Durchführungsverordnungen durch den zuständigen Bundesminister vorgegeben. Hauptversionen, also Aktualisierungen des Implementierungsleitfadens, welche zusätzliche verpflichtende Konformitätskriterien enthalten ("Mandatory" (M), "Required" (R) und "Fixed" (F)), sind mit ihren Fristen zur Bereitstellung per Verordnung kundzumachen. Andere Aktualisierungen (Nebenversionen) dürfen auch ohne Änderung dieser Verordnung unter www.gesundheit.gv.at veröffentlicht werden.
Die Anwendung dieses Implementierungsleitfadens hat im Einklang mit österreichischem und europäischem Recht, insbesondere mit den relevanten Materiengesetzen (z.B. Ärztegesetz 1998, Apothekenbetriebsordnung 2005, Krankenanstalten- und Kuranstaltengesetz, Gesundheits- und Krankenpflegegesetz, Rezeptpflichtgesetz, Datenschutzgesetz , Gesundheitstelematikgesetz 2012, DSGVO) zu erfolgen. Technische Möglichkeiten können gesetzliche Bestimmungen selbstverständlich nicht verändern, vielmehr sind die technischen Möglichkeiten im Einklang mit den Gesetzen zu nutzen.
3.2 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 gilt. |
|
- IHE Integrationsprofile Patient Care Coordination [23]
- HL7 Clinical Document Architecture (CDA) [24]
- Version 3 Product Suite (inkl. RIM) [25]
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria), 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.
3.3 Wichtige unterstützende Materialien
Auf der Website e-Impfpass Guide werden unter anderem folgende Materialien zur Verfügung gestellt:
- die PDF-Version dieses Leitfadens
- Beispieldokumente für den "Kompletten Immunisierungsstatus" und für "Update Immunisierungsstatus"
- Schematron-Prüfregeln
- Design-Beispiel
Die im Weiteren angeführten Templatespezifikationen wurden im Art-Decor Projektrepository e-Impfpass erstellt und können dort eingesehen werden. Eine Anleitung zum Verständnis der Art-Decor-Notation finden Sie im Artikel Art-Decor-Tabellen verstehen.
Weitere Informationen zu CDA-Leitfäden werden auf der Website der ELGA GmbH zur Unterstützung bereitgestellt:
- Beispieldokumente
- Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
- CDA2PDF Suite (Tool zur Erzeugung einer PDF-Datei zur Ausgabe am Drucker)
- Schematron-Dateien für die Prüfung der Konformität ("Richtigkeit") von CDA Dateien
- Vorgaben zur Registrierung von CDA-Dokumenten (Leitfaden für XDS-Metadaten)
- Hinweise für die zu verwendenden Terminologien
- Leitfaden zur richtigen Verwendung von Terminologien
Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an cda@elga.gv.at gesendet werden. Weitere Informationen finden Sie unter www.elga.gv.at/CDA.
4 Harmonisierung
Dieser Implementierungsleitfaden entstand durch die Harmonisierungsarbeit der Arbeitsgruppe e-Impfpass, die im Zeitraum von September 2018 bis Februar 2019 tagte. Die Teilnehmer der Arbeitsgruppe wurden durch ihre Organisation delegiert.
Die Arbeitsgruppe harmonisierte primär die inhaltlichen Vorgaben und soweit möglich die zu verwendenden Terminologien (Value Sets). Die Formulierung der technischen Spezifikation des CDA Implementierungsleitfadens e-Impfpass erfolgte durch die ELGA GmbH parallel bzw. nach der inhaltlichen Festlegung.
Der Leitfaden wird in einem technischen Abstimmungsverfahren durch die HL7 Austria ("Ballot") zu einem österreichischen Standard. Die Verbindlichkeit zur Anwendung soll durch eine Novellierung des Gesundheitstelematikgesetzes 2012, BGBl.I Nr.111/2012 begründet werden.
4.1 Autoren und Mitwirkende
Der vorliegende Leitfaden wurde unter der Leitung der ELGA GmbH von den Autoren und unter Mitwirkung der genannten Personen (Mitglieder der Arbeitsgruppe) erstellt. Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht. Die HL7 Austria und die ELGA GmbH genehmigen ausdrücklich die Anwendung des Leitfadens ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente und weisen darauf hin, dass dies mit dem Einverständnis aller Mitwirkenden erfolgt.
4.1.1 Autoren
Das Redaktionsteam bestand aus folgenden Personen:
| Name | Organisation | Rolle |
|---|---|---|
| Mag. Dr. Stefan Sabutsch | ELGA GmbH, HL7 Austria | Autor, Herausgeber |
| DI Andrea Klostermann | ELGA GmbH | Autor |
| DI Oliver Kuttin | ELGA GmbH | Autor |
Mit Beiträgen von: Tony Schaller (medshare GmbH), Stephan Rainer-Sablatnig (ELGA GmbH), Nina Svec, M.A. (ELGA GmbH), Gabriel Kleinoscheg, MSc. (ELGA GmbH), DI Nikola Tanjga (ELGA GmbH), Helene Prenner (ELGA GmbH)
4.1.2 Mitwirkende
Teilnehmer der Arbeitsgruppe e-Impfpass (in alphabetischer Reihenfolge): Anton Angerer (at.Software / WAVM), Patrick Awart (Atos), Elisabeth Bischof (Landessanitätsdirektion OÖ), DI (FH) Reindert Buter (Buter GmbH), Sabine Eder (Landessanitätsdirektion NÖ), Mag. Alexander Ertl (BASG / AGES), Dr. Katja Fischer (BMASGK), Günter Franz (Landessanitätsdirektion Salzburg), W HR Dr. Ernst Gschiel (Landessanitätsdirektion Burgenland), Dr. Eva Heinzl (Landessanitätsdirektion OÖ), Ingrid Huber (Landessanitätsdirektion NÖ), OPhysR Dr.in Ursula Karnthaler (Landessanitätsdirektion Wien), Herbert Karpf, BA (Landessanitätsdirektion Kärnten), HR Dr. med. univ. Franz Katzgraber (Landessanitätsdirektion Tirol), DI Andrea Klostermann (ELGA GmbH), DI Oliver Kuttin (ELGA GmbH), Dr. Irmgard Lechner (Landessanitätsdirektion NÖ), Ruprecht Leitner (Apothekerverlag), Dr. Anita Luckner-Hornischer (Landessanitätsdirektion Tirol), Dr. Lukas Murajda, PhD, MSc (Landessanitätsdirektion Salzburg), DI Michael Nöhammer (ÖÄK), Christopher Ozvald (BMASGK), Dr. Georg Palmisano (Landessanitätsdirektion OÖ), Dr. Maria Paulke-Korinek (BMASGK), Mag. Daniela Philadelphy (BASG / AGES), Daniela Piererfellner (Landessanitätsdirektion OÖ), Maria Pramhas (Land Salzburg - Impfadatenbank), Dr. Daniel Prenninger (Landessanitätsdirektion Burgenland), Mag. Margit Pufitsch-Weber (Wissenschaftliche Akademie für Vorsorgemedizin), Stephan Rainer-Sablatnig (ELGA GmbH), Dr. Stefan Sabutsch (ELGA GmbH), Robert Scharinger (BMASGK), Dr.Rudolf Schmitzberger (Impfreferat Österr Ärztekammer), DI Mag. Birgit Scholz (ELGA GmbH), Dr. Christoph Schweighofer (ÖÄK), Carina Seerainer, MSc (ELGA GmbH), Nina Sjencic (ELGA GmbH), Landessanitätsdirektorin OSRin Dr.in Karin SPACEK (Landessanitätsdirektion Wien (Magistratsabteilung 15 - Gesundheitsdienst der Stadt Wien)), Mag. Stefan Spitzbart (Hauptverband), Stephanie Stürzenbecher, BA MA (Hauptverband), Dr. Barbara Tucek, MD, MSc (BASG / AGES), Mag. Ilana Ventura, MSc (BMASGK), Dr.med. Heimo Wallenko, MAS (Landessanitätsdirektion Kärnten), Gabriele Wasner (Landessanitätsdirektion OÖ)
5 Begriffsdefinitionen
| Begriff | Definition |
|---|---|
| Zentrale e-Impfpass Anwendung | Die zentrale e-Impfpass Anwendung umfasst die Fachlogiken für den persönlichen e-Impfpass, die persönlichen Impfempfehlungen, statistische Auswertungen und die Abrechnungsunterstützung. |
| Zentrales Impfregister | Das zentrale Impfregister ist eine zentrale Datenbank, in der alle Daten zum Immunisierungsstatus der Patientinnen und Patienten gespeichert werden. Eine Auflistung der gespeicherten Daten ist dem vorliegenden CDA Implementierungsleitfaden für den e-Impfpass zu entnehmen. Die Daten aus dem zentralen Impfregister können, eine entsprechende gesetzliche Grundlage vorausgesetzt, für Funktionen wie zum Beispiel dem "persönlichen e-Impfpass", "Ausbruchsmanagement/Krisenmanagement" oder "Durchimpfungsraten" verwendet werden. |
| Immunisierungseintrag | Im zentralen Impfregister werden nicht nur Informationen zu einer Impfung dokumentiert ("Impfeintrag"), sondern auch weitere Informationen zu Immunisierungen, wie erlangte Immunität durch Krankheit oder Immunitätsnachweise durch Impftiter-Bestimmungen. Die Bezeichnung für die im Impfregister verwalteten Dateneinträge lautet daher "Immunisierungseintrag".
Abgrenzung: Der e-Impfpass umfasst keine passiven Immunisierungen (Verabreichungen von Immunglobulinen) und auch keine Hyposensibilisierungen ("Allergieimpfungen") |
| Persönlicher e-Impfpass | Der persönliche e-Impfpass fasst die Daten aus dem Impfregister zu einer gewissen Person zusammen. Diese Zusammenfassung enthält zumindest die Daten, die auch der Papierimpfpass umfasst (PatientInnendaten, Datum der Impfung, Handelsname des Impfstoffes, Chargenbezeichnung, Name der impfenden Ärztin bzw. des impfenden Arztes). |
| Persönliche Impfempfehlungen (im GTelG als "Impfkalender" definiert) | Die zentrale e-Impfpass Anwendung soll nicht nur der elektronischen Dokumentation von Impfungen dienen, sondern muss auch auf Basis der vorhandenen Impfungen und dem aktuellen, österreichischen Impfplan[26] die nächsten empfohlenen Impfungen und Impfzeitpunkte für die jeweilige Patientin, den jeweiligen Patienten berechnen können. Resultat sind übersichtlich dargestellte und ausdruckbare persönliche Impfempfehlungen über die nächsten anstehenden Impfungen. Im GTelG wird diese Funktionalität als "Impfkalender" bezeichnet, was automatisch mit einer Kalenderdarstellung assoziiert wird. Da sich Impfempfehlungsabstände über mehrere Jahre und Jahrzehnte erstrecken können, werden aufgrund der Benutzerfreundlichkeit und Bedienbarkeit die Impfempfehlungen nicht in Kalenderform, sondern als Listen umgesetzt. |
| Nationaler Impfplan – "Impfplan Österreich" | Der "Impfplan Österreich" wird in enger Zusammenarbeit des Bundesministeriums für Arbeit, Soziales, Gesundheit und Konsumentenschutz und den Mitgliedern des Nationalen Impfgremiums (NIG) nach den neuesten Erkenntnissen der Wissenschaft präzisiert und aktualisiert und veröffentlicht [26]. Er enthält alle aktuellen, nationalen Impfempfehlungen und den damit verbunden Impfintervallen und Impfschemata, als auch die Liste an Impfungen, die ins kostenfreie Kinderimpfprogramm [27]fallen. |
| Impfschema | Empfohlene Impfzeitpunkte werden im sogenannten "Impfschema" festgelegt und stellen ein Regelwerk der Impfdosen zur Erlangung der Grundimmunisierung oder deren Auffrischung dar. Für jeden Impfstoff gibt es ein Impfschema, das angibt, wie viele Impfungen in welchem zeitlichen Abstand zur Grundimmunisierung durchgeführt werden sollen, um den optimalen Impfschutz aufzubauen. Die Abstände zwischen den Impfungen sind immer Mindestabstände, die nur in dringenden Ausnahmefällen unterschritten werden sollten, z.B. wenn eine kurzfristige Auslandsreise ansteht. |
| Dosiskennung (Dosis, Impfdosis) | Das Wort Dosiskennung beschreibt die Reihenfolgenummer in der Sequenz der Impfdosen oder die Teilimpfungen innerhalb eines Impfschemas. Im Leitfaden wird synonym auch das Wort "Impfdosis" oder auch kurz "Dosis" verwendet |
| Kostenfreies Kinderimpfprogramm | Das kostenfreie Kinderimpfprogramm [27] hat zum Ziel, allen in Österreich lebenden Kindern bis zum 15. Lebensjahr Zugang zu den für die öffentliche Gesundheit wichtigen Impfungen zu ermöglichen, ohne dass dafür den Erziehungsberechtigten Kosten erwachsen. Nur so kann erreicht werden, dass die Impfbeteiligung in der Bevölkerung so verbreitet ist, dass auch Personen, die aus bestimmten Gründen nicht geimpft werden können (z.B. Personen mit Immunsuppression), vor einer Ansteckung geschützt sind (Herdenschutz). |
| e-Health-Anwendung vs. ELGA Anwendung | Die zentrale e-Impfpass Anwendung und deren Pilotierung werden entsprechend der Entschließung des Nationalrates als e-Health-Anwendung umgesetzt. Unter "e-Health Anwendung" versteht man den Einsatz von Informations- und Kommunikationstechnologien in gesundheitsbezogenen Produkten, Dienstleistungen und Prozessen. Das GTelG, welches Anpassungen hinsichtlich der Umsetzung des e-Impfpasses beinhaltet, unterscheidet daher zwischen "ELGA-Anwendungen" und "e-Health-Anwendungen":
Während ELGA-Anwendungen ausschließlich von berechtigten ELGA-Gesundheitsdiensteanbietern verwendet werden können, können e-Health-Anwendungen von berechtigten ELGA-Gesundheitsdiensteanbietern und weiteren definierten Gesundheitsdiensteanbietern genutzt werden. Die Berechtigungen für e-Health- und ELGA-Anwendungen sind pro Gesundheitsdiensteanbieter gesetzlich vorgegeben. |
| Elektronischer Impfpass als e-Health Anwendung | Mit der Umsetzung des elektronischen Impfpasses als e-Health Anwendung werden öffentliche Interessen verfolgt, wie z.B. die Sicherstellung der öffentlichen Gesundheit durch Gesundheitswarnungen, Ausbruchsmanagement sowie Prävention und Kontrolle ansteckender Krankheiten. Insofern ist eine möglichst vollständige und flächendeckende Dokumentation des Immunisierungsstatus der Bevölkerung im öffentlichen Interesse.
|
| Durchimpfungsrate | Damit Personen, die sich nicht gegen gewissen Krankheiten impfen lassen können (z.B. Säuglinge aufgrund des Alters oder Menschen mit chronischen Erkrankungen) vor Übertragung von Infektionskrankheiten geschützt sind, müssen genügend Personen in ihrem Umfeld geimpft sein (Herdenimmunität). Als Indikator zur Bestimmung der Herdenimmunität wird die Durchimpfungsrate bestimmt, die ein wichtiges Instrument zur Unterstützung der nationalen und internationalen hoheitlichen Aufgaben darstellt. Als Ausgangsbasis dienen die im zentralen Impfregister gespeicherten Daten, die für statistische Auswertungen aufbereitet werden müssen. Wie gesetzlich vorgegeben, ist der Personenbezug bis auf Geburtsmonat, Geburtsjahr und Gemeindekennziffer zu entfernen. Übliche Auswertungen sind beispielsweise über gewisse Bevölkerungsjahrgänge, Geschlecht und/oder Regionen/Wohnorte. |
| Krisenmanagement | Die Landessanitätsdirektionen stellen bei Krankheitsausbrüchen ein Krisenmanagement auf, das die Auswertungen der Durchimpfungsraten anfertigt, welche wiederum an das Bundesministerium weitergegeben werden. Im Rahmen des Krisenmanagements bei Krankheitsausbrüchen muss von Kontaktpersonen (z.B. in Schule, Kindergarten, Ordination, Wartebereichen in Ambulanzen) der Impfstatus erhoben werden. |
| Allergie | Als Allergie wird eine überschießende Abwehrreaktion des Immunsystems auf bestimmte Stoffe (Allergene) bezeichnet, die sich in typischen, oft mit entzündlichen Prozessen einhergehenden Symptomen äußert. |
| Impfung | Die empfohlenen Impfungen gemäß Österreichischem Impfplan bieten für die individuelle und öffentliche Gesundheit einen Basisschutz. Die Ärzteschaft soll die empfohlenen Impfungen gemäß dem Österreichischen Impfplan <ref name=Impfplan>, der periodisch aktualisiert wird, ihren Patienten empfehlen. |
| Empfohlene Impfungen für Risikogruppen | Gewisse Impfungen werden für bestimmte Risikogruppen als nutzbringend eingestuft. Die Ärzteschaft soll diese Impfungen den Risikopatienten empfehlen, wenn sie sie mit einem vertretbaren Aufwand erreichen. Die Informationen dazu sind im österreichischen, nationalen Impfplan enthalten [26]. |
| Impferfolg / Immunschutz | Impfungen sind nicht immer zu 100% wirksam. In bestimmten Fällen, wie z.B. der Rötelnimpfung wird der Impferfolg und damit der Immunschutz mittels Messung des "Impftiters" überprüft (z.B. im Rahmen der Schwangerschaftsvorsorge oder bei beruflich exponierten Personen der Impferfolg und Immunschutz gegen das Hepatitis B-Virus). Ein Immunschutz kann auch durch bereits durchgemachte Infektionen zustande kommen und damit den weiteren Impfplan und Impfempfehlungen beeinflussen. |
| Non-Responder ("Impfversager") | Gesunde Personen, die keine Immunität durch eine Impfung erlangen. |
| Impfempfehlung | Impfempfehlungen sind Empfehlungen, welche auf der Grundlage des aktuellen, jährlichen österreichischen Impfplans [26] und des individuellen Impfplanes für eine bestimmte Impfung, einen bestimmten Zeitpunkt oder einer bestimmten Situation abgegeben werden. |
| Impfreaktion | Impfreaktionen sind in der Regel harmlose Beschwerden nach einer verabreichten Impfung im Rahmen der Immunantwort. Sie treten in einem zeitlichen Zusammenhang mit einer Impfung auf. |
| Unerwünschte Impfreaktionen (Nebenwirkungen) | Sogenannte unerwünschte Impferscheinungen können nach der Impfung auftreten (am häufigsten innerhalb der ersten 8 Wochen nach der Impfung). Es besteht eine Pflicht zur Meldung schwerer Impfreaktionen an die BASG.
Als Impfschaden bezeichnet man stärkere Nebenwirkungen oder (dauerhafte) Gesundheitsschädigungen. |
| Impfstelle | Die Impfstelle ist diejenige Person resp. Organisation, welche eine Impfung durchgeführt hat. |
| Der nationale Impfplan – "Impfplan Österreich" | Die Informationen über die in Österreich empfohlenen Impfungen sind im aktuellen jährlichen Österreichischen Impfplan [26] des BMASKG enthalten. Eine Aktualisierung erfolgt jährlich durch das Nationale Impfgremium. |
| Nachtrag | Eine nachträgliche Eintragung einer Impfung, die ein anderer Gesundheitsdiensteanbieter verantwortet und dokumentiert hat. Diese Impfung liegt bereits in einer Primärdokumentation vor (z.B. Papier-Impfpass, lokale Impfdatenbank) und wird aus der Primärdokumentation in den e-Impfpass nachgetragen. Für das Nachtragen gelten andere Anforderungen an die bereitzustellenden Daten als bei der Dokumentation einer aktuellen Impfung: jedenfalls muss die Person erfasst werden, die für die fachliche Richtigkeit des Nachtrags verantwortlich ist ("Nachtragende Person"), aber auch der für die damalige Impfung verantwortliche Arzt, sofern eruierbar. Auch können hier "historische Impfstoffe" erfasst werden, die nicht mehr in Verwendung sind. Eine Nachtragung kann grundsätzlich nur auf Basis eines eindeutig nachvollziehbaren Impfdokuments erfolgen, z.B. über den gelben Papier-Impfpass. Abgrenzung: Beim Nachtrag handelt es sich nicht um das zeitlich verzögerte Dokumentieren einer "eigenen" Impfung, etwa wenn das IT-System gerade nicht verfügbar war. Dazu muss das Impfdatum auch auf einen Zeitpunkt in der Vergangenheit gesetzt werden können, um eine korrekte asynchrone Erfassung der tatsächlichen Impfung durchführen zu können. |
| Hersteller eines Impfstoffes | Unter Hersteller wird in diesem Leitfaden jenes Pharmaunternehmen verstanden, das gleichzeitig der "Zulassungsinhaber“ eines Impfstoffes ist. Wer die verschiedenen Schritte der Herstellung tatsächlich durchführt (wie Gewinnen, Anfertigen, Zubereiten, Be- oder Verarbeiten, Umfüllen einschließlich Abfüllen, Abpacken oder Kennzeichnen), wird nicht näher angegeben. |
6 Technischer Hintergrund
6.1 Allgemeine Richtlinien für die Implementierung des e-Impfpasses
6.1.1 Verwendung von Schlüsselwörtern
Wenn im Text die Verbindlichkeit von Vorgaben angegeben wird, wird das durch Schlüsselwörter gekennzeichnet [gemäß RFC 2119], die in Majuskeln (Großbuchstaben) geschrieben werden. Die Angabe der Verbindlichkeit ersetzt nicht die Angabe von Kardinalität oder Nullwerten (die in HL7 Version 3 als nullFlavors ausgedrückt werden).
- MUSS bedeutet eine verpflichtend einzuhaltende Vorschrift (Gebot). Entspricht den Konformitätskriterien [M] und [R] 1...
- NICHT ERLAUBT formuliert ein verpflichtend einzuhaltendes Verbot. Entspricht dem Konformitätskriterium [NP].
- SOLL oder EMPFOHLEN steht für eine pragmatische Empfehlung. Es ist gewünscht und empfohlen, dass die Anforderung umgesetzt wird, es kann aber Gründe geben, warum dies unterbleibt. Entspricht dem Konformitätskriterium [R] 0...
- KANN oder OPTIONAL (engl. MAY, OPTIONAL) Die Umsetzung der Anforderung ist optional, sie kann auch ohne zwingenden Grund unterbleiben. Entspricht dem Konformitätskriterium [O].
6.1.2 Kardinalität
Die Kardinalität beschreibt, wie oft ein Element innerhalb einer Struktur auftreten kann. Die Kardinalität wird durch ein Intervall zwischen der minimalen und maximalen Anzahl angegeben, getrennt durch "..". Eine unbegrenzte Anzahl wird durch ein "*" angegeben. Daraus ergeben sich mindestens folgende Möglichkeiten: 0..1; 0..*; 1..1; 1..*
6.1.3 Umgang mit optionalen Elementen
Sind Elemente bzw. Attribute als "optional" gekennzeichnet ([O]) so ist ihre Verwendung OPTIONAL, aber es ist NICHT ERLAUBT, dass sie, wenn sie verwendet werden, leer sind. Möchte man ein optionales Element explizit mit einem leeren Wert angeben, so hat dies durch Kennzeichnung mit nullFlavor zu erfolgen.
6.1.4 Legende der Konformitätskriterien
6.1.4.1 Optionalitäten von CDA-Elementen
| Konformitäts-Kriterium | Mögliche Kardinalität | Verwendung von nullFlavor | Beschreibung |
|---|---|---|---|
| [M] | 1..1 1..* |
nicht erlaubt | Das Element MUSS mit einem korrekten "echten" Wert angegeben werden ("mandatory"). nullFlavor oder "Dummy"-Werte sind NICHT ERLAUBT. |
| [NP] | 0..0 | nicht erlaubt | Das Element ist NICHT ERLAUBT ("not permitted"). |
| [R] | 1..1 1..* |
erlaubt | Das Element MUSS in der Instanz vorhanden sein ("required"). Wenn ein Element nicht bekannt ist, ist die Verwendung eines nullFlavors vorgeschrieben, "Dummy"-Werte sind NICHT ERLAUBT. |
| 0..1 0..* |
nicht erlaubt | Das Element SOLL in der Instanz vorhanden sein, sofern bekannt ("required"). Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Ein nullFlavor ist daher NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ("required if known"). | |
| [O] | 0..1 0..* |
erlaubt | Das Element ist OPTIONAL ("optional"). Sender können das Element angeben. Leere optionale Elemente sind nicht zugelassen, sofern kein nullFlavor angewandt wird. |
| [C] | Die Optionalität des Elements variiert in Abhängigkeit von anderen Elementen, Situationen oder Zuständen ("conditional"). Die konkreten Abhängigkeiten sind in Folge angegeben. |
[Tabelle 1]:Legende der Optionalitäten von Elementen
6.1.4.2 Optionalitäten von CDA-Attributen
| Konformitäts-Kriterium | Mögliche Kardinalität | Beschreibung |
|---|---|---|
| [NP] | 0..0 | Das Attribut ist NICHT ERLAUBT. ("not permitted") |
| [R] | 1..1 | Das Attribut MUSS in der Instanz vorhanden sein. ("required") |
| [O] | 0..1 | Das Attribut ist OPTIONAL. ("optional") |
| [F] | 0..1
1..1 |
Wenn das Attribut angegeben wird, ist ein fixer Wert vorgeschrieben. ("fixed")
Für das Attribut ist ein fixer Wert vorgeschrieben. ("fixed") |
[Tabelle 2]:Legende der Optionalitäten von Attributen
6.1.5 Der nullFlavor
Das Attribut @nullFlavor dient zur Kennzeichnung, dass ein Element nicht seiner Entsprechung gemäß befüllt werden kann. Die konkrete Anwendung des @nullFlavor Attributs ist im Rahmen dieser Implementierungsleitfäden nur erlaubt, wenn er explizit in der Spezifikation eines Elementes angegeben ist. Für codierte Elemente ist ein nullFlavor für unbekannte und fehlende Information nach Möglichkeit zu vermeiden, bevorzugt ist die Verwendung eines Codes mit demselben Informationsgehalt (etwa für "keine Allergie bekannt" das SNOMED Konzept 716186003 "No known allergy").
Beispiel für ein Element, welches mit dem @nullFlavor versehen wurde:
<id nullFlavor="UNK" />
Wenn in einem Element ein nullFlavor angegeben wurde, kann nicht gleichzeitig ein anderes Attribut eingetragen werden.
nullFlavor Beispiele:
| nullFlavor | displayName | Deutsche Übersetzung | Anwendung |
|---|---|---|---|
| NI | NoInformation | keine Information vorhanden | wenn es keine Informationen gibt |
| UNK | Unknown | unbekannt | wenn es Informationen gibt, diese aber unbekannt sind |
| MSK | Masked | maskiert | wenn es Informationen gibt, diese aber nicht bekannt gegeben werden (vertraulich, nicht freigegeben) |
| NA | Not applicable | nicht anwendbar | wenn keine Codierung verfügbar ist |
| OTH | Other | Andere | wenn eine Codierung nur in einem alternativen Codesystem verfügbar ist |
[Tabelle 3]: nullFlavor-Beispiele aus Value-Set ELGA_nullFlavor
6.1.6 Maximum-Set
Das CDA Modell beschreibt ein höchst umfangreiches Schema von Informationselementen und bietet in manchen Bereichen über rekursive, beliebig tief verschachtelbare Elemente eine theoretisch unendlich hohe Anzahl von Möglichkeiten, Informationen abzulegen. Die vollständige Beschreibung und Definition aller Elemente in einem Implementierungsleitfaden wäre daher äußerst aufwändig und ist in den ELGA Implementierungsleitfäden nicht erfolgt.
Vielmehr beschreiben die ELGA Implementierungsleitfäden lediglich jene Elemente, die erlaubt sind. Die Verwendung aller nicht angegebenen Elemente und Attribute ist NICHT ERLAUBT. Für alle Templates gelten die im Kapitel Datentypen angegebenen Einschränkungen. Die ELGA Implementierungsleitfäden beschreiben daher ein sogenanntes "Maximum-Set", Die ELGA Templates sind demnach als "closed templates" entsprechend dem HL7 Templates Standard zu betrachten.
Elemente oder Attribute, die nicht vom Allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden, sind NICHT ERLAUBT.
6.1.6.1 Ausnahmen
Für diese Regel existieren nur die im Folgenden genannten Ausnahmen:
6.1.6.1.1 Ausnahme: "templateId"
templateId-Elemente KÖNNEN bei Bedarf an allen laut CDA-Schema möglichen Stellen verwendet werden. Wenn bereits templateId-Elemente laut Spezifikation vorgeschrieben sind, KÖNNEN beliebig viele weitere templateId-Elemente angegeben werden.
6.1.6.1.2 Ausnahme: Fixierte Attribute
Attribute, die gem. CDA-Schema mit "fixed" angegeben sind, haben einen festen Wert, daher können diese Attribute auch weggelassen werden. Diese Attribute werden daher üblicherweise nicht beschrieben und angegeben. Die Angabe von fixierten Attributen oder Attributen mit ihrem gem. CDA-Schema definierten Default-Wert ist erlaubt, auch wenn diese nicht explizit im Leitfaden beschrieben sind.
6.1.6.1.3 Explizit angegebene Ausnahmen
Im speziellen Implementierungsleitfaden KÖNNEN bestimmte Sektionen als "offene Templates" definiert werden und Ausnahmen für Subsektionen und Entries zulassen.
6.1.6.2 Hinweis zur Implementierung weiterverarbeitender Software
CDA-Dokumente können unter Umständen "fremde" Elemente oder Attribute enthalten, die der "Maximum-Set" Vorschrift dieses Leitfadens widersprechen (z.B. aufgrund von Software-Fehlern). Sollten derartige Elemente oder Attribute im CDA-Dokument vorhanden sein, soll weiterverarbeitende Software so implementiert sein, dass dies nicht zu Fehlern in der Weiterverarbeitung der Dokumente führt.
6.1.7 Value Sets
Ein Value Set ist eine eindeutig identifizierbare und versionierte Sicht auf ein oder mehrere Codesysteme. Es kann als Zusammenstellung von einem oder mehreren Codes aus einem oder mehreren Codesysteme gesehen werden. Ein Value Set enthält die Codes selbst und die Information über die Herkunft des Codes (das Source-Codesystem).
Beispiele für Value-Sets: "ELGA_NullFlavor", "ELGA_Dokumentenklassen".
Wo immer in den CDA Implementierungsleitfäden eine Werteauswahl getroffen werden kann, wird ein passendes Value Set mit einem eindeutigen Namen angegeben. Sämtliche in den Implementierungsleitfäden verwendeten Value Sets werden am österreichischen Terminologieserver publiziert: https://termpub.gesundheit.gv.at/.
Value Sets sind nicht nur durch einen eindeutigen Namen, sondern auch durch eine OID, und eine Versionsnummer gekennzeichnet. Weiters werden Gültigkeitsstatus und ein "Gültig ab"-Datum angegeben.
Hinweise zum korrekten Umgang mit Terminologien finden sich im "Leitfaden für den Umgang mit Terminologien in ELGA" [TERMLEIT].
6.1.7.1 Änderbarkeit von Value Sets
Inhalte von Value Sets können sich ändern, der Name und die OID eines Value Sets bleiben aber gleich. Bei neuen Versionen werden Versionsnummer, Änderungsdatum und "Gültig ab"-Datum (effectiveDate) angegeben. Damit kann die Gültigkeit zu einer bestimmten Zeit rekonstruiert werden.
In Ausnahmen kann bei der Definition eines Value Sets angegeben werden, dass es nicht geändert oder versioniert werden darf (Property "Immutability").
6.1.7.2 Value Set Binding
Für ELGA gilt grundsätzlich eine DYNAMISCHE Bindung an Value Sets. Das bedeutet, dass immer die aktuell am Terminologieserver publizierte Version eines Value Sets anzuwenden ist. (Das Setzen des entsprechenden Schlüsselworts DYNAMIC ist daher in den Leitfäden optional).
Für jedes Value Set ist auch ein Zeitpunkt angegeben, an dem es Gültigkeit erlangt ("Gültig ab"), das ist für Value Sets wichtig, die schon vor ihrem Inkrafttreten veröffentlicht werden.
Value Sets können auch STATISCH an ein Code-Element gebunden werden. Das wird gekennzeichnet durch die Angabe des Value Sets mit Name, OID, Version und "Gültig ab"-Datum (effectiveDate) sowie dem Schlüsselwort STATIC.
6.1.8 PDF Format-Vorschrift
PDF-Attachments kommen im e-Impfpass nicht zur Anwendung.
6.1.9 Größenbeschränkung von eingebetteten Objekten
In CDA Dokumenten können verschiedene Objekte (z.B. PDF-Dokumente, Bilder) eingebettet werden (siehe "Eingebettetes Objekt Entry").
Dieser Implementierungsleitfaden schreibt keine Größenbeschränkung für diese Objekte vor, es wird allerdings EMPFOHLEN, diese in Bezug auf Anzahl und Speicherbedarf so klein wie möglich zu halten. Es liegt in der Verantwortung des Erstellers, die Größe der über ELGA bereitgestellten CDA-Dateien etwa durch Verringerung der Auflösung oder der Anzahl der Einzelbilder auf eine sinnvolle und angemessene Größe zu beschränken.
Damit beim Download keine unnötigen Verzögerungen verursacht werden, SOLL die Gesamtgröße der Datei 20 MB nicht überschreiten.6
6 Aktuell wird von ELGA die Größe von Doumenten auf 20MB beschränkt.
6.1.10 Verbot von CDATA
Die Verwendung von CDATA-Abschnitten (<![CDATA[…]]>), also von Zeichenketten, die vom Parser nicht als XML-Quellcode interpretiert werden können, ist für ELGA CDA Dokumente generell NICHT ERLAUBT.
7 Datentypen
Im folgenden Abschnitt werden nur die Datentypen beschrieben, die in e-Impfpass CDA-Dokumenten zur Anwendung kommen. Für weiterführende Informationen wird auf den zugrundeliegenden Standard Health Level Seven Version 3 (V3), Normative Edition verwiesen.
7.1 Identifikations-Elemente
7.1.1 id-Element II
Identifikationselemente erlauben die global eindeutige Identifikation durch Verwendung von Objektidentifikatoren (kurz "OID"), gemäß dem in ISO/IEC 9834-1 normierten Mechanismus zur weltweit eindeutigen Kennzeichnung von Informationsobjekten [OIDLEIT]. Die relevanten OID werden im OID-Portal für das Österreichische Gesundheitswesen7 registriert und veröffentlicht.
Identifikationselemente können im id-Element grundsätzlich auf zweierlei Arten angegeben werden:
- Methode 1: Angabe der ID sowie einer OID der ID-Liste, aus der die ID stammt
- Methode 2: Direkte Angabe der ID in Form einer OID. Alternativ zu OID kann hier auch eine UUID gemäß Standard ISO/IEC 9834-8:2014 verwendet werden, wobei die Buchstaben A-F der Hexadezimalzahlen in Großschreibung angegeben werden MÜSSEN.
7 OID Portal für das Österreichische Gesundheitswesen: https://www.gesundheit.gv.at/OID_Frontend/
7.1.1.1 Strukturbeispiele
Methode 1:
<!—
Angabe der OID der ID-Liste in @root
sowie der eigentlichen ID in @extension
-->
<id root="1.2.40.0.34.99.111.1.1"
extension="134F989"
assigningAuthorityName="KH Eisenstadt" />
Methode 2:
<!-- Angabe einer OID als direkten Identifikator -->
<id root="1.2.40.0.34.99.111.0.1"
assigningAuthorityName="KH Eisenstadt" />
<!-- Angabe einer UUID als direkten Identifikator -->
<id root="6B48B496-C68E-CD08-55D4-B40CAC520F28"
assigningAuthorityName="KH Eisenstadt" />
7.1.1.2 Spezifikation
Bei II Elementen werden, sofern nicht anders spezifiziert, immer die folgenden Attribute angegeben.
| Element/Attribut | DT | Kard | Konf | Beschreibung | |
|---|---|---|---|---|---|
| Id | II | ID | |||
| @root | uid | 1..1 | M | Methode 1: OID der ID-Liste, der die ID angehört
Methode 2: OID oder UUID des Objekts Die Hexadezimalzahlen A-F der UUID MÜSSEN bei der Verwendung in HL7 CDA in Großschreibung angegeben werden | |
| @extension | st | 0..1 | C | ||
| Konditioinale Konformität: Methode 1 Methode 2 |
1..1 0..0 |
M NP |
ID des Objekts aus der ID-Liste | ||
| @assigningAuthorityName | st | 0..1 | O | Klartext-Darstellung der die ID ausgebenden Stelle | |
7.1.1.3 Vorschriften für bereits definierte ID-Arten
Die folgenden Unterkapitel zeigen IDs, die in CDA-Dokumenten zur Anwendung kommen können.
7.1.1.3.1 ID aus dem GDA-Index
Die Vorgaben für IDs aus dem GDA-Index sind in der Basiskomponente "GDA-Index" beschrieben.
Informationen zum österreichischen OID-Konzept finden Sie online auf dem "OID Portal Österreich": https://www.gesundheit.gv.at/OID_Frontend/index.jsp?section=1
7.1.1.3.2 DVR-Nummer
Die Datenverarbeitungsregister-Nummer (DVR-Nummer) des jeweiligen Gesundheitsdienstleisters kann als zusätzliches ID-Element abgebildet werden.
7.1.1.3.2.1 Spezifikation
| Element/Attribut | DT | Kard | Konf | Beschreibung | |
|---|---|---|---|---|---|
| Id | II | ID | |||
| @root | uid | 1..1 | M | Fester Wert: 1.2.40.0.10.2.0.2.1 | |
| @extension | st | 1..1 | M | Datenverarbeitungsregister-Nummer (DVR-Nummer) z.B.: 0000137 | |
| @assigningAuthorityName | st | 0..1 | O | Fester Wert: Österreichisches Datenverarbeitungsregister | |
7.1.1.3.3 ATU Nummer
Die Umsatzsteueridentifikationsnummer (ATU-Nummer) des jeweiligen Gesundheits-dienstleisters kann als zusätzliches ID-Element abgebildet werden.
7.1.1.3.3.1 Spezifikation
| Element/Attribut | DT | Kard | Konf | Beschreibung | |
|---|---|---|---|---|---|
| Id | II | ID | |||
| @root | uid | 1..1 | M | Fester Wert: 1.2.40.0.10.2.0.3.1 | |
| @extension | st | 1..1 | M | Umsatzsteueridentifikationsnummer (ATU-Nummer) z.B.: ATU56658245 | |
| @assigningAuthorityName | st | 0..1 | O | Fester Wert: Österreichisches Finanzamt | |
7.1.1.3.4 Bankverbindung
Die einzelnen Elemente einer Bankverbindung (IBAN, SWIFT-Adresse oder BIC) können jeweils als eigene ID-Elemente abgebildet werden. Bankleitzahl und Kontonummer werden nicht mehr unterstützt.
7.1.1.3.4.1 Spezifikation: IBAN
| Element/Attribut | DT | Kard | Konf | Beschreibung | |
|---|---|---|---|---|---|
| Id | II | ID | |||
| @root | uid | 1..1 | M | Fester Wert: 1.0.13616 | |
| @extension | st | 1..1 | M | IBAN z.B.: 1200052066543301 | |
| @assigningAuthorityName | st | 0..1 | O | Fester Wert: Society for Worldwide Interbank Financial Telecommunication | |
7.1.1.3.4.2 Spezifikation: SWIFT-Adresse oder BIC
| Element/Attribut | DT | Kard | Konf | Beschreibung | |
|---|---|---|---|---|---|
| Id | II | ID | |||
| @root | uid | 1..1 | M | Fester Wert: 1.0.9362 | |
| @extension | st | 1..1 | M | SWIFT/BIC z.B.: BKAUATWW | |
| @assigningAuthorityName | st | 0..1 | O | Fester Wert: Society for Worldwide Interbank Financial Telecommunication | |
7.2 Codierungs-Elemente
Mit Codierungselementen können Konzepte über einen Code und der Angabe des Terminologie- bzw des Codesystems, aus dem der Code stammt, ausgedrückt werden.
7.2.1 code-Element CE CWE
Begriffsdefinitionen: CE "Coded with Equivalents", CWE "Coded with Exceptions" (bedeutet, dass das vom Standard angegebene Vokabular empfohlen wird, im Leitfaden können Ausnahmen definiert werden).
7.2.1.1 Strukturbeispiele
7.2.1.1.1 Minimal-Variante um einen Code eindeutig darzustellen:
<code code="E10"
codeSystem="1.2.40.0.34.5.56"/>
7.2.1.1.2 Gebräuchlichste Variante mit zusätzlichem Klartext für Code und Codesystem
<code code="E10"
displayName="Primär insulinabhängiger Diabetes mellitus, Typ-2-Diabetes"
codeSystem="1.2.40.0.34.5.56"
codeSystemName="ICD-10 BMG 2014"/>
7.2.1.1.3 Vollständige-Variante mit direkter Angabe des Textinhalts
<code code="E10"
displayName="Primär insulinabhängiger Diabetes mellitus, Typ-2-Diabetes"
codeSystem="1.2.40.0.34.5.56"
codeSystemName="ICD-10 BMG 2014"
codeSystemVersion="1.00">
<originalText>Diabetes mellitus Typ 2</originalText>
</code>
7.2.1.1.4 Vollständige-Variante mit Referenz in den narrativen Textbereich
<code code="E11"
displayName="Primär insulinabhängiger Diabetes mellitus, Typ-2-Diabetes"
codeSystem="1.2.40.0.34.5.56"
codeSystemName="ICD-10 BMG 2014"
codeSystemVersion="1.00">
<originalText>
<reference value="#entldiag-1"/>
</originalText>
</code>
Für eine detaillierte Beschreibung der Abbildung von Referenzen in den narrativen Bereich siehe Spezifikation und "Zusammenhang Text und Entry".
7.2.1.1.5 Vollständige-Variante mit Referenz in den narrativen Textbereich und Übersetzung in zwei andere Code-Systeme
<code code="E10"
displayName="Primär insulinabhängiger Diabetes mellitus, Typ-2-Diabetes"
codeSystem="1.2.40.0.34.5.56"
codeSystemName="ICD-10 BMG 2014">
<originalText>
<reference value="#entldiag-1"/>
</originalText>
<translation code="46635009"
displayName="Diabetes mellitus type I"
codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT">
<originalText>
<reference value="#entldiag-1"/>
</originalText>
</translation>
<translation code="xyz"
displayName="Diabetes mellitus juvenilis"
codeSystem="9.8.7.6.5.4.3.2.1" codeSystemName="AnderesCodesystem">
<originalText>
<reference value="#entldiag-1"/>
</originalText>
</translation>
</code>
7.2.1.2 Spezifikation
Bei CE CWE Elementen werden, sofern nicht anders spezifiziert, immer die folgenden Attribute angegeben:
| Element/Attribut | DT | Kard | Konf | Beschreibung | |||
|---|---|---|---|---|---|---|---|
| code | CE CWE |
Code Element | |||||
| @code | cs | 1..1 | M | Der eigentliche Code-Wert z.B. E10 | |||
| @displayName | st | 0..1 | R | Die Klartext-Darstellung des Code-Werts, wie vom originalen Codesystem (in der entsprechenden offiziellen Sprachvariante) vorgesehen. z.B. Primär insulinabhängiger Diabetes mellitus, Typ-2-Diabetes Der DisplayName ist nicht zur Weiterverarbeitung und zur Anzeige in einem User-Interface vorgesehen. Die Bedeutung wird durch @code und @codeSystem getragen und SOLL über die entsprechende Codeliste aufgelöst werden. | |||
| @codeSystem | uid | 1..1 | M | Die Identifikation der Codeliste z.B. 1.2.40.0.34.5.56 bzw. die aktuell gültige OID der Codeliste | |||
| @codeSystemName | st | 0..1 | R | Der Klartext-Darstellung der Codeliste z.B. ICD-10 BMG 2014 bzw. die aktuell gültige Version
| |||
| @codeSystemVersion | st | 0..1 | O | Die Versionsnummer der Codeliste z.B. 1.00 | |||
| originalText | ED | 0..1 | O | Textinhalt, der als Basis zur Codierung herangezogen wurde (… von der Person gesehen, als sie den Code vergeben hat). Entweder direkt angegeben als "String" oder indirekt als "Referenz" auf eine Textstelle im narrativen Bereich. Im Falle der direkten Angabe als "String", z.B. Diabetes mellitus Typ 1 | |||
| reference | TEL | 0..1 | C | Referenz Element | |||
| Konditionale Konformität: Wenn indirekte Angabe als "Referenz" Wenn direkte Angabe |
1..1 0..0 |
M NP |
|||||
| @value | url | 1..1 | M | #{generierter_ref_string}-{generierteID} z.B.: #entldiag-1, verweist auf die Textstelle im narrativen Block: <td ID="entldiag-1">Diabetes mellitus Typ 1</td> | |||
| translation | CE CWE |
0..* | O | Beliebig viele optionale Übersetzungen des Codes in andere Codesysteme gemäß derselben Spezifikation (CE CWE) wie das Code-Element selbst. | |||
7.2.2 code-Element CS CNE
Begriffsdefinitionen: CS "Coded simple"; CNE "coded no exceptions" (bedeutet, dass das angegebene Vokabular verwendet werden MUSS)
7.2.2.1 Strukturbeispiel
<languageCode code="de-AT" />
7.2.2.2 Spezifikation
Bei CS CNE Elementen wird nur das folgende Attribut angegeben:
| Element/Attribut | DT | Kard | Konf | Beschreibung | |
|---|---|---|---|---|---|
| code | CS CNE | Code Element | |||
| @code | cs | 1..1 | M | Der eigentliche Code-Wert z.B. de-AT | |
7.3 Zeit-Elemente
Angaben von Zeiten sind in HL7 CDA auf vielerlei Arten möglich. Es können Zeitpunkte, Zeitintervalle bestehend aus Beginn- und Endzeitpunkt, Zeitintervalle bestehend aus Beginnzeitpunkt und Dauer und vielerlei mehr Varianten abgebildet werden. Damit nicht alle beliebigen Varianten implementiert werden müssen, werden die Varianten über den Leitfaden stark eingeschränkt. Weitere Spezifizierungen von Zeit-Elementen können von den speziellen Implementierungsleitfäden vorgenommen werden, z.B. spezifiziert der Implementierungsleitfaden e-Medikation den Datentyp GTS (General Timing Specification) für komplexe Zeitangaben mit Anfang, Ende und Häufigkeit bei den Einnahmeregeln für Medikamente. Allgemein gilt, dass nicht angegebene Datums- und Zeitanteile (also z.B. fehlende Sekunden) mit 0 (Null) angenommen werden. D.h. 201908071633 entspricht 20190807163300.
Normale Angabe von Datum und Zeit
1) Zeitpunkte: Die häufigsten Datums- und Zeitangaben werden über den Datentyp TS.AT.TZ zusammengefasst und im Folgenden unter Einfaches Zeitelement TS beschrieben.
Hier kann der Wert für einen Zeitpunkt auf zweierlei Arten angegeben werden:
- Als taggenaues Datum
- Als Datum mit sekundengenauer Uhrzeit und Zeitzone
2) Zeitintervalle: Bestehen aus Anfangs- und Endpunkt, die wiederum als Zeitpunkt wie oben angegeben werden. Dieser Datentyp wird als Intervall-Zeitelement IVL_TS im Anschluss spezifiziert.
7.3.1 Zeitpunkt: Einfaches Zeitelement TS
7.3.1.1 Nur Datum
Wird ein Zeitpunkt als Datum (ohne Zeit) angegeben, MUSS dies in folgendem Format erfolgen: YYYYMMDD
Bedeutung:
- Jahr 4-stellig +
- Monat 2-stellig +
- Tag 2-stellig
7.3.1.2 Strukturbeispiel
<effectiveTime value="20081224"/> <!-- Datum 24.12.2008 -->
7.3.1.2.1 Datum, Zeit und Zeitzone
Wird ein Zeitpunkt als Datum mit Zeit angegeben, MUSS dies in folgendem Format erfolgen: YYYYMMDDhhmmss[+/-]HHMM
Bedeutung:
- Jahr 4-stellig +
- Monat 2-stellig +
- Tag 2-stellig
- Stunde 2-stellig (24 Stunden Format)
- Minute 2-stellig
- Sekunde 2-stellig
- + oder -
- Zeitzonenverschiebung Stunde 2-stellig
- Zeitzonenverschiebung Minute 2-stellig
Wird in einem Zeitelement zusätzlich zum Datum eine Zeit angegeben, MUSS die Zeitzone verpflichtend angegeben werden!
Die angegebene Zeitzone MUSS die aktuelle Sommerzeitregelung inkludieren.
7.3.1.3 Strukturbeispiele
a) Winterzeit, Österreich (MEZ)
<effectiveTime value="20081224150000+0100"/> <!-- Datum 24.12.2008, um 15:00 Uhr in Europa/Wien (bei Winterzeit) -->
b) Sommerzeit, Österreich (MESZ)
<effectiveTime value="20080824150000+0200"/> <!-- Datum 24.08.2008, um 15:00 Uhr in Europa/Wien (bei Sommerzeit) -->
7.3.1.4 Spezifikation
Bei Zeitpunkten werden, sofern nicht anders spezifiziert, immer die folgenden Unterelemente/Attribute angegeben:
| Element/Attribut | DT | Kard | Konf | Beschreibung | |
|---|---|---|---|---|---|
| effectiveTime | TS.AT.TZ | ||||
| @value | ts | 1..1 | M | Zeitpunkt (bei Zeitangabe mit Zeitzone) z.B. 20131224180000+0100 | |
7.3.2 Zeitintervall: Intervall-Zeitelement IVL_TS
7.3.2.1 Strukturbeispiel
<effectiveTime> <low value="..."/> <!-- Zeitpunkt von --> <high value="..."/> <!-- Zeitpunkt bis --> </effectiveTime>
7.3.2.2 Spezifikation
Bei Zeitintervallen werden, sofern nicht anders spezifiziert, immer die folgenden Unterelemente/Attribute angegeben:
| Element/Attribut | DT | Kard | Konf | Beschreibung | ||
|---|---|---|---|---|---|---|
| effectiveTime | IVL_TS | Zeitintervall | ||||
| low | TS.AT.TZ | 1..1 | R | Beginn des Intervalls Zugelassene nullFlavor: UNK | ||
| @value | ts | 1..1 | M | Zeitpunkt des Beginns des Intervalls | ||
| high | TS.AT.TZ | 1..1 | R | Ende des Intervalls Zugelassene nullFlavor: UNK | ||
| @value | ts | 1..1 | M | Zeitpunkt des Endes des Intervalls | ||
Ein Datum, das mit yyyymmdd angegeben wurde, wird gemäß Standard HL7 CDA Rel.2 interpretiert als yyyymmdd000000 – also der Tag um 0:00:00 Uhr. Wenn also als Zeitraum z.B.: der ganze 1.Dezember 2013 angegeben werden soll, MUSS das so erfolgen:
<low value="20131201"/> <high value="20131202"/>
Für mehr Klarheit empfiehlt sich daher die zusätzliche Angabe der Zeit mit Zeitzone:
<low value="20131201000000+0100"/> <high value="20131201235959+0100"/>
7.3.3 Minimale Datumsangabe: TS.DATE
Eine minimale Datumsangabe umfasst die möglichen Formate: YYYYMMDD, YYYYMM oder YYYY. Dies wird mit dem Datentyp TS.DATE angezeigt.
7.3.3.1 Strukturbeispiel
Datum: "Juni 2008"
<effectiveTime value="200806"/>
7.3.3.2 Spezifikation
Beim Datum TS.DATE werden, sofern nicht anders spezifiziert, immer die folgenden Unterelemente/Attribute angegeben:
| Element/Attribut | DT | Kard | Konf | Beschreibung | |
|---|---|---|---|---|---|
| effectiveTime | TS.DATE | ||||
| @value | ts | 1..1 | M | Datum im Format YYYY, YYYYMM, YYYYMMDD z.B. 20131224, 201312, 2013 | |
7.4 Kontaktdaten-Elemente
7.4.1 telecom-Element TEL
Ein telecom Kommunikations-Element dient zur Angabe von Kontaktdaten zu einem Personen- oder Organisationselement.
7.4.1.1 Strukturbeispiele
7.4.1.1.1 Beispiele für Präfixe in TEL Elementen
<telecom value="'''tel:'''+43.1.40400"/><br/><telecom value="'''fax:'''(02236)83.12323-12"/><br/><telecom value="'''mailto:'''office@organisation.at"/><br/><telecom value="'''http'''://www.organisation.at"/>
7.4.1.1.2 Beispiel für die Angabe einer Mobilnummer
<telecom use="MC" value="tel:+43.660.1234567"/>
7.4.1.2 Spezifikation
Bei TEL Elementen werden, sofern nicht anders spezifiziert, immer die folgenden Unterelemente/Attribute angegeben:
| Element/Attribut | DT | Kard | Konf | Beschreibung | |
|---|---|---|---|---|---|
| telecom | TEL | Kontakt-Element | |||
| @value | url | 1..1 | M | Die Kontaktadresse (Telefonnummer, Email, etc.) Formatkonvention siehe "telecom – Format Konventionen für Telekom-Daten" Bsp: tel:+43.1.1234567 Zulässige Werteliste für telecom Präfixe gemäß Value-Set "ELGA_URLScheme" | |
| @use | cs | 0..1 | O | Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …) Bsp: WP Zulässige Werte gemäß Value-Set "ELGA_TelecomAddressUse" | |
7.4.1.3 telecom – Format Konventionen für Telekom-Daten
Das @value Attribut des telecom-Elements …
- … MUSS das URI Schema "tel:", "mailto:", etc. aufweisen
- Zulässige Werteliste für telecom Präfixe gemäß Value-Set "ELGA_URLScheme"
- … MUSS im Falle von internationalen Telefonnummern mit einem "+" beginnen
- … DARF nur Ziffernzeichen 0 bis 9 nutzen sowie als visuelle Separatorzeichen nur Bindestrich –, Punkte . oder Klammern () verwenden.
- … Leerzeichen sind in Telefonnummern NICHT ERLAUBT
7.5 Namen-Elemente
7.5.1 Namen-Elemente von Personen PN
Personen-Namen werden über das Element name abgebildet.
Die Bedeutung des Namen-Elements KANN mit dem Attribut @use angegeben werden. Fehlt das Attribut, wird der Name als "rechtlicher Name" (Realname bzw. bürgerlicher Name) angenommen (entsprechend @use="L", legal name).
Werden mehrere Namen angegeben, MUSS die Bedeutung für jedes Namen-Element über das Attribut @use angegeben werden, wobei nur EIN rechtlicher Name angegeben werden DARF.
7.5.1.1 Granularitätsstufe 1: Unstrukturierte Angabe
In Granularitätsstufe 1 wird der Personen-Name unstrukturiert angegeben. Die einzelnen Elemente des Namens (Vorname, Nachname) werden nicht getrennt.
7.5.1.1.1 Strukturbeispiele
Beispiele für name-Elemente in Granularitätsstufe 1:
<name>Dr. Herbert Mustermann</name>
<name use="A">Dr. Kurt Ostbahn </name>
7.5.1.1.2 Spezifikation
Bei name-Elementen in dieser Granularitätsstufe werden, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben:
| Element/Attribut | DT | Kard | Konf | Beschreibung | |
|---|---|---|---|---|---|
| name | PN | Namen-Element (Person) | |||
| @use | cs | 0..1 | O | Die genaue Bedeutung des angegebenen Namens, beispielsweise, dass der angegebene Personen-Name ein "Künstlername" ist. Weitere Bsp: L (rechtlicher Name), A (Künstlername), R (Ordensname) Zulässige Werte gemäß Value-Set "ELGA_EntityNameUse" Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name ("L"). | |
7.5.1.2 Granularitätsstufe 2: Strukturierte Angabe
In Granularitätsstufe 2 wird der Personen-Name strukturiert angegeben. Die einzelnen Elemente des Namens (mindesten der Vorname und Nachname) werden getrennt angegeben.
7.5.1.2.1 Strukturbeispiel
Beispiel für ein name-Element in Granularitätsstufe 2:
<name> <prefix qualifier="PR">OMedR</prefix> <prefix qualifier="AC">Dr.</prefix> <given>Sissi</given> <family>Österreich</family> <family qualifier="BR">Habsburg</family> <suffix qualifier="AC">MSc</suffix> </name>
7.5.1.2.2 Spezifikation
Bei name-Elementen in dieser Granularitätsstufe werden, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben:
| Element/Attribut | DT | Kard | Konf | Beschreibung | ||
|---|---|---|---|---|---|---|
| name | PN | Namen-Element (Person) | ||||
| @use | cs | 0..1 | O | Die genaue Bedeutung des angegebenen Namens, beispielsweise, dass der angegebene Personen-Name ein "Künstlername" ist. Bsp: L (rechtlicher Name), A (Künstlername), R (Ordensname) Zulässige Werte gemäß Value-Set "ELGA_EntityNameUse" | ||
| prefix | en.prefix | 0..* | O | Beliebig viele Präfixe zum Namen z.B. Akademische Titel, Adelstitel Achtung: Die Angabe der Anrede ("Frau", "Herr"), ist im CDA nicht vorgesehen!
| ||
| @qualifier | cs | 0..1 | O | Die genaue Bedeutung eines prefix-Elements, beispielsweise, dass das angegebene Präfix einen akademischen Titel darstellt. z.B.: AC ("Akademischer Titel") Zulässige Werte gemäß Value-Set "ELGA_EntityNamePartQualifier" | ||
| given | en.given | 1..* | M | Mindestens ein Vorname | ||
| @qualifier | cs | 0..1 | O | Die genaue Bedeutung eines given-Elements, beispielsweise, dass das angegebene Element eine Initial (z.B. middle initial) bezeichnet. z.B.: IN ("Initial") Zulässige Werte gemäß Value-Set "ELGA_EntityNamePartQualifier" | ||
| family | en.family | 1..* | M | Mindestens ein Hauptname (Nachname) | ||
| @qualifier | cs | 0..1 | O | Die genaue Bedeutung eines family-Elements, beispielsweise, dass das angegebene Element einen Geburtsnamen bezeichnet. z.B.: BR ("Geburtsname") Zulässige Werte gemäß Value-Set br/>Zulässige Werte gemäß Value-Set "ELGA_EntityNamePartQualifier" | ||
| suffix | en.suffix | 0..* | O | Beliebig viele Suffixe zum Namen z.B. Akademische Titel, Adelstitel | ||
| @qualifier | cs | 0..1 | O | Die genaue Bedeutung eines suffix-Elements, beispielsweise, dass das angegebene Suffix einen akademischen Titel darstellt. z.B.: AC ("Akademischer Titel") Zulässige Werte gemäß Value-Set br/>Zulässige Werte gemäß Value-Set "ELGA_EntityNamePartQualifier" | ||
Die korrekte Reihenfolge der einzelnen Namenselemente ist wichtig. Als Richtlinie gilt, dass diese in der "natürlichen" Reihenfolge der Benutzung des Namens angegeben werden. Das ist besonders in den folgenden Fällen relevant:
- Präfixe (prefix) MÜSSEN immer vor dem Namen stehen, zu dem sie gehören.
- Vornamen (given) MÜSSEN immer in der offiziellen (gesetzlichen) Sequenz stehen.
- Nachnamen (family) und ein eventuelles Trennzeichen (meistens "-") MÜSSEN in der offiziellen Sequenz stehen, abhängig von der Wahl bei der Eheschließung.
- Suffixe (suffix) MÜSSEN immer hinter dem Namen stehen, zu dem sie gehören.
Für die Namenselemente kann zur näheren Bestimmung ein Qualifier angegeben werden (aus dem Value Set "ELGA_EntityNamePartQualifier"), v.a. für Prefix/Suffix.
Es gibt auch nicht näher bestimmte Prefixe/Suffixe, z.B. trifft das für die Angabe von "Junior" oder "Senior" bzw "Jun."/"Sen" oder "Jr."/"Sr" zu.
<name> <given>Herbert</given> <family>Mustermann</family> <suffix>Sen.</suffix> </name>
7.5.2 Namen-Elemente von Organisationen ON
Organisations-Namen werden über das Element name abgebildet.
Dieser Implementierungsleitfaden lässt nur die unstrukturierte Angabe des Organisationsnamens zu. Die Verwendung des @qualifier Attributs beim name-Element ist nicht gestattet.
7.5.2.1 Strukturbeispiel
Beispiel für die Angabe eines Organisationsnamens:
<name>Krankenhaus Wels</name>
7.5.2.2 Spezifikation
| Element/Attribut | DT | Kard | Konf | Beschreibung |
|---|---|---|---|---|
| name | ON | Name der Organisation |
7.6 Adress-Elemente
Adressen von Personen und Organisationen werden über das Element addr abgebildet. Das Adress-Element kann in verschiedenen Kontexten mit unterschiedlicher Detailgenauigkeit vorkommen. Daher werden drei Granularitätsstufen definiert, auf die je nach Anwendung entsprechend verwiesen wird.
Sind keine Adressdaten vorhanden, kann das Element entweder wegelassen werden oder mit NullFlavor angegeben werden – je nachdem wie das Adress-Element im Kontext spezifiziert wurde.
7.6.1 Granularitätsstufe 1: Unstrukturierte Angabe
In Granularitätsstufe 1 wird die Adresse unstrukturiert angegeben. Die einzelnen Elemente der Adresse (Straße, PLZ, Ort, …) werden nicht getrennt.
Hinweis: Diese Granularitätsstufe wird für Adressen in e-Impfpass nicht verwendet!
7.6.2 Granularitätsstufe 2: Strukturierte Angabe, Stufe 1
In Granularitätsstufe 2 wird die Adresse strukturiert angegeben, wobei aber Straße und Hausnummer noch zusammen angegeben werden.
7.6.2.1 Strukturbeispiel
Beispiel für ein addr-Element in Granularitätsstufe 2:
<addr> <streetAddressLine>Musterstraße 11a/2/1</streetAddressLine> <postalCode>7000</postalCode> <city>Eisenstadt</city> <state>Burgenland</state> <country>AUT</country> <additionalLocator>Station A, Zimmer 9</additionalLocator> </addr>
7.6.2.2 Spezifikation
Bei addr-Elementen in dieser Granularitätsstufe werden, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben:
| Element/Attribut | DT | Kard | Konf | Beschreibung | |
|---|---|---|---|---|---|
| addr | AD | Namen-Element | |||
| @use | cs | 0..1 | O | Die genaue Bedeutung der angegebenen Adresse, beispielsweise, dass die angegebene Adresse die Wohn-Adresse ist. Bsp: HP ("Home primary") Zulässige Werte gemäß Value-Set "ELGA_AddressUse" | |
| streetAddressLine | ADXP | 1..1 | M | Straße mit Hausnummer Bsp: Musterstraße 11a/2/1 | |
| postalCode | ADXP | 1..1 | M | Postleitzahl | |
| city | ADXP | 1..1 | M | Stadt | |
| state | ADXP | 0..1 | O | Bundesland | |
| country | ADXP | 1..1 | M | Staat Es wird EMPFOHLEN, den Staat im ISO 3 Ländercode (ISO-3166-1 Alpha 3) anzugeben, z.B. "AUT" für Österreich, "DEU" für Deutschland… | |
| additionalLocator | ADXP | 0..1 | O | Zusätzliche Addressinformationen z.B.: Station, Zimmernummer im Altersheim | |
7.6.3 Granularitätsstufe 3: Strukturierte Angabe, Stufe 2
In Granularitätsstufe 3 wird die Adresse maximal strukturiert angegeben (Straße und Hausnummer getrennt).
7.6.3.1 Strukturbeispiel
Beispiel für ein addr-Element in Granularitätsstufe 3:
<addr> <streetName>Musterstraße</streetName> <houseNumber>11a/2/1</houseNumber> <postalCode>7000</postalCode> <city>Eisenstadt</city> <state>Burgenland</state> <country>AUT</country> <additionalLocator>Station A, Zimmer 9</additionalLocator> </addr>
7.6.3.2 Spezifikation
Bei addr-Elementen in dieser Granularitätsstufe werden, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben:
| Element/Attribut | DT | Kard | Konf | Beschreibung | |
|---|---|---|---|---|---|
| addr | AD | Namen-Element | |||
| @use | cs | 0..1 | O | Die genaue Bedeutung der angegebenen Adresse, beispielsweise, dass die angegebene Adresse die Wohn-Adresse ist. Bsp: HP ("Home primary") Zulässige Werte gemäß Value-Set "ELGA_AddressUse" | |
| streetName | ADXP | 1..1 | M | Straße Bsp: Musterstraße | |
| houseNumber | ADXP | 1..1 | M | Hausnummer Bsp: 11a/2/1 | |
| postalCode | ADXP | 1..1 | M | Postleitzahl | |
| city | ADXP | 1..1 | M | Stadt | |
| state | ADXP | 0..1 | R | Bundesland | |
| country | ADXP | 1..1 | M | Staat Es wird EMPFOHLEN, den Staat im ISO 3 Ländercode (ISO-3166-1 Alpha 3) anzugeben, z.B. "AUT" für Österreich, "DEU" für Deutschland… | |
| additionalLocator | ADXP | 0..1 | O | Zusätzliche Addressinformationen z.B.: Station, Zimmernummer im Altersheim | |
7.7 Komplexe (zusammengesetzte) Elemente
7.7.1 Personen-Element
Personen-Elemente im CDA sind komplexe, zusammengesetzte Objekte und dienen zur Abbildung von Personen. Ein Personen-Element beinhaltet im Wesentlichen das name-Element der Person.
7.7.1.1 Strukturbeispiel
<assignedPerson>
<name>
<prefix qualifier="AC">Dr.</prefix>
<given>Hubert</given>
<family>Muster</family>
</name>
</assignedPerson>
7.7.1.2 Spezifikation
Bei Personen-Elementen MÜSSEN, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben werden:
| Element/Attribut | DT | Kard | Konf | Beschreibung |
|---|---|---|---|---|
| name | PN | 1..* | M | Name der Person Grundsätzlich sind die Vorgaben gemäß "Namen-Elemente von Personen PN" zu befolgen. |
7.7.2 Organisations-Element
Organisations-Elemente im CDA sind komplexe, zusammengesetzte Objekte und dienen zur Abbildung von Organisationen unter Berücksichtigung ihrer essentiellen Informationen, wie ID, Name, Adresse, Kontaktdaten, etc.
7.7.2.1 Strukturbeispiel
<serviceProviderOrganization> <id root="1.2.40.0.34.3.1.xxx" assigningAuthorityName="GDA Index"/> <name>Amadeus Spital</name> <telecom value="tel:+43.1.3453446.0"/> <telecom value="fax:+43.1.3453446.4674"/> <telecom value="mailto:info@amadeusspital.at"/> <telecom value="http://www.amadeusspital.at"/> <addr> <streetName>Mozartgasse</streetName> <houseNumber>1-7</houseNumber> <postalCode>1234</postalCode> <city>St.Wolfgang</city> <state>Salzburg</state> <country>AUT</country> </addr> </serviceProviderOrganization>
7.7.2.2 Spezifikation
Bei Organisations-Elementen MÜSSEN, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben werden:
7.7.2.2.1 id
| Element/Attribut | DT | Kard | Konf | Beschreibung |
|---|---|---|---|---|
| id | II | 0..* | O | Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc. Grundsätzlich sind die Vorgaben gemäß "Identifikations-Elemente" zu befolgen. |
7.7.2.2.2 Name der Organisation
| Element/Attribut | DT | Kard | Konf | Beschreibung |
|---|---|---|---|---|
| name | PN | 1..1 | M | Name der Organisation Grundsätzlich sind die Vorgaben gemäß "Namen-Elemente von Organisationen ON" zu befolgen. |
7.7.2.2.3 Kontakt-Elemente der Organisation
| Element/Attribut | DT | Kard | Konf | Beschreibung |
|---|---|---|---|---|
| telecom | TEL | 0..* | O | Beliebig viele Kontakt-Elemente der Organisation Grundsätzlich sind die Vorgaben gemäß "Kontaktdaten-Element" zu befolgen. |
7.7.2.2.4 Adress-Element der Organisation
| Element/Attribut | DT | Kard | Konf | Beschreibung |
|---|---|---|---|---|
| addr | AD | 0..1 | O | Ein Adress-Elemente der Organisation Grundsätzlich sind die Vorgaben gemäß "Adress-Elemente" zu befolgen. |
7.7.3 AssignedEntity-Element (Person + Organisation)
AssignedEntity-Elemente im CDA sind komplexe, zusammengesetzte Objekte und dienen zur Abbildung von abstrakten Entitäten, welche sich aus Person- und Organisationsinformationen zusammensetzen.
Hierbei MUSS jedenfalls die "Person" der Entität angegeben werden. Die Angabe der Organisation, der die Person angehört, ist prinzipiell optional. Diese Optionalität kann sich in Abhängigkeit vom konkreten Anwendungsfall in "verpflichtend" ändern.
7.7.3.1 Strukturbeispiel
<assignedEntity>
<id root="1.2.40.0.34.99.111.1.3"
extension="2222"
assigningAuthorityName="Amadeus Spital"/>
<addr>
<streetName>Währinger Gürtel</streetName>
<houseNumber>18-20</houseNumber>
<postalCode>1090</postalCode>
<city>Wien</city>
<state>Wien</state>
<country>AUT</country>
</addr>
<telecom value="tel:+43.1.3453446.0"/>
<telecom value="fax:+43.1.3453446.4674"/>
<telecom value="mailto:info@amadeusspital.at"/>
<telecom value="http://www.amadeusspital.at"/>
<assignedPerson>
:
</assignedPerson>
<representedOrganization>
:
</representedOrganization>
</assignedEntity>
7.7.3.2 Spezifikation
Bei AssignedEntity-Elementen MÜSSEN, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben werden:
7.7.3.2.1 id
| Element/Attribut | DT | Kard | Konf | Beschreibung |
|---|---|---|---|---|
| id | II | 1..* | R | Mindestens eine ID der Person der Entität Zugelassene nullFlavor:
Grundsätzlich sind die Vorgaben gemäß "Identifikations-Elemente" zu befolgen. |
7.7.3.2.2 Adress-Element der Organisation
| Element/Attribut | DT | Kard | Konf | Beschreibung |
|---|---|---|---|---|
| addr | AD | 0..1 | O | Ein Adress-Element der Person der Entität Grundsätzlich sind die Vorgaben gemäß "Adress-Elemente" zu befolgen. |
7.7.3.2.3 Kontakt-Elemente der Organisation
| Element/Attribut | DT | Kard | Konf | Beschreibung |
|---|---|---|---|---|
| telecom | TEL | 0..* | O | Beliebig viele Kontakt-Elemente der Person der Entität Grundsätzlich sind die Vorgaben gemäß "Kontaktdaten-Element" zu befolgen. |
7.7.3.2.4 Personen-Element der Entität
| Element/Attribut | DT | Kard | Konf | Beschreibung |
|---|---|---|---|---|
| assignedPerson | POCD_MT000040. Person |
1..1 | M | Personendaten der Person der Entität Grundsätzlich sind die Vorgaben gemäß "Personen-Element" zu befolgen. |
7.7.3.2.5 Organisations-Element der Entität
| Element/Attribut | DT | Kard | Konf | Beschreibung |
|---|---|---|---|---|
| representedOrganization | POCD_MT000040. Organization |
0..1 | O | Organisationsdaten der Entität Grundsätzlich sind die Vorgaben gemäß "Organisations-Element" zu befolgen. |
7.8 Weitere Informationen zu CDA
Weitere Informationen zum technischen Hintergrund finden sich unter folgenden Links:
- Allgemeine Informationen zu CDA [28]
- CDA Templates [29]
- Art-Decor-Tabellen verstehen [30]
- Technische Konformitätsprüfung [31]
- Terminologien [32]
8 Funktionale Anforderungen
8.1 Darstellung
Für die Darstellung des e-Impfpasses wird ein spezielles Stylesheet bereitgestellt, das im XML-Prolog referenziert wird ("ELGA_eimpf-stylesheet_v1.0.xsl"). Grundsätzlich werden die Daten aus den Entries dargestellt. Section.Text MUSS dennoch angegeben werden, da der CDA Rel. 2 Standard "Lesbarkeit für Menschen" ("human readability") vorschreibt.
8.2 Verwendung in der ELGA Infrastruktur
8.2.1 Vorgaben zu Dokument-Metadaten (XDS-Metadaten)
| XDS-Mapping | Optio-
nalität |
CDA-Element
clinicalDocument. |
Beispiel | Erklärung |
|---|---|---|---|---|
| formatCode | R | .templateId/@extension |
|
Version des Implementierungsleitfaden e-Impfpass - "Update Immunisierungsstatus" bzw. "Kompletter Immunisierungsstatus" mit XDSdocumentEntry.formatCode als Extension.
Das templateId-Element mit einer Extension beginnend mit "XDSdocumentEntry.formatCode^" wird ins XDS-Attribut formatCode gemappt (ohne Präfix XDSdocumentEntry.formatCode^). |
| classCode | R | .code |
|
Bezeichnet die "Dokumentklasse". Zulässige Werte gemäß Value-Set "ELGA_Dokumentklassen".
Aus Gründen der Kompatibilität zu IHE PCC und auch den Ableitungen im Schweizer CH-VACD haben alle Impfungsdokumente den Code 11369-6 History of Immunization Narrative. |
| typeCode | R | .code.translation |
|
Zur Unterscheidung des Dokumenttyps erhält das Element clinicalDocument.code des "Kompletter Immunisierungsstatus" ein zusätzliches translation-Element. |
|
Zur Unterscheidung des Dokumenttyps erhält das Element clinicalDocument.code des "Update Immunisierungsstatus" ein zusätzliches translation-Element. | |||
| title | R | .title | "Kompletter Immunisierungsstatus" | Für den lesenden Dokumentempfänger gedachter Titel des Kompletten Immunisierungsstatus. |
| "Update Immunisierungsstatus" | Für den lesenden Dokumentempfänger gedachter Titel des Update Immunisierungsstatus. | |||
| eventCodeList | R | .documentationOf
.serviceEvent.code |
|
Code der Gesundheitsdienstleistung. |
| serviceStartTime | R | .documentationOf.serviceEvent
.effectiveTime.low |
Zeitpunkt des ältesten effectiveTime aus:
|
Beginn der Gesundheitsdienstleistung beim Kompletter Immunisierungsstatus. |
| Zeitpunkt des Behandlungsbeginns (aktueller Besuch). | Beginn der Gesundheitsdienstleistung bei Update Immunisierungsstatus. | |||
| serviceStopTime | R | .documentationOf.serviceEvent
.effectiveTime.high |
Zeitpunkt des jüngsten effectiveTime aus:
|
Ende der Gesundheitsdienstleistung bei Kompletter Immunisierungsstatus. |
| Zeitpunkt des Behandlungsendes (aktuelle Behandlung,
muss sich von Behandlungsbeginn unterscheiden) |
Ende der Gesundheitsdienstleistung bei Update Immunisierungsstatus. | |||
| practiceSettingCode | R | Hinweis: dzt. noch nicht als CDA-Element umgesetzt (folgt in nächster Hauptversion) | Fachliche Zuordnung des Dokuments. Mögliche Werte: F023 "Interdisziplinärer Bereich" oder F001 "Allgemeinmedizin" |
8.3 Versionierung & Stornierung
Versionierung und Stornierung betrifft ausschließlich Dokumente vom Typ "Update Immunisierungsstatus".
Das von der e-Impfpass Anwendung erzeugte On-Demand Dokument "Kompletter Immunisierungsstatus" ist immer eine neue Version desselben Dokuments, d.h. es ändert sich nur die Versionsnummer (die SetID bleibt für alle Versionen des kompletten Immunisierungsstatus eines Patienten gleich).
8.3.1 Versionierung von Dokumenten
Dokumente vom Typ "Update Immunisierungsstatus" können über die IHE Transaktion ITI-41 versioniert werden. Die Inhalte werden von der zentralen e-Impfpass-Anwendung verarbeitet und alle Inhalte in den Datenbestand integriert. Das bedeutet, dass alle Daten, die bereits durch ein Dokument in den zentralen Datenbestand übernommen wurden, durch das Update ersetzt werden. Daten, die in der neu registrierten Version nicht enthalten sind, gelten als gelöscht. Die Fachlogik der zentralen e-Impfpass-Anwendung kann die Änderung oder Löschung verweigern, sollten dadurch inkonsistente Datenbestände entstehen (z.B. wenn Informationen gelöscht werden sollen, auf denen spätere Impfeinträge beruhen).
8.3.2 Stornierung von Dokumenten
Dokumente vom Typ "Update Immunisierungsstatus" können über IHE Transaktion ITI-57 storniert werden. Alle Inhalte, die ursprünglich durch das stornierte Dokument eingetragen wurden, werden gelöscht. Die Fachlogik der zentralen e-Impfpass-Anwendung kann die Stornierung verweigern, sollten dadurch inkonsistente Datenbestände entstehen (z.B. wenn Informationen gelöscht werden sollen, auf denen spätere Impfeinträge beruhen).
8.4 Impfempfehlungen
Ein Ziel des e-Impfpasses ist, interessierten Ärztinnen und Ärzten sowie Bürgerinnen und Bürgern einen raschen Überblick über aktuelle zur Verfügung stehende Impfungen zu geben. Dazu werden vom e-Impfpass "Impfempfehlungen" ausgegeben. Eine Impfempfehlung enthält zu einer Impfung den jeweils nächsten fälligen Impftermin und dazu eine Handlungsanweisung (Handlungsempfehlung/Handlungsvorschlag). Impfempfehlungen werden für alle Impfungen erstellt, die bereits mindestens einmal erhalten wurden oder die für die Person laut Österreichischen Impfplan empfohlen sind.
Die Impfempfehlungen werden vom Expertensystem der zentralen Anwendung aktuell erstellt und gemeinsam mit dem On-Demand-Dokument "Kompletter Immunisierungsstatus" ausgegeben. Das Expertensystem ist ein Teil der Fachlogik der zentralen Anwendung und bildet den jeweils aktuellen Österreichischen Impfplan ab, der vom Nationalen Impfgremium herausgegeben wird. Der Impfplan wird in ein tabellarisches Regelwerk übersetzt und ins Expertensystem importiert. Zur Berechnung der Impfempfehlung werden folgende Parameter aus der persönlichen Impfdokumentation herangezogen:
- Alter der Person
- Geschlecht
- Bereits erhaltene Impfungen:
- Dosiskennung der letzten eingetragenen Impfung
- Impfstoff
- Impfschema (sofern abweichend vom Defaultschema)
- Durchgemachte impfrelevante Erkrankungen
- Indikation für Impfung ("Risikogruppe")
Automatisch erstellte Impfempfehlungen können mit individuellen Impfempfehlungen eines Arztes überschrieben werden, z.B. bei Vorliegen einer Antikörperbestimmung (Impftiter-Ergebnis). Die Begründung kann (z.B. mit dem Messwert als Kommentar) angegeben werden.
Dosiskennung: Damit die nächste Impfung im Rahmen eines bestimmten Impfschemas korrekt berechnet werden kann, ist es nicht notwendig, dass alle bisher verabreichten Dosen einer Impfung dokumentiert werden. Es reicht, die jeweils letzte Dosis zu dokumentieren, dafür muss die Dosiskennung korrekt angegeben werden (z.B. "Dosis 3").
Impftiter: Ergebnisse von Antikörperbestimmungen werden NICHT von der Berechnungslogik berücksichtigt. Wenn der Impftiter ein Abweichen vom automatisch berechneten Impftermin notwendig macht, muss vom Arzt eine individuelle Impfempfehlung erstellt werden, als Kommentar soll der Impftiter angegeben werden.
Handlungsempfehlung: Für jede automatisch von der zentralen Anwendung ausgegebenen Impfempfehlung wird eine Handlungsempfehlung ausgegeben. Die Handlungsempfehlung wird durch einen Code repräsentiert (Element code im Immunization Recommendation Entry) und stammt aus einem Value Set (eImpf_SpecialCaseVaccination_VS). Die Bedeutung der Codes ist im Value Set beschrieben (Bedeutung, Anwendungsbeschreibung, Hinweise). Zur einfacheren Darstellung werden die Handlungsempfehlungen gruppiert und bestimmten farbigen Icons zugewiesen; die Zuordnung erfolgt über eine hierarchische Strukturierung im Value Set (Ebene 0 = Icon, Ebene 1 = Handlungsempfehlung)
8.4.1 Empfehlung, keine Impfung durchzuführen (Kontraindikation)
Eine Sonderform der Impfempfehlung ist die Empfehlung, KEINE Impfung durchzuführen, wenn eine medizinisch begründete Kontraindikation gegen eine bestimmte Impfung vorliegt. Für die Angabe einer Kontraindikation sind neben vom berechtigten dokumentierenden Arzt (Author) für einen Patienten folgende Daten einzutragen:
- Impfziel
- Zeitraum, in dem die Kontraindikation gilt
- Kommentar
- Optional: Impfstoff
Vom Expertensystem der zentralen Anwendung wird im Kompletten Immunisierungsstatus eine entsprechende Handlungsanweisung ergänzt ("Impfung nicht indiziert").
Die Angabe von Kontraindikationen ist derzeit nur für Impfungen gegen SARS-CoV-2 (COVID-19) möglich, um die Ausnahmen von der Impfpflicht zu dokumentieren.
8.5 Mehrsprachigkeit und grenzüberschreitender Austausch
Mehrsprachigkeit wird in dieser Version nicht unterstützt, ist aber für die Zukunft angedacht. Die entsprechenden Strukturen im Leitfaden sind bereits angelegt.
9 User Storys ("Anwendungsfälle")
Die Einsatzszenarien für dieses Datenaustauschformat werden in Form von User Storys ("Anwendungsfälle") knapp beschrieben, um dem Leser den Hintergrund zu vermitteln. Diese Beschreibung der Anwendungsfälle ist nicht normativ und keine Vorentscheidung für die tatsächliche Umsetzung. Eine detaillierte technische Beschreibung der Anwendungsfälle und der Geschäftsprozesse findet sich im Architekturdokument e-Impfpass [33].
Die derzeit bei den unterschiedlichen Akteuren des österreichischen Gesundheitswesens auftretenden Anwendungsfälle betreffend Impfungen werden im Folgenden skizziert.
9.1 Übersicht vorhandener Akteure und Komponenten
Folgende Abbildung zeigt einen Überblick über die Architektur mit den Akteuren und Komponenten für den e-Impfpass.
- e-Impfpass-Teilnehmer / Bürger
- Impfende GDA
- Niedergelassene Ärzte
- Fachärztinnen und Fachärzte für Kinder und Jugendheilkunde
- Ärztinnen und Ärzte für Allgemeinmedizin
- Landessanitätsdirektionen inkl. Amtsärzte (Amtsärzte, Schulärzte, Betriebsärzte)/öffentliche Gesundheitsdienste
- Niedergelassene Ärzte
- Interessensvertretung von Bürger- und Bürgerinnen-Rechten
- Bürgerinnen und Bürger, die im Z-PI erfasst sind, und dessen Vertreter, insbesondere Eltern-für-Kinder
- ELGA-Ombudsstelle
- ELGA-Serviceline
- Datenkorrigierender GDA
- Bezirksverwaltungsbehörde
- "Abrechnungsunterstützung" (im Rahmen des kostenlosen Kinderimpfprogramms)
- Landeshauptmann / Landeshauptfrau
- Bezirksverwaltungsbehörde
- Auswertungen für Durchimpfungsraten
- Landeshauptmann / Landeshauptfrau
- Zuständiges Bundesministerium für Gesundheit
Bei der Betrachtung der technischen Architektur haben folgende Ausgangspunkte einen besonderen Stellenwert und werden deshalb kurz zusammengefasst:
- Die e-Impfpass Anwendung ist eine eHealth-Anwendung mit zentraler Datenhaltung.
- Die e-Impfpass Anwendung nutzt betreffend Autorisierung, Protokollierung und Zugangskontrolle die bestehende ELGA Infrastruktur.
- Berechtigte e-Impfpass Anwender (GDA) sind im GDA-I mit entsprechender Rolle gelistet.
- Es muss zwischen folgend aufgelisteten rollenbasierenden Zugangangsarten unterschieden werden.
- Regulärer Zugang mittels Kontaktbestätigungen
- Behördlicher Zugang für tagaktuelles Ausbruchs-Management (und Durchimpfungsrate) welcher gesetzlich geregelt wird (auch ohne Kontaktbestätigung). Hier zählen Zugriffe auf die Impfdaten von eindeutig identifizierten Personen.
- Verabreichte Impfungen müssen lückenlos in der e-Impfpass Anwendung gespeichert werden. Da der Immunisierungsstatus im Ausbruchsfall jederzeit abrufbar sein muss, kommen individuelle Berechtigungen von e-Impfpass-Teilnehmern nicht zur Anwendung (Gesetzesgrundlage ist hier maßgebend).
- Die Geschäftslogik der Anwendung übernimmt die CDA-Verarbeitung und hat folgende Funktionen
- Speichert eingehende CDA Dokumente "Update Immunisierungsstatus", zerlegt diese (entsprechend gültigem Schema) und persistiert die Informationseinheiten.
- Das Zusammenstellen vom OnDemand-Dokument "Kompletter Immunisierungsstatus" (der eigentliche e-Impfpass der Teilnehmer) muss unterstützt werden. Hierfür werden die Inhalte der zentralen Datenbank zusammengestellt und im angeforderten Format (CDA) ausgehändigt.
- Die analytisch-statistische Weiterverarbeitung (Abzüge für BI) bzw. Auswertungen müssen ermöglicht werden.
- Auf Grundlage des gültigen Österreichischen Impfplanes muss bei der Abfrage des persönlichen e-Impfpasses eines Teilnehmers das Datum der nächste(n) fälligen Impfungen und etwaige Nachhol-Impftermine beigefügt werden. Vom GDA manuell eingefügte Impftermine müssen unterstützt werden und diese dürfen von der Fachlogik nicht überschrieben werden.
9.2 Allgemeine Vorbedingungen
Für den Zugriff auf den elektronischen Impfpass (lesend und schreibend) sind spezielle Rollen und Berechtigungen erforderlich. Diese sowie der Vorgang zur Authentifizierung und Autorisierung sind im Architekturdokument e-Impfpass [33]erläutert. Die notwendigen Stammdaten (z.B. Impfungen, Impfstoffe, impfrelevante Erkrankungen ...) werden über den Terminologieserver bereitgestellt.
Sowohl der berechtigte GDA (über das GDA System, sobald E-Card gesteckt wurde), als auch die Bürgerin/der Bürger (über das ELGA Portal) können auf den persönlichen e-Impfpass zugreifen.
9.3 U1 Kompletten Immunisierungsstatus abrufen
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")
Szenario:
- Max Muster (ELGA Teilnehmer) besucht seinen Hausarzt Dr. DeCarro (Impfender GDA) und möchte Informationen zu seinem Immunisierungsstatus erhalten.
- Dr. DeCarro fragt den e-Impfpass von Max Muster über seine Softwaresystem ab und erhält das On-Demand-Dokument "Kompletter Immunisierungsstatus", das Auskunft über die bisherigen Impfungen und entsprechende Impfempfehlungen enthält.
- Max Muster erfährt von Dr. DeCarro, dass laut Österreichischem Impfplan die nächste FSME-Auffrischungsimpfung in einem Monat ansteht und vereinbart hierfür einen Termin bei Dr. DeCarro.
Auch wenn noch keine Immunisierungseinträge in der e-Impfpass Anwendung gespeichert sind, können Impfempfehlungen abgerufen werden.
9.4 U2 Aktualisierung Immunisierungsstatus
Wird eine Änderung am dokumentierten Immunisierungsstatus vorgenommen (z.B. neuer Impfeintrag, Nachtragen einer Impfdokumentation oder Korrektur einer bestehenden Impfung, Eintrag einer impfrelevanten Erkrankung), so werden die Änderungen mit dem Datenaustauschformat "Update Immunisierungsstatus" an die zentrale e-Impfpass Anwendung übermittelt. Die zentrale Anwendung übernimmt die Änderungen als Update und berechnet die nächsten empfohlenen Impftermine.
Es kann zwischen folgenden Anwendungsfällen unterschieden werden:
9.4.1 U2.1 Eintragen des Immunisierungsstatus
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")
Szenario:
- Max Muster besucht seinen Hausarzt Dr. DeCarro, weil er einen Termin für eine FSME-Auffrischungsimpfung vereinbart hat.
- Dr. DeCarro fragt den e-Impfpass von Max Muster über seine Softwaresystem ab und erhält das Dokument "Kompletter Immunisierungsstatus" (U1), das Auskunft über die bisherigen Impfungen und entsprechende Impfempfehlungen enthält und kontrolliert, ob sich seit dem letzten Abruf Änderungen ergeben haben.
- Dr. DeCarro führt die Impfung durch und dokumentiert diese in seinem Softwaresystem. Nach der Freigabe der Dokumentation erzeugt das Softwaresystem ein Datenaustauschformat "Update Immunisierungsstatus" und sendet dieses an die zentrale Anwendung e-Impfpass, die das Dokument übernimmt und ein Update der Datenbank durchführt.
- Dr. DeCarro kann nun das Dokument "Kompletter Immunisierungsstatus" erneut abrufen und erhält eine neue Version des Dokuments mit aktualisiertem Immunisierungsstatus und neuen Impfempfehlungen für Max Muster.
9.4.2 U2.2 Korrektur eines Immunisierungseintrags (eigene Einträge)
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")
Szenario:
- Dr. DeCarro stellt fest, dass der Eintrag, den er für Max Muster erstellt hat, korrigiert werden muss (z.B. wegen eines Dokumentationsfehlers oder weil die individuelle Impfempfehlung vergessen wurde)
- Dr. DeCarro korrigiert den Eintrag in seinem Softwaresystem, das eine neue Version des Dokuments "Update Immunisierungsstatus" an die zentrale Anwendung übergibt (dabei sind alle Einträge in der Korrekturversion enthalten, auch jene, die nicht geändert werden müssen).
- Die zentrale Anwendung ersetzt alle Daten, die durch das originale Dokument "Update Immunisierungsstatus" übernommen worden waren durch die Daten, die in der korrigierten Version enthalten sind. Die korrigierten Daten werden in das Dokument "Kompletter Immunisierungsstatus" eingetragen (Dr. DeCarro bleibt der Author aller betreffenden Einträge).
Die Berechtigung für eine Korrektur von bereits eingetragenen Immunisierungseinträgen hat nur jener GDA, der diese Impfdaten eingetragen hat. Zusätzlich hat eine gesetzlich festgelegte Rolle die Berechtigung (siehe U4).
Anmerkung: Eigene Einträge erkennt man daran, dass das id-Element von "Berechtigter Bearbeiter" (Immunization Entry/participant @typeCode="AUT") die eigene GDA-OID enthält.
Die Vorversionen des CDA "Update Immunisierungsstatus" wurden als "DEPRECATED" gekennzeichnet. Die neue Version des CDA Dokuments wird mit dem Status "APPROVED" gespeichert.
9.4.3 U2.3 Stornierung eines Immunisierungseintrags
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")
Szenario:
- Dr. DeCarro stellt fest, dass der Eintrag, den er erstellt hat, storniert werden muss (z.B., weil er für den falschen Patienten dokumentiert hat)
- Dr. DeCarro löscht den Eintrag in seinem Softwaresystem, das eine Stornierungsnachricht mit dem Verweis auf das zu stornierende "Update Immunisierungsstatus"-Dokument an die zentrale Anwendung übergibt.
- Die zentrale Anwendung löscht alle Daten, die durch die originale Nachricht "Update Immunisierungsstatus" übernommen worden waren.
Die Berechtigung für eine Stornierung von bereits eingetragenen Immunisierungseinträgen hat nur jener GDA, der diese Impfdaten eingetragen hat oder eine gesetzlich festgelegte Rolle (siehe U4).
Stornierte CDA Dokumente wurden als "DEPRECATED" gekennzeichnet.
9.4.4 U2.4 Nachtragen der Impfdokumentation
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")
Szenario:
- Max Muster besucht seinen Hausarzt Dr. DeCarro und möchte seinen Papier-Impfpass in den e-Impfpass überführen.
- Dr. DeCarro überträgt das Papierdokument in sein Softwaresystem, das ein Datenaustauschformat "Update Immunisierungsstatus" erzeugt und an die zentrale Anwendung übergibt.
9.4.5 U2.5 Selbsteintragung von Impfungen durch den Bürger
Akteure: e-Impfpass Teilnehmer ("Max Muster")
Szenario:
- Max Muster möchte seinen Papier-Impfpass selbst in den e-Impfpass überführen.
- Max Muster überträgt das Papierdokument mit einem über das Internet verfügbarem Softwaresystem, das ein Datenaustauschformat "Update Immunisierungsstatus" erzeugt und an die zentrale Anwendung übergibt.
- Seinen Papierimpfpass kann er digitalisiert als Beilage anhängen (alle weiteren Sektionen sind bei einem Selbsteintrag nicht verfügbar).
Anmerkung: Dieses Szenario ergibt sich aus dem GTelG § 24e: "(1) Bürger/innen sowie deren gesetzliche oder bevollmächtigte Vertreter/innen haben das Recht (...) 2. Impfungen in das zentrale Impfregister einzutragen, wobei diese selbsteingetragenen Impfungen als solche gekennzeichnet werden und für Gesundheitsdiensteanbieter gemäß § 24c Abs. 2 Z 1 nur zur Information dienen.". Eine entsprechende Funktion steht zum Stand der Erstellung dieses Leitfadens noch nicht zur Verfügung.
9.5 U3 Abrechnung
Anmerkung: Die Abrechnung selbst steht nicht im Fokus dieses Leitfadens. Er stellt lediglich sicher, das die für die Abrechnungsunterstützung notwendigen Informationen über das Datenaustauschformat übertragen werden können.
Akteure: Impfender GDA ("Dr. DeCarro"), Abrechnungsunterstützung, Kind "Max Musterkind"
Szenario:
- Dr. DeCarro dokumentiert die Impfung des Kindes "Max Musterkind" (siehe U2.1)
- Das GDA-Softwaresystem erzeugt ein Datenaustauschformat "Update Immunisierungsstatus", das zusätzlich die Informationen zur Abrechenbarkeit enthält und sendet dieses an die zentrale Anwendung.
- Die Abrechnungsunterstützung erhält von der zentralen Anwendung einen Minimaldatensatz (d.h. nur die minimal notwendigen Daten für die Abrechnung), der ausschließlich die Impfungen enthält, die in der gewählten Zeit und Region entsprechen und die vom GDA als "abrechenbar" markiert wurden.
- Die Abrechnungsunterstützung kontrolliert den Anspruch an Abrechnung der einzelnen Einträge und leitet alle Schritte zur Überweisung des Abrechnungsbetrags in die Wege.
Im Rahmen des kostenfreien Kinderimpfprogramms rechnen sowohl Ärztinnen und Ärzte als auch Apotheken mit den Ländern Impfleistungen mit Hilfe der Informationen aus dem zentralen Impfregister ab. Die für die Abrechnung zuständigen Länderstellen können über die Informationen aus dem zentralen Impfregister nachvollziehen, welche Ärztin oder welcher Arzt, welche Impfung wann verabreicht hat und somit den Verrechnungs- und Ausbezahlungsprozess abwickeln. Nicht relevant für die Abrechnung sind z.B. nacherfasste oder stornierte Impfungen, Titereinträge oder Einträge zur Immunisierung durch Krankheit. Der aktuelle Stand der abrechnungsrelevanten Impfdaten aus dem zentralen Impfregister wird jeweils im Folgemonat für die Abrechnungsunterstützung zur Verfügung gestellt.
9.6 U4 Datenkorrektur durch Behörde (fremde Einträge)
Akteure: e-Impfpass Teilnehmer ("Max Muster"), Amtsarzt mit der Rolle "Korrekturberechtigte Person" ("Amelia Amtsarzt")
Szenario:
- Max Muster stellt fest, dass Dr. DeCarro, der mittlerweile in Pension ist, beim Übertragen einer Reiseimpfung aus dem Papierimpfpass eine falsche Impfung eingetragen hat und möchte diese in seinem e-Impfpass korrigieren lassen. Er stellt bei der Bezirksverwaltungsbehörde (Rolle "Korrekturberechtigte Person") einen entsprechenden Antrag.
- Amelia Amtsarzt aus der Bezirksverwaltungsbehörde ruft den "Kompletten Immunisierungsstatus" von Max Muster ab und trägt entsprechende Änderungen in ihr Softwaresystem ein.
- Das Softwaresystem der Bezirksverwaltungsbehörde, übergibt eine korrigierte Version des Dokuments "Update Immunisierungsstatus" (jenes, mit dem Dr. DeCarro damals den falschen Eintrag eingemeldet hat) an die zentrale Anwendung. Dabei sind alle Einträge in der Korrekturversion enthalten, auch jene, die nicht geändert werden müssen (als document.author ist Amelia Amtsarzt eingetragen).
- Die zentrale Anwendung ersetzt alle Daten, die durch das originale Dokument "Update Immunisierungsstatus" übernommen worden waren durch die Daten, die in der korrigierten Version enthalten sind. Die korrigierten Daten werden in das Dokument "Kompletter Immunisierungsstatus" eingetragen und Amelia Amtsarzt wird bei den geänderten Einträgen als "Korrigierende Person" geführt.
Grundlegend kann ein GDA nur jene Einträge in der ELGA-Infrastruktur aktualisieren, die von ihm selbst eingetragen wurden. Unter bestimmten Rahmenbedingungen sollen behördliche Stellen Daten im Impfpass korrigieren dürfen (z.B. wenn der impfende GDA, der eine Dokumentation ursprünglich erstellt hat, nicht mehr in der Lage ist, die Daten selbst zu korrigieren). Bei der zentralen e-Impfpass Anwendung gibt es daher ausgewählte GDA, die Bezirksverwaltungsbehörden, die Immunisierungseinträge von anderen GDA aktualisieren oder stornieren dürfen. Dies ist notwendig, da Immunisierungseinträge lebenslang gespeichert werden, und es somit eine vom eintragenden GDA unabhängige Korrekturmöglichkeit falscher Daten geben muss.
9.7 U5 Krisenmanagement
Anmerkung: Das Krisenmanagements selbst steht nicht im Fokus dieses Leitfadens, es wird nur der Vollständigkeit halber die Vorgehensweise beschrieben.
9.7.1 U5.1 Krankheitsausbrüche
Im Rahmen des Krisenmanagements bei Krankheitsausbrüchen muss von Kontaktpersonen (z.B. in Schule, Kindergarten, Ordination, Wartebereichen in Ambulanzen) der Impfstatus erhoben werden. Derzeit erfolgt die Erhebung des Impfstatus aufwändig manuell bzw. in den lokal begrenzten Datenbanken. Durch die zentrale e-Impfpass Anwendung werden Umgebungsuntersuchungen digital unterstützt, indem die Impfdokumentation von Kontaktpersonen für die österreichische Bevölkerung elektronisch bezogen wird. Dies wird das Ausbruchsmanagement beschleunigen und vereinfachen und somit Ansteckungen vermeiden sowie Kosten des Ausbruchs(-managements) senken.
9.7.2 U5.1 Chargenrückruf
Ein weiterer Anwendungsfall im Krisenmanagement betrifft den Chargenrückruf von Impfstoffen. Momentan veröffentlicht das Bundesamt für Sicherheit im Gesundheitswesen (BASG) im Anlassfall die Chargennummern von Arzneimitteln die Qualitätsmängel aufweisen. Apotheken, die Chargenrückrufe erhalten, sortieren die Ware aus und geben diese ihrem Lieferanten wieder mit. Sollte die Impfung die Apotheke schon verlassen haben, wird eruiert welcher GDA oder Bürger betroffen ist und im Anlassfall kontaktiert.
10 Datenarten
10.1 Dataset
| Name | Beschreibung | Mapping | Datenelement-Nr. |
|---|---|---|---|
| Unterzeichnende Person (Dokument) (Rechtlicher Unterzeichner) | Der "Rechtliche Unterzeichner" oder "Hauptunterzeichner" ist jene Person, welche für ein Update des Immunisierungsstatus bzw. den Nachtrag aus rechtlicher Sicht die Verantwortung übernimmt (gesamtes Dokument!). Der "Rechtliche Unterzeichner" entfällt beim Kompletten Immunisierungsstatus, da dieser automatisch von einem Gerät erstellt wird (hier entfällt die Angabe aller Unterzeichner). |
clinicalDoc.LegalAuthenticator | elgaimpf-dataelement-368 |
| Zeitpunkt der Unterzeichnung | Der Zeitpunkt, an dem das Dokument unterzeichnet wurde. | elgaimpf-dataelement-369 | |
| Signatur | elgaimpf-dataelement-370 | ||
| ID des Unterzeichners | elgaimpf-dataelement-371 | ||
| Kontaktdaten | Weitere Kontaktdaten (Telefon, Handy, Email...) | elgaimpf-dataelement-372 | |
| Name | Name der Person | elgaimpf-dataelement-373 | |
| Organisation | elgaimpf-dataelement-374 | ||
| Eintragende Person (Schreibkraft) | Datenverarbeitende Person. Die Person, die Daten für den Impfpass dokumentiert. | clinicalDoc.dataEnterer | elgaimpf-dataelement-32 |
| Verantwortliche Person (Impfung) (Medizinisch verantwortliche Person, auch: Impfstelle) | Die Person, die für die Impfung und ihre Dokumentation letztlich medizinisch verantwortlich ist. "Dr. X (im Privat-KH Y) war für die Impfung verantwortlich/hat sie angeordnet". Bei neuem Immunisierungseintrag muss dieses Element angegeben sein. Bei einem Nachtrag kann dieses Element entfallen, wenn nicht mehr eruierbar. Empfohlenes Label für entsprechende Eingabefelder einer GUI: „Für die Impfung verantwortlich“… |
substanceAdministration "Immunization Entry"/author | elgaimpf-dataelement-307 |
| Name | elgaimpf-dataelement-339 | ||
| Titel (Präfix) | Titel der Person (voran- und nachgestellte Titel) | elgaimpf-dataelement-340 | |
| Vorname | Vornamen der Person | elgaimpf-dataelement-343 | |
| Nachname | Nachname der Person | elgaimpf-dataelement-344 | |
| ID des Unterzeichners | ID der verantwortlichen Person (lokaler Identifikator) | elgaimpf-dataelement-346 | |
| Kontaktdaten | Weitere Kontaktdaten (Telefon, Handy, Email...) | elgaimpf-dataelement-347 | |
| Organisation | elgaimpf-dataelement-353 | ||
| ID der Organisation | elgaimpf-dataelement-381 | ||
| Name der Organisation | elgaimpf-dataelement-382 | ||
| Telekom | Weitere Kontaktdaten (Telefon, Handy, Email...) | elgaimpf-dataelement-383 | |
| Adresse | Adresse der Person (Subelemente: Straße, Hausnummer, PLZ, Ort) Qualifier zur Bezeichnung der Art der Adresse: Wohnadresse, Arbeitsadresse, Pflege, Temporär...) |
elgaimpf-dataelement-384 | |
| Freigabezeitpunkt (Zeitpunkt der Unterzeichnung) | Der Zeitpunkt, an dem die Dokumentation freigegeben wurde | substanceAdministation.author.time | elgaimpf-dataelement-366 |
| Impfende Person (Impfarzt) | Die Person, die im Auftrag der medizinisch verantwortlichen Person die Impfung durchführt, z.B. ein Turnusarzt, eine Hebamme oder eine diplomierte Pflegeperson. Die Impfende Person kann mit der medizinisch verantwortlichen Person ident sein und es können auch beide (redundant) angegeben werden. | substanceAdministration "Immunization Entry"/performer | elgaimpf-dataelement-140 |
| Name | Name der Person | elgaimpf-dataelement-236 | |
| Titel (Präfix) | Titel der Person (voran- und nachgestellte Titel) | elgaimpf-dataelement-237 | |
| Vorname | Vornamen der Person | elgaimpf-dataelement-240 | |
| Nachname | Nachname der Person | elgaimpf-dataelement-241 | |
| Organisation | elgaimpf-dataelement-294 | ||
| ID der Organisation | elgaimpf-dataelement-389 | ||
| Name der Organisation | elgaimpf-dataelement-390 | ||
| Telekom | Weitere Kontaktdaten (Telefon, Handy, Email...) | elgaimpf-dataelement-391 | |
| Adresse | Adresse der Person (Subelemente: Straße, Hausnummer, PLZ, Ort) Qualifier zur Bezeichnung der Art der Adresse: Wohnadresse, Arbeitsadresse, Pflege, Temporär...) |
elgaimpf-dataelement-392 | |
| Rolle | Berufsrolle der impfenden Person (Auswahlliste) | elgaimpf-dataelement-210 | |
| Nachtragende Person | Die Person, die für die fachliche Richtigkeit des Nachtrags verantwortlich ist. Nur für Nachtragung relevant, dort verpflichtend anzugeben. (Z.B: "Dr. Z hat diese Impfung nachgetragen.") Wenn Immunisierungsdaten per Stapelverarbeitung aus bestehenden Registern in den e-Impfpass übertragen werden, kann hier auch das Register eingetragen werden, aus dem die Daten stammen (z.B. "Impfregister des Landes…") |
substanceAdministration "Immunization Entry"/participant mit @typeCode = "ENT" | elgaimpf-dataelement-285 |
| Name | Name der Person | elgaimpf-dataelement-286 | |
| Titel (Präfix) | Titel der Person | elgaimpf-dataelement-287 | |
| Vorname | Vornamen der Person | elgaimpf-dataelement-290 | |
| Nachname | Nachname der Person | elgaimpf-dataelement-291 | |
| Datum der Eintragung (Eintragungsdatum, Datum der Dokumentation) | Datum und Zeit, an dem die Impfung in den e-Impfpass eingetragen d.h. dokumentiert oder geändert wurde. Gilt auch bei einer nachträglichen Eintragung aus einer anderen Quelle (z.B. Papier-Impfpass, andere elektronische Quellen), d.h. NICHT das Impf-Datum | substanceAdministration "Immunization Entry"/participant mit @typeCode = "ENT" / time | elgaimpf-dataelement-293 |
| Korrigierende Person | Die Person, die für die fachliche Richtigkeit der Korrektur eines bestehenden Immunisierungseintrags verantwortlich ist. | substanceAdministration "Immunization Entry"/participant mit @typeCode = "VRF" | elgaimpf-dataelement-402 |
| Name | Name der Person (mit Titel, Vorname, Name, Organisation) | elgaimpf-dataelement-404 | |
| Datum der Korrektur (Korrekturdatum) | Datum und Zeit, an dem die Korrektur im e-Impfpass eingetragen wurde. | substanceAdministration "Immunization Entry"/participant mit @typeCode = "VRF" / time | elgaimpf-dataelement-403 |
| Berechtigter Bearbeiter | Die eindeutige Kennung des GDA, der einen Immunisierungs-Eintrag (entry) bearbeiten darf. Das Berechtigungssystem erlaubt die Korrektur eines Eintrags nur einem GDA mit derselben OID oder GDA mit der Rolle "Korrekturberechtigte Person". | substanceAdministration "Immunization Entry"/participant mit @typeCode = "AUT" | elgaimpf-dataelement-405 |
| Impfling (Patient, Klient, Kunde) | Der Impfling ist die Person, über die der e-Impfpass Impfungen verwaltet und über deren Gesundheitsdaten berichtet wird.. Entspricht dem "Patienten". |
clinicalDocument.recordTarget | elgaimpf-dataelement-1 |
| Name | Name der Person | elgaimpf-dataelement-172 | |
| Titel (Präfix) | Titel der Person (voran- und nachgestellte Titel) | elgaimpf-dataelement-173 | |
| Vorname | Vornamen der Person | elgaimpf-dataelement-176 | |
| Nachname | Nachname der Person | elgaimpf-dataelement-177 | |
| Geburtstdatum | Geburtstdatum der Person | elgaimpf-dataelement-95 | |
| Geschlecht (Administatives Geschlecht) | Administatives Geschlecht der Person im Sinne der Anrede oder Adressierung zB Brief: "Herr" oder "Frau" | Werte: M, F. UNK (Unbekannt) | elgaimpf-dataelement-94 |
| LokaleID | Identifikator des Impflings im lokalen IT-System (Patientenbezogen, nicht fallbezogen) Verpflichtend mit Eintragung einer Impfung anzugeben. |
elgaimpf-dataelement-86 | |
| SVNr (Sozialversicherungsnummer) | Sozialversicherungsnummer | elgaimpf-dataelement-87 | |
| bPK-GH | Gemäß eGovernment-Gesetz ist das bPk-GH der eindeutige Identifikator für den Gesundheitsbereich. Verpflichtende Angabe im CDA-Header für spezifische ELGA-Anwendungen (z.B. e-Medikation) | elgaimpf-dataelement-88 | |
| Adresse | Adresse der Person (Subelemente: Straße, Hausnummer, PLZ, Ort) Qualifier zur Bezeichnung der Art der Adresse: Wohnadresse, Arbeitsadresse, Pflege, Temporär...) |
elgaimpf-dataelement-219 | |
| Straße | elgaimpf-dataelement-252 | ||
| Hausnummer | elgaimpf-dataelement-253 | ||
| Postleitzahl | elgaimpf-dataelement-254 | ||
| Stadt | elgaimpf-dataelement-255 | ||
| Bundesland | elgaimpf-dataelement-256 | ||
| Land | elgaimpf-dataelement-257 | ||
| Gemeindekennziffer (GKZ, ÖSTAT-Nr.) | Allen Gemeinden Österreichs ist eine 5-stellige Gemeindekennziffer (GKZ) zugeordnet. Das Gemeindeverzeichnis bildet die Verwaltungsgliederung in Verwaltungssprengel ab. Die Vergabe der Gemeindekennziffer obliegt Statistik Austria (Adressregisterverordnung – AdrRegV, BGBl. 218/2005, §1). |
Kein Mapping, ist nicht im CDA Dokumenten enthalten. Liegt in der zentralen Anwendung zur Adresse vor. | elgaimpf-dataelement-49 |
| Bezirkskennziffer (BKZ) | Wie Gemeindekennziffer, erste 3 Stellen | Kein Mapping, ist nicht im CDA Dokumenten enthalten. Liegt in der zentralen Anwendung zur Adresse vor. | elgaimpf-dataelement-85 |
| Kontaktdaten | Weitere Kontaktdaten (Telefon, Handy, Email...) | elgaimpf-dataelement-216 | |
| Telefon Mobil | elgaimpf-dataelement-227 | ||
| Telefon Festnetz | elgaimpf-dataelement-228 | ||
| elgaimpf-dataelement-229 | |||
| FAX | elgaimpf-dataelement-230 | ||
| Personengruppe (Expositionsrisikogruppe) | Merkmal für Zugehörigkeit des Impflings zu bestimmten Personen- oder Risikogruppen (z.B. Gesundheitsberufe). Bei bestimmten Personengruppen kann das Impfschema und damit die berechnete Impffrist abweichen. Optional, mehrfache Angabe möglich. |
Sektion "Expositionsrisiko Personengruppen" mit Act "Expositionsrisiko Problem Concern Entry" | elgaimpf-dataelement-125 |
| Zeitbereich | Zeitbereich, in dem die Zugehörigkeit zur Personengruppe aktiv ist oder war | elgaimpf-dataelement-394 | |
| Impfung (Vakzination, Schutzimpfung, Immunisierung ) | Dokumentierte Impfung: ein einzelne Gabe eines Impfstoffes | Sektion "Impfungen - kodiert", substanceAdministration "Immunization Entry" | elgaimpf-dataelement-2 |
| Impfung (Klassifikation) (Impfschutz, Impfstoffgruppe, Immunisierung) | Impfschutz gegen eine bestimmte Krankheit oder einen Erreger. Mehrfach-Attribut - Bei einer Impfung mit einem Produkt können mehrere Wirkstoffe (gegen mehrere Krankheiten) verabreicht werden. Alle einzelnen "Impfungen" müssen zu dem Produkt zentral verfügbar sein. |
substanceAdministration "Immunization Entry" und entryRelationship/Observation "Immunization Target Entry" | elgaimpf-dataelement-6 |
| Impfschema (Impfkonzept, vaccinationProtocol) | Name für den "Plan der notwendigen Impf-Dosen" (Regelwerk für die Gabe von Impfdosen bzw Teilimpfungen zur Immunisierung; Grundimmunissierung und Auffrischung) Wenn bei Impfung nicht angegeben, wird das "Default-Schema" angenommen. |
Mapping: substanceAdministration "Immunization Entry" und precondition/criterion "Immunization Schedule Entry" | elgaimpf-dataelement-25 |
| Dosiskennung (Dosis-Nummer, Reihenfolgenummer in der Sequenz der Impfdosen) | Angabe, um welche Impfung oder Teilimpfung es sich handelt (entsprechend einem Impfschema) | Mapping: criterion "Immunization Schedule Entry"/value | elgaimpf-dataelement-30 |
| Impfdatum (Vaccination administration date) | Zeitpunkt der Durchführung der Impfung | substanceAdministration "Immunization Entry"/effectiveTime | elgaimpf-dataelement-8 |
| Impfort | Ort, an dem die Impfung stattgefunden hat (wenn abweichend von Organisation Impfarzt). (z.B: Öffentliche Einrichtung, Schule (+ Klasse), Kaserne, Betrieb ...) | Muss immer im "Performer" Element des Immunization Entry angegeben werden.
Wenn der verantwortliche Arzt selbst impft, muss er zusätzlich als Impfarzt eingetragen werden. |
elgaimpf-dataelement-137 |
| Impfreaktion (Reaktion) | Aufgetretene Reaktion, Auswahlkatalog | Wurde nicht umgesetzt | elgaimpf-dataelement-283 |
| Abrechenbarkeit | Kennzeichen, ob Impfung mit Land abgerechnet werden kann (Eintragung durch impfenden Arzt) | Notwendig für Filterung der Daten, die an Länder zur Abrechnung der Impfungen weitergeleitet werden. Die Abrechenbarkeit selbst wird vom Land geprüft und festgestellt.Mapping: substanceAdministration "Immunization Entry" und entryRelationship/act "Immunization Billability Entry" | elgaimpf-dataelement-29 |
| Klassifikator (Honorar-Klassifikation) | Abrechnungsrelevante Klassifikation der Impfenden Person (zB "Arzt mit Hausapotheke"). Wird im Zentralsystem nicht mehr benötigt, daher gestrichen. --> Die Verrechnung etc. erfolgt über die internen GDA Systeme (benötigt wird nur die Kennzeichnungsmöglichkeit ob abrechenbar oder nicht |
act "Immunization Billability Entry"/code/qualifier | elgaimpf-dataelement-367 |
| Impfindikation | Grund für die Impfung (optional). Wird für Abrechnung benötigt: * IG1 Indikationsimpfung für Risikogruppe * IG2 Wiederholungsimpfung aufgrund medizinischer Indikation |
act "Immunization Billability Entry"/code/qualifier | elgaimpf-dataelement-379 |
| Impfgutschein | Identifikationskennzeichen eines Impf-Gutscheins (bei Vorliegen von Impf-Gutscheinheften) | Notwendig für Abrechnung. Alphanumerisches Kennzeichen (gültig 1x für eine Impfung). Keine weitere Prüfung im e-Impfpass.Mapping: act "Immunization Billability Entry" mit act/id | elgaimpf-dataelement-139 |
| Zusatzklassifikation | Zusätzliche strukturierte Information zu einer Impfung, zB eine Klassifizierung der Umgebung, in der die Impfung stattgefunden hat. | "Immunization Entry" mit observation "Zusatzklassifikation" Das @code-Attribut definiert die Art der Klassifizierung, der Wert wird im @value-Attribut angegeben. |
elgaimpf-dataelement-401 |
| Impfstoff (Produkt) (Arzneimittel) | Daten zur verabreichten Arzneimittelspezialität | substanceAdministration "Immunization Entry" und consumable/manufacturedProduct "Vaccine Product" bzw. "Vaccine Product nicht angegeben" | elgaimpf-dataelement-3 |
| Bezeichnung der Arnzei (Zulassungsname) | Bezeichnung des Impfstoffes, z.B. "Encepur 0,25 ml für Kinder Injektionssuspension in einer Fertigspritze" | manufacturedProduct/manufacturedMaterial/name | elgaimpf-dataelement-31 |
| Pharmazentralnummer (PZN) | Pharmazentralnummer der Arzneispezialität | manufacturedProduct/manufacturedMaterial/code | elgaimpf-dataelement-5 |
| Chargennummer (Charge) | Chargennummer der Arzneispezialität, die verabreicht wurde | manufacturedProduct/manufacturedMaterial/lotNumberText | elgaimpf-dataelement-4 |
| Ablaufdatum | Muss dokumentiert werden. Kann aus 2D Barcode abgleitet werden Nicht für "Nacherfassung" erforderlich |
substanceAdministration "Immunization Entry" mit entryRelationship/act "Immunization Billability Entry"/effectiveTime | elgaimpf-dataelement-134 |
| UniqueIdentifier (Serialisierungsnummer) | Serialisierungsnummer oder "Packungs-Identifikator. Durch die Serialisierungsnummer ist jede einzelne Packung im europäischen Markt individualisierbar, entsprechend Fälschungsschutzrichtlinie 2011/62/EU und zugehörigerr delegierte Verordnung (EU) 2016/161 | manufacturedProduct/id | elgaimpf-dataelement-135 |
| Hersteller (Zulassungsinhaber) | Hersteller (Zulassungsinhaber) des Impfstoffes (bzw. der Arzneispezialität) | manufacturedProduct/manufacturerOrganization | elgaimpf-dataelement-12 |
| ATC | ATC-Code des Wirkstoffs aus Fachinformation | manufacturedMaterial/pharm:ingredient/pharm:ingredient/pharm:code | elgaimpf-dataelement-235 |
| Wirkstoff | Wirkstoff(e) des Arzneimittels, zB "Masernviren, Stamm Schwarz (lebend, attenuiert) | manufacturedMaterial/pharm:ingredient | elgaimpf-dataelement-185 |
| Menge (Dosis) | Menge der verabreichten Arzneispezialität (Mengenangabe aus Fachinformation). Hinweis: Die tatsächlich verabreichte Menge kann dokumentiert werden, falls von Fachinformation abweichend. Falls zwei Impfdosen verabreicht werden ("zwei Packungen"), gibt es zwei Möglichkeiten der Dokumentation: Wenn die Packungen dieselbe Chargennummer besitzen: Verabreichte Menge verdoppeln, nur eine Impfung dokumentieren (zwei Impfungen mit derselben Chargennummer würden von der zentralen Applikation als Duplikat erkannt und ignoriert). Wenn zwei unterschiedliche Chargennummern verimpft werden, können beide jeweils als eine eigene Impfung mit derselben Dosiskennung und demselben Impfdatum gespeichert werden. |
substanceAdministration "Immunization Entry"/doseQuantity | elgaimpf-dataelement-15 |
| Impfempfehlung (Impfkalender) | Daten der empfohlenen (zukünftigen) Impfungen: * Impfung, Arzneimittel, frühestmöglicher Folgetermin (Tag) * Anzugebende Folgetermine: immer nur der nächste Folgetermin Die Impflogik gilt grundsätzlich für lt. Impfplan empfohlene Impfungen und für darüber hinaus bereits einmal verabreichte Impfungen Automatisch / von Arzt eingetragen (zusätzlich) |
Sektion "Impfempfehlungen - kodiert" mit entry/substanceAdministration "Immunization Recommendation Entry" und negationInd "false". | elgaimpf-dataelement-169 |
| Impf-Frist (Datum der nächsten Impfung) | Datum (Frist oder Zeitraum), an dem der nächste Impftermin (für diese Impfung) notwendig ist. Wird definiert durch: Nationaler Impfplan Fachinformation (liegt derzeit nicht strukturiert vor) Individuelle Konstellation des Impflings --> manueller Eintrag bei Impfung (Abhängig vom Produkt bzw "Impfung", wenn Kombinationspräparat) |
choice von /effectiveTime als TS und /effectiveTime als IVL_TS | elgaimpf-dataelement-28 |
| Dosiskennung (Dosis-Nummer, Reihenfolgenummer in der Sequenz der Impfdosen) | Angabe, um welche Impfung oder Teilimpfung es sich handelt (entsprechend einem Impfschema) | /precondition/criterion "Immunization Schedule Entry" | elgaimpf-dataelement-231 |
| Autor (Quelle) | Person oder System, das die Empfehlung generiert | /author | elgaimpf-dataelement-232 |
| Impfung (Klassifikation) (Referenz) | Verweist auf die Impfung, für die diese Empfehlung gilt. Eine Impfempfehlung pro Impfung (nicht pro Kombination) | entryRelationship mit observation "Immunization Target Entry" | elgaimpf-dataelement-380 |
| Impfstoff (Referenz) | Verweist auf das Produkt, für das die Empfehlung gilt; aber mit eingeschränkten Attributen (PZN) | consumable | elgaimpf-dataelement-233 |
| Impfschema (Referenz) | Referenz auf den der Empfehlung zugrundeliegenden Impfplan, Fachinformation, Dokumentation, … 1. Nationaler Impfplan 2. Fachinformation (liegt derzeit nicht strukturiert vor) 3. Individuelle Konstellation des Impflings --> manueller Eintrag bei Impfung (Abhängig vom Produkt bzw "Impfung", wenn Kombinationspräparat) |
reference/externalDocument | elgaimpf-dataelement-234 |
| Begründung | Freitext zur Begründung einer vom Impfarzt angepassten Impfempfehlung | entryRelationship/@typeCode = "RSON" mit act "Comment Entry" | elgaimpf-dataelement-171 |
| Kontraindikation für Impfungen | Daten der Impfungen, die nicht verabreicht werden sollen: * Impfung
|
Sektion "Impfempfehlungen - kodiert" mit entry/substanceAdministration "Immunization Recommendation Entry" und negationInd "true". | elgaimpf-dataelement-169 |
| Zeitraum | Zeitraum, in dem die Kontraindikation gilt | choice von /effectiveTime als TS und /effectiveTime als IVL_TS | elgaimpf-dataelement-28 |
| Autor (Quelle) | Person oder System, das die Kontraindikation bestätigt | /author | elgaimpf-dataelement-232 |
| Impfung (Klassifikation) (Referenz) | Verweist auf die Impfung, für die diese Kontraindikation gilt. | entryRelationship mit observation "Immunization Target Entry" | elgaimpf-dataelement-380 |
| Impfstoff (Referenz) | Verweist auf das Produkt, für das die Kontraindikation gilt | consumable | elgaimpf-dataelement-233 |
| Impfschema (Referenz) | Referenz auf den der Kontraindikation zugrundeliegenden Impfplan, Fachinformation, Dokumentation, … 1. Nationaler Impfplan 2. Fachinformation (liegt derzeit nicht strukturiert vor) 3. Individuelle Konstellation des Impflings --> manueller Eintrag bei Impfung (Abhängig vom Produkt bzw "Impfung", wenn Kombinationspräparat) |
reference/externalDocument | elgaimpf-dataelement-234 |
| Begründung | Freitext zur Begründung einer vom Arzt eingetragenen Kontraindikation | entryRelationship/@typeCode = "RSON" mit act "Comment Entry" | elgaimpf-dataelement-171 |
| Impfrelevante Erkrankung | Dokumentation von Infektionskrankheiten, die eine langfristige Immunisierung nach sich ziehen und daher eine weitere Impfung nicht notwendig machen. Die Eintragung erfolgt optional bei der Erhebung der Impfanamnese. |
Sektion "Impfrelevante Erkrankungen - kodiert" mit act "Impfrelevante Erkrankungen Problem Concern Entry" | elgaimpf-dataelement-27 |
| Impfrelevante Erkrankung | Impfrelevante Erkrankung (aus Auswahlkatalog, z.B. FSME, Varizellen, ...) | Sektion "Impfrelevante Erkrankungen - kodiert" mit act "Impfrelevante Erkrankungen Problem Concern Entry" | elgaimpf-dataelement-126 |
| Erkrankungsdatum | Zeitintervall, in der die Erkrankung beobachtet wurde | elgaimpf-dataelement-393 | |
| Bemerkungen (Anmerkungen) | Freitext für Eintragung des Nachweises der durchgemachten Erkrankung, z.B. durch Vorbefund oder Laborbefund mit Titer. | observation "Impfrelevante Erkrankungen Problem Entry" mit entryRelationship act "Comment Entry" | elgaimpf-dataelement-16 |
| Autor | Erfasser der Information | elgaimpf-dataelement-282 | |
| Impfung (Referenz) | Verknüpfung zu Impfung | elgaimpf-dataelement-284 | |
| Antikörper-Bestimmung (Impftiter) | Ergebnisse von Antikörper-Untersuchungen, Antikörper Bestimmungen für für Virushepatitis A und B, Röteln und Varizellen etc. | Sektion "Antikörper-Bestimmung" mit act "Lab Report Data Processing Entry" und entryRelationship "Laboratory Observation Entry" | elgaimpf-dataelement-129 |
| Analyse | Gemessener Laborparameter | "Laboratory Observation Entry" | elgaimpf-dataelement-271 |
| Wert | Wert der Analyse | "Laboratory Observation Entry" / value | elgaimpf-dataelement-272 |
| Einheit | Einheit des Messwerts. Muss in UCUM Notation angegeben werden |
"Laboratory Observation Entry" /value/@unit | elgaimpf-dataelement-273 |
| Bewertung (Interpretation) | Interpretations des Messwerts (Interpretationskennzeichen) | "Laboratory Observation Entry" /interpretationCode | elgaimpf-dataelement-274 |
| Datum | Datum der Abnahme (wenn nicht vorhanden, Datum der Bestimmung) | "Laboratory Observation Entry" /effectiveTime | elgaimpf-dataelement-275 |
| Durchführendes Labor | Durchführendes Labor | "Laboratory Observation Entry" / performer | elgaimpf-dataelement-276 |
| ID der Organisation | elgaimpf-dataelement-277 | ||
| Name der Organisation | elgaimpf-dataelement-278 | ||
| Telekom | Weitere Kontaktdaten (Telefon, Handy, Email...) | elgaimpf-dataelement-279 | |
| Adresse | Adresse der Person (Subelemente: Straße, Hausnummer, PLZ, Ort) Qualifier zur Bezeichnung der Art der Adresse: Wohnadresse, Arbeitsadresse, Pflege, Temporär...) |
elgaimpf-dataelement-280 | |
| Informationsquelle | Herkunft der Information | elgaimpf-dataelement-11 |
11 Technische Spezifikation
11.1 Übersicht CDA Struktur "Kompletter Immunisierungsstatus"
Die Struktur des CDA Austauschformats ist in den nachfolgenden Kapiteln im Detail beschrieben. Zum schnellen Einstieg findet sich hier eine stark vereinfachte Zusammenfassung der Elemente. Dieses Dokument kann von der zentralen Anwendung "e-Impfpass" angefragt werden. Es enthält alle gespeicherten Informationen zum Immunisierungsstatus der Person und wird jeweils aktuell erzeugt ("On-Demand-Dokument").
ELGA Interoperabilitätsstufen (EIS): Dieses Dokument existiert ausschließlich in einer voll strukturierten Form, eine Unterscheidung der Interoperabilitätsstufen ist daher nicht notwendig.
11.1.1 CDA Header
Der Header enthält die (administrativen) Dokument-Metadaten
- Allgemeine Dokumentinformationen: Dokumenten-Id, Code, Titel, Erstellungszeitpunkt, Sprache, Version
- "Impfling" Angaben zur Person (Patient), deren Immunisierungsstatus beschrieben wird: Name, Geburtsdatum, Geschlecht, Identifikatoren, Adresse und Kontaktdaten, ...
- Mitwirkende am Dokument: Autoren, Schreibkraft, Verwalter, Unterzeichner
- Related Document: Verweis auf ein allfällig ersetztes Dokument (Vorversion)
Der Header entspricht im Wesentlichen den bisherigen ELGA-CDA-Leitfäden ("Allgemeiner Leitfaden"). Für den e-Impfpass wurden punktuell Neuerungen eingeführt:
- TemplateIds für die Versionskennung
- Zusätzliches Translation-Element für den clinicalDocument.code
Hinweis: Einige Header-Elemente des Allgemeinen Leitfadens werden hier nicht benötigt [NP], sind aber der Vollständigkeit halber angegeben. [NP]-Elemente dürfen nicht angegeben werden, bzw. sind zu ignorieren. Beispiele: Data Enterer, Authorization, LegalAuthenticator, ...
11.1.2 CDA Body
Der "Structured Body" enthält die tatsächlichen (medizinischen) Inhalte des Dokuments
- Kapitel Impfungen: Sammlung der dokumentierten Impfungen
- Impfung, Impfdatum, Impfstoff, Impfschema und Dosiskennung, medizinisch verantwortliche Person, Krankheit gegen welche die Impfung schützt, PZN, Chargennummer (LOT-Nr), Dosierung und weitere Angaben zur Verabreichung (Teilnehmende Personen)
- Kapitel Personengruppe: Dokumentiert die Zugehörigkeit zu speziellen Personengruppen.
- Personengruppe, Datumsbereich der Zugehörigkeit zur Gruppe
- Kapitel Impfrelevante Erkrankungen: Sammlung der dokumentierten impfrelevanten Erkrankungen
- Erkrankung, Datumsbereich
- Kapitel Antikörper-Untersuchungen: Sammlung der dokumentierten Antikörper-Bestimmungen
- Untersuchung, Wert, Bewertung, Datum
- Kapitel Impfempfehlungen: Sammlung der dokumentierten Impfempfehlungen (automatisch erstellte sowie vom Impfarzt individuell empfohlene)
- Strukturell wie Impfungen, mit anderen Pflichtfeldern und anderem Status
- Kapitel Beilagen: digitalisierter Papierimpfpass als Attachment
Anmerkung: Impfreaktionen werden nicht unterstützt.
11.2 Übersicht CDA Struktur "Update Immunisierungsstatus"
Die Struktur des CDA Austauschformats ist in den nachfolgenden Kapiteln im Detail beschrieben. Zum schnellen Einstieg findet sich hier eine stark vereinfachte Zusammenfassung der Elemente.
Dieses Dokument wird vom impfenden GDA erstellt und an die zentrale Applikation gesendet. Es enthält die Informationen, die der GDA bei einem Besuch dokumentiert. Es kann Impfungen, Impfempfehlungen, impfrelevante Erkrankungen, Antikörperbestimmungen, etc enthalten.
ELGA Interoperabilitätsstufen (EIS): Dieses Dokument existiert ausschließlich in einer voll strukturierten Form, eine Unterscheidung der Interoperabilitätsstufen ist daher nicht notwendig.
11.2.1 CDA Header
Der Header enthält die (administrativen) Dokument-Metadaten
- Allgemeine Dokumentinformationen: Dokumenten-Id, Code, Titel, Erstellungszeitpunkt, Sprache, Version
- "Impfling" Angaben zur Person (Patient), deren Immunisierungsstatus beschrieben wird: Name, Geburtsdatum, Geschlecht, Identifikatoren, Adresse und Kontaktdaten, ...
- Mitwirkende am Dokument: Autoren, Erfasser, Verwalter, Unterzeichner
- Related Document: Verweis auf ein allfällig ersetztes Dokument (Vorversion)
Der Header entspricht im Wesentlichen den bisherigen ELGA-CDA-Leitfäden ("Allgemeiner Leitfaden"). Für den e-Impfpass wurden punktuell Neuerungen eingeführt:
- TemplateIds für die Versionskennung
- Zusätzliches Translation-Element für den clinicalDocument.code
11.2.2 CDA Body
Der "Structured Body" enthält die tatsächlichen (medizinischen) Inhalte des Dokuments
- Kapitel Impfungen: Sammlung der dokumentierten Impfungen
- Impfung, Impfdatum, Impfstoff, Impfschema und Dosiskennung, medizinisch verantwortliche Person, Krankheit gegen welche die Impfung schützt, PZN, Chargennummer (LOT-Nr), Dosierung und weitere Angaben zur Verabreichung (Teilnehmende Personen)
- Kapitel Personengruppe: Dokumentiert die Zugehörigkeit zu speziellen Personengruppen.
- Personengruppe, Datumsbereich der Zugehörigkeit zur Gruppe
- Kapitel Impfrelevante Erkrankungen: Sammlung der dokumentierten impfrelevanten Erkrankungen
- Erkrankung, Datumsbereich
- Kapitel Antikörper-Bestimmungen: Sammlung der dokumentierten Laboruntersuchungen der impfrelevanten Antikörper ("Impftiter")
- Untersuchung, Wert, Bewertung, Datum
- Kapitel Impfempfehlungen: Vom Impfarzt individuell empfohlene Impfungstermine, wenn abweichend von den automatisch erstellten Impfempfehlungen
- Strukturell wie Impfungen, mit anderen Pflichtfeldern und anderem Status
Anmerkung: Impfreaktionen werden nicht unterstützt.
11.3 Übersicht der Strukturen mit Konformität und Kardinalität
Folgende Tabellen sollen einen groben Überblick über die Inhalte der einzelnen Sektionen geben. Details sind den entsprechenden Templates zu entnehmen.
11.3.1 Sektion Impfungen - kodiert
1. Dokumentation einer Impfung:
- Kompletter Immunisierungsstatus: Impfung wird angezeigt.
- Update Immunisierungsstatus: Neue Impfung wird durchgeführt.
- Update Nachtrag Immunisierungsstatus: Nachtrag einer bereits durchgeführten Impfung.
Anmerkung: Entweder-Oder-Auswahlmöglichkeiten sind mit "#)" gekennzeichnet.
| Sektion Impfungen | Kompletter I. | Update I. | Update I.
Nachtrag | ||
|---|---|---|---|---|---|
| SECTION Impfungen - kodiert (1.2.40.0.34.6.0.11.2.1) | M [1..1] | M [1..1] | M [1..1] | ||
| Immunization Entry (1.2.40.0.34.6.0.11.3.1) | M [1..*] | M [1..*] | M [1..*] | ||
| #) Vaccine Product (1.2.40.0.34.6.0.11.9.32) | C [0..1] | M [1..1] | C [0..1] | ||
| #) Vaccine Product nicht angegeben (1.2.40.0.34.6.0.11.9.31) | C [0..1] | NP [0..0] | C [0..1] | ||
| Performer Body - Impfende Person (1.2.40.0.34.6.0.11.9.21) Impfende Person | C [0..1] | C [0..1] | O [0..1] | ||
| Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8) Medizinisch verantwortliche Person | C [0..1] | M [1..1] | O [0..1] | ||
| Informant Body (1.2.40.0.34.6.0.11.9.3) Bürger (bei Selbsteintragung) | C [0..1] | C [0..1] | NP [0..0] | ||
| Participant Body - Transcriber (1.2.40.0.34.6.0.11.9.14) Nachtragende Person | C [0..1] | NP [0..0] | M [1..1] | ||
| Participant Body - Verifier (1.2.40.0.34.6.0.11.9.44) Korrigierende Person | C [0..1] | NP [0..0] | NP [0..0] | ||
| Participant Body - Authorized Editor (1.2.40.0.34.6.0.11.9.46) Berechtigter Bearbeiter | C [0..1] | NP [0..0] | NP [0..0] | ||
| Participant Body - Data Enterer (1.2.40.0.34.6.0.11.9.47) Eintragende Person | C [0..1] | NP [0..0] | NP [0..0] | ||
| Immunization Target Entry (1.2.40.0.34.6.0.11.3.2) | M [1..*] | M [1..*] | M [1..*] | ||
| Immunization Billability Entry (1.2.40.0.34.6.0.11.3.5) | NP [0..0] | O [0..1] | NP [0..0] | ||
| Zusatzklassifikation (1.2.40.0.34.6.0.11.3.168) Impfsetting | R [0..*] | R [0..*] | R [0..*] | ||
| External Document Entry (1.2.40.0.34.6.0.11.3.14) Referenz auf zugrundeliegendes Update-Dokument | M [1..1] | R [0..1] | R [0..1] | ||
| External Document Entry (1.2.40.0.34.6.0.11.3.14) Referenz auf das Impfzertifikat | R [0..1] | R [0..1] | R [0..1] | ||
| Immunization Schedule Entry (1.2.40.0.34.6.0.11.3.10) Impfschema | M [1..1] | M [1..1] | M [1..1] | ||
| SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8) | O [0..*] | O [0..*] | O [0..*] | ||
| Author Body (1.2.40.0.34.6.0.11.9.36) | R [0..*] | R [0..*] | R [0..*] | ||
| Informant Body (1.2.40.0.34.6.0.11.9.3) | R [0..*] | R [0..*] | R [0..*] | ||
2. Es wird keine Impfung durchgeführt, sondern z.B. eine Krankheit eingetragen.
| Sektion Impfungen | Kompletter I. | Update I. | Update I.
Nachtrag | ||
|---|---|---|---|---|---|
| SECTION Impfungen - kodiert (1.2.40.0.34.6.0.11.2.1) | M [1..1] | M [1..1] | M [1..1] | ||
| Immunization Entry Impfung nicht angegeben (1.2.40.0.34.6.0.11.3.28) | M [1..1] | M [1..1] | M [1..1] | ||
| Vaccine Product nicht angegeben (1.2.40.0.34.6.0.11.9.31) | M [1..1] | M [1..1] | M [1..1] | ||
| SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8) (siehe Sektion Impfungen) | O [0..*] | O [0..*] | O [0..*] | ||
11.3.2 Sektion Expositionsrisiko Personengruppen - kodiert
| Sektion Expositionsrisiko Personengruppen | Kompletter I. | Update I. | Update I.
Nachtrag | |||
|---|---|---|---|---|---|---|
| SECTION Expositionsrisiko Personengruppen - kodiert (1.2.40.0.34.6.0.11.2.4) | O [0..1] | O [0..1] | O [0..1] | |||
| Expositionsrisiko Problem Concern Entry (1.2.40.0.34.6.0.11.3.20) | M [1..*] | M [1..*] | M [1..*] | |||
| Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8) | M [1..1] | M [1..1] | M [1..1] | |||
| Expositionsrisiko Problem Entry (1.2.40.0.34.6.0.11.3.21) | M [1..1] | M [1..1] | M [1..1] | |||
| Participant Body - Verifier (1.2.40.0.34.6.0.11.9.44) Korrigierende Person | C [0..1] | NP [0..0] | NP [0..0] | |||
| Participant Body - Authorized Editor (1.2.40.0.34.6.0.11.9.46) Berechtigter Bearbeiter | C [0..1] | NP [0..0] | NP [0..0] | |||
| Participant Body - Data Enterer (1.2.40.0.34.6.0.11.9.47) Eintragende Person | C [0..1] | NP [0..0] | NP [0..0] | |||
| External Document Entry (1.2.40.0.34.6.0.11.3.14) Referenz auf zugrundeliegendes Update-Dokument | M [1..1] | O [0..1] | O [0..1] | |||
| SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8) (siehe Sektion Impfungen) | O [0..*] | O [0..*] | O [0..*] | |||
11.3.3 Sektion Impfrelevante Erkrankungen - kodiert
| Sektion Impfrelevante Erkrankungen | Kompletter I. | Update I. | Update I.
Nachtrag | ||||
|---|---|---|---|---|---|---|---|
| SECTION Impfrelevante Erkrankungen - kodiert (1.2.40.0.34.6.0.11.2.5) | O [0..1] | O [0..1] | O [0..1] | ||||
| Impfrelevante Erkrankungen Problem Concern Entry (1.2.40.0.34.6.0.11.3.8) | M [1..*] | M [1..*] | M [1..*] | ||||
| Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8) | M [1..1] | M [1..1] | M [1..1] | ||||
| Impfrelevante Erkrankungen Problem Entry (1.2.40.0.34.6.0.11.3.9) | M [1..1] | M [1..1] | M [1..1] | ||||
| Participant Body - Verifier (1.2.40.0.34.6.0.11.9.44) Korrigierende Person | C [0..1] | NP [0..0] | NP [0..0] | ||||
| Participant Body - Authorized Editor (1.2.40.0.34.6.0.11.9.46) Berechtigter Bearbeiter | C [0..1] | NP [0..0] | NP [0..0] | ||||
| Participant Body - Data Enterer (1.2.40.0.34.6.0.11.9.47) Eintragende Person | C [0..1] | NP [0..0] | NP [0..0] | ||||
| Comment Entry (1.2.40.0.34.6.0.11.3.11) | O [0..1] | O [0..1] | O [0..1] | ||||
| Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8) | C [0..1] | C [0..1] | C [0..1] | ||||
| Informant Body (1.2.40.0.34.6.0.11.9.3) | C [0..1] | C [0..1] | C [0..1] | ||||
| External Document Entry (1.2.40.0.34.6.0.11.3.14) Referenz auf zugrundeliegendes Update-Dokument | M [1..1] | R [0..1] | R [0..1] | ||||
| External Document Entry (1.2.40.0.34.6.0.11.3.14) Referenz auf das Impfzertifikat | R [0..1] | R [0..1] | R [0..1] | ||||
| SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8) (siehe Sektion Impfungen) | O [0..*] | O [0..*] | O [0..*] | ||||
11.3.4 Sektion Antikörper-Bestimmung - kodiert
| Sektion Antikörper-Bestimmung | Kompletter I. | Update I. | Update I.
Nachtrag | |||||
|---|---|---|---|---|---|---|---|---|
| SECTION Antikörper-Bestimmung - kodiert (1.2.40.0.34.6.0.11.2.7) | O [0..1] | O [0..1] | O [0..1] | |||||
| Antikörper-Bestimmung Data Processing Entry (1.2.40.0.34.6.0.11.3.15) | M [1..*] | M [1..*] | M [1..*] | |||||
| Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8) | M [1..1] | M [1..1] | M [1..1] | |||||
| Antikörper-Bestimmung Battery Organizer (1.2.40.0.34.6.0.11.3.18) | M [1..*] | M [1..*] | M [1..*] | |||||
| Antikörper-Bestimmung Laboratory Observation Entry (1.2.40.0.34.6.0.11.3.16) | O [0..*] | O [0..*] | O [0..*] | |||||
| Participant Body - Verifier (1.2.40.0.34.6.0.11.9.44) Korrigierende Person | C [0..1] | NP [0..0] | NP [0..0] | |||||
| Participant Body - Authorized Editor (1.2.40.0.34.6.0.11.9.46) Berechtigter Bearbeiter | C [0..1] | NP [0..0] | NP [0..0] | |||||
| Participant Body - Data Enterer (1.2.40.0.34.6.0.11.9.47) Eintragende Person | C [0..1] | NP [0..0] | NP [0..0] | |||||
| Comment Entry (1.2.40.0.34.6.0.11.3.11) siehe Sektion Impfrelevante Erkrankungen | O [0..1] | O [0..1] | O [0..1] | |||||
| Participant (Validierende Person) | O [0..1] | O [0..1] | O [0..1] | |||||
| Performer Body - Laboratory (1.2.40.0.34.6.0.11.9.28) Externes Labor | O [0..*] | O [0..*] | O [0..*] | |||||
| External Document Entry (1.2.40.0.34.6.0.11.3.14) Referenz auf zugrundeliegendes Update-Dokument | M [1..1] | O [0..1] | O [0..1] | |||||
| External Document Entry (1.2.40.0.34.6.0.11.3.14) Referenz auf das Impfzertifikat | R [0..1] | R [0..1] | R [0..1] | |||||
| SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8) (siehe Sektion Impfungen) | O [0..*] | O [0..*] | O [0..*] | |||||
11.3.5 Sektion Impfempfehlungen - kodiert
| Sektion Impfempfehlungen | Kompletter I. | Update I. | Update I.
Nachtrag | |||
|---|---|---|---|---|---|---|
| SECTION Impfempfehlungen - kodiert (1.2.40.0.34.6.0.11.2.2) | R [1..1] | O [0..1] | O [0..1] | |||
| Immunization Recommendation Entry (1.2.40.0.34.6.0.11.3.3) | M [1..*] | M [1..*] | M [1..*] | |||
| #) Vaccine Product (1.2.40.0.34.6.0.11.9.32) | C [0..1] | C [0..1] | C [0..1] | |||
| #) Vaccine Product nicht angegeben (1.2.40.0.34.6.0.11.9.31) | C [0..1] | C [0..1] | C [0..1] | |||
| Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8) Medizinisch verantwortliche Person | M [1..1] | M [1..1] | M [1..1] | |||
| Participant Body - Verifier (1.2.40.0.34.6.0.11.9.44) Korrigierende Person | C [0..1] | NP [0..0] | NP [0..0] | |||
| Participant Body - Authorized Editor (1.2.40.0.34.6.0.11.9.46) Berechtigter Bearbeiter | C [0..1] | NP [0..0] | NP [0..0] | |||
| Participant Body - Data Enterer (1.2.40.0.34.6.0.11.9.47) Eintragende Person | C [0..1] | NP [0..0] | NP [0..0] | |||
| Immunization Target Entry (1.2.40.0.34.6.0.11.3.2) | M [1..*] | M [1..*] | M [1..*] | |||
| Comment Entry (1.2.40.0.34.6.0.11.3.11) siehe Sektion Impfrelevante Erkrankungen | O [0..1] | O [0..1] | O [0..1] | |||
| Impfplan Entry (1.2.40.0.34.6.0.11.3.22) | O [0..1] | O [0..1] | O [0..1] | |||
| External Document Entry (1.2.40.0.34.6.0.11.3.14) Referenz auf zugrundeliegendes Update-Dokument | O [0..1] | O [0..1] | O [0..1] | |||
| Immunization Schedule Entry (1.2.40.0.34.6.0.11.3.10) Impfschema | M [1..1] | M [1..1] | M [1..1] | |||
| SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8) (siehe Sektion Impfungen) | O [0..*] | O [0..*] | O [0..*] | |||
11.3.6 Sektion Beilagen
| Sektion Beilagen | Kompletter I. | Update I. | Update I.
Nachtrag | ||
|---|---|---|---|---|---|
| SECTION Beilagen (1.2.40.0.34.6.0.11.2.71) | O [0..1] | R [0..1] | O [0..1] | ||
| Eingebettetes Objekt Entry (1.2.40.0.34.6.0.11.3.19) | M [1..*] | M [1..*] | M [1..*] | ||
| Author Body (1.2.40.0.34.6.0.11.9.36) | C [0..1] | C [0..1] | C [0..1] | ||
| Informant Body (1.2.40.0.34.6.0.11.9.3) | C [0..1] | C [0..1] | C [0..1] | ||
11.4 CDA Templates
11.4.1 Document Level Templates
11.4.1.1 Kompletter Immunisierungsstatus
| Id | 1.2.40.0.34.6.0.11.0.4 | Gültigkeit | 2022‑07‑15 13:50:33 Andere Versionen mit dieser Id:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Status |  Aktiv | Versions-Label | 1.3.1+20220714 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Name | eimpf_document_KompletterImmunisierungsstatus | Bezeichnung | Kompletter Immunisierungsstatus | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Kontext | Pfadname / | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Klassifikation | CDA Document Level Template | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Offen/Geschlossen | Geschlossen (nur definierte Elemente sind erlaubt) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Assoziiert mit |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Benutzt |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Beziehung | Version: Template 1.2.40.0.34.6.0.11.0.4 Kompletter Immunisierungsstatus (2022‑01‑25 12:13:30) ref elgaimpf- Version: Template 1.2.40.0.34.6.0.11.0.4 Kompletter Immunisierungsstatus (2021‑08‑24 10:37:08) ref elgaimpf- Version: Template 1.2.40.0.34.6.0.11.0.4 Kompletter Immunisierungsstatus (2021‑05‑25 13:22:08) ref elgaimpf- Version: Template 1.2.40.0.34.6.0.11.0.4 Kompletter Immunisierungsstatus (2021‑05‑12 09:26:01) ref elgaimpf- Version: Template 1.2.40.0.34.6.0.11.0.4 Kompletter Immunisierungsstatus (2019‑04‑04 10:10:28) ref elgaimpf- Spezialisierung: Template 2.16.840.1.113883.10.12.1 CDA ClinicalDocument (2005‑09‑07) ref ad1bbr- | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Beispiel |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Beispiel |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
11.4.1.2 Update Immunisierungsstatus
| Id | 1.2.40.0.34.6.0.11.0.2 | Gültigkeit | 2022‑07‑15 13:52:04 Andere Versionen mit dieser Id:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Status | Aktiv | Versions-Label | 1.3.1+20220714 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Name | eimpf_document_UpdateImmunisierungsstatus | Bezeichnung | Update Immunisierungsstatus | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Kontext | Pfadname / | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Label | elgaimpf‑UpdateImmunisierungsstatus | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Klassifikation | CDA Document Level Template | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Offen/Geschlossen | Geschlossen (nur definierte Elemente sind erlaubt) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Benutzt |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Beziehung | Version: Template 1.2.40.0.34.6.0.11.0.2 Update Immunisierungsstatus (2022‑01‑25 12:15:38) ref elgaimpf- Version: Template 1.2.40.0.34.6.0.11.0.2 Update Immunisierungsstatus (2021‑08‑18 14:29:50) ref elgaimpf- Version: Template 1.2.40.0.34.6.0.11.0.2 Update Immunisierungsstatus (2021‑05‑25 13:23:24) ref elgaimpf- Version: Template 1.2.40.0.34.6.0.11.0.2 Update Immunisierungsstatus (2021‑05‑12 09:26:29) ref elgaimpf- Version: Template 1.2.40.0.34.6.0.11.0.2 Update Immunisierungsstatus (2019‑01‑15 16:55:36) ref elgaimpf- | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Beispiel |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Beispiel |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||