Um ein CDA-Dokument in einem Webbrowser anzeigen zu können, muss es nach HTML tranformiert werden. Das kann durch eine XSLT-Transformation (ein so genanntes „Stylesheet“) geschehen. Ist das Stylesheet im angegebenen Pfad erreichbar, wird dieses beim Öffnen des CDA-Dokuments mit einem Browser üblicherweise automatisch auf das CDA-Dokument angewandt und die Darstellung gerendert.
ELGA stellt zur einheitlichen Darstellung von CDA-Dokumenten ein „Referenz-Stylesheet“ zur Verfügung (Download ist von der ELGA Website http://www.elga.gv.at/cda möglich). Da der Zugriff auf XSLT-Programme von den meisten Browsern eingeschränkt ist, wird kein absoluter Pfad auf eine Webressource angegeben.
Das Stylesheet „ELGA_Stylesheet_v1.0.xsl“ MUSS angegeben werden [M]. Die Angabe eines Pfades ist NICHT ERLAUBT. Ausnahmen können für automatisiert erstellte Dokumente notwendig sein, diese müssen im allgemeinen und speziellen Leitfäden beschrieben werden.
1.2.2 Wurzelelement
Der XML-Namespace für CDA Release 2.0 Dokumente ist urn:hl7-org:v3 (Default-Namespace). Dieser MUSS in geeigneter Weise in jeder CDA XML Instanz genannt werden. In speziellen Leitfäden können weitere namespace-Präfixe angegeben werden.
Für ELGA CDA-Dokumente MUSS der Zeichensatz UTF-8 verwendet werden.
CDA-Dokumente beginnen mit dem Wurzelelement ClinicalDocument, der grobe Aufbau ist im folgenden Übersichtsbeispiel gegeben.
Templates sind definierte Vorlagen, die Strukturen von Dokumenten, Dokumentteilen oder Datenelementen vorgeben. In CDA bezeichnen solche Templates bestimmte Teilstrukturen. Mittels templateId-Elementen können Teile von CDA-Dokumenten hinsichtlich ihrer Konformität zu Templates oder Implementierungsleitfäden gekennzeichnet werden.
Der Einsatz von so genannten „templateId”-Elementen sichert zu, dass eine CDA-Instanz nicht nur CDA konform ist, sondern auch dem referenzierten Template oder Implementierungsleitfaden entspricht. Mit Zusicherung ist dabei nur eine informelle Behauptung des Verfassers gemeint und nicht notwendigerweise auch eine erfolgreich durchgeführte Validierung bzw. Zertifizierung.
Ein CDA Dokument, welches den Vorgaben dieses Implementierungsleitfadens entspricht, ist berechtigt und verpflichtet, die entsprechende templateId-Kennung einzutragen.
1.2.5.1 Strukturbeispiel
<ClinicalDocument xmlns="urn:hl7-org:v3">
<realmCode code="AT"/>
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<!— Folgt dem vorliegenden Implementierungsleitfaden-Template -->
<templateId root="1.2.40.0.34.11.1"/>
<!— Beliebig viele weitere templateIds, falls das Dokumente noch weiteren Implementierungsleitfäden oder Spezifikationen folgt -->
<templateId root="…"/>
:
</ClinicalDocument>
1.2.5.2 Spezifikation
Die OID des vorliegenden Implementierungsleitfadens MUSS im @root Attribut des Elements angegeben werden.
Mit Angabe dieses Elements wird ausgesagt, dass das vorliegende CDA-Dokument zu diesem Implementierungsleitfaden konform ist.
Element/Attribut
DT
Kard
Konf
Beschreibung
templateId[1]
II
1..1
M
ELGA TemplateId für den Allgemeinen Implementierungsleitfaden
Fester Wert: @root = 1.2.40.0.34.11.1
templateId[n]
II
0..*
O
Weitere TemplateIds
Verweis auf speziellen Implementierungsleitfaden:
Des Weiteren können zusätzlich die geforderten templateIds eines weiteren speziellen Implementierungsleitfadens angegeben werden (z.B. Entlassungsbrief, Laborbefund, etc.).
Die jeweils im @root Attribut einzutragende OID entnehmen Sie bitte den entsprechenden Implementierungsleitfaden gemäß der Dokumentklasse.
Folgt das CDA-Dokument noch anderen Implementierungsleitfäden oder Spezifikationen können beliebig viele weitere templateId-Elemente angegeben werden.
1.2.6 Dokumenten-Id („id”)
Die Dokumenten-Id eines CDA-Dokuments ist ein eindeutiger Instanzidentifikator, der das Dokument weltweit eindeutig und für alle Zeit identifiziert. Ein CDA-Dokument hat genau eine Id.
Zulässige Werte gemäß Value-Set „ELGA_Dokumentklassen“
Grundsätzlich sind die Vorgaben gemäß „code-Element CE CWE“ zu befolgen.
Verweis auf speziellen Implementierungsleitfaden:
Die gültigen Wertebereiche dieses Elements entnehmen Sie bitte den entsprechenden speziellen Implementierungsleitfaden gemäß der Dokumentklasse bzw dem Dokumententyp.
1.2.8 Titel des Dokuments („title“)
“Titel” (im CDA das Element ClinicalDocument/title) bezeichnet die verpflichtende „Dokumentenüberschrift“ (zusätzlich zur Dokumentenklasse).
Beispiele für Titel der Dokumente:
„Arztbrief“
„Entlassungsbrief der gynäkologischen Abteilung des SMZ Ost“
„Vorläufiger Entlassungsbrief“
„Befundbericht“
…
1.2.8.1 Strukturbeispiel
<title>Entlassungsbrief</title>
1.2.8.2 Spezifikation
Element/Attribut
DT
Kard
Konf
Beschreibung
title
ST
1..1
M
Dokumententitel
Der Sinn der Benennung MUSS mit der Dokumentklasse übereinstimmen.
1.2.9 Erstellungsdatum des Dokuments („effectiveTime“)
1.2.9.1 Spezifikation
Id
1.2.40.0.34.11.90008
ref
elgabbr-
Gültigkeit
2016‑07‑21
Andere Versionen mit dieser Id:
CDeffectiveTime vom 2013‑11‑07
Status
Aktiv
Versions-Label
Name
CDeffectiveTime
Bezeichnung
CD effectiveTime
Beschreibung
Mit Erstellungsdatum ist jenes Datum gemeint, welches normalerweise im Briefkopf eines Schriftstückes angegeben wird. (z.B.: Wien, am …). Das Erstellungsdatum dokumentiert den Zeitpunkt, an dem das Dokument inhaltlich fertiggestellt wurde.
Bemerkung: Das Erstellungsdatum des Dokuments muss nicht mit dem Datum der
rechtli-chen Unterzeichnung (oder „Vidierung“) übereinstimmen.
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
Id
Name
Datensatz
elgagab-dataelement-8
Erstellungsdatum
Datensatz
Beziehung
Version: Template 1.2.40.0.34.11.90008 CD effectiveTime (2016‑07‑21)
ref
elgabbr-
Beispiel
Nur Datum: Zeitpunkt als Datum (ohne Zeit) im Format YYYYMMDD
<effectiveTimevalue="20081224"/>
Beispiel
Datum, Zeit und Zeitzone: Zeitpunkt als Datum mit Zeit und Zeitzone im Format YYYYMMDDhhmmss[+/-]HHMM
<effectiveTimevalue="20081224082015+0100"/>
Item
DT
Kard
Konf
Beschreibung
Label
hl7:effectiveTime
TS.AT.TZ
1 … 1
M
Erstellungsdatum des Dokuments.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
“Vertraulichkeitscode” (im CDA das Element ClinicalDocument/confidentialityCode) bezeichnet die Vertraulichkeitsstufe dieses Dokuments.
Der tatsächliche Zugriff auf das Dokument muss von der übergeordneten Infrastrukturschicht geregelt werden. Die Information des Vertraulichkeitscodes im Dokument selbst, dient nur der
reinen Information und hat keine technischen Konsequenzen.
Da Dokumente nach der Vidierung weder technisch noch legistisch geändert werden dürfen, kann der Vertraulichkeitscode keine konkreten Zugriffsrechte auf das Dokument regeln, sondern nur auf „Metaebenen“, wie beispielsweise „geltendes Recht XY“ oder weiterführende Verwendungen über das IHE BPPC
Profil, verweisen.
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
Id
Name
Datensatz
elgagab-dataelement-266
Vertraulichkeitscode
Datensatz
Beziehung
Version: Template 1.2.40.0.34.11.90009 CD confidentialityCode (2013‑11‑07)
Die Sprache des Dokuments wird in diesem Attribut gemäß IETF (Internet Engineering Task Force), RFC 1766: Tags for the Identification of Languages nach ISO-639-1 (zweibuchstabige Codes für Sprachen, Kleinbuchstaben) und ISO 3166 (hier: zweibuchstabige Ländercodes, Großbuchstaben) festgelegt.
Das Format ist entsprechend
ss-CC, mit ss, zwei Kleinbuchstaben für den Sprachencode gemäß ISO-639-1, und CC, zwei Großbuchstaben für den Ländercode gemäß ISO 3166 (Tabelle mit zwei Buchstaben).
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
Id
Name
Datensatz
elgagab-dataelement-265
Sprachcode
Datensatz
Beziehung
Version: Template 1.2.40.0.34.11.90010 CD languageCode (2013‑11‑07)
ref
elgabbr-
Beispiel
Beispiel
<languageCodecode="de-AT"/>
Item
DT
Kard
Konf
Beschreibung
Label
hl7:languageCode
CS.LANG
1 … 1
M
Sprachcode des Dokuments.
(CDl...ode)
elgagab-dataelement-265
Sprachcode
Datensatz
@code
CONF
1 … 1
F
de-AT
1.2.12 Versionierung des Dokuments („setId“ und „versionNumber“)
1.2.12.1 Spezifikation
Es MÜSSEN immer beide Elemente (setID und versionNumber) angegeben werden.
Id
1.2.40.0.34.11.90007
ref
elgabbr-
Gültigkeit
2015‑09‑18
Andere Versionen mit dieser Id:
CDsetIdversionNumber vom 2015‑05‑29
CDsetIdversionNumber vom 2013‑11‑07
Status
Aktiv
Versions-Label
Name
CDsetIdversionNumber
Bezeichnung
SetId VersionNumber
Beschreibung
Der CDA-Header repräsentiert ebenfalls die Beziehungen zu anderen Dokumenten mit Referenz auf die oben genannte Dokumenten-Identifikation.
Mittels der Attribute setId und versionNumber kann eine Versionskennung des Dokuments erreicht werden. Für ELGA-CDA-Dokumente MÜSSEN immer beide Elemente angegeben werden.
Die setId bezeichnet das Set von Dokumenten, die zu einer Reihe von Versionen gehören. Sie bleibt über alle Versionen der Dokumente gleich (initialer Wert bleibt erhalten). Die versionNumber ist eine natürliche Zahl für die fortlaufende Versionszählung. Mit einer neuen Version wird diese Zahl hochgezählt, die setId bleibt gleich.
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
<!-- Die bei setId angegebene ID SOLLTE nicht gleich sein wie die id des Dokuments.--> <art:placeholder> <idroot="1.2.40.0.34.99.111.1.1"extension="AAAAAAAAAAAAAAA"/><setIdroot="1.2.40.0.34.99.111.1.1"extension="ZZZZZZZZZZZZZZZ"/><versionNumbervalue="1"/></art:placeholder>
Beispiel
Beispiel für die 2.Version eines Dokuments
<!--Die bei setId angegebene ID MUSS mit der setId der Vorversion übereinstimmen.--> <art:placeholder> <idroot="1.2.40.0.34.99.111.1.1"extension="BBBBBBBBBBBBBBB"/><setIdroot="1.2.40.0.34.99.111.1.1"extension="ZZZZZZZZZZZZZZZ"/><versionNumbervalue="2"/></art:placeholder>
Item
DT
Kard
Konf
Beschreibung
Label
hl7:setId
II
1 … 1
M
Eindeutige Id des Dokumentensets. Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.
Hinweis: Bestimmte Systeme, die bei der
Übernahme der SetID in die XDS-Metadaten mit dem V2-Datentyp CX arbeiten, könnten ein Problem mit @Extension-Attributen haben, die länger als 15 Zeichen sind. Die SetID sollte unterschiedlich zur clinicalDocument.id sein.
Achtung: Manche Validatoren erkennen es als Fehler, wenn die SetID und ID gleich sind.
1.3 Teilnehmende Parteien
1.3.1 Patient („recordTarget/patientRole“)
Im CDA-Header wird mindestes eine Patientenrolle beschrieben, die zu genau einer Person zugehörig ist. Die recordTarget Beziehung weist auf die Patient-Klasse und gibt an, zu welchem Patienten dieses Dokument gehört.
Auszug aus dem R-MIM:
Abbildung 7: Klassen rund um den Patienten.
1.3.1.1 Spezifikation
Id
1.2.40.0.34.11.20001
ref
elgabbr-
Gültigkeit
2017‑07‑20
Andere Versionen mit dieser Id:
HeaderRecordTarget vom 2018‑10‑18 14:23:51
HeaderRecordTarget vom 2017‑03‑27
HeaderRecordTarget vom 2013‑10‑08
HeaderRecordTarget vom 2013‑02‑10
HeaderRecordTarget vom 2011‑12‑19
Status
Entwurf
Versions-Label
Name
HeaderRecordTarget
Bezeichnung
HeaderRecordTarget
Beschreibung
Das RecordTarget-Element enthält den Patienten: Die Person, die von einem Gesundheitsdiensteanbieter (Arzt, einer Ärztin oder einem Angehörigen anderer Heilberufe) behandelt wird und über die bzw über deren Gesundheitsdaten im Dokument berichtet wird.
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
<recordTargettypeCode="RCT"contextControlCode="OP"> <patientRoleclassCode="PAT"> <!-- lokale Patienten ID vom System --> <idroot="1.2.40.0.34.99.111.1.2"extension="4711"assigningAuthorityName="Amadeus Spital"/><!-- Sozialversicherungsnummer des Patienten --> <idroot="1.2.40.0.10.1.4.3.1"extension="1111241261"assigningAuthorityName="Österreichische Sozialversicherung"/><!-- Adresse des Patienten --> <addruse="H"> <streetName>Musterstraße</streetName><houseNumber>13a</houseNumber><postalCode>7000</postalCode><city>Eisenstadt</city><state>Burgenland</state><country>AUT</country></addr><!-- Kontaktdaten des Patienten--> <telecomvalue="tel:+43.1.40400"use="H"/><telecomvalue="tel:+43.664.1234567"use="MC"/><telecomvalue="mailto:herbert.mustermann@provider.at"/><!-- Name des Patienten --> <patientclassCode="PSN"determinerCode="INSTANCE"> <name> <prefixqualifier="AC">Dipl.Ing.</prefix><given>Herbert</given><given>Hannes</given><family>Mustermann</family><familyqualifier="BR">VorDerHeirat</family><suffixqualifier="AC">BSc</suffix><suffixqualifier="AC">MBA</suffix></name><!-- Geschlecht des Patienten --> <administrativeGenderCodecode="M"displayName="Male"codeSystem="2.16.840.1.113883.5.1"codeSystemName="HL7:AdministrativeGender"/><!-- Geburtsdatum des Patienten --> <birthTimevalue="19701224"/><!-- Familienstand des Patienten --> <maritalStatusCodecode="D"displayName="Divorced"codeSystem="2.16.840.1.113883.5.2"/><!-- Religionszugehörigkeit des Patienten --> <religiousAffiliationCodecode="101"displayName="Römisch-Katholisch"codeSystem="2.16.840.1.113883.2.16.1.4.1"codeSystemName="HL7.AT:ReligionAustria"/><!-- Vormund/Sachwalter des Patienten "Organisation"--> <guardian> <!--Eine Organisation als Guardian, hier als Strukturbeispiel--> <addr> <streetAddressLine>Kinderdorfstraße 1</streetAddressLine><postalCode>2371</postalCode><city>Hinterbrühl</city><state>Niederösterreich</state><country>AUT</country></addr><!-- Kontaktdaten des Vormunds/Sachwalters (Organisation)--> <telecomuse="H"value="tel:+43.2236.2928"/><telecomuse="WP"value="tel:+43.2236.9000"/><guardianOrganization> <!-- Name der Vormund/Sachwalter-Organisation--> <name>SOS Kinderdorf Hinterbrühl</name></guardianOrganization></guardian><!-- Vormund/Sachwalter des Patienten "Person" --> <guardian> <!-- Adresse des Vormunds/Sachwalters (Person) --> <addr> <streetAddressLine>Musterstraße 1234</streetAddressLine><postalCode>8011</postalCode><city>Graz</city><state>Steiermark</state><country>AUT</country></addr><!-- Kontaktdaten des Vormunds/Sachwalters (Person) --> <telecomuse="MC"value="tel:+43.676.1234567"/><telecomuse="H"value="tel:+43.316.717.653.9939"/><telecomuse="WP"value="tel:+43.316.608.271.9000"/><guardianPerson> <!-- Name der Vormund/Sachwalter-Organisation --> <name> <given>Susi</given><family>Sorgenvoll</family></name></guardianPerson></guardian><!-- Geburtsort des Patienten --> <birthplace> <place> <addr>Graz</addr></place></birthplace></patient></patientRole></recordTarget>
Beispiel
Minimalbeispiel 1
<recordTargettypeCode="RCT"contextControlCode="OP"> <patientRoleclassCode="PAT"> <!-- lokale Patienten ID vom System --> <idroot="1.2.40.0.34.99.111.1.2"extension="4711"/><!-- Name des Patienten --> <patientclassCode="PSN"determinerCode="INSTANCE"> <name> <given>Herbert</given><family>Mustermann</family></name><!-- Geschlecht des Patienten --> <administrativeGenderCodecode="M"codeSystem="2.16.840.1.113883.5.1"/><!-- Geburtsdatum des Patienten --> <birthTimevalue="19701224"/></patient></patientRole></recordTarget>
Beispiel
Minimalbeispiel 2
<recordTarget> <patientRole> <!-- lokale Patienten ID --> <idroot="1.2.40.0.34.99.111.1.2"extension="4711"/><!-- Name des Patienten --> <patient> <name> <given>Herbert</given><family>Mustermann</family></name><!-- Geschlecht des Patienten --> <administrativeGenderCodenullFlavor="UNK"/><!-- Geburtsdatum des Patienten --> <birthTimenullFlavor="UNK"/></patient></patientRole></recordTarget>
bPK-GH des Patienten: Bereichskürzel + bPK (Base64,28 Zeichen)
<idroot="1.2.40.0.10.2.1.1.149"extension="GH:XNV5ThCj5OwJR0oOcWmK4WUs5p4="assigningAuthorityName="Österreichische Stammzahlenregisterbehörde"/><!--Anmerkung: Das bPK dient ausschließlich der Zuordnung der elektronischen Identität und darf daher nicht am Ausdruck erscheinen-->
hl7:addr
AD
0 … 1
Adresse des Patienten.
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.
(Hea...get)
hl7:streetAddressLine
0 … 1
(Hea...get)
hl7:streetName
0 … 1
(Hea...get)
hl7:houseNumber
0 … 1
(Hea...get)
Schematron assert
role
error
test
hl7:streetAddressLine or (hl7:streetName and hl7:houseNumber)
Meldung
Granularitätsstufen Adresse beachten: streetAddressLine oder streetName+houseNumber
hl7:postalCode
1 … 1
M
(Hea...get)
hl7:city
1 … 1
M
(Hea...get)
hl7:state
0 … 1
C
(Hea...get)
hl7:country
1 … 1
M
(Hea...get)
hl7:additionalLocator
0 … 1
(Hea...get)
hl7:telecom
TEL.AT
0 … *
Kontaktdaten des Patienten.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(Hea...get)
hl7:patient
0 … 1
(Hea...get)
@classCode
cs
0 … 1
F
PSN
@determinerCode
cs
0 … 1
F
INSTANCE
hl7:name
PN
1 … 1
M
Name des Patienten.
Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...get)
hl7:prefix
0 … *
(Hea...get)
hl7:given
1 … *
M
(Hea...get)
hl7:family
1 … *
M
(Hea...get)
hl7:suffix
0 … *
(Hea...get)
hl7:administrativeGenderCode
CE
1 … 1
R
Codierung des Geschlechts des Patienten.
Zugelassene nullFlavor: UNK
Mittels nullFlavor="UNK" wird "Unbekannt" abgebildet. Dies schließt die Ausprägung "Keine Angabe" mit ein.
(Hea...get)
CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.4 ELGA_AdministrativeGender (DYNAMIC)
hl7:birthTime
TS.DATE.MIN
1 … 1
R
Geburtsdatum des Patienten.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
Zugelassene nullFlavor: UNK
(Hea...get)
hl7:maritalStatusCode
CE
0 … 1
Codierung des Familienstands des Patienten.
(Hea...get)
CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.11 ELGA_MaritalStatus (DYNAMIC)
hl7:religiousAffiliationCode
CE
0 … 1
Codierung des Religionsbekenntnisses des Patienten.
(Hea...get)
CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.18 ELGA_ReligiousAffiliation (DYNAMIC)
hl7:raceCode
NP
Rasse des Patienten
Darf nicht verwendet werden!
(Hea...get)
hl7:ethnicGroupCode
NP
Ethnische Zugehörigkeit des Patienten. Darf nicht verwendet werden!
OID der österreichischen bPK Fester Wert: 1.2.40.0.10.2.1.1.149
@extension
st
1..1
M
bPK-GH des Patienten: Bereichskürzel + bPK (Base64, 28 Zeichen) (insg. 31 Stellen) Anmerkung: Das bPK dient ausschließlich der Zuordnung der elektronischen Identität und darf daher nicht am Ausdruck erscheinen
Hinweis: Die Reihenfolge der id-Elemente MUSS unbedingt eingehalten werden!
1.3.1.1.2 addr
Es MUSS eine mögliche Adresse unterstützt werden. Spezielle Leitfäden (z.B. Entlassungsbrief Pflege) können es erforderlich machen, dass auch mehr als eine Adresse unterstützt werden muss.
1.3.1.1.3 patient/languageCommunication
In der Klasse languageCommunication können Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform (z.B. gesprochen oder geschrieben) des Patienten angegeben werden.
Dieser Leitfaden schränkt die möglichen Werte für die Sprache auf Werte aus dem Value Set ELGA_HumanLanguage ein. Gemäß IETF / RFC 3066 enthält es ein bestimmtes Subset von Codes aus ISO 639-1 und ISO 639-2 (also zwei- und dreistellige Sprachcodes). Gemäß RFC 3066 ist es zulässig, eine Angabe der landestypischen Ausprägung der Sprache nach einem Bindestrich anzufügen. Das Land wird dabei nach ISO 3166-1 Alpha 2 angegeben. Dies MUSS bei der Auswertung des languageCodes berücksichtigt und toleriert werden.
1.3.1.1.4 patient/guardian
In der Klasse guardian können Informationen bezüglich eines Vormunds/Sachwalters des Patienten angegeben werden.
Begriffsdefinition:
Ein Vormund kann existieren, wenn die Person noch nie geschäftsfähig war
z.B. Kinder
Ein Sachwalter kann existieren, wenn die Person schon geschäftsfähig war, die Geschäftsfähigkeit aber entzogen wurde
z.B. Alte Personen
Vormund/Sachwalter kann entweder eine Person (guardianPerson) oder eine Organisation (guardianOrganization) sein.
Beim Patient können optional ein oder mehrere Vormund/Sachwalter Element(e) angegeben werden. Wenn ein Sachwalter bekannt ist, SOLL diese Information auch angegeben werden.
1.3.2 Verfasser des Dokuments („author“)
Auszug aus dem R-MIM:
Abbildung 8: Klassen rund um den Autor.
1.3.2.1 Spezifikation
Id
1.2.40.0.34.11.20002
ref
elgabbr-
Gültigkeit
2015‑05‑09
Andere Versionen mit dieser Id:
HeaderAuthor vom 2018‑10‑18 14:32:49
HeaderAuthor vom 2013‑02‑10
HeaderAuthor vom 2011‑12‑19
Status
Aktiv
Versions-Label
Name
HeaderAuthor
Bezeichnung
HeaderAuthor
Beschreibung
Der Dokumentersteller („author“) ist in der Regel die „das Dokument verfassende Person“ oder ein „datenerstellendes Gerät“. Damit ist diejenige Person oder das Gerät gemeint, welche das Dokument „inhaltlich“ verfasst (z.B.: diktiert). Die das Dokument „schreibende“ Person (z.B. Schreibkraft, Stationsschwester, …) wird in CDA in einem eigenen Element (dataEnterer) abgebildet (siehe „Personen der Dateneingabe („dataEnterer“)“).
Es kann auch mehr als ein Dokumentersteller angegeben werden (mehrere author-Elemente).
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
<authortypeCode="AUT"contextControlCode="OP"> <!-- Funktionscode --> <functionCodecode="OA"displayName="Diensthabender Oberarzt"codeSystem="1.2.40.0.34.99.111.2.1"codeSystemName="Amadeus Spital Funktionen"/><!-- Zeitpunkt der Erstellung --> <timevalue="20081224082015+0100"/><assignedAuthorclassCode="ASSIGNED"> <!-- Identifikation des Verfassers des Dokuments --> <idroot="1.2.40.0.34.99.111.1.3"extension="1111"assigningAuthorityName="Amadeus Spital"/><!-- Fachrichtung des Verfassers des Dokuments --> <codecode="107"displayName="Fachärztin/Facharzt für Chirurgie"codeSystem="1.2.40.0.34.5.160"codeSystemName="ELGA_Fachaerzte"/><!-- Kontaktdaten des Verfassers des Dokuments --> <telecomvalue="tel:+43.1.40400"/><telecomvalue="mailto:herbert.mustermann@organization.at"/><assignedPersonclassCode="PSN"determinerCode="INSTANCE"> <!-- Name des Verfassers des Dokuments --> <name> <prefixqualifier="AC">Univ.-Prof. Dr.</prefix><given>Isabella</given><family>Stern</family></name></assignedPerson><!-- Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat --> <representedOrganization> <idroot="1.2.40.0.34.99.3"assigningAuthorityName="GDA Index"/><!-- Name der Organisation --> <name>Amadeus Spital, 1. Chirurgische Abteilung</name><!-- Kontaktdaten der Organisation --> <telecomvalue="tel:+43.6138.3453446.0"/><telecomvalue="mailto:chirurgie@amadeusspital.at"/><addr> <streetName>Mozartgasse</streetName><houseNumber>1-7</houseNumber><postalCode>5350</postalCode><city>St.Wolfgang</city><state>Salzburg</state><country>AUT</country></addr></representedOrganization></assignedAuthor></author>
Beispiel
Strukturbeispiel für datenerstellende Geräte als „author“
<author> <!-- Zeitpunkt der Erstellung --> <timevalue="20081224082015+0100"/><assignedAuthor> <!-- Geräte Identifikation (oder nullFlavor) --> <idroot="86562fe5-b509-4ce9-b976-176fd376e477"/><!-- Geräte Beschreibung --> <assignedAuthoringDevice> <manufacturerModelName>Good Health System</manufacturerModelName><softwareName>Best Health Software Application</softwareName></assignedAuthoringDevice><representedOrganization> <idroot="1.2.40.0.34.99.3"assigningAuthorityName="GDA Index"/><!-- Name der Organisation --> <name>Amadeus Spital, 1. Chirurgische Abteilung</name><!-- Kontaktdaten der Organisation --> <telecomvalue="tel:+43.6138.3453446.0"/><telecomvalue="mailto:chirurgie@amadeusspital.at"/><addr> <streetName>Mozartgasse</streetName><houseNumber>1-7</houseNumber><postalCode>5350</postalCode><city>St.Wolfgang</city><state>Salzburg</state><country>AUT</country></addr></representedOrganization></assignedAuthor></author>
Item
DT
Kard
Konf
Beschreibung
Label
hl7:author
Verfasser des Dokuments.
(Hea...hor)
elgagab-dataelement-48
Autor
Datensatz
@typeCode
cs
0 … 1
F
AUT
@contextControlCode
cs
0 … 1
F
OP
hl7:functionCode
CE
0 … 1
Funktionscode des Verfassers des Dokuments
z.B: „Diensthabender Oberarzt“, „Verantwortlicher Arzt für Dokumentation“,„Stationsschwester“, …
Eigene Codes und Bezeichnungen können verwendet werden.
Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen.
(Hea...hor)
hl7:time
TS.AT.TZ
1 … 1
R
Der Zeitpunkt an dem das Dokument verfasst wurde.Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
Zugelassene nullFlavor: UNK
(Hea...hor)
hl7:assignedAuthor
1 … 1
R
Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat.
Identifikation des Verfassers des Dokuments im lokalen System/ des/der datenerstellenden Gerätes/Software.ODERIdentifikation des/der datenerstellenden
Gerätes/Software.
Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen. Zugelassene nullFlavor:
NI … Person hat keine ID / Gerät/Software hat keine ID
UNK … Person hat eine ID, diese ist jedoch unbekannt /Gerät/Software hat eine ID, diese ist jedoch unbekannt
(Hea...hor)
hl7:code
CE
0 … 1
Angabe der Fachrichtung des Verfassers des Dokuments („Sonderfach“ gem. Ausbildungsordnung)z.B: „Facharzt/Fachärzting für Gynäkologie“,
Wenn ein Autor mehreren
ärztlichen Sonderfächern zugeordnet ist, kann das anzugebende Sonderfach gewählt werden. Additivfächer werden nicht angegeben. Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen.
(Hea...hor)
CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC)
hl7:telecom
TEL.AT
0 … *
Kontaktdaten des Verfassers des Dokuments.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(Hea...hor)
Auswahl
1 … 1
Elemente in der Auswahl:
hl7:assignedPerson
hl7:assignedAuthoringDevice
hl7:assignedPerson
… 1
Personendaten des Verfassers des Dokuments.
Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.
(Hea...hor)
Eingefügt
von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
@classCode
cs
0 … 1
F
PSN
@determinerCode
cs
0 … 1
F
INSTANCE
hl7:name
PN
1 … 1
M
Name der Person
Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...hor)
hl7:assignedAuthoringDevice
… 1
(Hea...hor)
@classCode
cs
0 … 1
F
DEV
@determinerCode
cs
0 … 1
F
INSTANCE
hl7:manufacturerModelName
SC
1 … 1
R
Hersteller und Modellbezeichnung des datenerstellenden Gerätes.
(Hea...hor)
hl7:softwareName
SC
1 … 1
R
Bezeichnung (und ggf Version) der datenerstellenden Software.
(Hea...hor)
hl7:representedOrganization
1 … 1
M
Organisation, in deren Auftrag der Verfasser des
Dokuments die Dokumentation verfasst hat.
Die das Dokument „schreibende“ Person (z.B. Schreibkraft, Stationsschwester, …). Das Element "DataEnterer" ist bei automatisch erstellten Dokumenten nicht notwendig.
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
<dataEnterer> <!-- Zeitpunkt des Schreibens --> <timevalue="20081224082015+0100"/><assignedEntity> <!-- Die das Dokument schreibende Person --> <idroot="1.2.40.0.34.99.111.1.3"extension="2222"assigningAuthorityName="Amadeus Spital"/><telecomvalue="tel:+43.1.40400.4711"/><telecomvalue="mailto:eva.musterfrau@amadeusspital.at"/><assignedPerson> <name>DiplKrSr. Eva Musterfrau</name></assignedPerson></assignedEntity></dataEnterer>
Item
DT
Kard
Konf
Beschreibung
Label
hl7:dataEnterer
Person der Dateneingabe.
(Hea...rer)
elgagab-dataelement-65
Schreibkraft
Datensatz
hl7:time
TS.AT.TZ
0 … 1
Der Zeitpunkt an dem das Dokument geschrieben wurde.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
(Hea...rer)
hl7:assignedEntity
1 … 1
R
Personendaten der schreibenden Person
Grundsätzlich sind die Vorgaben für „AssignedEntity-Element (Person + Organisation)“ zu befolgen.
(Hea...rer)
Eingefügt
von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC)
hl7:id
II
1 … *
R
Mindestens eine Id der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...rer)
hl7:addr
AD
0 … 1
Ein Adress-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...rer)
hl7:telecom
TEL.AT
0 … *
Mindestens ein Telecom-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...rer)
hl7:assignedPerson
1 … 1
M
Persondendaten der validierenden Person.
(Hea...rer)
Eingefügt
von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
@classCode
cs
0 … 1
F
PSN
@determinerCode
cs
0 … 1
F
INSTANCE
hl7:name
PN
1 … 1
M
Name der Person
Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...rer)
hl7:representedOrganization
0 … 1
Organistationsdaten der validierenden Person.
(Hea...rer)
Eingefügt
von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
@classCode
0 … 1
F
ORG
@determinerCode
0 … 1
F
INSTANCE
hl7:id
II
0 … *
(Hea...rer)
hl7:name
ON
1 … 1
M
(Hea...rer)
hl7:telecom
TEL.AT
0 … *
(Hea...rer)
hl7:addr
AD
0 … 1
(Hea...rer)
1.3.4 Verwahrer des Dokuments („custodian“)
Auszug aus dem R-MIM:
Abbildung 9: Klassen rund um die das Dokument verwaltende Organisation.
1.3.4.1 Spezifikation
Id
1.2.40.0.34.11.20004
ref
elgabbr-
Gültigkeit
2015‑05‑28
Andere Versionen mit dieser Id:
HeaderCustodian vom 2011‑12‑19
Status
Aktiv
Versions-Label
Name
HeaderCustodian
Bezeichnung
HeaderCustodian
Beschreibung
Der „Verwahrer des Dokuments“ ist diejenige Organisation, die „für die Verwahrung/Verwaltung des Dokuments verantwortlich ist“.
Beispiele:
Das erstellende Krankenhaus ist selbst der Verwalter des Dokuments.
Der übergeordnete Krankenhausträger ist der Verwalter des Dokuments.
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Identifikation des Verwahrers des Dokuments, wie im GDA-Index angegeben.
Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.
Zugelassene nullFlavor:
NI … Organisation hat keine ID aus dem GDA-Index
UNK
… Organisation hat eine ID aus dem GDA-Index, diese ist jedoch unbekannt
(Hea...ian)
hl7:name
1 … 1
M
Name des Verwahrers des Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Namen-Elemente von Organisationen ON“ zu befolgen.
(Hea...ian)
hl7:telecom
TEL.AT
0 … 1
Kontaktdaten des Verwahrers des Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Kontaktdaten-Elemente“ zu befolgen.
(Hea...ian)
hl7:addr
AD
1 … 1
M
Adresse des Verwahrers des Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.
(Hea...ian)
1.3.4.1.1 id
Element/Attribut
DT
Kard
Konf
Beschreibung
id
II
1..1
R
Identifikation des Verwahrers des Dokuments aus dem GDA-Index.
Grundsätzlich sind die Vorgaben gemäß Kapitel „Identifikations-Elemente“ zu befolgen.“
Zugelassene nullFlavor:
NI … Organisation hat keine ID aus dem GDA-Index
UNK … Organisation hat eine ID aus dem GDA-Index, diese ist jedoch unbekannt
In der nächsten Version des Leitfadens wird die Konformität entsprechend dem CDA-Standard auf [M] erhöht, Null Flavors sind dann nicht mehr erlaubt.
1.3.5 Beabsichtigte Empfänger des Dokuments („informationRecipient“)
Auszug aus dem R-MIM:
Abbildung 10: Klassen rund um die beabsichtigten Empfänger des Dokuments.
1.3.5.1 Spezifikation
Id
1.2.40.0.34.11.20005
ref
elgabbr-
Gültigkeit
2011‑12‑19
Status
Entwurf
Versions-Label
Name
HeaderInformationRecipient
Bezeichnung
HeaderInformationRecipient
Beschreibung
Die beabsichtigten Empfänger des Dokuments können in der Klasse intendedRecipient näher angegeben werden. Hierbei ist zu beachten, dass es sich um die unmittelbar bei der Erstellung des Dokuments festgelegten bzw. bekannten Empfänger handelt.
Beispiel: Bei
der Erstellung der Dokumentation ist beispielsweise schon bekannt, dass man das Dokument primär an den Hausarzt und ggf. als Kopie an einen mitbehandelnden Kollegen senden wird. In diesem Fall sollten genau diese beiden Empfänger angegeben werden.
Empfohlene Information für einen Empfänger ist die ID aus dem GDA-Index, sein
Name in möglichst hoher Granularität und die Organisation, der er angehört in möglichst hoher Granularität. Aufgrund der gängigen Praxis kann als minimale Information für den Empfänger der unstrukturierte Name angegeben werden.
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
<informationRecipienttypeCode="PRCP"> <intendedRecipient> <!-- Identifikation des beabsichtigten Empfängers --> <idnullFlavor="UNK"/><!-- Personendaten des beabsichtigten Empfängers --> <informationRecipient> <name> <prefixqualifier="AC"> Dr.</prefix><given>Robert</given><family>Empfänger</family></name></informationRecipient><!-- Organisation, der der beabsichtigte Empfänger angehört --> <receivedOrganization> <!-- Name der Organisation des beabsichtigten Empfängers --> <name>Ordination Dr. Empfänger</name><!-- Kontaktdaten der Organisation des beabsichtigten Empfängers --> <telecomvalue="tel:0512.1234567"/><telecomvalue="fax:0512.1234567.11"/><telecomvalue="mailto:office@ordination-empfaenger.at"/><telecomvalue="http://www.ordination-empfaenger.at"/><telecomvalue="me:12345678791"/><!-- Adresse der Organisation des beabsichtigten Empfängers --> <addr> <streetName>Musterstraße</streetName><houseNumber>27/1/13</houseNumber><postalCode>6020</postalCode><city>Innsbruck</city><country>AUT</country></addr></receivedOrganization></intendedRecipient></informationRecipient>
Beispiel
Beabsichtigter Empfänger ist eine unbekannte Person („An den Hausarzt“)
<informationRecipienttypeCode="PRCP"> <intendedRecipient> <!-- Der Patient besitzt keine ID --> <idnullFlavor="NI"/><!-- Hinweis auf den Patienten --> <informationRecipient> <name>Ergeht an den Patienten Dr. Herbert Mustermann</name></informationRecipient></intendedRecipient></informationRecipient><!--Eine erneute Angabe der Adresse des Patienten ist nicht erforderlich.-->
Item
DT
Kard
Konf
Beschreibung
Label
hl7:informationRecipient
Beabsichtiger Empfänger des Dokuments.
(Hea...ent)
elgagab-dataelement-259
Empfänger
Datensatz
@typeCode
cs
0 … 1
Typ des Informationsempfängers.
Bsp: PRCP „Primärer Empfänger“
Wird das Attribut weggelassen, gilt der Empfänger als primärer Empfänger.
CONF
Der Wert von @typeCode muss gewählt werden aus dem Value Set 1.2.40.0.34.10.29 ELGA_InformationRecipientType (DYNAMIC)
hl7:intendedRecipient
1 … 1
M
(Hea...ent)
hl7:id
II
1 … *
R
Identifikation des beabsichtigten Empfängers (Person).Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.
Zugelassene nullFlavor:
NI … Person hat keine ID
UNK ... Person hat eine ID, diese ist jedoch unbekannt
Personendaten des beabsichtigten Empfängers. Grundsätzlich sind die Vorgaben gemäß Kapitel „Personen-Element“ zu befolgen.
(Hea...ent)
Eingefügt
von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
@classCode
cs
0 … 1
F
PSN
@determinerCode
cs
0 … 1
F
INSTANCE
hl7:name
PN
1 … 1
M
Name der Person
Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...ent)
hl7:receivedOrganization
0 … 1
Organisation, der der beabsichtigte Empfänger angehört.z.B.: „Ordination des empfangenden Arztes“ Grundsätzlich sind die Vorgaben gemäß Kapitel „Organisations-Element“ zu
befolgen.
(Hea...ent)
Eingefügt
von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
Abbildung 11: Klassen rund um den Rechtlichen Unterzeichner und Mitunterzeichner.
1.3.6.1 Spezifikation
Id
1.2.40.0.34.11.20006
ref
elgabbr-
Gültigkeit
2011‑12‑19
Andere Versionen mit dieser Id:
HeaderLegalAuthenticator vom 2018‑10‑18 14:34:23
Status
Entwurf
Versions-Label
Name
HeaderLegalAuthenticator
Bezeichnung
HeaderLegalAuthenticator
Beschreibung
Der „Rechtliche Unterzeichner“ oder Hauptunterzeichner ist jene Person, welche für das Dokument aus rechtlicher Sicht die Verantwortung übernimmt. Es muss organisatorisch sichergestellt werden, dass die Person, die als rechtlicher Unterzeichner eingetragen wird, über die entsprechende Berechtigung verfügt.
Grundsätzlich MUSS der Hauptunterzeichner angegeben werden, in bestimmten Fällen kann dies aber unterbleiben. Diese Fälle sind in den jeweiligen speziellen Leitfaden entsprechend angegeben.
Multidisziplinäre Befunde: Der CDA-Standard in Release 2.0 erlaubt nur die Angabe eines legalAuthenticator-Elements, es können jedoch beliebig viele (Mit-) Unterzeichner angegeben werden, siehe „Weitere Unterzeichner („authenticator“)“. Wenn kein eindeutiger Hauptunterzeichner ermittelt werden kann (z.B. bei multidisziplinären Befunden, die von mehreren Fachärzten mit unterschiedlicher Fachrichtung gleichermaßen verantwortet werden), kann die Angabe des Hauptunterzeichners entfallen, wenn mindestens zwei Mitunterzeichner angegeben werden.
Automatisch erstellte Befunde: Bei Dokumenten, die von „Geräten“ erstellt wurden (wenn der Inhalt durch einen Algorithmus erzeugt und nicht von einer natürlichen Person freigegeben wurde), entfällt die Angabe aller Unterzeichner.
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
<legalAuthenticator> <!-- Zeitpunkt der Unterzeichnung --> <timevalue="20130324082015+0100"/><!-- Signaturcode --> <signatureCodecode="S"/><!-- Personen- und Organisationsdaten des Rechtlichen Unterzeichners des Dokuments --> <assignedEntity> <!-- Identifikation des Rechtlichen Unterzeichners des Dokuments --> <idroot="1.2.40.0.34.99.111.1.3"extension="2222"assigningAuthorityName="Amadeus Spital"/><!-- Kontaktdaten des Rechtlichen Unterzeichners des Dokuments --> <telecomuse="WP"value="tel:+43.6138.3453446.2222"/><!-- Personendaten des Rechtlichen Unterzeichners des Dokuments --> <assignedPerson> <!-- Name des Rechtlichen Unterzeichners des Dokuments --> <name> <prefix>Univ.-Prof.Dr.</prefix><given>Sigrid</given><family>Kollmann</family></name></assignedPerson><!-- Organisation, in deren Auftrag der Rechtlichen Unterzeichners des Dokuments die Dokumentation unterzeichnet hat --> <representedOrganization> <idroot="1.2.40.0.34.99.3"assigningAuthorityName="GDA Index"/><name>Amadeus Spital - Chirurgische Abteilung</name><telecomvalue="tel:+43.6138.3453446.0"/><telecomvalue="fax:+43.6138.3453446.4674"/><telecomvalue="mailto:info@amadeusspital.at"/><telecomvalue="http://www.amadeusspital.at"/><addr> <streetName>Mozartgasse</streetName><houseNumber>1-7</houseNumber><postalCode>5350</postalCode><city>St.Wolfgang</city><state>Salzburg</state><country>AUT</country></addr></representedOrganization></assignedEntity></legalAuthenticator>
Item
DT
Kard
Konf
Beschreibung
Label
hl7:legalAuthenticator
Rechtlicher Unterzeichner.
(Hea...tor)
elgagab-dataelement-79
Rechtlicher Unterzeichner
Datensatz
elgagab-dataelement-87
Rechtlicher Unterzeichner
Datensatz
@typeCode
cs
0 … 1
F
LA
hl7:time
TS.DATE.MIN
1 … 1
R
Der Zeitpunkt, an dem das Dokument unterzeichnet wurde.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
Zugelassene nullFlavor: UNK
(Hea...tor)
hl7:signatureCode
CS
1 … 1
M
Signaturcode gibt an, dass das Originaldokument unterzeichnet wurde.
(Hea...tor)
@code
CONF
1 … 1
F
S
hl7:assignedEntity
1 … 1
M
Personendaten des rechtlichen Unterzeichners.
Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben gemäß Kapitel „AssignedEntity-Element (Person + Organisation)“ zu befolgen.
(Hea...tor)
Eingefügt
von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC)
hl7:id
II
1 … *
R
Mindestens eine Id der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...tor)
hl7:addr
AD
0 … 1
Ein Adress-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...tor)
hl7:telecom
TEL.AT
0 … *
Mindestens ein Telecom-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...tor)
hl7:assignedPerson
1 … 1
M
Persondendaten der validierenden Person.
(Hea...tor)
Eingefügt
von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
@classCode
cs
0 … 1
F
PSN
@determinerCode
cs
0 … 1
F
INSTANCE
hl7:name
PN
1 … 1
M
Name der Person
Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...tor)
hl7:representedOrganization
0 … 1
Organistationsdaten der validierenden Person.
(Hea...tor)
Eingefügt
von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
@classCode
0 … 1
F
ORG
@determinerCode
0 … 1
F
INSTANCE
hl7:id
II
0 … *
(Hea...tor)
hl7:name
ON
1 … 1
M
(Hea...tor)
hl7:telecom
TEL.AT
0 … *
(Hea...tor)
hl7:addr
AD
0 … 1
(Hea...tor)
1.3.6.1.1 legalAuthenticator Element Allgemein
Element/Attribut
DT
Kard
Konf
Beschreibung
legalAuthenticator
POCD_MT000040.LegalAuthenticator
C
Rechtlicher Unterzeichner
Konditionale Konformität:
Regelfall: Der Inhalt des Dokuments wird durch eine natürliche Person freigegeben.
Sonderfall: Multidisziplinärer Befund mit gleichberechtigten ärztlichen Unterzeichnern
Sonderfall „automatisch erstellte Dokumente“: Dokumente, deren Inhalt durch einen Algorithmus erzeugt und die nicht von einer natürlichen Person freigegeben werden.
1..1
0..1
0..0
M
O
NP
Der rechtliche Unterzeichner MUSS angegeben werden
Ob einer der Sonderfälle zur Anwendung kommen DARF, ist in den jeweiligen speziellen Leitfäden definiert.
Der rechtliche Unterzeichner KANN angegeben werden, wenn er fehlt, MÜSSEN mindestens zwei Authenticator-Elemente angegeben werden.
Der legalAuthenticator DARF NICHT angegeben werden.
Siehe auch Spezifikation: Datenerstellende Geräte als „author“, Kapitel.
1.3.7 Weitere Unterzeichner („authenticator“)
1.3.7.1 Spezifikation
Id
1.2.40.0.34.11.20007
ref
elgabbr-
Gültigkeit
2011‑12‑19
Andere Versionen mit dieser Id:
HeaderAuthenticator vom 2018‑10‑18 14:33:54
Status
Entwurf
Versions-Label
Name
HeaderAuthenticator
Bezeichnung
HeaderAuthenticator
Beschreibung
Dokumente können neben dem verpflichtenden legalAuthenticator („rechtlichen Unterzeichner“, Hauptunterzeichner) auch beliebig viele weitere Mitunterzeichner beinhalten.
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
<authenticator> <!-- Zeitpunkt der Unterzeichnung --> <timevalue="20130324081915+0100"/><!-- Signaturcode --> <signatureCodecode="S"/><!-- Personen- und Organisationsdaten des Weiteren Unterzeichners des Dokuments --> <assignedEntity> <idroot="1.2.40.0.34.99.111.1.3"extension="3333"assigningAuthorityName="Amadeus Spital"/><telecomuse="WP"value="tel:+43.6138.3453446.3333"/><assignedPerson> <!-- Name des Weiteren Unterzeichners des Dokuments --> <name> <prefix>Dr.</prefix><given>Walter</given><family>Hummel</family></name></assignedPerson><!-- Organisation, in deren Auftrag der Weiteren Unterzeichner des Dokuments die Dokumentationunterzeichnet hat --> <representedOrganization> <idroot="1.2.40.0.34.99.3"assigningAuthorityName="GDA Index"/><name>Amadeus Spital - Chirurgische Abteilung</name><telecomvalue="tel:+43.6138.3453446.0"/><telecomvalue="fax:+43.6138.3453446.4674"/><telecomvalue="mailto:info@amadeusspital.at"/><telecomvalue="http://www.amadeusspital.at"/><addr> <streetName>Mozartgasse</streetName><houseNumber>1-7</houseNumber><postalCode>5350</postalCode><city>St.Wolfgang</city><state>Salzburg</state><country>AUT</country></addr></representedOrganization></assignedEntity></authenticator>
Der Zeitpunkt, an dem das Dokument unterzeichnet wurde.
Grundsätzlich sind die Vorgaben gemäß für „Zeit-Elemente“ zu befolgen.
Zugelassene nullFlavor: UNK
(Hea...tor)
hl7:signatureCode
CS
1 … 1
M
(Hea...tor)
@code
CONF
1 … 1
F
S
hl7:assignedEntity
1 … 1
M
Personendaten des weiteren
Unterzeichners.Grundsätzlich sind die Vorgaben gemäß Kapitel „AssignedEntity-Element (Person + Organisation)“ zu befolgen.
(Hea...tor)
Eingefügt
von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC)
hl7:id
II
1 … *
R
Mindestens eine Id der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...tor)
hl7:addr
AD
0 … 1
Ein Adress-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...tor)
hl7:telecom
TEL.AT
0 … *
Mindestens ein Telecom-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...tor)
hl7:assignedPerson
1 … 1
M
Persondendaten der validierenden Person.
(Hea...tor)
Eingefügt
von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
@classCode
cs
0 … 1
F
PSN
@determinerCode
cs
0 … 1
F
INSTANCE
hl7:name
PN
1 … 1
M
Name der Person
Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...tor)
hl7:representedOrganization
0 … 1
Organistationsdaten der validierenden Person.
(Hea...tor)
Eingefügt
von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
@classCode
0 … 1
F
ORG
@determinerCode
0 … 1
F
INSTANCE
hl7:id
II
0 … *
(Hea...tor)
hl7:name
ON
1 … 1
M
(Hea...tor)
hl7:telecom
TEL.AT
0 … *
(Hea...tor)
hl7:addr
AD
0 … 1
(Hea...tor)
1.3.8 Weitere Beteiligte („participant“)
Mit dieser Assoziation und den entsprechenden Klassen können weitere für die Dokumentation wichtige beteiligte Personen oder Organisationen wie Angehörige, Verwandte, Versicherungsträger sowie weitere in Beziehung zum Patienten stehende Parteien genannt werden.
Es können grundsätzlich beliebig viele participant-Elemente im Dokument angegeben werden, teilweise gibt es aber Einschränkungen für die einzelnen Elemente.
Auszug aus dem R-MIM:
Abbildung 12: Klassen rund um weitere Beteiligte (participants).
1.3.8.1 Festlegung der „Art“ des Beteiligten
Die „Art“ des Beteiligten wird über eine Kombination aus
Attribut participant/@typeCode
Element participant/functionCode
Attribut participant/associatedEntity/@classCode
festgelegt.
Eine eindeutige Identifikation ist darüber hinaus noch über das templateId-Element möglich, welches für jede Art von Beteiligten einen eindeutigen Wert enthält.
Ebenfalls erhalten die Elemente innerhalb der Unterelemente ihre Bedeutung in Abhängigkeit von der Beteiligten-Art. Beispielsweise drückt das time-Element zwar generell den Zeitraum der Beteiligung, im Falle der Darstellung einer Versicherung allerdings den Gültigkeitsbereich der Versicherungspolizze aus.
Dieses Kapitel enthält eine detaillierte Anleitung zur Angabe der folgenden Arten von „weiteren Beteiligten“:
Kard
Konf
Art des Beteiligten
0..1
O
Fachlicher Ansprechpartner
0..1
O
Einweisender/Zuweisender/Überweisender Arzt
0..1
O
Hausarzt
0..*
O
Notfall-Kontakt / Auskunftsberechtigte Person
0..*
O
Angehörige
0..*
O
Versicherter/Versicherung
0..1
O
Betreuende Organisation
0..1
O
Weitere Behandler
Verweis auf speziellen Implementierungsleitfaden:
Welche der folgenden „weiteren Beteiligten“ im Dokument angegeben werden müssen bzw. sollen ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
1.3.8.2 Fachlicher Ansprechpartner
Der fachliche Ansprechpartner ist jene Kontaktperson oder –stelle, welche zur Kontaktaufnahme für fachliche Auskünfte zum betreffenden Dokument veröffentlicht wird. Diese Maßnahme dient zur Kanalisierung und Vereinheitlichung der Kommunikationsschiene zwischen dem Erzeuger und dem Empfänger der Dokumentation, beispielsweise für Rückfragen oder Erfragung weiterer fachlicher Informationen.
Die Angabe dieses Elements ist grundsätzlich optional, wobei in den speziellen Leitfäden eine verpflichtende Angabe spezifiziert sein kann. Bei Verwendung sollen möglichst präzise Kontaktdaten angegeben werden. Es obliegt der dokumenterzeugenden Organisation zu entscheiden, welchen Ansprechpartner sie veröffentlicht.
Abbildung 13: Besonders hervorgehobene Darstellung des fachlichen Ansprechpartners durch das ELGA Referenz-Stylesheet.
Soll als Ansprechpartner der Verfasser des Dokuments angegeben werden, so sind die entsprechenden Daten an dieser Stelle noch einmal anzugeben.
Als fachlicher Ansprechpartner kann aber auch eine Stelle beschrieben sein, die eingehende Anfragen als erste entgegennimmt und in Folge an die zuständigen Personen weiterleitet.
Diese Beteiligten-Art wird durch folgende Kombination angegeben:
Element
Wert
Beschreibung
Bedeutung
@typeCode
CALLBCK
Callback contact
Fachlicher Ansprechpartner
templateId
1.2.40.0.34.11.1.1.1
-
Template ID zur Identifikation dieser Art von Beteiligten
functionCode
-
-
Wird nicht angegeben
@classCode
PROV
Healthcare provider
Gesundheitsdienstanbieter
1.3.8.2.1 Spezifikation
Id
1.2.40.0.34.11.1.1.1
ref
elgabbr-
Gültigkeit
2014‑03‑25
Andere Versionen mit dieser Id:
HeaderParticipantAnsprechpartner vom 2013‑10‑16
Status
Aktiv
Versions-Label
Name
HeaderParticipantAnsprechpartner
Bezeichnung
HeaderParticipant Ansprechpartner
Beschreibung
Der fachliche Ansprechpartner ist jene Kontaktperson oder –stelle, welche zur Kontaktaufnahme für fachliche Auskünfte zum betreffenden Dokument veröffentlicht wird. Diese Maßnahme dient zur Kanalisierung und Vereinheitlichung der Kommunikationsschiene zwischen dem Erzeuger und dem Empfänger der Dokumentation, beispielsweise für Rückfragen oder Erfragung
weiterer fachlicher Informationen.
Die Angabe dieses Elements ist grundsätzlich optional, wobei in den speziellen Leitfäden eine verpflichtende Angabe spezifiziert sein kann. Bei Verwendung sollen möglichst präzise Kontaktdaten angegeben werden. Es obliegt der dokumenterzeugenden Organisation zu entscheiden, welchen Ansprechpartner sie
veröffentlicht.
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
wo [hl7:templateId [@root='1.2.40.0.34.11.1.1.1']]
@typeCode
cs
1 … 1
F
CALLBCK
hl7:templateId
II
1 … 1
M
(Hea...ner)
@root
uid
1 … 1
F
1.2.40.0.34.11.1.1.1
hl7:time
NP
(Hea...ner)
hl7:associatedEntity
1 … 1
M
(Hea...ner)
@classCode
cs
1 … 1
F
PROV
hl7:addr
AD
0 … 1
Adresse des Beteiligten. Grundsätzlich sind die Vorgaben für "Adress-Elemente" zu befolgen.
(Hea...ner)
hl7:telecom
TEL.AT
1 … *
M
Beliebig viele Kontaktdaten des Beteiligten.
Es MUSS mindestens eine Telefon-Nummer angegeben werden
(Hea...ner)
hl7:associatedPerson
1 … 1
M
Beteiligte Person.
(Hea...ner)
Eingefügt
von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
@classCode
cs
0 … 1
F
PSN
@determinerCode
cs
0 … 1
F
INSTANCE
hl7:name
PN
1 … 1
M
Name der Person
Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...ner)
hl7:scopingOrganization
0 … 1
Organisation, der der Beteiligte angehört (mit Adresse und Kontaktdaten der Organisation). Grundsätzlich sind die Vorgaben für "Organisations-Element" zu befolgen.
(Hea...ner)
Eingefügt
von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
Diese Beteiligten-Art wird durch folgende Kombination angegeben:
Element
Wert
Beschreibung
Bedeutung
@typeCode
REF
Referrer
Einweisender/Zuweisender/Überweisender Arzt
templateId
1.2.40.0.34.11.1.1.2 1.3.6.1.4.1.19376.1.3.3.1.6
-
Template ID für: Einweisender/Zuweisender/Überweisender Arzt Labor-Auftraggeber
functionCode
-
-
Wird nicht angegeben
@classCode
PROV
Healthcare provider
Gesundheitsdienstanbieter
Verweis auf speziellen Implementierungsleitfaden:
Für den Laborbefund gilt hier eine Ausnahme. Der participant mit dem typeCode="REF" wird in der Definition des IHE Laboratory Technical Framework als Auftraggeber bzw. „Ordering Provider“ mit templateId "1.3.6.1.4.1.19376.1.3.3.1.6" angewendet.
1.3.8.3.1 Spezifikation
Id
1.2.40.0.34.11.1.1.2
ref
elgabbr-
Gültigkeit
2013‑10‑16
Status
Aktiv
Versions-Label
Name
HeaderParticipantRefArzt
Bezeichnung
HeaderParticipant Ref Arzt
Beschreibung
Einweisender/Zuweisender Arzt/Überweisender Arzt
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
<participanttypeCode="IND"> <templateIdroot="1.2.40.0.34.11.1.1.3"/><functionCodecode="PCP"displayName="primary care physician"codeSystem="2.16.840.1.113883.5.88"codeSystemName="HL7:ParticipationFunction"/><associatedEntityclassCode="PROV"> <!-- Identifikation des Hausarztes (Person) aus dem GDA-Index --> <idroot="1.2.3.999"extension="--example only--"/><addr/><telecom/><!-- Personendaten des Hausarztes --> <associatedPerson> <name> <prefixqualifier="AC">Dr.</prefix><given>Walter</given><family>Mustermann</family></name></associatedPerson><!-- Organisation, der der Hausarzt angehört --> <scopingOrganization> <idroot="1.2.40.0.34.3.1.xxx"assigningAuthorityName="GDA Index"/><name>Allgemeinmedizinische Praxis Dr. Mustermann</name><telecomvalue="tel:0512.1234567"/><telecomvalue="fax:0512.1234567.11"/><telecomvalue="mailto:office@ordination.at"/><telecomvalue="http://www.ordination.at"/><telecomvalue="me:12345678792"/><addr> <streetName>Sekundärstraße</streetName><houseNumber>22</houseNumber><postalCode>6020</postalCode><city>Innsbruck</city><country>AUT</country></addr></scopingOrganization></associatedEntity></participant>
Item
DT
Kard
Konf
Beschreibung
Label
hl7:participant
Beteiligter (Hausarzt).
(Hea...rzt)
wo [hl7:templateId [@root='1.2.40.0.34.11.1.1.3']]
elgagab-dataelement-100
Hausarzt
Datensatz
@typeCode
cs
1 … 1
F
IND
In indirektem Bezug.
hl7:templateId
II
1 … 1
M
Template ID zur Identifikation dieser Art von Beteiligten.
(Hea...rzt)
@root
uid
1 … 1
F
1.2.40.0.34.11.1.1.3
hl7:functionCode
CE
1 … *
M
Hausarzt.
(Hea...rzt)
@code
CONF
1 … 1
F
PCP
@codeSystem
1 … 1
F
2.16.840.1.113883.5.88 (Participation Function)
hl7:associatedEntity
1 … 1
M
Beschreibung der Entität.
(Hea...rzt)
@classCode
cs
1 … 1
F
PROV
Gesundheitsdienstanbieter.
hl7:id
II
0 … *
Identifikation des Beteiligten (Person) aus dem GDA-Index.Zugelassene nullFlavor:
NI … Organisation hat keine ID
UNK … Organisation hat eine ID, diese ist jedoch unbekannt
Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.
(Hea...rzt)
hl7:addr
AD
0 … 1
Adresse des Beteiligten.
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.
(Hea...rzt)
hl7:telecom
TEL.AT
0 … *
Beliebig viele Kontaktdaten des
Beteiligten.
(Hea...rzt)
hl7:associatedPerson
1 … 1
M
Beteiligte Person.
Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.
(Hea...rzt)
Eingefügt
von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
@classCode
cs
0 … 1
F
PSN
@determinerCode
cs
0 … 1
F
INSTANCE
hl7:name
PN
1 … 1
M
Name der Person
Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...rzt)
hl7:scopingOrganization
0 … 1
Organisation, der der Beteiligte angehört (mit Adresse und Kontaktdaten der Organisation), zB die Arztpraxis oder Ordination.
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.
(Hea...rzt)
Eingefügt
von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
@classCode
0 … 1
F
ORG
@determinerCode
0 … 1
F
INSTANCE
hl7:id
II
0 … *
(Hea...rzt)
hl7:name
ON
1 … 1
M
(Hea...rzt)
hl7:telecom
TEL.AT
0 … *
(Hea...rzt)
hl7:addr
AD
0 … 1
(Hea...rzt)
1.3.8.5 Notfall-Kontakt/Auskunftsberechtigte Person
Der Notfall-Kontakt entspricht in Österreich der „Auskunftsberechtigten Person“ (oder auch „Vertrauensperson“).
Diese Beteiligten-Art wird durch folgende Kombination angegeben:
Element
Wert
Beschreibung
Bedeutung
@typeCode
IND
Indirect target
In indirektem Bezug
templateId
1.2.40.0.34.11.1.1.4
-
Template ID zur Identifikation dieser Art von Beteiligten
functionCode
-
-
Wird nicht angegeben
@classCode
ECON
Emergency contact
Notfall-Kontakt
1.3.8.5.1 Spezifikation
Id
1.2.40.0.34.11.1.1.4
ref
elgabbr-
Gültigkeit
2013‑11‑13
Andere Versionen mit dieser Id:
HeaderParticipantNotfallkontakt vom 2013‑10‑16
Status
Aktiv
Versions-Label
Name
HeaderParticipantNotfallkontakt
Bezeichnung
HeaderParticipant Notfallkontakt
Beschreibung
Notfall-Kontakt / Auskunftsberechtigte Person
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
wo [hl7:templateId [@root='1.2.40.0.34.11.1.1.4']]
elgagab-dataelement-105
Notfall-Kontakt
Datensatz
@typeCode
cs
1 … 1
F
IND
hl7:templateId
II
1 … 1
M
(Hea...akt)
@root
uid
1 … 1
F
1.2.40.0.34.11.1.1.4
hl7:time
IVL_TS
0 … 1
Zeitraum, in dem der angegebene Kontakt den Notfall-Kontakt darstellt.Wird nur angegeben, wenn der Kontakt bereits absehbar nur in einem eingeschränkten Zeitraum zur Verfügung steht.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
(Hea...akt)
hl7:associatedEntity
1 … 1
M
Beschreibung der Entität.
(Hea...akt)
@classCode
cs
1 … 1
F
ECON
hl7:code
CE
0 … 1
Verwandtschaftsverhältnis des Beteiligten zum Patienten. Beispiel: DAU („daughter“), wenn die Beteiligte die Tochter des Patienten
ist.
(Hea...akt)
CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.17 ELGA_PersonalRelationship (DYNAMIC)
hl7:addr
AD
0 … 1
Adresse des Beteiligten.
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.
(Hea...akt)
hl7:telecom
TEL.AT
0 … *
R
Beliebig viele Kontaktdaten des Beteiligten.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
Es SOLL mindestens eine Telefonnummer angegeben werden.
(Hea...akt)
hl7:associatedPerson
1 … 1
M
Name des Beteiligten.
Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.
(Hea...akt)
Eingefügt
von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
@classCode
cs
0 … 1
F
PSN
@determinerCode
cs
0 … 1
F
INSTANCE
hl7:name
PN
1 … 1
M
Name der Person
Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...akt)
hl7:scopingOrganization
0 … 1
Organisation, der der Beteiligte angehört (mit Adresse und Kontaktdaten der Organisation).
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.
(Hea...akt)
Eingefügt
von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
@classCode
0 … 1
F
ORG
@determinerCode
0 … 1
F
INSTANCE
hl7:id
II
0 … *
(Hea...akt)
hl7:name
ON
1 … 1
M
(Hea...akt)
hl7:telecom
TEL.AT
0 … *
(Hea...akt)
hl7:addr
AD
0 … 1
(Hea...akt)
1.3.8.6 Angehörige
Als Angehörige sind in Österreich jene Personen anzusehen, welche in einem Verwandtschaftsverhältnis zum Patienten stehen, aber nicht unter die Gruppe der „Auskunftsberechtigten Personen“ fallen (siehe Notfall-Kontakt/Auskunftsberechtigte Person).
Diese Beteiligten-Art wird durch folgende Kombination angegeben:
Element
Wert
Beschreibung
Bedeutung
@typeCode
IND
Indirect target
In indirektem Bezug
templateId
1.2.40.0.34.11.1.1.5
-
Template ID zur Identifikation dieser Art von Beteiligten
functionCode
-
-
Wird nicht angegeben
@classCode
PRS
Personal relationship
In persönlicher Beziehung
1.3.8.6.1 Spezifikation
Id
1.2.40.0.34.11.1.1.5
ref
elgabbr-
Gültigkeit
2016‑07‑21
Andere Versionen mit dieser Id:
HeaderParticipantAngehoerige vom 2013‑11‑13
HeaderParticipantAngehoerige vom 2013‑10‑16
Status
Aktiv
Versions-Label
Name
HeaderParticipantAngehoerige
Bezeichnung
HeaderParticipant Angehörige
Beschreibung
Als Angehörige sind in Österreich jene Personen anzusehen, welche in einem Verwandtschaftsverhältnis zum Patienten stehen, aber nicht unter die Gruppe der „Auskunftsberechtigten Personen“ fallen.
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
<!-- In diesem Fall können die Angaben zur Person (Adresse, Kontaktdaten, Name des Patienten) entfallen, da diese bereits in der Klasse patientRole angegeben sind. --> <participanttypeCode="HLD"> <templateIdroot="1.2.40.0.34.11.1.1.6"/><time> <lowvalue="20020101"/><highvalue="20151231"/></time><associatedEntityclassCode="POLHOLD"> <idroot="1.2.40.0.10.1.4.3.1"extension="123424121970"assigningAuthorityName="Österreichische Sozialversicherung"/><codecode="SELF"displayName="self"codeSystem="2.16.840.1.113883.5.111"codeSystemName="HL7:RoleCode"/><scopingOrganization> <name>Sozialversicherung der gew. Wirtschaft</name><telecomvalue="tel:01.54654-0"/><telecomvalue="fax:01.54654-385"/><telecomvalue="http://esv-sva.sozvers.at"/><addr> <streetName>Wiedner Hauptstraße</streetName><houseNumber>84-86</houseNumber><postalCode>1051</postalCode><city>Wien</city><country>AUT</country></addr></scopingOrganization></associatedEntity></participant>
Beispiel
Patient ist bei einem Angehörigen mitversichert
<!-- In diesem Fall MÜSSEN die Angaben zur versicherten Person vorhanden sein. Im Mindesten MUSS der Name der versicherten Person angegeben sein. --> <participanttypeCode="HLD"> <templateIdroot="1.2.40.0.34.11.1.1.6"/><!-- Versicherungszeitraum vom 01.01.2002 – 31.12.2008 --> <time> <lowvalue="20020101"/><highvalue="20081231"/></time><associatedEntityclassCode="POLHOLD"> <!-- SV Nummer der Person, bei der der Patient mitversichert ist --> <idroot="1.2.40.0.10.1.4.3.1"extension="123424121970"assigningAuthorityName="Österreichische Sozialversicherung"/><!-- Code FAMDEP (Mitversichert bei Familienangehörigen) --> <codecode="FAMDEP"displayName="family dependent"codeSystem="2.16.840.1.113883.5.111"codeSystemName="HL7:RoleCode"/><!-- Adresse der Person, bei der der Patient mitversichert ist --> <addr> <streetName>Musterstrasse</streetName><houseNumber>47-51</houseNumber><postalCode>8010</postalCode><city>Graz</city><country>AUT</country></addr><!-- Kontakt(e) der Person, bei der der Patient mitversichert ist --> <telecomvalue="tel:+43.(0)50.55460-0"/><!-- Name der Person, bei der der Patient mitversichert ist --> <associatedPerson> <name> <given>Herbert</given><family>Vater</family></name></associatedPerson><!-- Versicherungsgesellschaft --> <scopingOrganization> <name>Sozialversicherung der gew. Wirtschaft</name><telecomvalue="tel:01.54654-0"/><telecomvalue="fax:01.54654-385"/><telecomvalue="http://esv-sva.sozvers.at"/><addr> <streetName>Wiedner Hauptstraße</streetName><houseNumber>84-86</houseNumber><postalCode>1051</postalCode><city>Wien</city><state>Wien</state><country>AUT</country></addr></scopingOrganization></associatedEntity></participant>
Item
DT
Kard
Konf
Beschreibung
Label
hl7:participant
Beteiligter (Versicherter/Versicherung).
(Hea...ung)
wo [hl7:templateId [@root='1.2.40.0.34.11.1.1.6']]
elgagab-dataelement-119
Versicherter/Versicherung
Datensatz
@typeCode
cs
1 … 1
F
HLD
hl7:templateId
II
1 … 1
M
(Hea...ung)
@root
uid
1 … 1
F
1.2.40.0.34.11.1.1.6
hl7:time
IVL_TS
0 … 1
Gültigkeitszeitraum der Versicherungspolizze.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
(Hea...ung)
hl7:associatedEntity
1 … 1
M
Beschreibung der Entität.
(Hea...ung)
@classCode
cs
1 … 1
F
POLHOLD
hl7:id
II
0 … *
Sozialversicherungsnummer des Patienten (SELF) oder der Person, bei der der Patient mitversichert ist (FAMDEP)
Zugelassene nullFlavor:
NI … Patient hat keine Sozialversicherungsnummer (z.B. Ausländer, …)
UNK … Patient hat eine Sozialversicherungsnummer, diese ist jedoch unbekannt
(Hea...ung)
hl7:code
CE
0 … 1
Versicherungsverhältnis codiert.Beispiele:SELF, wenn der Patient selbst der Versicherte ist.FAMDEP, wenn der Patient bei einem Familienmitglied mitversichert ist.
(Hea...ung)
CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.9 ELGA_InsuredAssocEntity (DYNAMIC)
hl7:addr
AD
0 … 1
Adresse des Beteiligten.
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.
(Hea...ung)
hl7:telecom
TEL.AT
0 … *
Beliebig viele Kontaktdaten des Beteiligten.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(Hea...ung)
hl7:associatedPerson
0 … 1
Name des Beteiligten.
Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.
(Hea...ung)
Eingefügt
von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
@classCode
cs
0 … 1
F
PSN
@determinerCode
cs
0 … 1
F
INSTANCE
hl7:name
PN
1 … 1
M
Name der Person
Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...ung)
Schematron assert
role
error
test
hl7:code/@code!='FAMDEP' or count(hl7:associatedPerson)=1
Meldung
Wenn das Versicherungsverhältnis "familienversichert" ist, dann muss eine associatedPerson angegeben sein
hl7:scopingOrganization
1 … 1
R
Versicherungsgesellschaft.
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.
(Hea...ung)
Eingefügt
von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
@classCode
0 … 1
F
ORG
@determinerCode
0 … 1
F
INSTANCE
hl7:id
II
0 … *
(Hea...ung)
hl7:name
ON
1 … 1
M
(Hea...ung)
hl7:telecom
TEL.AT
0 … *
(Hea...ung)
hl7:addr
AD
0 … 1
(Hea...ung)
1.3.8.8 Betreuende Organisation
Als betreuende Organisation ist jene Organisation anzusehen, welche den Patienten nach Entlassung betreut (Trägerorganisationen, Vereine).
Beispiele: Mobile Hauskrankenpflege, Wohn- und Pflegeheime, Behinderteneinrichtungen, sozial betreutes Wohnen, …
Diese Beteiligten-Art wird durch folgende Kombination angegeben:
Element
Wert
Beschreibung
Bedeutung
@typeCode
IND
Indirect target
In indirektem Bezug
templateId
1.2.40.0.34.11.1.1.7
-
Template ID zur Identifikation dieser Art von Beteiligten
functionCode
-
-
Wird nicht angegeben
@classCode
CAREGIVER
Betreuer
Betreuende Entität
1.3.8.8.1 Spezifikation
Id
1.2.40.0.34.11.1.1.7
ref
elgabbr-
Gültigkeit
2013‑10‑16
Status
Aktiv
Versions-Label
Name
HeaderParticipantBetreuorg
Bezeichnung
HeaderParticipant Betreuungsorganisation
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
<participanttypeCode="IND"> <templateIdroot="1.2.40.0.34.11.1.1.7"/><associatedEntityclassCode="CAREGIVER"> <!-- Betreuende Organisation --> <scopingOrganization> <!-- Name der betreuenden Organisation --> <name>Altenpflegeheim Sorgenfrei</name><!-- Kontaktdaten der betreuenden Organisation --> <telecomvalue="tel:+43.1.3453446.0"/><telecomvalue="fax:+43.1.3453446.4674"/><telecomvalue="mailto:info@altenpflegeheim-sorgenfrei.at"/><telecomvalue="http://www.altenpflegeheim-sorgenfrei.at"/><!-- Adresse der betreuenden Organisation --> <addr> <streetName>Im schönen Walde</streetName><houseNumber>24</houseNumber><postalCode>2500</postalCode><city>Baden</city><state>Niederösterreich</state><country>AUT</country></addr></scopingOrganization></associatedEntity></participant>
Item
DT
Kard
Konf
Beschreibung
Label
hl7:participant
Beteiligter (Betreuende Organisation).
(Hea...org)
wo [hl7:templateId [@root='1.2.40.0.34.11.1.1.7']]
elgagab-dataelement-251
Betreuende Organisation
Datensatz
@typeCode
cs
1 … 1
F
IND
hl7:templateId
II
1 … 1
M
(Hea...org)
@root
uid
1 … 1
F
1.2.40.0.34.11.1.1.7
hl7:associatedEntity
1 … 1
M
Beschreibung der Entität.
(Hea...org)
@classCode
cs
1 … 1
F
CAREGIVER
hl7:scopingOrganization
1 … 1
M
Betreuende Organisation.
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.
(Hea...org)
Eingefügt
von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
@classCode
0 … 1
F
ORG
@determinerCode
0 … 1
F
INSTANCE
hl7:id
II
0 … *
(Hea...org)
hl7:name
ON
1 … 1
M
(Hea...org)
hl7:telecom
TEL.AT
0 … *
(Hea...org)
hl7:addr
AD
0 … 1
(Hea...org)
1.3.8.9 Weitere Behandler
Über dieses Element können weitere an der medizinischen Behandlung maßgeblich beteiligte Personen angegeben werden. Das können Ärzte aus der gleichen oder einer anderen Abteilung sein, weiters niedergelassene behandelnde Ärzte (z.B. der behandelnde Internist oder Kinderarzt) aber auch nicht-ärztliche Behandler, wie z.B. Psychologen.
Die Angabe dieses Elements ist grundsätzlich optional, wobei in den speziellen Leitfäden eine verpflichtende Angabe spezifiziert sein kann. Bei Verwendung sollen möglichst präzise Kontaktdaten angegeben werden. Es obliegt der dokumenterzeugenden Organisation zu entscheiden, welche weitere Behandler sie veröffentlicht.
Diese Beteiligten-Art wird durch folgende Kombination angegeben:
Element
Wert
Beschreibung
Bedeutung
@typeCode
CON
Consultant
Weitere Behandler
templateId
1.2.40.0.34.11.1.1.8
-
Template ID zur Identifikation dieser Art von Beteiligten
functionCode
Wert aus Value Set ELGA_Funktionscodes
Angabe der Funktion bzw. der Fachrichtung des Behandlers
@classCode
PROV
Healthcare provider
Gesundheitsdienstanbieter
1.3.8.9.1 Spezifikation
Id
1.2.40.0.34.11.1.1.8
ref
elgabbr-
Gültigkeit
2017‑02‑20
Status
Aktiv
Versions-Label
Name
HeaderParticipantConsultant
Bezeichnung
HeaderParticipant Weitere Behandler
Beschreibung
Über dieses Element können weitere an der medizinischen Behandlung maßgeblich beteiligte Personen angegeben werden. Das können Ärzte aus der gleichen oder einer anderen Abteilung sein, weiters niedergelassene behandelnde Ärzte (z.B. der behandelnde Internist oder Kinderarzt) aber auch nicht-ärztliche Behandler, wie z.B. Psychologen. Bei Verwendung sollen möglichst präzise Kontaktdaten angegeben werden. Es obliegt der dokumenterzeugenden Organisation zu entscheiden, welche weitere Behandler sie veröffentlicht.
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
Id
Name
Datensatz
elgagab-dataelement-136
Weitere Behandler
Datensatz
Benutzt
Benutzt 2 Templates
Benutzt
als
Name
Version
1.2.40.0.34.11.90001
Inklusion
PersonElements
DYNAMIC
1.2.40.0.34.11.90002
Inklusion
OrganizationElements
DYNAMIC
Beziehung
Version: Template 1.2.40.0.34.11.1.1.8 HeaderParticipant Weitere Behandler (2017‑02‑20)
ref
elgabbr-
Beispiel
Strukturbeispiel Weitere Behandler
<participanttypeCode="CON"> <templateIdroot="1.2.40.0.34.11.1.1.8"/><functionCodecode="130"displayName="Facharzt für Neurologie"codeSystem="1.2.40.0.34.5.160"codeSystemName="ELGA_Fachaerzte"/><associatedEntityclassCode="PROV"> <!-- Kontaktdaten des Behandlers --> <telecomvalue="tel:+43.6138.3453446.1"/><telecomvalue="mailto:robert.betterman@amadeusspital.at"/><associatedPerson> <!-- Name des Behandlers --> <name> <prefixqualifier="AC">Dr.</prefix><given>Robert</given><family>Betterman</family></name><!-- ... ODER ... --> <name>Dr. Robert Betterman</name></associatedPerson></associatedEntity></participant>
Item
DT
Kard
Konf
Beschreibung
Label
hl7:participant
Beteiligter (Fachlicher Ansprechpartner).
(Hea...ant)
wo [hl7:templateId [@root='1.2.40.0.34.11.1.1.8']]
elgagab-dataelement-136
Weitere Behandler
Datensatz
@typeCode
cs
1 … 1
F
CON
Weitere Behandler.
hl7:templateId
II
1 … 1
M
(Hea...ant)
@root
uid
1 … 1
F
1.2.40.0.34.11.1.1.8
hl7:functionCode
CE
0 … 1
R
Angabe der Funktion bzw. der Fachrichtung des Behandlers.
z.B: „Facharzt für Neurologie“
Eigene Codes und Bezeichnungen dürfen verwendet werden.
Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen.
(Hea...ant)
CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC)
hl7:associatedEntity
1 … 1
M
(Hea...ant)
@classCode
cs
1 … 1
F
PROV
Gesundheitsdienstanbieter.
hl7:addr
AD
0 … 1
Adresse des Beteiligten.
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.
(Hea...ant)
hl7:telecom
TEL.AT
0 … *
R
Beliebig viele Kontaktdaten des Beteiligten. Es MUSS mindestens eine Telefon-Nummer angegeben werden.
(Hea...ant)
hl7:associatedPerson
1 … 1
M
Beteiligte Person
Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.
(Hea...ant)
Eingefügt
von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
@classCode
cs
0 … 1
F
PSN
@determinerCode
cs
0 … 1
F
INSTANCE
hl7:name
PN
1 … 1
M
Name der Person
Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...ant)
hl7:scopingOrganization
0 … 1
R
Organisation, der der Beteiligte angehört (mit Adresse und Kontaktdaten der Organisation)
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.
(Hea...ant)
Eingefügt
von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
@classCode
0 … 1
F
ORG
@determinerCode
0 … 1
F
INSTANCE
hl7:id
II
0 … *
(Hea...ant)
hl7:name
ON
1 … 1
M
(Hea...ant)
hl7:telecom
TEL.AT
0 … *
(Hea...ant)
hl7:addr
AD
0 … 1
(Hea...ant)
1.4 Zuweisung und Ordermanagement
1.4.1 Auftrag („inFulfillmentOf“)
Das Element inFulfillmentOf enthält den Bezug zum zugrundeliegenden Auftrag des Auftraggebers. Dies kann zum Beispiel eine Auftrags- oder Anforderungsnummer sein. Das Element erlaubt genau ein order Unterelement.
Auszug aus dem R-MIM:
Abbildung 14: Klassen rund um den Zuweisung und Ordermanagement.
1.4.1.1 Spezifikation
Id
1.2.40.0.34.11.20009
ref
elgabbr-
Gültigkeit
2011‑12‑19
Status
Aktiv
Versions-Label
Name
HeaderInFulfillmentOf
Bezeichnung
HeaderInFulfillmentOf
Beschreibung
Das Element “inFulfillmentOf” ermöglicht die Referenz zum ursprünglichen Auftrag des Auftraggebers. Dies kann zum Beispiel eine Auftrags- oder Anforderungsnummer sein. Das Element erlaubt genau ein order Unterelement.
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Auftragsnummer, Anforderungsnummer. Grundsätzlich sind die Vorgaben gemäß Kapitel „Identifikations-Elemente“ zu befolgen.
(Hea...tOf)
1.5 Dokumentation der Gesundheitsdienstleistung
1.5.1 Service Events („documentationOf/serviceEvent“)
Mit der Assoziation documentationOf/serviceEvent wird die eigentliche Gesundheitsdienstleistung repräsentiert, die in dem Dokument dokumentiert wird (z. B. eine Koloskopie, Appendektomie, etc.). Dies ist in engem Zusammenhang mit dem Dokumententyp zu sehen, der in ClinicalDocument/code wiedergegeben ist. Mit der documentationOf Beziehung kann die dokumentierte Gesundheitsdienstleistung näher spezifiziert werden. Dies darf natürlich nicht im Widerspruch zum Dokumententyp stehen.
In serviceEvent/effectiveTime kann der Zeitpunkt/Zeitraum der Gesundheitsdienstleistung angegeben werden. Im Gegensatz zum Encounter (siehe Kapitel „Informationen zum Patientenkontakt“), der ggf. mehrere Gesundheitsdienstleistungen „umrahmt“.
Da diese Informationen in die XDS-Metadaten übernommen werden, ergeben sich folgende Implikationen:
Die serviceEvents sind die einzigen (rein) medizinischen Informationen zum Dokument im Dokumentenregister
Können daher als Such-/Filterkriterium verwendet werden
Scheint ggf. in den Ergebnissen der Suchabfragen auf
-> Sollte eine wertvolle Information sein (für den Behandler!)
Auszug aus dem R-MIM:
Abbildung 15: Klassen rund um die Gesundheitsdienstleistung.
1.5.1.1 Spezifikation
Da dieses Element automatisch in die XDS-Metadaten übernommen wird, SOLL mindestens eine Gesundheitsdienstleistung als documentationOf/serviceEvent-Element angegeben werden [R2].
ACHTUNG: Die Zeitangaben der Gesundheitsdienstleistung (erstes documentationOf/serviceEvent-Element) werden in die Dokument-Metadaten übernommen!
Die Bedeutung der Dokument-Metadaten-Elemente lautet daher wie folgt:
serviceStartTime: Beginn des ersten documentationOf/serviceEvent-Elements serviceStopTime: Ende des ersten documentationOf/serviceEvent-Elements
Die semantische Bedeutung dieser Zeitpunkte wird in den speziellen Implementierungs-leitfäden festgelegt.
Es können beliebig viele weitere Gesundheitsdienstleistungen als weitere documentationOf/serviceEvent-Elemente angegeben werden.
Id
1.2.40.0.34.11.20010
ref
elgabbr-
Gültigkeit
2011‑12‑19
Status
Aktiv
Versions-Label
Name
HeaderServiceEvent
Bezeichnung
HeaderServiceEvent
Beschreibung
Mit der Assoziation documentationOf/serviceEvent wird die eigentliche Gesundheitsdienstleistung repräsentiert, die in dem Dokument dokumentiert wird (z. B. eine Koloskopie, Appendektomie, etc.). Dies ist in engem Zusammenhang mit dem Dokumententyp zu sehen, der in ClinicalDocument/code wiedergegeben ist. Mit der documentationOf Beziehung kann die dokumentierte
Gesundheitsdienstleistung näher spezifiziert werden. Dies darf natürlich nicht im Widerspruch zum Dokumententyp stehen.
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Code der Gesundheitsdienstleistung. Zugelassene nullFlavor: UNK Grundsätzlich sind die Vorgaben für „Codierungs-Elemente“ zu befolgen.
(Hea...ent)
hl7:effectiveTime
IVL_TS
1 … 1
M
Zeitraum der Gesundheitsdienstleistung.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
(Hea...ent)
hl7:low
TS
1 … 1
M
(Hea...ent)
hl7:high
TS
1 … 1
M
(Hea...ent)
hl7:performer
0 … *
Durchführende Entität(en) der Gesundheitsdienstleistung.
(Hea...ent)
hl7:assignedEntity
1 … 1
M
(Hea...ent)
Eingefügt
von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC)
hl7:id
II
1 … *
R
Mindestens eine Id der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...ent)
hl7:addr
AD
0 … 1
Ein Adress-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...ent)
hl7:telecom
TEL.AT
0 … *
Mindestens ein Telecom-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...ent)
hl7:assignedPerson
1 … 1
M
Persondendaten der validierenden Person.
(Hea...ent)
Eingefügt
von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
@classCode
cs
0 … 1
F
PSN
@determinerCode
cs
0 … 1
F
INSTANCE
hl7:name
PN
1 … 1
M
Name der Person
Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...ent)
hl7:representedOrganization
0 … 1
Organistationsdaten der validierenden Person.
(Hea...ent)
Eingefügt
von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
@classCode
0 … 1
F
ORG
@determinerCode
0 … 1
F
INSTANCE
hl7:id
II
0 … *
(Hea...ent)
hl7:name
ON
1 … 1
M
(Hea...ent)
hl7:telecom
TEL.AT
0 … *
(Hea...ent)
hl7:addr
AD
0 … 1
(Hea...ent)
Verweis auf speziellen Implementierungsleitfaden: serviceEvent Element Allgemein
Ob eine Gesundheitsdienstleistung angegeben werden muss, und welche Bedeutung dieses Element hat, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden. code
Welche Codierung angewandt werden soll, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden. effectiveTime
Welche Start- und Endezeiten eingetragen werden sollen, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden. performer
Ob und welche durchführende Entität eingetragen werden soll, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
effectiveTime
Hinweis: Für die automatisierte Datenübernahme aus dem CDA-Dokument in die XDS-Dokumentmetadaten ist stets ein Zeitintervall anzugeben.
1.6 Bezug zu vorgehenden Dokumenten
1.6.1 Allgemeines
Dieses Kapitel beschreibt die Versionsverwaltung von CDA-Dokumenten.
Der Bezug zu Vorgängerversionen von Dokumenten wird durch die relatedDocument-Beziehung und die ParentDocument-Klasse, zusammen mit setId und versionNumber aus der ClinicalDocument-Klasse (siehe Versionierung des Dokuments), spezifiziert.
Abbildung 16: Grundsätzlicher Aufbau eines CDA-Dokuments aus XML Sicht.
Der Bezug zum Vordokument wird dabei über die parentDocument Beziehung ausgedrückt, in dem der dazugehörige @typeCode einen Wert aus der Liste der gültigen @typeCodes in der relatedDocument-Beziehung erhält. Das Originaldokument, auf das sich das Dokument bezieht, bleibt dabei unverändert.
Liste der möglichen Werte der @typeCodes in der relatedDocument Beziehung:
code
displayName
Bedeutung
APND
append
Verwendung NICHT ERLAUBT Zusammenhängen von Dokumenten. Dies ist in ELGA bereits über das Einbetten von Dokumenten realisiert.
RPLC
replaces
Das Dokument ersetzt ein existierendes Dokument. Der Status des zu ersetzenden Dokumentes wird auf "überholt" gesetzt, das ursprüngliche Dokument bleibt aber noch im System als historische Referenz verfügbar.
XFRM
transformed
Verwendung NICHT ERLAUBT
Das Dokument ist Ergebnis eines Transformationsprozesses, d.h. ist aus einem anderen Originaldokument hervorgegangen.
Hinweis: Die parallele Ablage von CDA-Dokumenten, welche vom Dokumentersteller bereits mit einem Stylesheet zu einem PDF Dokument gerendert wurden, kann mit der XFRM – Transaktion vorgenommen werden.
Es ist nicht auszuschließen, dass die Transformation in lokalen Affiniy Domains Anwendung findet. Für ELGA ist die Transformation jedoch kein Anwendungsfall.
Der Bezug zu vorgehenden Dokumenten wird durch die relatedDocument-Beziehung und die ParentDocument-Klasse, zusammen mit setId und versionNumber aus der ClinicalDocument-Klasse, spezifiziert.
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.
(Hea...ent)
1.7 Einverständniserklärung
1.7.1 Autorisierung („authorization“)
In dieser optionalen Klasse können die Einverständniserklärungen reflektiert werden, die mit dem Dokument verbunden sind. Dies kann ein Einverständnis für einen Eingriff oder die Verfügbarmachung der Informationen gegenüber Dritten beinhalten. Der Typ der Einverständniserklärung wird dabei in Consent.code angegeben.
Auszug aus dem R-MIM:
Abbildung 17: Consent Klasse.
1.7.1.1 Spezifikation
Id
1.2.40.0.34.11.20012
ref
elgabbr-
Gültigkeit
2011‑12‑19
Status
Aktiv
Versions-Label
Name
HeaderAuthorization
Bezeichnung
HeaderAuthorization
Beschreibung
Der Einverständniserklärung ist derzeit ungenutzt. Dieses Element wird daher derzeit nicht angegeben.
In dieser optionalen Klasse können die Einverständniserklärungen reflektiert werden, die mit dem Dokument verbunden sind. Dies kann ein Einverständnis für einen Eingriff oder die Verfügbarmachung der Informationen gegenüber Dritten beinhalten. Der Typ der Einverständniserklärung wird dabei in Consent.code angegeben.
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Diese Klasse repräsentiert Informationen, in welchem Rahmen der Patientenkontakt, der dokumentiert wird, stattgefunden hat. Dokumente werden nicht notwendigerweise immer während eines Patientenkontakts erstellt, sondern ggf. auch zu einem späteren Zeitpunkt, wenn beispielsweise ein Arzt wegen eines pathologischen Laborwertes den Patienten vergeblich versucht zu erreichen und dennoch seine Verlaufsdokumentation fortführt.
Wenn die Dokumentation ein Entlass- oder Verlegungsdokument ist, muss die Information in dieser Klasse mitgegeben werden, inklusive der Dauer des Aufenthalts (hier: nicht nur stationäre Aufenthalte, sondern auch Patientenkontakt in der Praxis eines Niedergelassenen beispielsweise) und der Einrichtung, wo der Patientenaufenthalt stattfand.
Auszug aus dem R-MIM:
Abbildung 18: EncompassingEncounter Klasse und Umgebung.
1.8.1.1 Spezifikation
Id
1.2.40.0.34.11.20013
ref
elgabbr-
Gültigkeit
2011‑12‑19
Status
Aktiv
Versions-Label
Name
HeaderEncompassingEncounter
Bezeichnung
HeaderEncompassingEncounter
Beschreibung
Diese Klasse repräsentiert Informationen, in welchem Rahmen der Patientenkontakt, der dokumentiert wird, stattgefunden hat. Dokumente werden nicht notwendigerweise immer während eines Patientenkontakts erstellt, sondern ggf. auch zu einem späteren Zeitpunkt, wenn beispielsweise ein Arzt wegen eines pathologischen Laborwertes den Patienten vergeblich versucht
zu erreichen und dennoch seine Verlaufsdokumentation fortführt.
Wenn die Dokumentation ein Entlass- oder Verlegungsdokument ist, muss die Information in dieser Klasse mitgegeben werden, inklusive der Dauer des Aufenthalts (hier: nicht nur stationäre Aufenthalte, sondern auch Patientenkontakt in der Praxis eines Niedergelassenen beispielsweise) und der
Einrichtung, wo der Patientenaufenthalt stattfand.
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
<componentOf> <encompassingEncounter> <!-- Aufenthaltszahl --> <idroot="1.2.40.0.34.99.111.1.4"extension="Az123456"assigningAuthorityName="Amadeus Spital"/><!-- Codierung des Patientenkontakts --> <codecode="IMP"displayName="Inpatient encounter"codeSystem="2.16.840.1.113883.5.4"codeSystemName="HL7:ActCode"/><!-- Zeitraum des Patientenkontakts --> <effectiveTime> <lowvalue="20081224082015+0100"/><highvalue="20081225113000+0100"/></effectiveTime><!-- Verantwortliche Person für den Patientenkontakt --> <responsibleParty> <assignedEntity> <!-- Identifikation der Verantwortlichen Person für den Patientenkontakt--> <idroot="1.2.40.0.34.99.111.1.3"extension="2222"assigningAuthorityName="Amadeus Spital"/><!-- Kontaktdaten der Verantwortlichen Person für den Patientenkontakt --> <telecomuse="WP"value="tel:+43.6138.3453446.2222"/><!-- Personendaten der Verantwortlichen Person für den Patientenkontakt --> <assignedPerson> <!-- Name der Verantwortlichen Person für den Patientenkontakt --> <name> <prefix>Univ.-Prof.Dr.</prefix><given>Sigrid</given><family>Kollmann</family></name></assignedPerson></assignedEntity></responsibleParty><!-- Organisation, in deren Verantwortungsbereich der Patientenkontakt stattfand --> <location> <healthCareFacility> <serviceProviderOrganization> <!-- ID der Organisation aus dem GDA Index --> <idroot="1.2.40.0.34.99.3"assigningAuthorityName="GDA Index"/><!-- Name der Organisation --> <name>Amadeus Spital - Chirurgische Abteilung</name><!-- Kontaktdaten der Organisation --> <telecomvalue="tel:+43.6138.3453446.0"/><telecomvalue="fax:+43.6138.3453446.4674"/><telecomvalue="mailto:info@amadeusspital.at"/><telecomvalue="http://www.amadeusspital.at"/><!-- Adresse der Organisation --> <addr> <streetName>Mozartgasse</streetName><houseNumber>1-7</houseNumber><postalCode>5350</postalCode><city>St.Wolfgang</city><state>Salzburg</state><country>AUT</country></addr></serviceProviderOrganization></healthCareFacility></location></encompassingEncounter></componentOf>
Item
DT
Kard
Konf
Beschreibung
Label
hl7:componentOf
Komponente für den Patientenkontakt.
(Hea...ter)
elgagab-dataelement-156
Patientenkontakt
Datensatz
@typeCode
cs
0 … 1
F
COMP
hl7:encompassingEncounter
1 … 1
R
Patientenkontakt.
(Hea...ter)
@classCode
cs
0 … 1
F
ENC
@moodCode
cs
0 … 1
F
EVN
hl7:id
II
0 … 1
Identifikationselement zur Aufnahme der Aufenthaltszahl.
(Hea...ter)
hl7:code
CE
1 … 1
M
Codierung des Patientenkontakts.
(Hea...ter)
CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.5 ELGA_ActEncounterCode (DYNAMIC)
hl7:effectiveTime
IVL_TS
1 … 1
M
Zeitraum des Patientenkontakts.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
(Hea...ter)
hl7:low
TS.DATE.MIN
1 … 1
R
(Hea...ter)
hl7:high
TS.DATE.MIN
0 … 1
(Hea...ter)
hl7:responsibleParty
0 … 1
Komponente für die verantwortliche Person.
(Hea...ter)
hl7:assignedEntity
1 … 1
M
Entität der verantwortlichen Person.
Grundsätzlich sind die Vorgaben für „AssignedEntity-Element (Person + Organisation)“ zu befolgen.
(Hea...ter)
Eingefügt
von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC)
hl7:id
II
1 … *
R
Mindestens eine Id der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...ter)
hl7:addr
AD
0 … 1
Ein Adress-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...ter)
hl7:telecom
TEL.AT
0 … *
Mindestens ein Telecom-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...ter)
hl7:assignedPerson
1 … 1
M
Persondendaten der validierenden Person.
(Hea...ter)
Eingefügt
von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
@classCode
cs
0 … 1
F
PSN
@determinerCode
cs
0 … 1
F
INSTANCE
hl7:name
PN
1 … 1
M
Name der Person
Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...ter)
hl7:representedOrganization
0 … 1
Organistationsdaten der validierenden Person.
(Hea...ter)
Eingefügt
von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
@classCode
0 … 1
F
ORG
@determinerCode
0 … 1
F
INSTANCE
hl7:id
II
0 … *
(Hea...ter)
hl7:name
ON
1 … 1
M
(Hea...ter)
hl7:telecom
TEL.AT
0 … *
(Hea...ter)
hl7:addr
AD
0 … 1
(Hea...ter)
Eingefügt
1 … 1
M
von 1.2.40.0.34.11.90006 Encounter Location 1 (DYNAMIC)
Verweis auf speziellen Implementierungsleitfaden:
Ob der Patientenkontakt angegeben werden muss, und welche Bedeutung dieses Element hat ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
1.8.1.1.2 id
Grundsätzlich sind die Vorgaben gemäß Kapitel „id-Element II“ zu befolgen.
Verweis auf speziellen Implementierungsleitfaden:
Ob, und welche Identifikation eingetragen werden soll ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
1.8.1.1.3 code
Grundsätzlich sind die Vorgaben gemäß Kapitel „code-Element CE CWE“ zu befolgen.
Verweis auf speziellen Implementierungsleitfaden:
Welche Codierung angewandt werden soll, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
1.8.1.1.4 effectiveTime
Verweis auf speziellen Implementierungsleitfaden:
Welche Start- und Endezeiten eingetragen werden sollen, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
1.8.1.1.5 responsibleParty
Die verantwortliche Person für den Patientenkontakt (Aufenthalt) KANN optional angegeben werden.
Verweis auf speziellen Implementierungsleitfaden:
Die konkrete Bedeutung der verantwortlichen Person für den Patientenkontakt (Aufenthalt) und eine ggf. verpflichtende Angabe dieses Elements ergeben sich aus dem jeweiligen speziellen Implementierungsleitfaden.
1.8.1.1.6 location
Die Organisation, in deren Verantwortungsbereich der Patientenkontakt stattfand, MUSS verpflichtend angegeben werden (z.B.: die entlassende Krankenanstalt mit Abteilung).
Verweis auf speziellen Implementierungsleitfaden:
Die konkrete Bedeutung der Organisation, in deren Verantwortungsbereich der Patientenkontakt (Aufenthalt) stattfand, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.