Palliativdokumentation

Aus Hl7wiki
Implementierungsleitfaden
Wechseln zu: Navigation, Suche


Inhaltsverzeichnis

Palliativdokumentation

Cdapd:Ansprechpartner und Autoren Cdapd:Einleitung Cdapd:Dynamisches Modell Cdapd:Dokumenttypen Cdapd:Datentypen


Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

CDA-Header-Assoziationen

Der Header umfasst neben bereits aufgelisteten einfachen Metadaten noch folgende Beziehungen, diese sind hier der Übersicht halber aufgelistet. Die Verwendung im Arztbrief wird unter Arztbriefstruktur aufgelistet und deren genauen Details später noch genauer spezifiziert.

CDA-Header-Assoziationen
Element (Sequenz) Bedeutung
Participations
recordTarget Patient
author Autor / Urheber
dataEnterer Datentypist
informant Informant
custodian verwaltende Organisation
informationRecipient Empfänger
legalAuthenticator vor dem Gesetz verantwortlicher Unterzeichner
authenticator weitere Unterzeichner
participant Beteiligte
Act Relationships
inFulfillmentOf In Erfüllung von, –noch nicht verwendet–
documentationOf Dokumentierte Gesundheitsdienstleistung, –noch nicht verwendet–
relatedDocument Bezug zu vorhergehenden Dokumenten
authorization Einverständniserklärung
componentOf Informationen zum Patientenkontakt

[Tabelle 1] CDA-Header-Assoziationen

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Patient (recordTarget - generisch)

Id1.2.276.0.76.10.2001Gültigkeit2013‑07‑10
StatusKgreen.png AktivVersions-Label
NameHeader​Record​TargetBezeichnungCDA recordTarget
Beschreibung
Das recordTarget repräsentiert die Person, über die dokumentiert wird. recordTarget umfasst neben der Identifikation und dem Namen, Geschlecht, Adressen etc. auch optionale Zusatzangaben wie zum Beispiel Geburtsort und Sprachfähigkeiten.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.276.0.76.10.90030InklusionKgreen.png PersonennameDYNAMIC
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.101 CDA recordTarget (DYNAMIC)
ref
ad1bbr-
Beispiel
Standard-Beispiel
<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    <id root="2.16.840.1.113883.3.37.6.2.23.3" extension="12345"/>    <addr use="HP">
      <streetName>Musterstraße</streetName>      <houseNumber>15</houseNumber>      <postalCode>50825</postalCode>      <city>Köln</city>    </addr>
    <telecom use="HP" value="tel:+49(221)7812220"/>    <patient classCode="PSN" determinerCode="INSTANCE">
      <name>
        <given>Marie</given>        <family>Müller</family>      </name>
      <administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>      <birthTime value="19700924"/>      <birthplace>
        <place>
          <addr>
            <city>Köln</city>          </addr>
        </place>
      </birthplace>
    </patient>
  </patientRole>
</recordTarget>
Beispiel
Maximal-Beispiel
<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    <id root="2.16.840.1.113883.3.37.6.2.23.3" extension="12345"/>    <id root="1.2.276.0.76.4.8" extension="8003004447"/>    <addr use="HP">
      <streetName>Musterstraße</streetName>      <houseNumber>15</houseNumber>      <postalCode>50825</postalCode>      <city>Köln</city>    </addr>
    <telecom use="HP" value="tel:+49(221)7812220"/>    <telecom use="HP" value="mailto:MuellerMar@gmx.de"/>    <patient classCode="PSN" determinerCode="INSTANCE">
      <name>
        <given>Marie</given>        <family>Müller</family>      </name>
      <administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>      <birthTime value="19700924"/>      <!-- Familienstand des Patienten -->
      <maritalStatusCode code="M" displayName="Married" codeSystem="2.16.840.1.113883.5.2" codeSystemName="HL7 MaritalStatusCode"/>      <!-- Religionszugehörigkeit des Patienten-->
      <religiousAffiliationCode code="1077" displayName="Protestant" codeSystem="2.16.840.1.113883.5.1076"/>      <!-- Vormund/Sachwalter des Patienten -->
      <guardian>
        <addr use="HP">
          <streetName>Musterstraße</streetName>          <houseNumber>15</houseNumber>          <postalCode>50825</postalCode>          <city>Köln</city>        </addr>
        <telecom use="HP" value="..."/>        <guardianPerson>
          <name>
            <given>Marius</given>            <family>Müller</family>          </name>
        </guardianPerson>
      </guardian>
      <birthplace>
        <place>
          <addr>
            <city>Köln</city>          </addr>
        </place>
      </birthplace>
      <languageCommunication>
        <languageCode code="EN"/>        <modeCode code="ESP"/>        <proficiencyLevelCode code="G"/>        <preferenceInd value="true"/>      </languageCommunication>
    </patient>
  </patientRole>
</recordTarget>
Beispiel
Minimal-Beispiel
<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    <id root="2.16.840.1.113883.3.37.6.2.23.3" extension="12345"/>  </patientRole>
</recordTarget>
ItemDTKardKonfBeschreibungLabel
hl7:recordTarget
(Hea...get)
Treetree.png@typeCode
0 … 1FRCT
Treetree.png@context​Control​Code
0 … 1FOP
 Beispiel<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    <!-- ... -->
  </patientRole>
</recordTarget>
Treetree.pnghl7:patientRole
1 … 1(Hea...get)
Treeblank.pngTreetree.png@classCode
0 … 1FPAT
 Beispiel<patientRole classCode="PAT">
  <id extension="186245" root="1.2.276.0.76.3.1.139.3.871"/>  <patient classCode="PSN" determinerCode="INSTANCE">
    <!-- ... -->
  </patient>
</patientRole>
Treeblank.pngTreetree.pnghl7:id
II1 … *(Hea...get)
 Beispiel<id extension="6245" root="2.16.840.1.113883.3.933"/><id extension="1543627549" root="1.2.276.0.76.4.1"/>
Treeblank.pngTreetree.pnghl7:addr
AD0 … *Adresse des Patienten(Hea...get)
 Beispiel<addr use="HP">
  <streetName>Dorfstraße</streetName>  <houseNumber>54</houseNumber>  <postalCode>51371</postalCode>  <city>Leverkusen</city></addr>
Treeblank.pngTreetree.pnghl7:telecom
TEL0 … *Kontaktdaten des Patienten(Hea...get)
 Beispiel<telecom use="H" value="tel:+4930140400"/><telecom use="MC" value="tel:+492211234567"/><telecom value="mailto:herberthannes.mustermann@provider.de"/>
Treeblank.pngTreetree.pnghl7:patient
0 … 1(Hea...get)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
 Beispiel<patient classCode="PSN" determinerCode="INSTANCE">
  <name>
    <!-- ... -->
  </name>
  <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>  <birthTime value="19541223"/></patient>
