Änderungen

ILF:E-Impfpass (Version 2)

73.728 Bytes hinzugefügt, 15:51, 17. Jul. 2023

keine Bearbeitungszusammenfassung

Gabriele Wasner (Landessanitätsdirektion OÖ)

=Begriffsdefinitionen={~~{ILF~~| class="wikitable" style="margin-left: 16px; margin-right: 16px;"!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 Papier-Impfpass umfasst (PatientInnendaten, Datum der Impfung, Handels- bzw. Zulassungsname des Impfstoffes, Chargennummer, 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<ref name="Impfplan">Impfplan Österreich [Online Dez. 2022] https://www.sozialministerium.at/Themen/Gesundheit/Impfen/Impfplan-%C3%96sterreich.html</ref> die nächsten empfohlenen Impfungen und Impfzeitpunkte für die jeweilige Patientin, den jeweiligen Patienten berechnen können. Diese automatischen Empfehlungen können bei Bedarf mit individuellen Impfempfehlungen eines Arztes überschrieben werden. 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"<ref name="Impfplan" /> wird in enger Zusammenarbeit des für Gesundheit zuständigen Bundesministeriums und den Mitgliedern des Nationalen Impfgremiums (NIG)<ref>Nationales Impfgremium [Online Jän. 2023] https://www.sozialministerium.at/Themen/Gesundheit/Impfen/Nationales-Impfgremium.html</ref> nach den neuesten Erkenntnissen der Wissenschaft präzisiert und aktualisiert. Er enthält alle aktuellen, nationalen Impfempfehlungen und den damit verbunden Impfintervallen und Impfschemata, als auch die Liste an Impfungen, die ins kostenfreie Kinderimpfprogramm<ref name="Kinderimpfkonzept">Kostenfreies Kinderimpfprogramm [Online Apr. 2022]: https://www.sozialministerium.at/Themen/Gesundheit/Impfen/Kostenfreies-Kinderimpfprogramm.html</ref> fallen. Müssen einzelne Impfempfehlungen kurzfristig aktualisiert werden, so befinden sich diese unmittelbar nach dem Impfplan aufgelistet und stellen einen integralen Bestandteil des Impfplans dar.|-|'''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'''|Das Wort Dosiskennung beschreibt die Reihenfolgenummer in der Sequenz der Impfdosen oder die Teilimpfungen innerhalb eines Impfschemas.|-|'''Kostenfreies Kinderimpfprogramm'''|Das kostenfreie Kinderimpfprogramm <ref name="Kinderimpfkonzept" /> 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": *'''"ELGA-Anwendungen"''' sind jene, die gesetzlich aufgelistet sind und "einen bestimmten Zweck […] von ELGA durch ELGA-Gesundheitsdiensteanbieter/innen und ELGA-Teilnehmer/innen" verfolgen.*'''"e-Health-Anwendungen"''' sind jene, die gesondert gesetzlich aufgelistet sind und "einen bestimmten Zweck […] von ELGA-Komponenten durch Bürger/innen und Gesundheitsdiensteanbieter/innen" verfolgen. Erste gesetzlich vorgesehene e-Health-Anwendungen sind für die Primärversorgung und den e-Impfpass definiert. 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.|-|'''e-Impfpass als e-Health Anwendung'''|Mit der Umsetzung des e-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. *'''Gesundheitsdiensteanbieter, die nicht ELGA-GDA sind''': e-Health Anwendungen können von ELGA-GDA und Nicht-ELGA-GDA genützt werden. Betreffend e-Impfpass seien beispielhaft die von ELGA gesetzlich ausgeschlossenen Akteure Amtsärztinnen und Amtsärzte, Schulärztinnen und Schulärzte, Bezirksverwaltungsbehörden, Länder oder das für Gesundheit zuständige Bundesministerium zu nennen. *'''Verwendung der ELGA Infrastruktur''': Die Verwendung der bestehenden ELGA Infrastruktur inkl. der Betriebs- und Supportprozesse bietet mehrere Vorteile für die Sicherstellung des bereits beschriebenen öffentlichen Interesses. Einerseits erlaubt die Wiederverwendung bestehender ELGA-Infrastruktur eine schnellere Projektabwicklung zu geringeren Kosten, andererseits können Bürger:~~Begriffsdefinitionen~~ innen durch das Zugangsportal ihre Gesundheitsdaten einsehen und administrieren. |-|'''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.|-|'''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 Indikationsgruppen'''|Gewisse Impfungen werden für bestimmte Indikationsgruppen als nutzbringend eingestuft. Die Ärzteschaft soll diese Impfungen den Betroffenen empfehlen, wenn sie sie mit einem vertretbaren Aufwand erreichen. Die Informationen dazu sind im österreichischen, nationalen Impfplan enthalten <ref name="Impfplan" />.|-|'''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.|-|'''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.|-|'''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.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 das Bundesamt für Sicherheit im Gesundheitswesen (BASG). Als Impfschaden bezeichnet man stärkere Nebenwirkungen oder (dauerhafte) Gesundheitsschädigungen. Die Aufnahme von Impfreaktionen in den e-Impfpass wird derzeit nicht vom CDA Leitfaden unterstützt.|-|'''Impfstelle'''|Die Impfstelle ist diejenige Person resp. Organisation, welche eine Impfung durchgeführt hat.|-|'''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'' ("Nacherfassung"), 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.|-|'''Nacherfassung'''|Das zeitlich verzögerte Dokumentieren einer ''"eigenen" Impfung'', etwa wenn das IT-System gerade nicht verfügbar war.|-|'''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.|}

=Technischer Hintergrund=

==Allgemeine Richtlinien für die Implementierung des e-Impfpasses=====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]'''''. ===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..* ===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 '''''[[#Der_nullFlavor|nullFlavor]]''''' zu erfolgen. ===Legende der Konformitätskriterien=======Optionalitäten von CDA-Elementen===={| class="wikitable" width="100%"|- ! style="text-align:left" width="15%" |Konformitäts-Kriterium|| style="text-align:left" width="15%" |Mögliche Kardinalität|| style="text-align:left" width="15%" |Verwendung von nullFlavor|| style="text-align:left" width="55%" |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 i'''st NICHT ERLAUBT ''("not permitted")''.|- | rowspan="2" |'''''[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.|-|}<ref group="Tabelle">Legende der Optionalitäten von Elementen</ref>:''Legende der Optionalitäten von Elementen'' ====Optionalitäten von CDA-Attributen===={| class="wikitable" width="100%"|- ! style="text-align:left" width="15%" |Konformitäts-Kriterium|| style="text-align:left" width="15%" |Mögliche Kardinalität|| style="text-align:left" width="55%" |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..11..1|Wenn das '''Attribut''' angegeben wird, ist ein fixer Wert vorgeschrieben. ''("fixed")''Für das '''Attribut''' ist ein fixer Wert vorgeschrieben. ''("fixed")''|-|}<ref group="Tabelle">Legende der Optionalitäten von Attributen</ref>:''Legende der Optionalitäten von Attributen'' ===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 [[ILF:~~eImpfpass_Allgemeine_Richtlinien~~ Allgemeiner_Implementierungsleitfaden_2020#Codierungs-Elemente|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:<pre class="ilfbox_code"><id nullFlavor="UNK" /></pre>Wenn in einem Element ein nullFlavor angegeben wurde, kann nicht gleichzeitig ein anderes Attribut eingetragen werden. '''nullFlavor Beispiele''':{| class="wikitable" |-! nullFlavor! displayName! Deutsche Übersetzung! Anwendung|-| '''NI'''| NoInformation| keine Information vorhanden| wenn es keine Informationen gibt|-| '''UNK'''| ~~Allgemeine Richtlinien~~ 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|}<ref group="Tabelle">nullFlavor-Beispiele aus Value Set ELGA_NullFlavor</ref>: nullFlavor-Beispiele aus Value Set [https://termgit.elga.gv.at/ValueSet/elga-nullflavor ELGA_NullFlavor] ===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 [[#Datentypen|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.{{BeginYellowBox}}Elemente oder Attribute, die nicht vom Allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden, sind NICHT ERLAUBT. {{EndYellowBox}}====Ausnahmen====Für diese Regel existieren nur die im Folgenden genannten Ausnahmen: =====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. =====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. =====Explizit angegebene Ausnahmen=====Im speziellen Implementierungsleitfaden KÖNNEN bestimmte Sektionen als "offene Templates" definiert werden und Ausnahmen für Subsektionen und Entries zulassen. ====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 CDA-Dokumente führt. ===Value Sets===Ein Value Set ist eine eindeutig durch Name oder OID identifizierbare und versionierte Sicht auf ein oder mehrere Codesysteme. Es kann als Zusammenstellung von einem oder mehreren Codes aus einem oder mehreren Codesystemen gesehen werden. Ein Value Set enthält die Codes selbst und die Information über die Herkunft des Codes (das Source-Codesystem), z.B. "ELGA_NullFlavor" oder "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://termgit.elga.gv.at/. ====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, aktuell gibt es auch keine ValueSets die statisch gebunden sind). Für jedes Value Set ist am Terminologieserver auch ein Zeitpunkt angegeben, an dem es Gültigkeit erlangt ("Status: Active as of"), das ist speziell für Value Sets wichtig, die schon vor ihrem Inkrafttreten veröffentlicht werden. Value Sets sind so lange gültig, bis das Gültigkeitsdatum einer neueren Version dieses Value Sets erreicht wird – dann gilt die neuere Version. Im CDA-Dokument KANN über die Attribute @ValueSet und @ValueSetVersion angegeben werden, welches Value Set in welcher Version als Basis für die Befüllung des jeweiligen Datenelements verwendet wurde. ====Änderbarkeit von Value Sets====Inhalte von Value Sets können sich ändern, der Name und die OID eines Value Sets bleiben aber gleich. Alle ValueSets, die für ein CDA des Implementierungsleitfadens verwendet werden, sollen periodisch gemeinsam aktualisiert werden. Das Datum, an dem die lokal zur Implementierung verwendeten Value Sets mit dem österreichischen Terminologieserver abgeglichen wurden, wird im Terminologiedatum-Header-Element "terminologyDate" angegeben. Damit kann die Gültigkeit zu einer bestimmten Zeit rekonstruiert werden. ====Publikation der Value Sets am Terminologieserver====Sämtliche in den Implementierungsleitfäden verwendeten Value Sets werden am österreichischen Terminologieserver publiziert.<ref name="Terminologieserver">Österreichischer e-Health-Terminologie-Browser https://termgit.elga.gv.at</ref>Damit die jeweils aktuelle Version der Value Sets angewendet werden kann, soll der Terminologieserver regelmäßig auf Update abgeprüft werden. Es wird EMPFOHLEN, diese Überprüfung täglich durchzuführen. ====Terminologiedatum====Das Datum, an dem sämtliche lokal zur Implementierung verwendeten Value Sets mit dem österreichischen Terminologieserver abgeglichen wurden, wird über das "Terminologiedatum" angegeben: Dieses Datum wird in der Notation "YYYYMMDD" im eigenen Element "terminologyDate" angegeben.Beim Abgleich der Terminologien müssen immer alle Value Sets, die für ein CDA-Dokument notwendig sind, auf die am Terminologieserver aktuelle Version aktualisiert werden. Dokumente, die nur teilweise auf dem aktuellen Stand beruhen, könnten inkonsistent sein und MÜSSEN vermieden werden. ===PDF Format-Vorschrift===In CDA Dokumenten können Dokumente im PDF Format an verschiedensten Stellen eingebettet werden, entweder als gesamter CDA-Body oder als eingebetteter Inhalt in gewissen CDA-Sektionen. Im Hinblick auf eine dauerhafte Verfügbarkeit der Daten muss mindestens gewährleistet werden, dass diese PDF-Dokumente zuverlässig und eindeutig visuell reproduzierbar sind. Dies kann über die Einhaltung der Mindestkriterien der Norm ISO 19005-1:2005 sichergestellt werden (PDF/A-1b Basic bzw. PDF/A-3b Basic). Die Norm beschreibt zusätzlich die Barrierefreiheit der Dokumente, sodass sie von einem Screenreader vorgelesen werden können (PDF/A-1a Accessible bzw. PDF/A-3a Accessible). Dieser Implementierungsleitfaden schreibt daher als Minimalanforderung vor, dass jedes eingebettete PDF-Dokument dem Standard PDF/A-1b bzw. PDF/A-3b entsprechen MUSS. Im Sinne der Barrierefreiheit ist die Umsetzung von PDF/A-1a bzw. PDF/A-3a EMPFOHLEN.{{BeginYellowBox}}Alle in ELGA-CDA-Dokumente eingebetteten PDF-Dateien MÜSSEN dem Standard PDF/A-1b bzw. PDF/A3-b (gemäß "ISO 19005-1:2005 Level A conformance") entsprechen. Die Umsetzung von PDF/A-1a bzw. PDF/A-3a ist EMPFOHLEN.{{EndYellowBox}} ===Größenbeschränkung von eingebetteten Objekten===In CDA-Dokumenten können verschiedene Objekte (z.B. PDF-Dokumente, Bilder) eingebettet werden (siehe "[[#Eingebettetes_Objekt_Entry|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-Dokumente etwa durch Verringerung der Auflösung oder der Anzahl der Einzelbilder auf eine sinnvolle und angemessene Größe zu beschränken.{{BeginYellowBox}}Damit beim Download keine unnötigen Verzögerungen verursacht werden, SOLL die Gesamtgröße des CDA-Dokuments 20 MB nicht überschreiten.{{EndYellowBox}} ===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'''. =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. ==Identifikations-Elemente=====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. Die relevanten OID werden im OID-Portal <ref name="OID-Portal">OID Portal Österreich [Online Mai 2023]: https://www.gesundheit.gv.at/OID_Frontend/index.jsp?section=1</ref> für das Österreichische Gesundheitswesen 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. ====Strukturbeispiele===='''Methode 1:'''<pre class="ilfbox_code"><!— 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" /></pre>'''Methode 2:'''<pre class="ilfbox_code"><id root="1.2.40.0.34.99.111.0.1" assigningAuthorityName="KH Eisenstadt" /></pre> <pre class="ilfbox_code"><id root="6B48B496-C68E-CD08-55D4-B40CAC520F28" assigningAuthorityName="KH Eisenstadt" /></pre> ====Spezifikation====Bei II Elementen werden, sofern nicht anders spezifiziert, immer die folgenden Attribute angegeben. {| class="wikitable" width="100%"|- ! colspan="2" style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | colspan="2" style="text-align:left" | Id || II || || || ID |- style="background:#FFFFFF"| || @root || uid || 1..1 || M || Methode 1: OID der ID-Liste, der die ID angehörtMethode 2: OID oder UUID des Objekts{{BeginYellowBox}}Die Hexadezimalzahlen A-F der UUID MÜSSEN bei der Verwendung in HL7 CDA in Großschreibung angegeben werden.{{EndYellowBox}} |- style="background:#FFFFFF"| || @extension|| st|| 0..1 || style="background:#EBEBEB"| C || |- style="background:#EBEBEB"| ||colspan="2"| ''Konditioinale Konformität:'' Methode 1 Methode 2|| 1..1 0..0|| M NP || ID des Objekts aus der ID-Liste |- style="background:#FFFFFF"| || @assigningAuthorityName|| st|| 0..1 || O || Klartext-Darstellung der Stelle, welche die ID ausgibt|-|} ====Vorschriften für bereits definierte ID-Arten====Die folgenden Unterkapitel zeigen IDs, die in CDA-Dokumenten zur Anwendung kommen können. =====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 =====DVR-Nummer=====Die Datenverarbeitungsregister-Nummer (DVR-Nummer) des jeweiligen Gesundheitsdienstleisters kann als zusätzliches ID-Element abgebildet werden. ======Spezifikation======{| class="wikitable" width="100%"|- ! colspan="2" style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | colspan="2" style="text-align:left" | Id || II || || || ID |- style="background:#FFFFFF"| || @root || uid || 1..1 || M || Fester Wert: '''1.2.40.0.10.2.0.2.1 ''' |- style="background:#FFFFFF"| || @extension|| st|| 1..1 || style="background:lightblue"| M || '''Datenverarbeitungsregister-Nummer''' '''(DVR-Nummer)''' z.B.: 0000137 |- style="background:#FFFFFF"| || @assigningAuthorityName|| st|| 0..1 || O || Fester Wert: '''Österreichisches Datenverarbeitungsregister'''|-|} =====ATU Nummer=====Die Umsatzsteueridentifikationsnummer (ATU-Nummer) des jeweiligen Gesundheitsdienstleisters kann als zusätzliches ID-Element abgebildet werden. ======Spezifikation======{| class="wikitable" width="100%"|- ! colspan="2" style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | colspan="2" style="text-align:left" | Id || II || || || ID |- style="background:#FFFFFF"| || @root || uid || 1..1 || M || Fester Wert: '''1.2.40.0.10.2.0.3.1''' |- style="background:#FFFFFF"| || @extension|| st|| 1..1 || style="background:lightblue"| M || '''Umsatzsteueridentifikationsnummer''' '''(ATU-Nummer)''' z.B.: ATU56658245 |- style="background:#FFFFFF"| || @assigningAuthorityName|| st|| 0..1 || O || Fester Wert: '''Österreichisches Finanzamt'''|-|} =====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. ======Spezifikation: IBAN======{| class="wikitable" width="100%"|- ! colspan="2" style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | colspan="2" style="text-align:left" | Id || II || || || ID |- style="background:#FFFFFF"| || @root || uid || 1..1 || M || Fester Wert: '''1.0.13616 ''' |- style="background:#FFFFFF"| || @extension|| st|| 1..1 || style="background:lightblue"| M || '''IBAN''' z.B.: 1200052066543301 |- style="background:#FFFFFF"| || @assigningAuthorityName|| st|| 0..1 || O || Fester Wert: '''Society for Worldwide Interbank Financial Telecommunication'''|-|} ======Spezifikation: SWIFT-Adresse oder BIC======{| class="wikitable" width="100%"|- ! colspan="2" style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | colspan="2" style="text-align:left" | Id || II || || || ID |- style="background:#FFFFFF"| || @root || uid || 1..1 || M || Fester Wert: '''1.0.9362''' |- style="background:#FFFFFF"| || @extension|| st|| 1..1 || style="background:lightblue"| M || '''SWIFT/BIC''' z.B.: BKAUATWW |- style="background:#FFFFFF"| || @assigningAuthorityName|| st|| 0..1 || O || Fester Wert: '''Society for Worldwide Interbank Financial Telecommunication'''|-|} ==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. ===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) ====Strukturbeispiele==== =====Minimal-Variante um einen Code eindeutig darzustellen:=====<pre class="ilfbox_code"><code code="E10" codeSystem="1.2.40.0.34.5.56"/></pre> =====Gebräuchlichste Variante mit zusätzlichem Klartext für Code und Codesystem=====<pre class="ilfbox_code"><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"/></pre> =====Vollständige-Variante mit direkter Angabe des Textinhalts=====<pre class="ilfbox_code"><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></pre> =====Vollständige-Variante mit Referenz in den narrativen Textbereich=====<pre class="ilfbox_code"><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></pre>Für eine detaillierte Beschreibung der Abbildung von Referenzen in den narrativen Bereich siehe [[#Spezifikation_4|Spezifikation]] und [[ILF:Allgemeiner_Implementierungsleitfaden_(Version_3)#Verkn.C3.BCpfung_von_Text_und_Entry_.28.22CDA_Level_4.22.29|"Verknüpfung von Text und Entry"]]. =====Vollständige-Variante mit Referenz in den narrativen Textbereich und Übersetzung in zwei andere Code-Systeme=====<pre class="ilfbox_code"><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></pre> ====Spezifikation====Bei CE CWE Elementen werden, sofern nicht anders spezifiziert, immer die folgenden Attribute angegeben:{| class="wikitable" width="100%"|- ! colspan="4" style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | colspan="4" style="text-align:left" | code|| CE CWE|| || || Code Element |- style="background:#FFFFFF"| || colspan="3" | @code|| cs|| 1..1 || M || Der eigentliche Code-Wert z.B. '''E10''' |- style="background:#FFFFFF"| || colspan="3" | @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. |- style="background:#FFFFFF"| || colspan="3" | @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 |- style="background:#FFFFFF"| || colspan="3" | @codeSystemName|| st|| 0..1 || R|| Der Klartext-Darstellung der Codeliste z.B. '''ICD-10 BMG 2014''' bzw. die aktuell gültige Version |- style="background:#FFFFFF"| || colspan="3" | @codeSystemVersion|| st|| 0..1 || O || Die Versionsnummer der Codeliste z.B. '''1.00''' |- style="background:#FFFFFF"| || colspan="3" | 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''' |- style="background:#FFFFFF"| || || colspan="2" | reference|| TEL|| 0..1 || style="background:#EBEBEB" | C || Referenz Element |- style="background:#EBEBEB"| || || || colspan="2" | ''Konditionale Konformität:'' Wenn indirekte Angabe als "Referenz" Wenn direkte Angabe|| 1..1 0..0 || M NP || |- style="background:#FFFFFF"| || || || @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> |- style="background:#FFFFFF"| || colspan="3" | translation|| CE CWE || 0..* || O || Beliebig viele optionale Übersetzungen des Codes in andere Codesysteme gemäß derselben Spezifikation (CE CWE) wie das Code-Element selbst.|} ===code-Element CS CNE===Begriffsdefinitionen: * CS "Coded Simple"* CNE "Coded No Exceptions" (bedeutet, dass das angegebene Vokabular verwendet werden MUSS) ====Strukturbeispiel====<pre class="ilfbox_code"><languageCode code="de-AT" /> </pre> ====Spezifikation====Bei CS CNE Elementen wird nur das folgende Attribut angegeben:{| class="wikitable" width="100%"|- ! colspan="2" style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | colspan="2" style="text-align:left" | code|| CS CNE || || || Code Element |- style="background:#FFFFFF"| || @code|| cs || 1..1 || M || Der eigentliche Code-Wert z.B. '''de-AT''' |-|} ==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-~~Impfpasses~~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 [https://art-decor.org/mediawiki/index.php?title=DTr1_TS.AT.TZ 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. ===Zeitpunkt: Einfaches Zeitelement TS=== =====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 ====Strukturbeispiel====<pre class="ilfbox_code"><effectiveTime value="20081224"/> </pre> =====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-stelligWird in einem Zeitelement zusätzlich zum Datum eine Zeit angegeben, '''''MUSS die Zeitzone verpflichtend angegeben werden!''''' Die angegebene Zeitzone MUSS die aktuelle Sommerzeitregelung inkludieren. ====Strukturbeispiele ==== a) Winterzeit, Österreich (MEZ)<pre class="ilfbox_code"><effectiveTime value="20081224150000+0100"/> </pre>b) Sommerzeit, Österreich (MESZ)<pre class="ilfbox_code"><effectiveTime value="20080824150000+0200"/> </pre> ====Spezifikation====Bei Zeitpunkten werden, sofern nicht anders spezifiziert, immer die folgenden Unterelemente/Attribute angegeben:{| class="wikitable" width="100%"|- ! colspan="2" style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | colspan="2" style="text-align:left" | effectiveTime|| TS.AT.TZ || || || |- style="background:#FFFFFF"| || @value|| ts|| 1..1 || M || '''Zeitpunkt (bei Zeitangabe mit Zeitzone)''' z.B. 20131224180000+0100|-|} ===Zeitintervall: Intervall-Zeitelement IVL_TS=======Strukturbeispiel====<pre class="ilfbox_code"><effectiveTime> <low value="..."/>  <high value="..."/> </effectiveTime></pre> ====Spezifikation====Bei Zeitintervallen werden, sofern nicht anders spezifiziert, immer die folgenden Unterelemente/Attribute angegeben:{| class="wikitable" width="100%"|- ! colspan="3" style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | colspan="3" style="text-align:left" | effectiveTime|| IVL_TS || || || Zeitintervall |- style="background:#FFFFFF"| || colspan="2" style="text-align:left" | low || TS.AT.TZ || 1..1 || R || Beginn des Intervalls Zugelassene nullFlavor: '''UNK''' |- style="background:#FFFFFF"| || || @value || ts || 1..1 || M || '''Zeitpunkt des Beginns des Intervalls''' |- style="background:#FFFFFF"| || colspan="2" style="text-align:left" | high|| TS.AT.TZ || 1..1 || R || Ende des Intervalls Zugelassene nullFlavor: '''UNK''' |- style="background:#FFFFFF"| || || @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:<pre class="ilfbox_code"> <low value="20131201"/> <high value="20131202"/></pre>Für mehr Klarheit empfiehlt sich daher die zusätzliche Angabe der Zeit mit Zeitzone:<pre class="ilfbox_code"> <low value="20131201000000+0100"/> <high value="20131201235959+0100"/></pre> ===Minimale Datumsangabe: TS.DATE=== Eine minimale Datumsangabe umfasst die möglichen Formate: YYYYMMDD, YYYYMM oder YYYY. Dies wird mit dem Datentyp [https://art-decor.org/mediawiki/index.php?title=DTr1_TS.DATE TS.DATE] angezeigt. ====Strukturbeispiel====Datum: "Juni 2008"<pre class="ilfbox_code"><effectiveTime value="200806"/></pre> ====Spezifikation====Beim Datum [https://art-decor.org/mediawiki/index.php?title=DTr1_TS.DATE TS.DATE] werden, sofern nicht anders spezifiziert, immer die folgenden Unterelemente/Attribute angegeben:{| class="wikitable" width="100%"|- ! colspan="2" style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | colspan="2" style="text-align:left" | effectiveTime|| TS.DATE || || || |- style="background:#FFFFFF"| || @value|| ts|| 1..1 || M || '''Datum im Format YYYY, YYYYMM, YYYYMMDD''' z.B. 20131224, 201312, 2013|-|} ==Kontaktdaten-Elemente=====telecom-Element TEL===Ein telecom Kommunikations-Element dient zur Angabe von Kontaktdaten zu einem Personen- oder Organisationselement. ====Strukturbeispiele=========Beispiele für Präfixe in TEL Elementen=====<pre class="ilfbox_code"><telecom value="'''tel:'''+43.1.40400"/> <telecom value="'''fax:'''(02236)83.12323-12"/> <telecom value="'''mailto:'''office@organisation.at"/> <telecom value="'''http'''://www.organisation.at"/></pre> =====Beispiel für die Angabe einer Mobilnummer=====<pre class="ilfbox_code"><telecom use="MC" value="tel:+43.660.1234567"/></pre> ====Spezifikation====Bei ''TEL'' Elementen werden, sofern nicht anders spezifiziert, immer die folgenden Unterelemente/Attribute angegeben:{| class="wikitable" width="100%"|- ! colspan="2" style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | colspan="2" style="text-align:left" | telecom|| TEL|| || || Kontakt-Element |- style="background:#FFFFFF"| || @value|| url || 1..1 || M || Die Kontaktadresse (Telefonnummer, Email, etc.) Formatkonvention siehe "[[#telecom_.E2.80.93_Format_Konventionen_f.C3.BCr_Telekom-Daten|telecom – Format Konventionen für Telekom-Daten]]" Bsp: ''tel'':+43.1.1234567 Zulässige Werteliste für telecom Präfixe gemäß Value Set '''[https://termgit.elga.gv.at/ValueSet/elga-urlscheme ELGA_URLScheme]''' |- style="background:#FFFFFF"| || @use|| cs|| 0..1 ||O || Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …) Bsp: WP Zulässige Werte gemäß Value Set '''[https://termgit.elga.gv.at/ValueSet/elga-telecomaddressuse ELGA_TelecomAddressUse]'''|-|} ====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 '''[https://termgit.elga.gv.at/ValueSet/elga-urlscheme 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 ==Namen-Elemente=====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. ====Granularitätsstufe 1: Unstrukturierte Angabe====In Granularitätsstufe 1 wird der Personen-Name unstrukturiert angegeben. Die einzelnen Elemente des Namens (Vornamen, Nachnamen) werden nicht getrennt.=====Strukturbeispiele=====Beispiele für ''name''-Elemente in Granularitätsstufe 1:<pre class="ilfbox_code"><name>Dr. Herbert Mustermann</name></pre> <pre class="ilfbox_code"><name use="A">Dr. Kurt Ostbahn </name></pre> =====Spezifikation=====Bei ''name''-Elementen in dieser Granularitätsstufe werden, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben:{| class="wikitable" width="100%"|- ! colspan="2" style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | colspan="2" style="text-align:left" | name|| PN || || || Namen-Element (Person) |- style="background:#FFFFFF"| || @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 '''[https://termgit.elga.gv.at/ValueSet/elga-entitynameuse ELGA_EntityNameUse]''' Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name ("L").|-|} ====Granularitätsstufe 2: Strukturierte Angabe====In Granularitätsstufe 2 wird der Personen-Name strukturiert angegeben. Die einzelnen Elemente des Namens (mindesten ein Vorname und mindesten ein Nachname) werden getrennt angegeben.=====Strukturbeispiel=====Beispiel für ein ''name''-Element in Granularitätsstufe 2:<pre class="ilfbox_code"><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></pre> =====Spezifikation=====Bei ''name''-Elementen in dieser Granularitätsstufe werden, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben:{| class="wikitable" width="100%"|- ! colspan="3" style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | colspan="3" style="text-align:left" | name|| PN|| || || Namen-Element (Person) |- style="background:#FFFFFF"| || colspan="2" style="text-align:left" | @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 '''[https://termgit.elga.gv.at/ValueSet/elga-entitynameuse ELGA_EntityNameUse]''' Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name ("L"). |- style="background:#FFFFFF"| || colspan="2" style="text-align:left" | prefix|| en.prefix|| 0..* || O || Beliebig viele Präfixe zum Namen z.B. Akademische Titel, Adelstitel {{BeginYellowBox}}Achtung: Die Angabe der Anrede ("Frau", "Herr"), ist im CDA nicht vorgesehen!{{EndYellowBox}} |- style="background:#FFFFFF"| || || @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 '''[https://termgit.elga.gv.at/ValueSet/elga-entitynamepartqualifier ELGA_EntityNamePartQualifier]''' |- style="background:#FFFFFF"| || colspan="2" style="text-align:left" | given|| en.given|| 1..* || M || Mindestens ein Vorname |- style="background:#FFFFFF"| || || @qualifier|| cs|| 0..1 || O || Die genaue Bedeutung eines ''given''-Elements, beispielsweise, dass das angegebene Element ein Initial (z.B. ''middle initial'') bezeichnet. z.B.: IN ("Initial") Zulässige Werte gemäß Value Set '''[https://termgit.elga.gv.at/ValueSet/elga-entitynamepartqualifier ELGA_EntityNamePartQualifier]''' |- style="background:#FFFFFF"| || colspan="2" style="text-align:left" | family|| en.family|| 1..* || M || Mindestens ein Hauptname (Nachname) |- style="background:#FFFFFF"| || || @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 '''[https://termgit.elga.gv.at/ValueSet/elga-entitynamepartqualifier ELGA_EntityNamePartQualifier]''' |- style="background:#FFFFFF"| || colspan="2" style="text-align:left" | suffix|| en.suffix|| 0..* || O || Beliebig viele Suffixe zum Namen z.B. Akademische Titel, Adelstitel |- style="background:#FFFFFF"| || || @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 '''[https://termgit.elga.gv.at/ValueSet/elga-entitynamepartqualifier 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 [https://termgit.elga.gv.at/ValueSet/elga-entitynamepartqualifier ELGA_EntityNamePartQualifier]), v.a. für Präfix/Suffix. Es gibt auch nicht näher bestimmte Präfixe/Suffixe, z.B. trifft das für die Angabe von "Junior" oder "Senior" bzw. "Jun."/"Sen" oder "Jr."/"Sr" zu.<pre class="ilfbox_code"><name> <given>Herbert</given> <family>Mustermann</family> <suffix>Sen.</suffix></name></pre> ===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. ====Strukturbeispiel====Beispiel für die Angabe eines Organisationsnamens:<pre class="ilfbox_code"><name>Krankenhaus Wels</name></pre> ====Spezifikation===={| class="wikitable" width="100%"|- ! style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | style="text-align:left" | name|| ON|| || || Name der Organisation|-|} ==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. ===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.{{BeginYellowBox}}Hinweis: Diese Granularitätsstufe wird für Adressen in e-Impfpass nicht verwendet! {{EndYellowBox}} ===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.====Strukturbeispiel====Beispiel für ein ''addr''-Element in Granularitätsstufe 2:<pre class="ilfbox_code"><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></pre> ====Spezifikation====Bei ''addr''-Elementen in dieser Granularitätsstufe werden, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben:{| class="wikitable" width="100%"|- ! colspan="2" style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | colspan="2" style="text-align:left" | addr|| AD|| || || Adress-Element |- style="background:#FFFFFF"| || style="text-align:left" | @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 '''[https://termgit.elga.gv.at/ValueSet/elga-addressuse ELGA_AddressUse]''' Wird kein @use Attribut angegeben, gilt bei Personen die Adresse als "Wohnadresse" ("H") und bei Organisationen als Büroadresse ("WP"). |- style="background:#FFFFFF"| || style="text-align:left" | streetAddressLine|| ADXP|| 1..1 || M || Straße mit Hausnummer Bsp: Musterstraße 11a/2/1 |- style="background:#FFFFFF"| || style="text-align:left" | postalCode|| ADXP|| 1..1 || M || Postleitzahl |- style="background:#FFFFFF"| || style="text-align:left" | city|| ADXP|| 1..1 || M || Stadt |- style="background:#FFFFFF"| || style="text-align:left" | state|| ADXP|| 0..1 || O || Bundesland |- style="background:#FFFFFF"| || style="text-align:left" | 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… |- style="background:#FFFFFF"| || style="text-align:left" | additionalLocator|| ADXP|| 0..1 || O || Zusätzliche Addressinformationen z.B.: Station, Zimmernummer im Altersheim|-|} ===Granularitätsstufe 3: Strukturierte Angabe, Stufe 2===In Granularitätsstufe 3 wird die Adresse maximal strukturiert angegeben (Straße und Hausnummer getrennt). ====Strukturbeispiel====Beispiel für ein ''addr''-Element in Granularitätsstufe 3:<pre class="ilfbox_code"><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></pre> ====Spezifikation====Bei ''addr''-Elementen in dieser Granularitätsstufe werden, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben:{| class="wikitable" width="100%"|- ! colspan="2" style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | colspan="2" style="text-align:left" | addr|| AD|| || || Adress-Element |- style="background:#FFFFFF"| || style="text-align:left" | @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 '''[https://termgit.elga.gv.at/ValueSet/elga-addressuse ELGA_AddressUse]''' Wird kein @use Attribut angegeben, gilt bei Personen die Adresse als "Wohnadresse" ("H") und bei Organisationen als Büroadresse ("WP"). |- style="background:#FFFFFF"| || style="text-align:left" | streetName|| ADXP|| 1..1 || M || Straße Bsp: Musterstraße |- style="background:#FFFFFF"| || style="text-align:left" | houseNumber|| ADXP|| 1..1 || M || Hausnummer Bsp: 11a/2/1 |- style="background:#FFFFFF"| || style="text-align:left" | postalCode|| ADXP|| 1..1 || M || Postleitzahl |- style="background:#FFFFFF"| || style="text-align:left" | city|| ADXP|| 1..1 || M || Stadt |- style="background:#FFFFFF"| || style="text-align:left" | state|| ADXP|| 0..1 || R || Bundesland |- style="background:#FFFFFF"| || style="text-align:left" | 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… |- style="background:#FFFFFF"| || style="text-align:left" | additionalLocator|| ADXP|| 0..1 || O || Zusätzliche Addressinformationen z.B.: Station, Zimmernummer im Altersheim|-|} ==Komplexe (zusammengesetzte) Elemente=====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. ====Strukturbeispiel====<pre class="ilfbox_code"><assignedPerson> <name> <prefix qualifier="AC">Dr.</prefix> <given>Hubert</given> <family>Muster</family> </name></assignedPerson></pre> ====Spezifikation====Bei Personen-Elementen MÜSSEN, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben werden:{| class="wikitable" width="100%"|- ! style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | style="text-align:left" | name|| PN|| 1..* || M || Name der Person Grundsätzlich sind die Vorgaben gemäß "[[#Namen-Elemente_von_Personen_PN|Namen-Elemente von Personen PN]]" zu befolgen.|-|} ===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. ====Strukturbeispiel====<pre class="ilfbox_code"><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></pre> ====Spezifikation====Bei Organisations-Elementen MÜSSEN, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben werden:=====id====={| class="wikitable" width="100%"|- ! style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | style="text-align:left" | 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|Identifikations-Elemente]]" zu befolgen.|-|} =====Name der Organisation====={| class="wikitable" width="100%"|- ! style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | style="text-align:left" | name || PN|| 1..1 || M || Name der Organisation Grundsätzlich sind die Vorgaben gemäß "[[#Namen-Elemente_von_Organisationen_ON|Namen-Elemente von Organisationen ON]]" zu befolgen.|-|} =====Kontakt-Elemente der Organisation====={| class="wikitable" width="100%"|- ! style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | style="text-align:left" | telecom|| TEL || 0..* || O || Beliebig viele Kontakt-Elemente der Organisation Grundsätzlich sind die Vorgaben gemäß "[[#Kontaktdaten-Elemente|Kontaktdaten-Element]]" zu befolgen.|-|} =====Adress-Element der Organisation====={| class="wikitable" width="100%"|- ! style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | style="text-align:left" | addr|| AD|| 0..1 || O || Ein Adress-Element der Organisation Grundsätzlich sind die Vorgaben gemäß "[[#Adress-Elemente|Adress-Elemente]]" zu befolgen.|-|} ===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. ====Strukturbeispiel====<pre class="ilfbox_code"><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></pre> ====Spezifikation====Bei AssignedEntity-Elementen MÜSSEN, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben werden:=====id====={| class="wikitable" width="100%"|- ! style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | style="text-align:left" | id|| II|| 1..* || R || Mindestens eine ID der Person der Entität Zugelassene nullFlavor: * '''NI''' … Die Person der Entität hat keine Identifikationsnummer* '''UNK''' … Die Person der Entität hat eine Identifikationsnummer, diese ist jedoch unbekanntGrundsätzlich sind die Vorgaben gemäß "[[#Identifikations-Elemente|Identifikations-Elemente]]" zu befolgen.|-|} =====Adress-Element der Organisation====={| class="wikitable" width="100%"|- ! style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | style="text-align:left" | addr|| AD|| 0..1 || O || Ein Adress-Element der Person der Entität Grundsätzlich sind die Vorgaben gemäß "[[#Adress-Elemente|Adress-Elemente]]" zu befolgen.|-|} =====Kontakt-Elemente der Organisation====={| class="wikitable" width="100%"|- ! style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | style="text-align:left" | telecom|| TEL|| 0..* || O || Beliebig viele Kontakt-Elemente der Person der Entität Grundsätzlich sind die Vorgaben gemäß "[[#Kontaktdaten-Elemente|Kontaktdaten-Element]]" zu befolgen.|-|} =====Personen-Element der Entität====={| class="wikitable" width="100%"|- ! style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung |- style="background:#FFFFFF" | style="text-align:left" | assignedPerson|| POCD_MT000040. Person|| 1..1 || M || Personendaten der Person der Entität Grundsätzlich sind die Vorgaben gemäß "[[#Personen-Element|Personen-Element]]" zu befolgen.|-|}

=====Organisations-Element der Entität=====

{| class="wikitable" width="100%"

|-

! style="text-align:left" width="20%" | Element/Attribut ||style="text-align:left" width="5%" | DT ||style="text-align:left" width="5%" | Kard ||style="text-align:left" width="5%" | Konf ||style="text-align:left" width="65%" | Beschreibung

~~{{ILF~~|- style="background:~~eImpfpass_Datentypen~~ #FFFFFF" | style="text-align:left" | representedOrganization|| POCD_MT000040. Organization|| 0..1 | e| O || Organisationsdaten der Entität Grundsätzlich sind die Vorgaben gemäß "[[#Organisations-~~Impfpass Datentypen}~~Element|Organisations-Element]]" zu befolgen.|-|}

==Weitere Informationen zu CDA==

Kleinoscheg

Bürokraten, Prüfer

1.104

Bearbeitungen

Änderungen

ILF:E-Impfpass (Version 2)

Navigationsmenü

Meine Werkzeuge

Namensräume

Varianten

Ansichten

Mehr

Suche

Navigation

Leitfäden

Wissensbasis

Hilfe

Werkzeuge