Folgende Elemente erfordern keine speziellen Vorgaben:
XML Metainformationen
Wurzelelement
Hoheitsbereich („realmCode“)
Dokumentformat („typeId“)
Dokumenten-Id („id”)
Erstellungsdatum des Dokuments („effectiveTime“)
Vertraulichkeitscode („confidentialityCode“)
Sprachcode des Dokuments („languageCode“)
Verweis auf den Allgemeinen Leitfaden:
Die Elemente erfordern keine speziellen Vorgaben. Es gelten die Vorgaben der entsprechenden Kapitel des „Allgemeinen Implementierungsleitfadens“.
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.1.3 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.
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.
1.1.7 Erstellungsdatum des Dokuments („effectiveTime“)
1.1.7.1 Spezifikation
Id
1.2.40.0.34.11.90008
ref
elgabbr-
Gültigkeit ab
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)
Mit Angabe dieses Elements wird ausgesagt, dass das vorliegende CDA-Dokument zu diesem Implementierungsleitfaden konform ist. Ein Dokument, welches dem vorliegenden Implementierungsleitfaden folgt, muss auch dem übergeordneten „Allgemeinen Implementierungsleitfaden“ folgen.
1.1.10.1.1 Spezielle Vorgaben für Entlassungsbriefe (Pflege)
Die templateId-Elemente für diesen Implementierungsleitfaden sind anzugeben.
1.1.10.1.2 Strukturbeispiel
<ClinicalDocument xmlns="urn:hl7-org:v3">
:
<!-- ELGA CDA Dokumente -->
<templateId root="1.2.40.0.34.11.1"/>
<!-- ELGA CDA Entlassungsbrief (Pflege) -->
<templateId root="1.2.40.0.34.11.3"/>
<!--
In Abhängigkeit von der ELGA Interoperabilitätsstufe (EIS)
-->
<!-- EIS „Basic” -->
<templateId root="1.2.40.0.34.11.3.0.1"/>
... oder ...
<!-- EIS „Enhanced” -->
<templateId root="1.2.40.0.34.11.3.0.2"/>
... oder ...
<!-- EIS „Full support” -->
<templateId root="1.2.40.0.34.11.3.0.3"/>
:
</ClinicalDocument>
1.1.10.1.3 Spezifikation
Element/Attribut
DT
Kard
Konf
Beschreibung
templateId
II
1..1
M
ELGA TemplateId für den Allgemeinen Implementierungsleitfaden Fester Wert: @root = 1.2.40.0.34.11.1
templateId
II
1..1
M
ELGA TemplateId für den speziellen Implementierungsleitfaden Entlassungsbrief (Pflege) Fester Wert: @root = 1.2.40.0.34.11.3
--- zusätzlich eine der folgenden templateIds ---
Im Falle von EIS „Basic“
(Das Dokument enthält entweder unstrukturierten oder eingebetteten Inhalt (z.B. PDF) oder enthält strukturierten Inhalt, wobei jedoch nicht alle Sektionen den Vorgaben von EIS „Enhanced“ oder höher folgen)
(Alle Sektionen folgen ausnahmslos den Vorgaben von EIS „Full support“)
templateId
II
1..1
M
ELGA CDA Entlassungsbrief (Pflege) in EIS „Full support“ Fester Wert @root = 1.2.40.0.34.11.3.0.3
1.1.10.2 Titel des Dokuments („title“)
Der Titel des Dokuments ist für den lesenden Dokumentempfänger das sichtbare Element. Dieser wird nicht dem Attribut displayName des Elements code entnommen, sondern dem (verpflichtenden) Element title.
1.1.10.2.1 Spezielle Vorgaben für Entlassungsbriefe (Pflege)
Da Entlassungsdokumente in ihrem code-Element nicht zwischen „vorläufigen“ oder „endgültigen“ Fassungen von Entlassungsbriefen unterscheiden, soll der Titel auch die darüberhinausgehende Zusatzinformation, wie „vorläufig“ o.ä. beinhalten. Siehe hierzu auch Kapitel „Dokumentenklasse (“code”)“. Auch „vorläufige“ Entlassungsbriefe müssen freigegeben („vidiert“) werden (siehe Weitere Beteiligte).
Als Titel ist eine Formulierung zu wählen, die „Entlassungsbrief“ und „Pflege“ enthält.
Kann zusätzlich Hinweise zum Dokumentstatus („vorläufig“, …) oder Abteilungen inkludieren.
Beispiele:
„Pflegerischer Entlassungsbrief“
„Entlassungsbrief Pflege“
Pflege-Entlassungsbrief der gynäkologischen Abteilung“
„Pflege-Entlassungsbrief der chirurgischen Abteilung“
Bei den in der österreichischen Praxis entstehenden Entlassungsdokumenten wird grundsätzlich zwischen endgültigen Entlassungsbriefen und vorläufigen Entlassungsbriefen unterschieden. Des Weiteren werden auch fachbezogene Entlassungsbriefe (z.B.: „Entlassungsbrief der gynäkologischen Abteilung“) ausgegeben.
1.1.10.3.1 Spezielle Vorgaben für Entlassungsbriefe (Pflege)
Alle Pflege-Entlassungsdokumente aus dem stationären Bereich werden unabhängig von Inhalt, ausstellender Abteilung oder Status (z.B. „vorläufig“ oder „abgeschlossen“) mit dem folgenden LOINC Code codiert:
Folgende Elemente erfordern keine speziellen Vorgaben:
Verfasser des Dokuments („author“)
Personen bei der Dateneingabe („dataEnterer“)
Verwahrer des Dokuments („custodian“)
Beabsichtigte Empfänger des Dokuments („informationRecipient“)
Weitere Unterzeichner („authenticator“)
Verweis auf den Allgemeinen Leitfaden:
Die Elemente erfordern keine speziellen Vorgaben. Es gelten die Vorgaben der entsprechenden Kapitel des „Allgemeinen Implementierungsleitfadens“.
Auszug aus dem Allgemeinen Implementierungsleitfaden
1.2.2 Verfasser des Dokuments („author“)
Auszug aus dem R-MIM:
Abbildung 8: Klassen rund um den Autor.
1.2.2.1 Spezifikation
Id
1.2.40.0.34.11.20002
ref
elgabbr-
Gültigkeit ab
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.
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.
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
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
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.
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.
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.
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.
hl7:assignedAuthoringDevice
… 1
@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.
hl7:softwareName
SC
1 … 1
R
Bezeichnung (und ggf Version) der datenerstellenden Software.
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.
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.
hl7:assignedEntity
1 … 1
R
Personendaten der schreibenden Person
Grundsätzlich sind die Vorgaben für „AssignedEntity-Element (Person + Organisation)“ zu befolgen.
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
hl7:addr
AD
0 … 1
Ein Adress-Element der validierenden Person.
Zugelassene nullFlavor: UNK
hl7:telecom
TEL.AT
0 … *
Mindestens ein Telecom-Element der validierenden Person.
Zugelassene nullFlavor: UNK
hl7:assignedPerson
1 … 1
M
Persondendaten der validierenden Person.
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.
hl7:representedOrganization
0 … 1
Organistationsdaten der validierenden Person.
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 … *
hl7:name
ON
1 … 1
M
hl7:telecom
TEL.AT
0 … *
hl7:addr
AD
0 … 1
1.2.4 Verwahrer des Dokuments („custodian“)
Auszug aus dem R-MIM:
Abbildung 9: Klassen rund um die das Dokument verwaltende Organisation.
1.2.4.1 Spezifikation
Id
1.2.40.0.34.11.20004
ref
elgabbr-
Gültigkeit ab
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
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.
hl7:telecom
TEL.AT
0 … 1
Kontaktdaten des Verwahrers des Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Kontaktdaten-Elemente“ zu befolgen.
hl7:addr
AD
1 … 1
M
Adresse des Verwahrers des Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.
1.2.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.2.5 Beabsichtigte Empfänger des Dokuments („informationRecipient“)
Auszug aus dem R-MIM:
Abbildung 10: Klassen rund um die beabsichtigten Empfänger des Dokuments.
1.2.5.1 Spezifikation
Id
1.2.40.0.34.11.20005
ref
elgabbr-
Gültigkeit ab
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.
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
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.
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.
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.
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 … *
hl7:name
ON
1 … 1
M
hl7:telecom
TEL.AT
0 … *
hl7:addr
AD
0 … 1
1.2.6 Weitere Unterzeichner („authenticator“)
1.2.6.1 Spezifikation
Id
1.2.40.0.34.11.20007
ref
elgabbr-
Gültigkeit ab
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>
In dem Fall, dass der Patient nicht zuhause gepflegt werden kann, kann im Pflege-Entlassungsbrief die Angabe einer „Pflege-Adresse“ notwendig werden.
1.2.7.1.1 Spezielle Vorgaben für Entlassungsbriefe (Pflege)
Die Angabe einer Pflege-Adresse des Patienten hat in Form eines zusätzlichenaddr-Elements zu erfolgen, welche mit dem @use Attribut „TMP“ gekennzeichnet ist.
Im Pflege-Entlassungsbrief ist verpflichtend die Angabe eines „Ansprechpartners“ vorgesehen. Dieser ist mit vollständiger Kontaktadresse inklusive Telefonnummer anzugeben.
Zweck dieser Information ist es, etwaige Anfragen der Dokumentempfänger an den Dokumentersteller zu kanalisieren. Es obliegt der Organisation des Dokumenterstellers, diese Information gemäß ihrer eigenen Richtlinien zu befüllen.
1.2.7.2.1 Spezielle Vorgaben für Entlassungsbriefe (Pflege)
1.2.7.2.1.1 Änderung 1: Konformitäten der Beteiligten geändert
Die Konformitäten der Beteiligten sind wie folgt geändert:
Kard
Konf
Art des Beteiligten
1..1
[M]
Rechtlicher Unterzeichner (legalAuthenticator)
1..1
[M]
Fachlicher Ansprechpartner
0..1
[R2]
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
1.3 Dokumentation der Gesundheitsdienstleistung
1.3.1 Service Events („documentationOf/serviceEvent“)
Da die angegebenen Gesundheitsdienstleistungen in die XDS-Metadaten übernommen werden, stellen sie die einzigen (rein) medizinischen Informationen zum Dokument im Dokumentenregister dar. Sie können daher in Folge für Suche und Filterung verwendet werden, und erleichtern mitunter die Navigation in der Krankengeschichte des Patienten.
Verweis auf den Allgemeinen Leitfaden (mit Anpassungen):
Das Element ist grundsätzlich gemäß den Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“ anzugeben, es sind jedoch spezielle Vorgaben vorgeschrieben.
Auszug aus dem Allgemeinen Implementierungsleitfaden
1.4 Dokumentation der Gesundheitsdienstleistung
1.4.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.4.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 ab
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.
hl7:effectiveTime
IVL_TS
1 … 1
M
Zeitraum der Gesundheitsdienstleistung.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
hl7:low
TS
1 … 1
M
hl7:high
TS
1 … 1
M
hl7:performer
0 … *
Durchführende Entität(en) der Gesundheitsdienstleistung.
hl7:assignedEntity
1 … 1
M
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
hl7:addr
AD
0 … 1
Ein Adress-Element der validierenden Person.
Zugelassene nullFlavor: UNK
hl7:telecom
TEL.AT
0 … *
Mindestens ein Telecom-Element der validierenden Person.
Zugelassene nullFlavor: UNK
hl7:assignedPerson
1 … 1
M
Persondendaten der validierenden Person.
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.
hl7:representedOrganization
0 … 1
Organistationsdaten der validierenden Person.
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 … *
hl7:name
ON
1 … 1
M
hl7:telecom
TEL.AT
0 … *
hl7:addr
AD
0 … 1
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.4.1.2 Spezielle Vorgaben für Entlassungsbriefe (Pflege)
Die Sinnhaftigkeit und der Nutzen von angegebenen Gesundheitsdienstleistungen hängen entscheidend von der eingesetzten Codeliste ab. Automatisierte Codierung durch Eintrag der ohnehin vorhandenen MEL-Elemente2 kann derzeit zwar von den Dokumenterstellern geliefert werden, wurde aber von den Dokumentempfängern als zu wenig aussagekräftig erachtet.
Es wird der fixe Wert „GDLSTATAUF“ („Gesundheitsdienstleistung im Rahmen eines stationären Aufenthalts“) aus der Codeliste „ELGA_ServiceEventsEntlassbrief“ angegeben.
Als Zeitangabe MUSS der Zeitraum des Aufenthalts (Aufnahme bis Entlassung) angegeben werden. Als Zeitpunkt der Entlassung SOLL der Zeitpunkt der administrativen Entlassung angegeben werden. Alternativ darf auch der Zeitpunkt der medizinischen Entlassung angegeben werden.
ACHTUNG: Diese Zeitangaben werden in die Dokument-Metadaten übernommen!
Die Bedeutung der Dokument-Metadaten-Elemente lautet daher wie folgt:
serviceStartTime: Aufnahme des Patienten in den stationären Aufenthalt
serviceStopTime: Entlassung des Patienten aus dem stationären Aufenthalt
2 Katalog Medizinischer Einzelleistungen
1.4.1.3 Strukturbeispiel
<documentationOf>
<serviceEvent>
<code code="GDLSTATAUF"
displayName="Gesundheitsdienstleistung im Rahmen eines stationären Aufenthalts"
codeSystem="1.2.40.0.34.5.21"
codeSystemName="ELGA_ServiceEventsEntlassbrief" />
<effectiveTime>
<low value="<Zeitpunkt der Aufnahme>"/>
<high value="<Zeitpunkt der Entlassung>"/>
</effectiveTime>
</serviceEvent>
</documentationOf>
Konformität geändert auf [M]. Kardinalität geändert auf 1..1.
Element/Attribut
DT
Kard
Konf
Beschreibung
documentationOf
POCD_MT000040.DocumentationOf
1..1
M
Komponente für die Gesundheitsdienstleistung
serviceEvent
POCD_MT000040.ServiceEvent
1..1
M
Gesundheitsdienstleistung
1.4.1.4.2 Änderung 2: code
Es wird der fixe Wert „GDLSTATAUF“ („Gesundheitsdienstleistung im Rahmen eines stationären Aufenthalts“) angegeben.
Element/Attribut
DT
Kard
Konf
Beschreibung
code
CE CWE
1..1
M
Code der Gesundheitsdienstleistung
@code
cs
1..1
M
Fester Wert: GDLSTATAUF
@displayName
st
1..1
M
Fester Wert: Gesundheitsdienstleistung im Rahmen eines stationären Aufenthalts
@codeSystem
uid
1..1
M
Fester Wert: 1.2.40.0.34.5.21
@codeSystemName
st
1..1
M
Fester Wert: ELGA_ServiceEventsEntlassbrief
1.4.1.4.3 Änderung 3: effectiveTime
Als Zeitangabe MUSS der Zeitraum des Aufenthalts angegeben werden.
Der Zeitraum des Aufenthalts erstreckt sich vom
Zeitpunkt der Aufnahme in den stationären Aufenthalt
bis zum
Zeitpunkt der Entlassung aus dem stationären Aufenthalt.
Hinweis: Als Zeitpunkt der Entlassung SOLL der Zeitpunkt der administrativen Entlassung angegeben werden. Alternativ darf auch der Zeitpunkt der medizinischen Entlassung angegeben werden.
1.4.1.4.4 Änderung 4: performer
Es wird keine durchführende Entität der Gesundheitsdienstleistung angegeben.
Element/Attribut
DT
Kard
Konf
Beschreibung
performer
POCD_MT000040.Performer1
0..0
NP
Durchführende Entität der Gesundheitsdienstleistung
1.5 Bezug zu vorgehenden Dokumenten
Verweis auf den Allgemeinen Leitfaden:
Das Element erfordert keine speziellen Vorgaben. Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“.
Auszug aus dem Allgemeinen Implementierungsleitfaden
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.
1.7 Einverständniserklärung
Verweis auf den Allgemeinen Leitfaden:
Das Element erfordert keine speziellen Vorgaben. Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“.
Auszug aus dem Allgemeinen Implementierungsleitfaden
1.8 Einverständniserklärung
1.8.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.8.1.1 Spezifikation
Id
1.2.40.0.34.11.20012
ref
elgabbr-
Gültigkeit ab
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)
Verweis auf den Allgemeinen Leitfaden (mit Anpassungen):
Es gelten die Vorgaben der entsprechenden Kapitel des „Allgemeinen Implementierungsleitfadens“ mit folgenden Änderungen:
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.10.1.1 Spezifikation
Id
1.2.40.0.34.11.20013
ref
elgabbr-
Gültigkeit ab
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.
elgagab-dataelement-156
Patientenkontakt
Datensatz
@typeCode
cs
0 … 1
F
COMP
hl7:encompassingEncounter
1 … 1
R
Patientenkontakt.
@classCode
cs
0 … 1
F
ENC
@moodCode
cs
0 … 1
F
EVN
hl7:id
II
0 … 1
Identifikationselement zur Aufnahme der Aufenthaltszahl.
hl7:code
CE
1 … 1
M
Codierung des Patientenkontakts.
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.
hl7:low
TS.DATE.MIN
1 … 1
R
hl7:high
TS.DATE.MIN
0 … 1
hl7:responsibleParty
0 … 1
Komponente für die verantwortliche Person.
hl7:assignedEntity
1 … 1
M
Entität der verantwortlichen Person.
Grundsätzlich sind die Vorgaben für „AssignedEntity-Element (Person + Organisation)“ zu befolgen.
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
hl7:addr
AD
0 … 1
Ein Adress-Element der validierenden Person.
Zugelassene nullFlavor: UNK
hl7:telecom
TEL.AT
0 … *
Mindestens ein Telecom-Element der validierenden Person.
Zugelassene nullFlavor: UNK
hl7:assignedPerson
1 … 1
M
Persondendaten der validierenden Person.
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.
hl7:representedOrganization
0 … 1
Organistationsdaten der validierenden Person.
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 … *
hl7:name
ON
1 … 1
M
hl7:telecom
TEL.AT
0 … *
hl7:addr
AD
0 … 1
Eingefügt
1 … 1
M
von 1.2.40.0.34.11.90006 Encounter Location 1 (DYNAMIC)
1.10.1.1.1 encompassingEncounter Element Allgemein
Verweis auf speziellen Implementierungsleitfaden:
Ob der Patientenkontakt angegeben werden muss, und welche Bedeutung dieses Element hat ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
1.10.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.10.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.10.1.1.4 effectiveTime
Verweis auf speziellen Implementierungsleitfaden:
Welche Start- und Endezeiten eingetragen werden sollen, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
1.10.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.10.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.
1.10.1.2 Spezielle Vorgaben für Entlassungsbriefe (Pflege)
Das Element für den Patientenkontakt erhält im Rahmen der „Entlassungsbriefe“ derzeit die Bedeutung des „Stationären Aufenthalts“.
Identifikationselement zur Aufnahme der Aufenthaltszahl. Zugelassene nullFlavor:
NI … Patient hat keine Aufenthaltszahl
UNK … Patient hat eine Aufenthaltszahl, diese ist jedoch unbekannt
@root
uid
1..1
M
OID der Liste der Aufenthaltszahlen der Organisation
@extension
st
1..1
M
Aufenthaltszahl
@assigningAuthorityName
st
0..1
O
Name der Stelle, welche die ID zugewiesen hat z.B.: „Amadeus Spital“
1.10.1.4.3 Änderung 3: code
Die derzeitige Fassung des Implementierungsleitfadens berücksichtigt nur die Entlassung aus dem stationären Bereich. Als Code ist derzeit fix „IMP“ anzugeben.
Element/Attribut
DT
Kard
Konf
Beschreibung
code
CE CWE
1..1
M
Codierung des Patientenkontakts
@code
cs
1..1
M
Fester Wert: IMP
@displayName
st
1..1
M
Fester Wert: inpatient encounter
@codeSystem
uid
1..1
M
Fester Wert: 2.16.840.1.113883.5.4
@codeSystemName
st
1..1
M
Fester Wert: HL7:ActCode
originalText
ED
0..1
O
Textinhalt, der codiert wurde.<b/> z.B.: Stationärer Aufenthalt
1.10.1.4.4 Änderung 4: effectiveTime
Als Zeitangabe MUSS der Zeitraum des Aufenthalts angegeben werden.
Der Zeitraum des Aufenthalts erstreckt sich vom
Zeitpunkt der Aufnahme in den stationären Aufenthalt
bis zum
Zeitpunkt der Entlassung aus dem stationären Aufenthalt.
Hinweis: Als Zeitpunkt der Entlassung SOLL der Zeitpunkt der administrativen Entlassung angegeben werden. Alternativ darf auch der Zeitpunkt der medizinischen Entlassung angegeben werden.
1.10.1.4.5 Änderung 5: responsibleParty
Konformität geändert auf [R2]. 1.2.40.0.34.11.3 1.2.40.0.34.11.2
Als verantwortliche Person ist
im Falle einer Entlassung aus einer Abteilung eines Krankenhauses, der Vorstand der entlassenden Abteilung
oder
im Falle einer Entlassung aus einer eigenständigen Organisation, die (gesetzliche) pflegerische Leitung der Organisation anzugeben.
Element/Attribut
DT
Kard
Konf
Beschreibung
responsibleParty
POCD_MT000040.ResponsibleParty
0..1
R2
Komponente für die verantwortliche Person.
assignedEntity
POCD_MT000040.AssignedEntity
1..1
M
Entität der verantwortlichen Person. Gemäß Vorgaben im „Allgemeinen Implementierungsleitfaden“, Kapitel „AssignedEntity-Element“.
1.10.1.4.6 Änderung 6: location
Die „Organisationsdaten des Aufenthalts“ MÜSSEN die entlassende Organisation darstellen.
Granularität des Organisation-Elements der entlassenden Organisation:
id
Konformität geändert auf [R].
Mindestanforderung:
ID aus dem GDA-Index
Zugelassene nullFlavor:
NI … Organisation hat keine ID aus dem GDA-Index
UNK … Organisation hat eine ID aus dem GDA-Index, diese ist jedoch unbekannt