Eingefügt1 … 1M von 1.2.276.0.76.10.90030 Personenname (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1MDie Reihenfolge der Namensbestandteile soll der typischen Schreibweise entsprechen. Zu beachten ist, dass prefix- und suffix-Elemente mit einem Leerzeichen enden müssen, wenn sie nicht unmittelbar an den folgenden Namensbestandteil anschließen sollen.
(Hea...get)
 Beispiel
Dr. med. Sine Johanna Gräfin von Oberberg
<name>
  <prefix qualifier="AC">Dr. med. </prefix>  <given>Sine Johanna</given>  <prefix qualifier="NB">Gräfin </prefix>  <prefix qualifier="VV">von </prefix>  <family>Oberberg</family></name>
 Beispiel
Prof. Dr. med. Dr. rer. nat. Fritz Julius Karl Freiherr von und zu Rathenburg vor der Isar, MdB
<name>
  <prefix qualifier="AC">Prof. Dr. med. Dr. rer. nat. </prefix>  <given>Fritz</given>  <given>Julius</given>  <given>Karl</given>  <prefix qualifier="NB">Freiherr </prefix>  <prefix qualifier="VV">von und zu </prefix>  <family>Rathenburg vor der
Isar
</family>
  <suffix>, MdB</suffix></name>
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
ENXP0 … *Titel(Hea...get)
wo [@qualifier='AC']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
set_cs1 … 1FAC
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:given
ENXP0 … *Vorname(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
ENXP0 … *Namenszusatz(Hea...get)
wo [@qualifier='NB']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
set_cs1 … 1FNB
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
ENXP0 … *Vorsatzwort(Hea...get)
wo [@qualifier='VV']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
set_cs1 … 1FVV
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:family
ENXP0 … *Nachname(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:suffix
ENXP0 … *Suffix(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:administrative​Gender​Code
CE1 … 1RGeschlecht (administrativ) des Patienten(Hea...get)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.1 Administrative Gender (HL7 V3) (DYNAMIC)
 Beispiel<administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>
Treeblank.pngTreeblank.pngTreetree.pnghl7:birthTime
TS.​DATE.​MIN1 … 1RGeburtsdatum des Patienten(Hea...get)
 Beispiel<birthTime value="19491224"/>
Treeblank.pngTreeblank.pngTreetree.pnghl7:marital​Status​Code
CE0 … 1Familienstand des Patienten(Hea...get)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.12212 Marital Status (DYNAMIC)
 Beispiel<maritalStatusCode code="S" displayName="Never Married" codeSystem="2.16.840.1.113883.5.2"/>
Treeblank.pngTreeblank.pngTreetree.pnghl7:religious​Affiliation​Code
CE0 … 1Religionszugehörigkeit des Patienten(Hea...get)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.19185 Religious Affiliation (DYNAMIC)
 Beispiel<religiousAffiliationCode code="1077" displayName="Protestant" codeSystem="2.16.840.1.113883.5.1076"/>
Treeblank.pngTreeblank.pngTreetree.pnghl7:raceCode
NPdarf nicht verwendet werden(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:ethnic​Group​Code
NPdarf nicht verwendet werden(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:guardian
0 … *Vormund/Sachwalter des Patienten(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(Hea...get)
Auswahl1 … 1Elemente in der Auswahl:
  • hl7:guardian​Person
  • hl7:guardian​Organization
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian​Person
(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian​Organization
(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:birthplace
0 … 1Geburtsort des Patienten(Hea...get)
 Beispiel<birthplace>
  <place>
    <addr>Hamburg</addr>  </place>
</birthplace>
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:place
1 … 1M(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD1 … 1M(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:language​Communication
0 … *(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:language​Code
CS0 … 1(Hea...get)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.11526 HumanLanguage (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:modeCode
CE0 … 1(Hea...get)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.12249 LanguageAbilityMode (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:proficiency​Level​Code
CE0 … 1(Hea...get)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.12199 LanguageAbilityProficiency (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:preference​Ind
BL0 … 1(Hea...get)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Participant: Informant (informant)

Id1.2.276.0.76.10.2018Gültigkeit2014‑08‑25
StatusKyellow.png EntwurfVersions-Label
NameCDAinformantBezeichnungCDA Informant
BeschreibungInformant, Personen, die Informationen zu dem Arztbrief beigesteuert haben (i.d.R. natürliche Personen, die nicht als Leistungserbringer agieren)
KlassifikationCDA Header Level Template
CDA Entry Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 2 Templates
Benutzt als NameVersion
1.2.276.0.76.10.90012InklusionKgreen.png CDA Assigned Entity ElementsDYNAMIC
1.2.276.0.76.10.90020InklusionKyellow.png RelatedEntity (Body)DYNAMIC
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.319 CDA Informant (Body) (2005‑09‑07)
ref
ad1bbr-
Beispiel
Beispiel
<informant typeCode="INF">
  <assignedEntity>
    <id extension="4342116437" root="2.16.840.1.113883.3.933"/>    <assignedPerson>
      <name>
        <prefix>Dr. </prefix>        <given>Ursula</given>        <family>Müller</family>      </name>
    </assignedPerson>
  </assignedEntity>
</informant>
Beispiel
Beispiel
<informant typeCode="INF">
  <relatedEntity>
    <id nullFlavor="UNK"/>    <relatedPerson>
      <name>
        <given>Hanna</given>        <family>Anverwandt</family>      </name>
    </relatedPerson>
  </relatedEntity>
</informant>
ItemDTKardKonfBeschreibungLabel
hl7:informant
(CDA...ant)
Treetree.png@typeCode
0 … 1FINF
Treetree.png@context​Control​Code
0 … 1FOP
Auswahl1 … 1Elemente in der Auswahl:
  • hl7:assignedEntity[hl7:assigned​Person]
  • hl7:relatedEntity
Treeblank.pngTreetree.pnghl7:assignedEntity
0 … 1Gesundheitsdienstleister(CDA...ant)
Eingefügt von 1.2.276.0.76.10.90012 CDA Assigned Entity Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *R(CDA...ant)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1R(CDA...ant)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *R(CDA...ant)
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
1 … 1M(CDA...ant)
Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(CDA...ant)
Treeblank.pngTreeblank.pngTreetree.pnghl7:represented​Organization
0 … 1(CDA...ant)
Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(CDA...ant)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(CDA...ant)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(CDA...ant)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(CDA...ant)
Treeblank.pngTreetree.pnghl7:relatedEntity
0 … 1Verwandte, Bekannte, Sozialhelfer, Betreuer/Erzieher(CDA...ant)
Eingefügt von 1.2.276.0.76.10.90020 RelatedEntity (Body) (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs1 … 1R
 CONF
Der Wert von @classCode muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.19316 RoleClassMutualRelationship (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CE0 … 1(CDA...ant)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.19563 PersonalRelationshipRoleType (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … *(CDA...ant)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(CDA...ant)
Treeblank.pngTreeblank.pngTreetree.pnghl7:effectiveTime
IVL_TS0 … 1(CDA...ant)
Treeblank.pngTreeblank.pngTreetree.pnghl7:relatedPerson
0 … 1(CDA...ant)
Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(CDA...ant)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Participant: Empfänger (informationRecipient)

Id1.2.276.0.76.10.2005Gültigkeit2013‑07‑10
StatusKgreen.png AktivVersions-Label
NameHeader​Information​RecipientBezeichnungCDA informationRecipient
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. (Es sind nicht die möglichen Empfänger, die jemals eine Kopie des Dokuments empfangen könnten.) So weiß man beispielsweise bei der Erstellung der Dokumentation, dass man einen „Brief" primär an den Hausarzt (informationRecipient.typeCode gleich PRCP, siehe unten) und ggf. einen zweiten („in Kopie") an einen mitbehandelnden Kollegen sendet (informationRecipient.typeCode ist gleich TRC).
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 2 Templates
Benutzt als NameVersion
1.2.276.0.76.10.90010InklusionKgreen.png CDA Person ElementsDYNAMIC
1.2.276.0.76.10.90011InklusionKgreen.png CDA Organization ElementsDYNAMIC
Beispiel
Beispiel
<informationRecipient typeCode="PRCP">
  <intendedRecipient>
    <id extension="4736437" root="2.16.840.1.113883.3.933"/>    <informationRecipient>
      <name>
        <prefix>Dr.med.</prefix>        <given>Kai</given>        <family>Heitmann</family>      </name>
    </informationRecipient>
    <receivedOrganization>
      <telecom use="WP" value="fax:+49247365746"/>      <addr>
        <streetAddress>Mühlenweg
1a
</streetAddress>
        <houseNumber>1a</houseNumber>        <postalCode>52152</postalCode>        <city>Simmerath</city>      </addr>
    </receivedOrganization>
  </intendedRecipient>
</informationRecipient>
ItemDTKardKonfBeschreibungLabel
hl7:information​Recipient
0 … *(Hea...ent)
Treetree.png@typeCode
cs0 … 1 Typ des Empfängers: im @typeCode der Participation kann angegeben werden, ob es sich um einen primären Empfänger handelt (default) oder einen sekundären Empfänger („CC Kopie").
Der typeCode PRCP ist der default.
 CONF
@typeCode muss "PRCP" sein
oder
@typeCode muss "TRC" sein
Treetree.pnghl7:intended​Recipient
1 … 1M(Hea...ent)
Treeblank.pngTreetree.pnghl7:id
II1 … *R(Hea...ent)
Auswahl1 … *
Wenn der beabsichtigte Empfänger eine Person ist, dann wird dies durch die Anwesenheit der Person Klasse mit oder ohne zugehörige Organisation spezifiziert. Wenn der beabsichtigte Empfänger eine Organisation ist, wird nur die Organisation angegeben, die Person fehlt.
Elemente in der Auswahl:
  • hl7:information​Recipient
  • hl7:received​Organization
Treeblank.pngTreeblank.pngTreetree.pnghl7:information​Recipient
0 … 1(Hea...ent)
Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(Hea...ent)
Treeblank.pngTreeblank.pngTreetree.pnghl7:received​Organization
0 … 1(Hea...ent)
Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...ent)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...ent)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(Hea...ent)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...ent)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Participant: Datentypist (dataEnterer)

Id1.2.276.0.76.10.2017Gültigkeit2014‑08‑25
StatusKyellow.png EntwurfVersions-Label
NameHeaderDataEntererBezeichnungCDA dataEnterer
BeschreibungDatentypist, die bei der Dateneingabe beteiligte Person(en) wie die Sekretärin u.a.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.276.0.76.10.90012InklusionKgreen.png CDA Assigned Entity ElementsDYNAMIC
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.103 CDA dataEnterer (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:dataEnterer
0 … 1(Hea...rer)
Treetree.png@typeCode
0 … 1FENT
Treetree.png@context​Control​Code
0 … 1FOP
Treetree.pnghl7:time
TS0 … 1gibt den Zeitpunkt an, an dem der Datentypist seinen Beitrag am Dokument beendet hat(Hea...rer)
Treetree.pnghl7:assignedEntity
1 … 1R(Hea...rer)
Eingefügt von 1.2.276.0.76.10.90012 CDA Assigned Entity Elements (DYNAMIC)
Treeblank.pngTreetree.pnghl7:id
II1 … *R(Hea...rer)
Treeblank.pngTreetree.pnghl7:addr
AD0 … 1R(Hea...rer)
Treeblank.pngTreetree.pnghl7:telecom
TEL0 … *R(Hea...rer)
Treeblank.pngTreetree.pnghl7:assigned​Person
1 … 1M(Hea...rer)
Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(Hea...rer)
Treeblank.pngTreetree.pnghl7:represented​Organization
0 … 1(Hea...rer)
Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...rer)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...rer)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(Hea...rer)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...rer)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Autor (author - generisch)

Id1.2.276.0.76.10.2002Gültigkeit2013‑07‑10
StatusKyellow.png EntwurfVersions-Label
NameHeaderAuthorBezeichnungCDA author
BeschreibungDie Autor-Relation gibt den Urheber der Dokumentation und den Zeitpunkt der Autorenschaft wieder. Dies sind in der Regel Personen (Gesundheitsdienstleister) oder auch Geräte, die Daten erzeugen.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 2 Templates
Benutzt als NameVersion
1.2.276.0.76.10.90010InklusionKgreen.png CDA Person ElementsDYNAMIC
1.2.276.0.76.10.90011InklusionKgreen.png CDA Organization ElementsDYNAMIC
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.102 CDA author (DYNAMIC)
ref
ad1bbr-
Beispiel
Autor ist eine Person
<author typeCode="AUT">
  <functionCode code="DISPHYS" displayName="discharging physician" codeSystem="2.16.840.1.113883.5.88" codeSystemName="ParticipationFunction"/>  <time value="20130407130000+0500"/>  <assignedAuthor classCode="ASSIGNED">
    <assignedPerson classCode="PSN" determinerCode="INSTANCE">
      <name>
        <given>Marie</given>        <family>Müller</family>      </name>
    </assignedPerson>
    <representedOrganization>
      <id root="2.16.840.1.113883.19.5"/>      <name>Beispiel Krankenhaus</name>    </representedOrganization>
  </assignedAuthor>
</author>
Beispiel
Autor ist ein Gerät/Maschine
<author typeCode="AUT">
  <assignedAuthor classCode="ASSIGNED">
    <assignedAuthoringDevice classCode="DEV" determinerCode="INSTANCE">
      <code>...</code>    </assignedAuthoringDevice>
  </assignedAuthor>
</author>
ItemDTKardKonfBeschreibungLabel
hl7:author
(Hea...hor)
Treetree.png@typeCode
0 … 1FAUT
Treetree.png@context​Control​Code
0 … 1FOP
 Beispiel<author typeCode="AUT" contextControlCode="OP">
  <time value="201306101654"/>  <assignedAuthor classCode="ASSIGNED">
    <!-- ... -->
  </assignedAuthor>
</author>
Treetree.pnghl7:functionCode
CE0 … 1(Hea...hor)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.10267 ParticipationFunction (DYNAMIC)
Treetree.pnghl7:time
TS.​DATE.​MIN1 … 1gibt den Zeitpunkt an, an dem der Autor seinen Beitrag am Dokument beendet hat; dies kommt bei einem Autoren praktisch überein mit ClinicalDocument.effectiveTime(Hea...hor)
Treetree.pnghl7:assignedAuthor
1 … 1(Hea...hor)
Treeblank.pngTreetree.png@classCode
0 … 1FASSIGNED
Treeblank.pngTreetree.pnghl7:id
II1 … *(Hea...hor)
Treeblank.pngTreetree.pnghl7:code
CE0 … 1Fachgebiet/Spezialität des Gesundheitsdienstleister, z. B. Ärztin/Arzt für Allgemeinmedizin, Approbierte Ärztin/Approbierter Arzt, Fachärztin/Facharzt für Anästhesiologie und Intensivmedizin(Hea...hor)
Treeblank.pngTreetree.pnghl7:telecom
TEL0 … *(Hea...hor)
Auswahl1 … 1Elemente in der Auswahl:
  • hl7:assigned​Person
  • hl7:assigned​Authoring​Device
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
 … 1(Hea...hor)
Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(Hea...hor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Authoring​Device
 … 1(Hea...hor)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FDEV
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:manufacturer​Model​Name
SC1 … 1(Hea...hor)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:softwareName
SC1 … 1(Hea...hor)
Treeblank.pngTreetree.pnghl7:represented​Organization
1 … 1M(Hea...hor)
 Beispiel<representedOrganization classCode="ORG" determinerCode="INSTANCE">
  <name>
    <!-- ... -->
  </name>
</representedOrganization>
Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...hor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...hor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(Hea...hor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...hor)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Unterzeichner gesetzlich verantwortlich (legalAuthenticator - generisch)

Id1.2.276.0.76.10.2020Gültigkeit2014‑08‑25
StatusKyellow.png EntwurfVersions-Label
NameHeaderLegalAuthenticatorBezeichnungCDA legalAuthenticator
BeschreibungVor dem Gesetz verantwortliche Unterzeichner des Dokumentes
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.276.0.76.10.90012InklusionKgreen.png CDA Assigned Entity ElementsDYNAMIC
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.106 CDA legalAuthenticator (2005‑09‑07)
ref
ad1bbr-
Beispiel
Beispiel
<legalAuthenticator typeCode="LA">
  <time value="20130327130000"/>  <signatureCode code="S"/>  <assignedEntity>
    <id extension="a00123456" root="1.2.276.0.76.3.9.8.7.6"/>    <assignedPerson>
      <name>
        <prefix qualifier="AC">Prof. Dr.</prefix>        <given>Hugo</given>        <family>Reinhardt</family>      </name>
    </assignedPerson>
    <representedOrganization>
      <name>Klinik am Zempiner Steig</name>      <telecom use="WP" value="tel:0332-4556"/>      <telecom use="WP" value="fax:0332-45577"/>      <addr>
        <streetName>Zempiner Steig</streetName>        <houseNumber>4</houseNumber>        <postalCode>15266</postalCode>        <city>Berlin</city>      </addr>
    </representedOrganization>
  </assignedEntity>
</legalAuthenticator>
ItemDTKardKonfBeschreibungLabel
hl7:legalAuthenticator
0 … 1(Hea...tor)
Treetree.png@typeCode
0 … 1FLA
Treetree.png@context​Control​Code
0 … 1FOP
Treetree.pnghl7:time
TS1 … 1R(Hea...tor)
Treetree.pnghl7:signatureCode
CS1 … 1R(Hea...tor)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.10282 ParticipationSignature (DYNAMIC)
Treetree.pnghl7:assignedEntity
1 … 1R(Hea...tor)
Eingefügt von 1.2.276.0.76.10.90012 CDA Assigned Entity Elements (DYNAMIC)
Treeblank.pngTreetree.pnghl7:id
II1 … *R(Hea...tor)
Treeblank.pngTreetree.pnghl7:addr
AD0 … 1R(Hea...tor)
Treeblank.pngTreetree.pnghl7:telecom
TEL0 … *R(Hea...tor)
Treeblank.pngTreetree.pnghl7:assigned​Person
1 … 1M(Hea...tor)
Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(Hea...tor)
Treeblank.pngTreetree.pnghl7:represented​Organization
0 … 1(Hea...tor)
Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...tor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...tor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(Hea...tor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...tor)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Verwaltende Organisation (custodian - generisch)

Id1.2.276.0.76.10.2004Gültigkeit2020‑03‑29
Andere Versionen mit dieser Id:
  • Kblank.png HeaderCustodian vom 2013‑07‑17
  • Kblank.png HeaderCustodian vom 2013‑07‑07
StatusKgreen.png AktivVersions-Label
NameHeaderCustodianBezeichnungCDA custodian
BeschreibungVerantwortliche Organisation für ein erstelltes Dokument (die das Dokument verwaltende Organisation). In der Regel ist es die erstellende Institution des Dokumentes.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
ItemDTKardKonfBeschreibungLabel
hl7:custodian
(Hea...ian)
Treetree.png@typeCode
0 … 1FCST
 Beispiel<custodian typeCode="CST">
  <assignedCustodian classCode="ASSIGNED">
    <representedCustodianOrganization classCode="ORG" determinerCode="INSTANCE">
      <!-- ... -->
    </representedCustodianOrganization>
  </assignedCustodian>
</custodian>
Treetree.pnghl7:assignedCustodian
1 … 1M(Hea...ian)
Treeblank.pngTreetree.png@classCode
0 … 1FASSIGNED
Treeblank.pngTreetree.pnghl7:represented​Custodian​Organization
1 … 1M(Hea...ian)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1M(Hea...ian)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...ian)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … 1(Hea...ian)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...ian)

cdaab2:Beteiligte (participant) (Template)

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

CDA R2 Body

Allgemeiner Aufbau des Body

Während im CDA Header die Akteure und mehr oder weniger administrative Inhalte wie Informationen über das Dokument selbst, den Patienten, den Autor etc. festgelegt wurden, enthält der CDA Body des hier definierten Arztbriefes die eigentliche klinische Dokumentation und stellt den „menschenlesbaren" medizinischen Teil dar.

Der hier definierte Arztbrief besteht im Body entweder aus einem nonXMLBody oder einem structuredBody Element, das wiederum section Elemente aufweist, mit denen die Information strukturiert werden kann. Falls nur die Metainformationen (Header) strukturiert übertragen werden und der Body nur aus einem Dokument (z. B. PDF) besteht, sollte man nonXMLBody verwenden (CDA Level1), das Dokumente entweder referenziert oder eingebettet wiedergeben.

Danach zeichnet sich für den Arztbrief folgende Grobstruktur ab.

Variante 1 - unstrukturierter Body

<ClinicalDocument>
  <!-- CDA Header -->
       ... siehe Beschreibung CDA R2 Header
  <!-- CDA Body -->
  <component>
    <nonXMLBody>
      <text mediaType="application/pdf" representation="B64">
        sadsfFAETQETEdfgStreTdsfgSrgregWRTERtSFGwERtwtergq45ttGw5TW%TwtR%TG
        vbnbnDJDZwrGTarGFaerewFasFaGaERgGtRzRthsYDFfGeRTertwerfFgERT3$RT34r
        dfE$R%34ReFD34T34TG§$t§4%T3ER§4t5§4TWEWRt§$t5§$t§g§$rt§$tGF$§t§$t$t
        ...
        cwER"§$wer§$65$%gTGH5643FD§$KJDU21%ZuTz$%z3vXCvSDf2EQeGFE§rwFG3$T%$
        e545REG34T%$gtrfgeg=
      </text>
      <languageCode code="de-DE"/>
    </nonXMLBody>
  </component>
</ClinicalDocument>
Variante 2 - strukturierter Body

<ClinicalDocument>
  <!-- CDA Header -->
       ... siehe Beschreibung CDA R2 Header
  <!-- CDA Body -->
    <component>
        <structuredBody>
              ... CDA R2 Body
        </structuredBody>
   </component>
</ClinicalDocument>

nonXMLBody (Variante 1)

Wie bereits angedeutet gibt es die Möglichkeit, lediglich den Header zur Übermittlung von strukturierten Metadaten zu einem Arztbrief zu nutzen:

Cdaab2 nonxmlbody.jpg

Cdaab2 nonxmlbody.jpg

[Abbildung 1] CDA nonXMLBody

Bei dieser Variante wird der Inhalt als Ganzes übermittelt. In diesem Fall besteht der Body lediglich aus einer verkürzten XML-Struktur, in der das Dokument eingebettet ist. Dann kann es allerdings nicht weiterverarbeitet und nur zur Anzeige mit einem geeigneten Viewer gebracht werden. In diesem Fall kommt ausschließlich die nonXMLBody-Section zum Einsatz.

structuredBody (Variante 2)

In der folgenden Grafik ist wiedergegeben, dass der CDA Body für den Arztbrief aus ein bis vielen Abschnitten (section) besteht. Diese können auch ineinander geschachtelt sein, um so – ähnlich wie in einem Buch – Unterabschnitte zu reflektieren. Als Beispiel ist hier ein „Kapitel" Anamnese zu nennen, das sich wiederum untergliedern könnte in „Eigenanamnese", „Familienanamnese", „Sozialanamnese" sowie „bisherige Operationen", „bisherige Impfungen" etc. In der Regel sind die Abschnitte mit Codes versehen (siehe unten). Manche Abschnitte sind mit zusätzlichen Einträgen (Komponenten) versehen, die RIM-Klassen entsprechen und hochstrukturierte Codierungen zulassen.

Zusammenfassend sind drei Typen von Abschnitten in der hier vorliegenden Arztbrief-Definition zu finden.

  • Text in Abschnitten, die nicht mit Codes identifiziert sind, innerhalb eines Abschnitts mit optionalen Unterabschnitten (Level 1, s. u.)
  • Text in Abschnitten, die mit Codes identifiziert sind, innerhalb eines Abschnitts mit optionalen Unterabschnitten (Level 2, s. u.)
  • Text in Abschnitten und Unterabschnitten, zusätzlich mit codierten Einträgen, die RIM-Klassen entsprechen (Level 3, s. u.).

Cdaab1 body.jpg

Cdaab1 body.jpg

[Abbildung 2] Übersicht über den Body-Teil des CDA-Dokuments. Die medizinische Dokumentation wird als Text in Abschnitten abgelegt, die vorzugsweise mit Codes identifiziert sind. Innerhalb eines Abschnitts kann es optionale Unterabschnitte geben, die eine weiter gehende Strukturierung ermöglichen. Für Diagnosen werden neben codierten Abschnitten auch hochstrukturierte Komponenten vorgesehen, die RIM-Klassen (z. B. Observation) entsprechen. Hier ist als Beispiel der Diagnose-Code für eine Entlass-Diagnose angedeutet.

Der structuredBody eines CDA Release 2 Dokuments setzt sich aus ein oder mehreren Komponenten zusammen, wobei jede Komponente wiederum aus einer oder mehreren Sektionen und gegebenenfalls aus einem oder mehreren „Entry"-Elementen (siehe Abschnitt „Level: 1 bis 3") besteht.

Das bedeutet unter anderem, dass ein CDA-Dokument dahingehend näher bestimmt werden kann, dass es spezifische Abschnitte, Paragrafen und andere Strukturbestandteile aufweisen muss. So kann ein Entlassbrief aus der Urologie beispielsweise ganz bestimmte Abschnitte beinhalten (Anamnese, Behandlung, Medikation, weiteres Vorgehen etc.), während ein OP-Bericht oder ein Pathologie-Befund ganz andere Erfordernisse bezüglich der Abschnitte und Strukturen haben kann bzw. muss.

Attribute von strukturierten Sections

Section.title: Titel des Abschnitts

Das section Element enthält einen optionalen Titel. Näheres regeln die entsprechenden spezialisierten Templates.

Section.text: Text des Abschnitts

Das section Element enthält eine narrative Beschreibung des Inhaltes und ist verpflichtend anzugeben.

Section.code: Klassifizierung des Abschnitts

Das section Element kann ein code Element enthalten, das den Inhalt des Abschnitts klassifiziert. Als Beispiel ist 10164-2 der LOINC Code für „History of Present Illness". Im Arztbrief sind zur primären Klassifikation ausschließlich LOINC Codes zugelassen. Alternative Codes können angegeben werden. Näheres regeln die entsprechenden spezialisierten Templates.

Section.languageCode: Sprache des Abschnitts

Jeder Abschnitt kann in einer anderen Sprache geschrieben sein. Dies wird im section-Element languageCode angegeben, wenn diese von der für das ganze Dokument (mittels languageCode im Header) gewählten abweicht. Weitere Informationen finden sich bei der Beschreibung des Elements languageCode des Headers. Hiervon wird allerdings typischerweise selten Gebrauch gemacht.

Beispiele für Abschnitte in einem Dokument

Ein Dokument besteht aus einem oder mehreren Abschnitten, die bei CDA auch Sections genannt werden. Nachfolgend ein paar typische Beispiele:

Entry

Die Abschnitte/Sections enthalten den Text, der direkt zur Anzeige verwendet werden soll. Für eine Maschine ist dieser normalerweise nicht direkt auswertbar. Dafür ist ein weiterer Mechanismus vorgesehen, bei dem die dem Text zugrundeliegenden Inhalte strukturiert ausgedrückt und in XML dargestellt werden. Diese Zusatzinformationen werden Entries genannt und innerhalb der Abschnitte optional eingebettet.

So kann beispielsweise ein Abschnitt Diagnose mit einer textuellen Darstellung der Diagnose ("Patient hat Blinddarmentzündung") ein Entry Diagnose enthalten, in dem die Diagnose als ICD-Code mit allen dazugehörigen Metadaten dargestellt wird.

Levels

Die CDA Level repräsentieren die unterschiedliche Feinheit (Granularität) der wiedergegebenen klinischen Informationen und des maschinen-auswertbaren Markups (standardisierte Form der maschinenauswertbaren Auszeichnung von Text).

Level 1

Mit Level 1 ist ein XML Dokument gekennzeichnet, das vor allem auf „menschliche Interoperabilität" abzielt („human readable"), also leicht für den menschlichen Gebrauch zugänglich gemacht werden kann, zum Beispiel durch Stylesheets. Es gibt keine Einschränkungen den Gebrauch oder Zweck des Dokuments oder den Inhalt betreffend. Die technischen Anforderungen, Level 1 Dokumente zu erzeugen oder zu verarbeiten, sind verhältnismäßig niedrig. Dies ist aus Datenverarbeitungssicht das gröbste Niveau von Informationen, gewährleistet damit aber sofort die Mensch-Mensch-Interoperabilität, die aus der reinen Papierwelt bekannt ist.

Cdaab1 section lvl1.jpg

Cdaab1 section lvl1.jpg

[Abbildung 3] CDA Level 1

Level 2

Im Level 2 wird der Aufbau der Abschnitte genauer festgelegt. Diese Festlegung kann sowohl die textuelle Darstellung mit <text> und <title> Elementen betreffen als auch die Vorgabe, den Abschnitt mit einem bestimmten Code kenntlich zu machen.

Die Identifikation dieser Abschnitte ist dann auch für Applikationen zugänglich, also maschinenauswertbar. Dies wird typischerweise erreicht durch die Assoziation des Abschnitts mit einem Code (oder einem Set von mehreren Codes). Hierfür werden in diesem Leitfaden ausschließlich LOINC Codes zur Dokumentenabschnittsklassifizierung verwendet. Eine andere Möglichkeit der Kenntlichmachung ist die Zuordnung einer Template-Identifikation, von der in dieser Spezifikation auch Gebrauch gemacht wird (siehe unten).

Cdaab1 section lvl2.jpg

Cdaab1 section lvl2.jpg

[Abbildung 4] CDA Level 2

Als Folge davon können so genannte section-level Templates zur Anwendung kommen. Mit den Codes sind die Abschnitte auch maschinen-auswertbar, d. h. durch Applikationen identifizierbar. Das bedeutet unter anderem, dass ein CDA Abschnitt dahingehend näher bestimmt werden kann, dass es spezifische Textteile (Paragraphen, Listen, Tabllen, etc.) aufweisen muss. So kann für einen Abschnitt mit Labordaten bspw. genau die Tabellenstruktur vorgegeben werden, d.h. welche Spalten in welcher Reihenfolge zu erscheinen haben.

Es liegt auf der Hand, dass die Spezifikation der Abschnitte eng verbunden ist mit dem Typ des Dokuments, z.B. ein OP-Bericht. In Arztbriefen - wofür dieser Leitfaden entwickelt wurde - macht man hier relativ wenig Vorgaben, während in Formularen oder Berichten relativ genaue Vorgaben zu erwarten sind.

Die häufigste Präzisierung ist die Vorgabe einer Menge von Codes für das Attribut code.

Level 3

CDA-Dokumente, die auch Level 3 konform sind, beinhalten zusätzlich auf dem Niveau von Einzelinformationen maschinen-auswertbare Komponenten (wie beispielsweise „systolischer Blutdruck"), die RIM-Klassen entsprechen. Eine Anwendung kann damit Daten wie eine einzelne Beobachtung, Prozedur, Medikamentengabe etc. identifizieren und verarbeiten. Selbst die Anwesenheit von bestimmten Einzelinformationen kann durch Vorgaben (Templates-Konzept) verpflichtend gemacht werden.

Cdaab1 section lvl3.jpg

Cdaab1 section lvl3.jpg

[Abbildung 5] CDA Level 3

Ingesamt spricht man bei CDA und der hier beschriebenen Architektur der Level von einer „inkrementellen bzw. variablen semantischen Interoperabilität". Das heißt schlicht, dass man sehr „bescheiden" anfangen kann und elektronische Dokumente nutzt, die im Wesentlichen Gegenstücke zum Papier sind: Mensch-Mensch-Interoperabilität. Je mehr eine Anwendung oder eine Anwendungsumgebung ermöglicht, desto mehr XML Markup kann man schrittweise zufügen: zunächst dadurch, bestimmte Abschnitte zu identifizieren oder gar zu fordern (Level 2) oder schließlich auf dem Niveau von Einzelinformationen anzugeben bzw. diese verpflichtend zu machen (Level 3). Dies bedeutet dann Anwendungsinteroperabilität.

Die folgende Grafik gibt eine Section Komponente mit ihren Bestandteilen wieder.

Cdaab1 section comp.jpg

Cdaab1 section comp.jpg

[Abbildung 6] CDA Section Komponente mit ihren Bestandteilen

Abbildung: Eine Abschnittskomponente (section) besteht aus einem <code>, der den Abschnitt typisiert, sowie einer Überschrift im <title>. Im obligatorischen <text> Teil sind die lesbaren Informationen repräsentiert. Dies ist verknüpft mit dem Begriff Level 2. Teile des narrativen Texts können darüber hinaus maschinenauswertbar im Level 3 repräsentiert werden, den so genannten CDA Entries <entry>. Zwischen Teilen des narrativen Texts und den Entries können Verbindungen angegeben werden.

XML-technisch gesprochen validieren CDA-Dokumente unabhängig vom Level gegen das generische CDA Schema. Zusätzlich können durch Festlegung bzw. Einschränkung der Abschnitte oder Detailinformationen weitere Validierungen verfügbar gemacht und genutzt werden.

Mit diesem Konzept ist es möglich,

  • narrative Befunde elektronisch strukturiert wiederzugeben, so wie sie heute in der papierbasierten Welt zu finden sind, mit oder ohne zusätzliches Markup. Gleichzeitig wird gewährleistet, dass so viele gemeinsame Informationen wie möglich den Anwendungen zur Verfügung stehen (shared semantics), wie zum Beispiel die Identifikation und andere allgemeine Daten des Patienten.
  • feingranulierte und kodierte Informationen darzustellen, wie Diagnosen, Prozeduren, Medikationen etc., die in (ggf. vorgegebenen) Kodierschemas wie ICD 10 repräsentiert sind, sowie Mess- oder Laborergebnisse darzustellen.
  • Dokumente abzubilden, die irgendetwas zwischen diesen beiden Extremen von grober Strukturierung von narrativem Text bis zu feingranulären Einzelinformationen repräsentieren.

Man kann dies auch als Möglichkeit ansehen, „sanft" und ohne allzu hohe Ansprüche zu beginnen, elektronische Dokumente einzuführen und mit steigenden Anforderungen und technischen Möglichkeiten zu höherer Anwendungsinteroperabilität zu migrieren.

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Textstrukturierung

Die medizinischen Informationen werden im CDA Body im Sinne von Level 1 immer in Textform wiedergegeben (verpflichtend) und wo immer möglich auch mit Section-Codes versehen, also auf Level 2 dargestellt. Dies garantiert, dass die Dokumente immer für den Menschen lesbar (und verstehbar) sind. Im Folgenden ist das Muster einer Level 1 und Level 2 Darstellung gezeigt. Level 3 ist angedeutet:

<component>
  <structuredBody>
  ... 
    <component>
      <section>
        <!-- Level 2 -->
        <code code="..." codeSystem="..." />
        <!-- Level 1 -->
        <title> ... </title>
        <text>
           ...
        </text>
        <!-- Level 3 -->
        <entry>
           ...
        </entry>
      </section>
    </component>
    ...
  </structuredBody>
</component>

Textauszeichnung

Der Text selber kann wiederum Strukturelemente aufweisen. Dies kann genutzt werden, um Listen, Tabellen oder auch Unterabschnitte zu definieren. Innerhalb eines Section-Tags wird in CDA Level 2 das text Tag verwendet, um den narrativen Text („plain text") darzustellen. In vielen Fällen lassen sich die medizinischen Inhalte aber auch noch weiter gehend strukturiert darstellen. Dazu stehen in CDA als Stil-Elemente Listen, Tabellen und Unterabschnitte (Paragrafen) zur Verfügung. Mit Hilfe eines einfachen Stylesheets können die Inhalte in diesen Strukturelementen für den Menschen lesbar dargestellt werden.

Listen

Das Strukturelement „Liste" dient zur Abbildung einer einfachen Aufzählung medizinischer Inhalte. Eine Liste wird mit dem list Tag eingeschlossen. Das optionale Attribut @listType ermöglicht die Auflistung unsortiert (@listType="unsorted"), die üblicherweise mit Bulletpoints • dargestellt wird, und in sortierter Form (@listType="sorted") , die mit Zahlen etc. dargestellt wird. Ohne Angabe von @listType ist die Liste unsortiert. Ein Element der Aufzählung (item) wird mit dem item Tag eingeschlossen. Eine Liste hat formal das folgende Aussehen:

<list>
  <item> 1. Element der Liste</item>
  <item> 2. Element der Liste</item>
  <item> ...</item>
  <item> n. Element der Liste</item>
</list>

Das folgende Beispiel zeigt eine mögliche Darstellung eines Befundes, strukturiert mittels Liste.

<text>
  <list>
    <item>Pulmo: Basal diskrete RGs</item>
    <item>Cor: oB</item>
    <item>Abdomen: weich, Peristaltik: +++</item>
    <item>Muskulatur: atrophisch</item>
    <item>Mundhöhle: Soor, Haarleukoplakie</item>
    <item>Haut blass, seborrhoisches Ekzem, Schleimhäute blass,
          Hautturgor herabgesetzt</item>
    <item>Neuro: herabgesetztes Vibrationsempfinden der Beine,
          distal betont, Parästesien der Beine, PSR, AST
          oB und seitengleich.</item>
  </list>
</text>

Dasselbe Beispiel in der Ansicht eines Browsers (mittels Stylesheet).

Ansicht im Browser
  • Pulmo: Basal diskrete RGs
  • Cor: oB
  • Abdomen: weich, Peristaltik: +++
  • Muskulatur: atrophisch
  • Mundhöhle: Soor, Haarkoplakie
  • Haut blass, seborrhoisches Ekzem, Schleimhäute blass, Hautturgor herabgesetzt
  • Neuro: herabgesetztes Vibrationsempfinden der Beine, distal betont, Parästesien der Beine, PSR, AST oB und seitengleich.
Tabellen

Zur Repräsentation medizinischer Inhalte, die sich adäquat tabellarisch darstellen lassen, bietet sich die Tabellenform an. Als Beispiele seien genannt: Laborwerte, Allergiewerte, Diagnose mit ICD-Verschlüsselung etc. CDA realisiert ein vereinfachtes XHTML Table Modell, das HTML sehr ähnelt. Eine Tabelle wird angedeutet mit dem table Element. Als Attribut ist hier @border vorgesehen, das die Breite der Umrahmung angibt.

<table border="1">
  ''...Tabellen-Elemente''
</table>

Eine Tabelle besteht aus einer oder mehreren Spalten. In der ersten Zeile werden die Spaltenüberschriften aufgeführt. Die Tabellenüberschrift wird eingeschlossen in thead Tags, die Überschriftenzeile in tr Tags und die einzelnen Spalten-Items der Überschrift mit th Tag.

<table>
  <thead>
    <tr>  <!-- Überschrift-Zeile -->
      <th> Spaltenüberschrift 1</th> 
      ...
      <th> Spaltenüberschrift n</th>
    </tr>
  </thead>
  ...
</table>

Die eigentlichen Inhalte werden in tbody Tags, die Datenzeile in tr Tags und die einzelnen Spalteninhalte einer Datenzeile mit td Tag gekapselt. Insgesamt hat eine Tabelle formal das folgende Aussehen:

<table>
  <thead>
    <tr>  <!-- Überschrift-Zeile -->
      <th> Spaltenüberschrift 1</th>
      ...
      <th> Spaltenüberschrift n</th>
    </tr>
  </thead>
  <tbody>
    <tr>  <!-- 1. Zeile mit Daten -->
      <td>Inhalt Spalte 1 in Zeile 1</td>
      ...
      <td>Inhalt Spalte n in Zeile 1</td>
    </tr>
    ...
    <tr> <!-- m. Zeile mit Daten -->
      <td>Inhalt Spalte 1 in Zeile m</td>
        ...
      <td>Inhalt Spalte n in Zeile m</td>
    </tr>
  </tbody>
</table>

Das folgende Beispiel zeigt die Repräsentation einer Diagnose in Tabellenform, wobei die Spaltenüberschriften lauten: "Diagnose", "ICD Code", "Lokalisation" und "Zusatz"

<table>
  <thead>
    <tr>
      <th>Diagnose</th>
      <th>ICD Code</th>
      <th>Lokalisation</th>
      <th>Zusatz</th>
    </tr>
  </thead>
  <tbody>
   <tr>
      <td>Tuberkulose des Ohres</td>
      <td>A18.6</td>
      <td>R</td>
      <td>G</td>
    </tr>
    <tr>
      <td>Ausschluss Lungenemphysem</td>
      <td>J43.9</td>
      <td>--</td>
      <td>A</td>
    </tr>
    <tr>
      <td>V. a. Allergische Rhinopathie durch Pollen</td>
      <td>J31.1</td>
      <td>--</td>
      <td>V</td>
    </tr>
  </tbody>
</table>



Beispiel

[Abbildung 7] Dasselbe Beispiel in der Ansicht eines Browsers (mittels Stylesheet).

Unterabschnitte

Zur Strukturierung eines längeren Textes kann das paragraph Tag verwendet werden. Beispiel:

<text>
  <paragraph> Sollten nach der empfohlenen Medikation mit Atemur die
  klinischen Zeichen weiterhin bestehen, halte ich bei dem umfangreichen
  Risikoprofil einen Kuraufenthalt für zwingend notwendig.</paragraph>
  <paragraph> Ich bitte dann um Wiedervorstellung des Patienten.
  </paragraph>
</text>
Überschriften

Mit dem caption Element kann man Paragrafen, Listen, Listenelemente, Tabellen oder Tabellenzellen mit einer Beschreibung („Überschrift") versehen. Ein caption Element enthält Text und kann Verweise (Links) oder Fußnoten enthalten.

Superskripts und Subskripts

Diese Gestaltungsmöglichkeiten sind im CDA-Standard beschrieben, werden aber in diesem Leitfaden noch nicht genutzt.

Zeilenumbrüche

Das br Element <br/> kann benutzt werden, um im laufenden Text einen „harten" Zeilumbruch zu erzwingen. Dies unterscheidet sich vom paragraph Element, da der Zeilenumbruch keinen Inhalt hat. Empfänger sind gehalten, dieses Element als Zeilenumbruch darzustellen.

Beispiel

<text>
  Patient hat Asthma seit seinem zehnten Lebensjahr.<br/>
  Patient kommt damit gut zurecht.
</text>
Fußnoten

Diese Gestaltungsmöglichkeiten sind im CDA-Standard beschrieben, werden aber in diesem Leitfaden noch nicht genutzt.

Sonstige Zeichenstile

Mittels des @styleCode Attributs im Textteil, das in content Elementen verwendet werden kann, ist es möglich, Vorschläge des Autors des Dokuments bezüglich der Visualisierung von umschlossenen Textteilen zu beschreiben. Der Empfänger ist nicht verpflichtet, den Text tatsächlich so visuell darzustellen, wie es die Vorschläge andeuten. Bisher werden im Rahmen dieses Leitfadens die folgenden Style-Codes unterstützt, die in beliebiger Reihenfolge genutzt werden können.

Font-Stil-Angaben (Änderung der Font-Charakteristik)
Code Definition
Bold Fettdruck
Underline Unterstrichen
Italics Kursivschrift
Emphasis Betont

[Tabelle 2] Stil-Codes für den narrativen Text

<text>
  Einiges vom Text wird <content styleCode="Bold">im Fettdruck</content> 
  dargestellt, anderes in <content styleCode="Bold Italics">fetter
  Kursivschrift</content>.
</text>

Referenzierter Inhalt (content)

Das CDA content Element wird benutzt, um Text ausdrücklich mit Tags „einzurahmen", so dass er referenziert werden kann oder bestimmte Möglichkeiten zur visuellen Darstellung genutzt werden können. Das content Element kann rekursiv ineinander geschachtelt werden, was die Einrahmung von ganzen Texten bis hin zu kleinsten Teilen (Worte, Buchstaben etc.) erlaubt.

Das content Element enthält ein optionales Identifikator Attribut, das als Ziel einer XML Referenz dienen kann. Alle diese IDs sind als XML IDs definiert und müssen im gesamten Dokument eindeutig sein. Die originalText Komponente einer RIM Klasse, die sich in den CDA Entries (siehe unten) wieder findet, kann sich somit explizit auf die vom content Element im Textteil umschlossene Information beziehen.

Im Beispiel wird das Textstück Asthma durch das content Element eingerahmt, so dass in einem möglichen Level 3 Entry darauf Bezug genommen werden kann (originalText.reference, siehe unten).

Beim Patienten wurde <content ID="diag-1">Asthma</content> diagnostiziert.

Das content Element wird auch zur Einrahmung von Text benutzt, der in einem, bestimmten Stil dargestellt werden soll, was mit dem @styleCode Attribut (siehe unten) näher beschrieben wird.

Referenz zu (externen) Multimedia-Inhalten

Es ist möglich, zusätzlich zu dem Text auch Referenzen auf externe Multimediaobjekte wie Bilder etc. zu spezifizieren. Dies geschieht über das renderMultiMedia Element und dient dazu aufzuzeigen, wo das Multimedia-Objekt gezeigt/dargestellt werden soll.

Das renderMultiMedia Element hat ein optionales caption Element. Es weist außerdem die Referenz (XML ID) zum erforderlichen Objekt auf, die als XML IDREF im selben Dokument definiert sein muss. XML ID und IDREF sind also korrespondierende Definitionen (einmalig) und Referenzen darauf (mehrfach möglich) eines CDA Entry ObservationMedia (oder RegionOfInterest) im selben Dokument.

Das renderMultiMedia Element trägt dabei im @referencedObject Attribut die ID.

Die Information zum eigentlichen Objekt wird in einem CDA Entry festgehalten. Für diesen Leitfaden wird ausschließlich das Element observationMedia verwendet.

Dieser Eintrag trägt im entry Element unter anderem das @ID Attribut als Zielreferenz des @referencedObject Attributs vom renderMultiMedia Element.

ObservationMedia Klasse

Die Klasse ObservationMedia selbst ist im Prinzip ein Clinical Statement, wobei die im Folgenden genannten Elemente möglich sind.

Observation Media

[Abbildung 8] ObservationMedia CDA Entry zur Darstellung der Informationen eines Multimedia-Objektes.

Eine detaillierte Beschreibung ist beim entsprechenden Template Eingebettetes Objekt Entry angegeben.

Regel OMVL: Wenn die Klasse observationMedia genutzt wird, muss sie ein value Element mit dem eigentlichen Objekt enthalten.

Vokabular

Der Datentyp von Multimedia-Objekten ist immer ED (encapsulated data). Dabei ist auch der Medientyp (MIME) im entsprechenden @mediaType Attribut zu nennen. Zugelassen sind hier zunächst nur die folgenden Mime-Typen. Als „verpflichtend", also als zu unterstützen, werden die Typen text/plain, application/pdf sowie audio/mpeg, image/png, image/jpeg und video/mpeg eingestuft.

Diese Terminologie ist eine Momentaufnahme vom . Terminologien können sich im Laufe der Zeit weiterentwickeln. Wenn eine neuere (dynamische) Versionen dieser Terminologie benötigt wird, bitte von der Quelle abrufen.
Id1.2.276.0.76.11.14Gültigkeit2014‑08‑25
StatusKyellow.png EntwurfVersions-Label
NameMediatypesBezeichnungMedientypen
Benutzung: 1
IdNameTyp
Template
1.2.276.0.76.10.4014Eingebettetes Objekt Entry DYNAMIC
Quell-Codesystem
1.2.840.10003.5.109 - FHIR: urn:oid:1.2.840.10003.5.109
Level/ TypCodeBezeichnungCodesystemBeschreibung
0‑L
text/plain
Mime Type text/plain
1.2.840.10003.5.109Für beliebige Texte. Dies ist der ’default’ Typ. In dieser Form ist er identisch mit dem ST Typ
0‑L
text/html
Mime Type text/html
1.2.840.10003.5.109Bestimmt für formatierte Texte in HTML Format. HTML reicht für die meisten Anwendungen aus, bei denen Layout erwünscht ist. HTML ist Plattform-unabhängig und weit verbreitet.
0‑L
text/xml
Mime Type text/xml
1.2.840.10003.5.109
0‑L
application/pdf
Mime Type application/pdf
1.2.840.10003.5.109Adobe Portable Document Format
0‑L
image/png
Mime Type image/png
1.2.840.10003.5.109Portable Network Graphics (PNG, http://www.cdrom.com/pub/png) ist eine verlustfreie Komprimierung von Bilddateien. Wo vorher GIF benutzt wurde, muss jetzt PNG unterstützt werden.
0‑L
image/jpeg
Mime Type image/jpeg
1.2.840.10003.5.109Dieses Format wird benutzt für hohe Auflösungen bei Fotos und anderen Bilddateien. Die Komprimierung verläuft nicht ohne Verluste, wodurch dieses Format nicht immer geeignet ist für diagnostische Zwecke. JPEG wird vorwiegend benutzt werden für ’thumbnails’ von großen (DICOM) Dateien.
0‑L
image/gif
Mime Type image/gif
1.2.840.10003.5.109
0‑L
video/mpeg
Mime Type video/mpeg
1.2.840.10003.5.109MPEG ist ein internationaler Standard für Videobilder. Er ist weit verbreitet und Open-Source-Implementierungen sind verfügbar.
0‑L
audio/mpeg
Mime Type audio/mpeg
1.2.840.10003.5.109MPEG-1 Audio layer-3 (auch bekannt als MP3) ist momentan der Standard für komprimierte Audiodaten.

Legende: Typ L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavor OTH (other) schlägt Text in originalText vor. HL7 V3: NullFlavors werden im @nullFlavor Attribut statt in @code angegeben.


[Tabelle 3] mediaType Attribut Werte (Datenarten)

Beispiel

Das in observationMedia.value befindliche reference Element enthält als Wert den Verweis auf das eigentliche Multimedia-Objekt.

Das folgende Beispiel beschreibt einen Befund am linken Zeigefinger, der zusätzlich mit einem Bild dokumentiert ist.

<section>
   <code code="8709-8" codeSystem="2.16.840.1.113883.6.1" 
    codeSystemName="LOINC"/>
   <title>Untersuchung der Haut</title>
   <text>Rötung an der Palmarfläche des linken Zeigefingers
     <renderMultiMedia referencedObject="MM1"/>
   </text>
   <entry>
      <observationMedia classCode="OBS" moodCode="EVN">
         <templateId root="1.2.276.0.76.10.4014"/>
         <value mediaType="image/jpeg">
            <reference value="lefthand.jpeg"/>
         </value>
      </observationMedia>
   </entry>
</section>

Cdapd:StatischesModell Cdapd:Section: Symptomerfassung Cdapd:Section: Pflegedokumentation Cdapd:Section: Einschätzung (Karnofsky-Index)

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Section: Diagnosen

Die Diagnosen werden im Arztbrief im Idealfall

  • in Level 1 zur direkten Ausgabe formatiert,
  • in Level 2 als Diagnose markiert und
  • in Level 3 codiert angegeben (im jetzigen Leitfaden nicht beschrieben, sondern alleinig in den nicht-normativen Einzelabschnitten zu den Diagnosen wiedergegeben):

Die folgenden Typen von Diagnosen werden in den entsprechenden Sektionen wiedergegeben.

Aufnahmediagnose

Id1.2.276.0.76.10.3026Gültigkeit2013‑12‑30
Andere Versionen mit dieser Id:
  • Kblank.png Admissiondiagnosissection vom 2017‑02‑01
StatusKgreen.png AktivVersions-Label
NameAdmissiondiagnosissectionBezeichnungAufnahmediagnose
BeschreibungSpeziell gekennzeichnete Diagnose, die im Verlauf der Aufnahmeuntersuchung gestellt wird.
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:section
(Adm...ion)
Treetree.pnghl7:templateId
II1 … 1(Adm...ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.3026
Treetree.pnghl7:code
CE1 … 1M(Adm...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F46241-6
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(Adm...ion)
 CONF
Elementinhalt muss "Aufnahmediagnosen" sein
Treetree.pnghl7:text
SD.TEXT1 … 1M(Adm...ion)


Entlassungsdiagnose

Id1.2.276.0.76.10.3027Gültigkeit2013‑12‑30
Andere Versionen mit dieser Id:
  • Kblank.png Dischargediagnosissection vom 2017‑02‑01
StatusKgreen.png AktivVersions-Label
NameDischargediagnosissectionBezeichnungEntlassungsdiagnose
BeschreibungDiagnose, mit der der Patient entlassen wurde
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:section
(Dis...ion)
Treetree.pnghl7:templateId
II1 … 1(Dis...ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.3027
Treetree.pnghl7:code
CE1 … 1M(Dis...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F11535-2
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(Dis...ion)
 CONF
Elementinhalt muss "Entlassungsdiagnosen" sein
Treetree.pnghl7:text
SD.TEXT1 … 1M(Dis...ion)


Textformatierung für Diagnosen (auf Level 1)

Das nachfolgende Beispiel zur Textformatierung zeigt die Nutzung von Tabellen am Beispiel der Diagnosen.

Beispiel

<component>                     
  <!-- Diagnose mit ICD Komponente auf CDA Level 2--> 
  <section>
    <code code="29548-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
    <title>29.08.2005: Diagnosen mit ICD 10</title>
    <text>
      <table border="1">
        <thead>
          <tr>
          <th>Diagnose</th>
          <th>ICD Code</th>
          <th>Lokalisation</th>
          <th>Zusatz</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td><content ID ="DIAG200508291">Allergisches Asthma</content></td>
            <td>J45.0</td>
            <td>--</td>
            <td>G</td>
          </tr>
          <tr>
            <td><content ID ="DIAG200508292">Ausschluss Lungenemphysem</content></td>
            <td>J43.9</td>
            <td>--</td>
            <td>A</td>
          </tr>
          <tr>
            <td><content ID ="DIAG200508293">V.a. Allergische Rhinopathie durch Pollen</content></td>
            <td>J31.1</td>
            <td>--</td>
            <td>V</td>
          </tr>
        </tbody>
      </table>
    </text>
  </section>
</component>

Cdapd:Section: Metastasen Cdapd:Section: Zugänge Katheter

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Section: Medikationen

In diesem Leitfaden werden folgende Templates zu Medikations-Informationen unterstützt:

Medikation bei Einweisung (Historie)

Id1.2.276.0.76.10.3029Gültigkeit2013‑12‑30
Andere Versionen mit dieser Id:
  • Kblank.png Admissionmedicationsection vom 2017‑02‑01
StatusKgreen.png AktivVersions-Label
NameAdmissionmedicationsectionBezeichnungMedikation bei Einweisung (Historie)
BeschreibungErhobene Medikation bei Aufnahme des Patienten.
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:section
(Adm...ion)
Treetree.pnghl7:templateId
II1 … 1(Adm...ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.3029
Treetree.pnghl7:code
CE1 … 1M(Adm...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F42346-7
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(Adm...ion)
 CONF
Elementinhalt muss "Medikation bei Aufnahme" sein
Treetree.pnghl7:text
SD.TEXT1 … 1M(Adm...ion)

Verabreichte Medikation während des Aufenthalts

Id1.2.276.0.76.10.3030Gültigkeit2013‑12‑30
Andere Versionen mit dieser Id:
  • Kblank.png Medicationduringstaysection vom 2017‑02‑01
StatusKgreen.png AktivVersions-Label
NameMedicationduringstaysectionBezeichnungVerabreichte Medikation während des Aufenthalts
BeschreibungSämtliche verabreichte Medikation während des Aufenthalts
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:section
0 … *(Med...ion)
Treetree.pnghl7:templateId
II1 … 1R(Med...ion)
Treeblank.pngTreetree.png@root
1 … 1F1.2.276.0.76.10.3030
Treetree.pnghl7:code
CE1 … 1M(Med...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F29549-3
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(Med...ion)
 CONF
Elementinhalt muss "Verabreichte Medikation während des Aufenthalts" sein
Treetree.pnghl7:text
SD.TEXT1 … 1M(Med...ion)

Medikation bei Entlassung

Id1.2.276.0.76.10.3031Gültigkeit2013‑12‑30
Andere Versionen mit dieser Id:
  • Kblank.png Dischargemedicationsection vom 2017‑02‑01
StatusKgreen.png AktivVersions-Label
NameDischargemedicationsectionBezeichnungMedikation bei Entlassung
BeschreibungMedikation bei Entlassung
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:section
(Dis...ion)
Treetree.pnghl7:templateId
II1 … 1(Dis...ion)
Treeblank.pngTreetree.png@root
1 … 1F1.2.276.0.76.10.3031
Treetree.pnghl7:code
CE1 … 1M(Dis...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F10183-2
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(Dis...ion)
 CONF
Elementinhalt muss "Medikation bei Entlassung" sein
Treetree.pnghl7:text
SD.TEXT1 … 1M(Dis...ion)

Cdapd:Section: Hilfsmittel Cdapd:Section: Hospizdokumentation Cdapd:Section: SAPV Verordnung Cdapd:Section: Versorgungsunterbrechung Cdapd:Section: Abschluss Cdapd:Section: Wichtige Anmerkungen

Referenzen


Referenzfehler: Es sind <ref>-Tags für die Gruppe „Tabelle“ vorhanden, jedoch wurde kein dazugehöriges <references group="Tabelle" />-Tag gefunden oder ein schließendes </ref> fehlt.
Referenzfehler: Es sind <ref>-Tags für die Gruppe „Abbildung“ vorhanden, jedoch wurde kein dazugehöriges <references group="Abbildung" />-Tag gefunden oder ein schließendes </ref> fehlt.