IG:Übermittlung meldepflichtiger Krankheiten Labormeldung

Übermittlung meldepflichtiger Krankheiten - Labormeldung

Übermittlung meldepflichtiger Krankheiten - Labormeldung

Implementierungsleitfaden

vorgelegt von:
xxxx
xxx

Entwurf

Version:	0.00
Datum:	xxx
Status:	Entwurf
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

Copyright © 2011-2013: HL7 Deutschland

Implementierungsleitfaden zur Übermittlung meldepflichtiger Krankheiten - Labormeldung

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 .

Ansprechpartner und Autoren

Ansprechpartner:

• Lars Treinat, Zentrum für Telematik und Telemedizin GmbH, Bochum

Autoren:

• Lars Treinat, Zentrum für Telematik und Telemedizin GmbH, Bochum
• Mathias Aschhoff, Zentrum für Telematik und Telemedizin GmbH, Bochum
• Stefan Brüne, Zentrum für Telematik und Telemedizin GmbH, Bochum
• Cindy Gieselmann, Zentrum für Telematik und Telemedizin GmbH, Bochum
• Dr. Frank Oemig, Agfa HealthCare, Bonn
• Dr. Kai U. Heitmann, Heitmann Consulting and Services, Hürth

Editoren:

• Dr. Frank Oemig, Agfa HealthCare, Bonn
• Dr. Kai U. Heitmann, Heitmann Consulting and Services, Hürth

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 .

Einleitung

Motivation und Ziel

Vor dem Hintergrund der jüngsten Epidemien wurden vielfach Forderungen erhoben das Meldewesen in Deutschland zu modernisieren und schneller zu machen. In Abstimmung mit den aktuellen Aktivitäten auf Bundesebene beabsichtigt das Land Nordrhein-Westfalen die Erprobung eines elektronischen Meldeweges weiter voranzutreiben. Zu diesem Zweck wurde das Zentrum für Telematik im Gesundheitswesen (ZTG) mit der Erarbeitung der Grundlagen für die Einführung eines elektronischen Meldeverfahrens zur Übermittlung von meldepflichtigen Krankheiten und Erregern von Ärztinnen/Ärzten und Laboreinrichtungen an die zuständigen Gesundheitsämter sowie mit der Betreuung entsprechender Pilotversuche betraut. Zielsetzung ist die Übermittlung für die Meldepflichtigen so schnell und einfach wie möglich zu gestalten. Dafür wird angestrebt, in den Primärsystemen bereits vorhandene Informationen zum Erkennen eines meldepflichtigen Falls und zum weitgehenden Vorbefüllen eines Meldedatensatzes zu nutzen, so dass eine Meldung gemäß den Vorgaben des IfSG bzw. des Robert-Koch-Instituts (RKI) „auf Knopfdruck“ verschlüsselt an das zuständige Gesundheitsamt übermittelt werden kann. Der prinzipielle Meldeweg und -umfang an sich bleiben von der Umstellung auf eine elektronische Meldung unberührt.

Der hier dargestellte Entwurf eines Implementierungsleitfadens ist derzeit noch in Entwicklung und orientiert sich an den umfangreichen Vorarbeiten eines PDF-Leitfadens aus dem Jahr 2008. Allerdings ist vorerst der inhaltliche Fokus enger gefasst und auf die elektronische Umsetzung der existierenden (aktuell gesetzlich vorgegebenen) Meldewege für namentliche Meldungen ausgerichtet.

Hintergrund der etablierten Formulare zur Übermittlung von meldepflichtigen Krankheiten und Erregern gemäß Infektionsschutzgesetz (IfSG)

Inhalt der Meldungen nach IfSG ist die Übermittlung meldepflichtiger Infektionskrankheiten bzw. Erregernachweise durch Ärzte und Labore an die zuständigen Behörden. In den meisten Fällen sind dies die Gesundheitsämter entweder am Ort des Krankenhauses oder dem Wohnort des Patienten. Dies dient u.a. dazu, dass die zuständigen Behörden geeignete seuchenhygienische Maßnahmen zum Schutz der Bevölkerung einleiten können und ein umfassendes Lagebild bei Epidemien erhalten.

Die Meldekette in ihrer heutigen Form ist - abgesehen von der "ersten Meile" vom Meldepflichtigen zum zuständigen Gesundheitsamt - weitestgehend durch elektronische Übermittlung von maschinell verarbeitbaren Datensätzen realisiert. Für die Übermittlung der Daten zwischen den Gesundheitsämtern, Landesgesundheitsbehörden und dem auf Bundesebene zuständigen Robert-Koch-Institut (RKI) stehen durch das RKI definierte Datensatzstrukturen und Tools (SurvNet@RKI) zur Verfügung. Bei der initialen Übermittlung auf der "ersten Meile" erfolgt die Meldung auf Basis von Formularen, deren Systematik für eine papierorientierte Meldung primär darauf ausgerichtet ist, alle relevanten Daten möglichst auf einer DIN-A4-Seite abzubilden. In der Praxis werden diese Formularmuster häufig handschriftlich ausgefüllt und per Brief oder Fax übermittelt. Daneben werden mit zunehmender Tendenz auch frei gestaltete Meldungen per Fax oder Email an die Gesundheitsämter gesandt. Dies führt zu einem erheblichen Aufwand bei der Auswertung und Erfassung der Meldungen.

Angestoßen von der Vogelgrippe in 2009 und der EHEC-Epidemie im Sommer 2011 wurde der Ansatz wieder aufgenommen, die Meldungen der meldepflichtigen Personenkreise an die zuständigen Behörden vom heute üblichen Post- oder Fax-Versand durch eine elektronische Übermittlung mittels eines standardisierten und strukturierten Datensatzes abzulösen. Zielsetzung ist dabei zum Einen den meldepflichtigen Personenkreisen (insbesondere Ärzten und Laboren) einen zeitgemäßen Übertragungsweg zu eröffnen, der eine optimierte Integration in die Abläufe der Praxen, Krankenhäuser und Labore ermöglicht und zum Anderen das Potential bietet, die Geschwindigkeit, Qualität und bei bestimmten Erkrankungen auch die Quantität der Meldungen erheblich zu verbessern.

Die grundlegenden Inhalte der Meldung sind im Infektionsschutzgesetz (§ 6 Meldepflichtige Krankheiten, § 7 Meldepflichtige Nachweise von Krankheitserregern) bundesrechtlich geregelt. Details legt das RKI in einem jährlich aktualisierten Regelwerk fest. Entsprechend der unterschiedlichen Inhalte und Struktur der Meldungen bei Krankheiten und Erregern, adressiert die Meldepflicht hierfür unterschiedliche Personengruppen. Meldungen von Krankheiten erfolgen gemäß § 6 i.V.m. § 8 Abs. 1 IfSG größtenteils durch den feststellenden Arzt in Praxis, Krankenhäusern oder anderen stationären Einrichtungen. Daneben sind in diesen Fällen eine Reihe weiterer Personen meldepflichtig (z.B. Angehörige eines anderen Heil- oder Pflegeberufs, Leiter von stationären Einrichtungen, Flugzeug- oder Schiffsführer), wenn eine Meldung durch den Arzt noch nicht erfolgt ist. Die Meldung von Krankheitserregern erfolgt gem. § 7 i.V.m. § 8 Abs. 2 und 3 IfSG durch labordiagnostische Einrichtungen. Vor diesem Hintergrund finden sich auch unterschiedliche Musterformulare des Robert-Koch-Instituts (RKI) für die Meldungsarten Arztmeldung und Labormeldung. Aufbauend auf den Musterformularen des RKI existieren eine Reihe von bundesland-spezifischen Ausprägungen der Arzt- und Labor-Meldebögen, die sich z.T. nicht nur im Layout unterscheiden sondern darüber hinaus in Einzelfällen Angaben enthalten, die aus landesspezifischen Vorgaben resultieren. (Beispielsweise wurden in NRW im Arztmeldebogen zusätzlich Informationen zum Impfstatus aufgenommen.)

Grundtypen von Meldungen

Es können folgende Grundtypen von Meldungen unterschieden werden:

Arztmeldung

§ 6 IfSG, Erkrankungen, namentliche Meldung an das örtlich zuständige Gesundheitsamt

Labormeldungen

• § 7 Abs. 1 und 2 IfSG, Krankheitserreger, namentliche Meldung an das örtlich zuständige Gesundheitsamt
• § 7 Abs. 3 IfSG, Krankheitserreger, nicht-namentliche Meldung an das RKI
  (bestimmte Erkrankungen: Syphilis, HIV, Echinokokkose, Malaria, Röteln/Toxoplasmose)

Die Inhalte der Standard-Meldebögen für die namentliche Meldung von Erkrankungen und Erregern werden im Abschnitt Dokumenttypen vergleichend dargestellt.

Aufgabenstellung eMeldewesen

Um die Übermittlung von Meldungen über meldepflichtige Krankheiten und Erreger an die heutigen Rahmenbedingungen - welche durch eine hohe Mobilität der Menschen über große Entfernungen und ein größeres Risikopotential für die schnelle Ausbreitung von Infektionskrankheiten und Erregern gekennzeichnet sind - anzupassen, bietet sich die Nutzung von standardisierten und strukturierten Übermittlungsformaten an, die nicht nur eine schnelle Übertragung, sondern auch eine schnelle Verarbeitung und Auswertung dieser Meldungen ermöglichen. Wichtig für den flächendeckenden Einsatz eines elektronischen Meldeverfahrens ist dabei die möglichst weitgehende Unterstützung und Entlastung der meldepflichtigen Akteure von administrativen Zusatzaufwänden. Hierfür sind drei Teilaufgaben in einer für den Zweck angemessenen Detailtiefe zu lösen:

Primärsystemintegration

Idealerweise sollte die Erkennung eines meldepflichtigen Falles, das Ausfüllen einer Meldung an die zuständige Gesundheitsbehörde (hier im Fokus: namentliche Meldung an das Gesundheitsamt) und den Export einer elektronischen Meldung zur Übermittlung mittels eines geeigneten gesicherten Transportverfahrens in das Primärsystem integriert sein. Als Trigger für das Erkennen eines potentiell meldepflichtigen Falls kann beispielsweise bei Erkrankungen (Arztmeldung nach § 6 IfSG) die vom DIMDI in Abstimmung mit dem RKI gepflegte Kennzeichnung von Diagnosen in den Metadaten des ICD-10 genutzt werden. Das alleine löst aber noch nicht das Problem der Abbildung des entsprechenden Regelwerkes. Beispielsweise sollen Masern nur in Kombination mit Fieber gemeldet werden. Bei den Laborinformationssystemen ist die Erkennung eines meldepflichtigen Falls und eine Unterstützungsfunktion für die Erzeugung einer Meldung häufig schon implementiert. Hier liegt die Herausforderung darin eine strukturell und inhaltlich standardkonforme Meldung zu erzeugen und diese nicht wie bislang üblich an einen Fax-Server zu senden, sondern in ein CDA-Dokument einzubringen.

Strukturierter Datensatz

Für die Übermittlung vom meldepflichtigen Akteur an zuständigen Gesundheitsbehörden (Gesundheitsämter) bietet es sich an, in Anlehnung an den VHitG-Arztbrief auf der Basis HL7/CDA aufzusetzen und in diesem Rahmen einen standardkonformen Datensatz zu definieren. Die Inhalte des Datensatzes basieren im Wesentlichen auf den existierenden Muster-Meldebögen und versuchen auch die Perspektive der weiterverarbeitenden Meldekette (Gesundheitsamt, zuständige Landesbehörde und RKI) berücksichtigen. Des Weiteren muss der Datensatz den Anforderungen des Datenschutzes (hier insbes. Erforderlichkeit, Datensparsamkeit und Zweckbindung) genügen. Dies bedeutet u.a., dass die Inhalte auf jene personenbezogenen Informationen zu beschränken sind, die von der Rechtsgrundlage der Meldepflicht (IfSG) vorgegeben sind.

Darüber hinaus soll die Spezifikation so flexibel sein, dass die inviduellen Anforderungen der einzelnen Länder abbildbar sind.

Sicherer Transportweg

Um sicherzustellen, dass auf dem Weg vom Melder zum Gesundheitsamt keine unberechtigten Personen Kenntnis von den Inhalten der elektronischen Meldung erhalten können, sind geeignete Transportmechanismen vorzusehen. Aus Datenschutzsicht stehen hier die Aspekte Vertraulichkeit, Integrität und Authentizität im Vordergrund. Als Beispiele für sichere Transportwege werden technische Transportlösungen wie KV-SafeNet/D2D (evtl. künftig auch KV-CONNECT) oder OSCI-Transport angesehen, die ihrerseits bereits durch Datenschutzbeauftragte des Bundes oder der Länder positiv bewertet wurden. Perspektivisch ist jedoch bereits heute die Migration in die künftige Telematikinfrastruktur im Gesundheitswesen (TI) konzeptionell zu berücksichtigen.

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 .

Dynamisches Modell

Die inhaltliche Spezifikation ist unabhängig vom Transportweg:

Abbildung: Aufgabenstellung und Akteure einer elektronischen Meldung

D2D

Gegenwärtig wird in einer Reihe von Szenarien D2D als akzeptiertes Transportmittel eingesetzt, das auch vom Datenschützer akzeptiert ist:

Abbildung: Transport per D2D

Webservices

Denkbar wäre auch die Daten über eine gesicherte Verbindung bzw. verschlüsselt an einen Webservice zu übermitteln.

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 .

Dokumenttypen

Im Rahmen des Erprobungsprojektes in Nordrhein-Westfalen steht die Übermittlung der namentlichen Meldungen an das örtlich zuständige Gesundheitsamt im Fokus der Aktivitäten.

Während bei der Arztmeldung die Erkrankungen über den ICD-10-Code weitgehend auf CDA-Level 3 abgebildet werden können, ist für die Labormeldungen nach aktuellen Stand nicht sichergestellt, dass von allen Primärsystemen eine einheitliche Nomenklatur für die Erreger und Nachweismethoden verwendet wird. Aktuell wird bei den Labormeldungen ebenfalls CDA-Level 3 angestrebt. In diesem Zusammenhang gibt es konkrete Aktivitäten geeignete Kodiersystematiken zu erproben.

Dokumententyp	Beschreibung	Template-ID
Arztmeldung	Arztmeldung nach § 6 IfSG	1.2.276.0.76.10.1010
Labormeldung	Labormeldung nach § 7 Abs. 1 und 2 IfSG	1.2.276.0.76.10.1011

Im Leitfaden nicht betrachtet ist die nicht-namentliche Labormeldung nach § 7 Abs. 3 IfSG. Hierunter fällt die Meldung spezifischer Erreger (z.B. HIV) vom Labor direkt an das Robert Koch-Institut (RKI). Die identifizierenden Merkmale werden dabei entsprechend § 10 IfSG durch eine fallbezogene Verschlüsselung (Pseudonymisierung) ersetzt. Das Verfahren ist im Vergleich zu den anderen Meldungen im Zusammenspiel zwischen Labor, Arzt und RKI komplexer und wird derzeit noch über vom RKI herausgegebene, fortlaufend durchnummerierte Durchschreibebögen abgewickelt, die weitgehend manuell ausgefüllt werden. Dieser Meldungstyp ist aktuell nicht im Fokus des Projekts. Allerdings ist vorgesehen, die Anforderungen bezüglich der Kodierung der betreffenden Erreger und Nachweismethoden bereits konzeptionell zu berücksichtigen, um ein künftiges elektronisches Meldeverfahren zu unterstützen.

Dokumenttyp	Arztmeldebogen	Labormeldebogen
Header
Dokumentinformationen	1..1	1..1
Patient	1..1	1..1
Meldende Person/Stelle	1..1	1..1
Verwalter des Dokuments	1..1	1..1
Empfangendes Gesundheitsamt	1..1	1..1
Einsender	0..1	1..1
Auftragsidentifikation	0..1	1..1
Dienstleistung	0..1	1..1
Body Arztmeldung
Diagnose	1..*	-
Symptom	0..*	-
Angaben zum Tod (Text)	0..1	-
Zusatzangaben (Text)	0..1	-
Betreuung in Einrichtung (Text)	0..1	-
Tätigkeit (Text)	0..1	-
Impfstatus (Text)	0..1	-
Exposition (Text)	0..1	-
Spende (Text)	0..1	-
Labor (Text)	0..1	-
Body Labormeldung
Labormeldung Section	-	1..1
_Probenuntersuchung	-	1..*
__Abnahmeinformationen	-	1..1
__Annahmeinformationen	-	1..1
__Meldung	-	1..1
___Erreger	-	1..1
___Häufung von Beobachtungen	-	0..1
__Mikrobiologische Ergebnisse	-	0..*
__Laborergebnisse	-	1..*
___Laborergebnis	-	1..*
Zusatzangaben	-	0..1

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)

Id	1.2.276.0.76.10.2001	Gültigkeit	2013‑07‑10
Status	Aktiv	Versions-Label
Name	Header​Record​Target	Bezeichnung	CDA 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.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt	Benutzt 1 Template Benutzt als Name Version 1.2.276.0.76.10.90030 Inklusion Personenname DYNAMIC
Beziehung	Spezialisierung: 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>
Item DT Kard Konf Beschreibung Label hl7:recordTarget (Hea...get) @typeCode 0 … 1 F RCT @context​Control​Code 0 … 1 F OP   Beispiel <recordTarget typeCode="RCT" contextControlCode="OP">   <patientRole classCode="PAT">     <!-- ... -->   </patientRole></recordTarget> hl7:patientRole 1 … 1 (Hea...get) @classCode 0 … 1 F PAT   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> hl7:id II 1 … * (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"/> hl7:addr AD 0 … * Adresse des Patienten (Hea...get)   Beispiel <addr use="HP">   <streetName>Dorfstraße</streetName>  <houseNumber>54</houseNumber>  <postalCode>51371</postalCode>  <city>Leverkusen</city></addr> hl7:telecom TEL 0 … * 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"/> hl7:patient 0 … 1 (Hea...get) @classCode 0 … 1 F PSN @determiner​Code 0 … 1 F INSTANCE   Beispiel <patient classCode="PSN" determinerCode="INSTANCE">   <name>     <!-- ... -->   </name>  <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>  <birthTime value="19541223"/></patient> Eingefügt 1 … 1 M von 1.2.276.0.76.10.90030 Personenname (DYNAMIC) hl7:name PN 1 … 1 M Die 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> hl7:prefix ENXP 0 … * Titel (Hea...get) wo [@qualifier='AC'] @qualifier set_cs 1 … 1 F AC hl7:given ENXP 0 … * Vorname (Hea...get) hl7:prefix ENXP 0 … * Namenszusatz (Hea...get) wo [@qualifier='NB'] @qualifier set_cs 1 … 1 F NB hl7:prefix ENXP 0 … * Vorsatzwort (Hea...get) wo [@qualifier='VV'] @qualifier set_cs 1 … 1 F VV hl7:family ENXP 0 … * Nachname (Hea...get) hl7:suffix ENXP 0 … * Suffix (Hea...get) hl7:administrative​Gender​Code CE 1 … 1 R Geschlecht (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"/> hl7:birthTime TS.​DATE.​MIN 1 … 1 R Geburtsdatum des Patienten (Hea...get)   Beispiel <birthTime value="19491224"/> hl7:marital​Status​Code CE 0 … 1 Familienstand 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"/> hl7:religious​Affiliation​Code CE 0 … 1 Religionszugehö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"/> hl7:raceCode NP darf nicht verwendet werden (Hea...get) hl7:ethnic​Group​Code NP darf nicht verwendet werden (Hea...get) hl7:guardian 0 … * Vormund/Sachwalter des Patienten (Hea...get) hl7:addr AD 0 … 1 (Hea...get) hl7:telecom TEL 0 … * (Hea...get) Auswahl 1 … 1 Elemente in der Auswahl: hl7:guardian​Person hl7:guardian​Organization hl7:guardian​Person (Hea...get) hl7:name PN 1 … 1 M (Hea...get) hl7:guardian​Organization (Hea...get) hl7:name ON 1 … 1 M (Hea...get) hl7:birthplace 0 … 1 Geburtsort des Patienten (Hea...get)   Beispiel <birthplace>   <place>     <addr>Hamburg</addr>  </place></birthplace> hl7:place 1 … 1 M (Hea...get) hl7:addr AD 1 … 1 M (Hea...get) hl7:language​Communication 0 … * (Hea...get) hl7:language​Code CS 0 … 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) hl7:modeCode CE 0 … 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) hl7:proficiency​Level​Code CE 0 … 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) hl7:preference​Ind BL 0 … 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 .

Patient (recordTarget - spezialisiert)

Beschreibung

Der Aufbau der Personendaten des Patienten entspricht dem recordTarget-Template aus dem Arztbrief mit ein paar Besonderheiten. Für die namentliche Meldung (§ 9 IfSG) ist ein spezialisiertes Templates des recordTarget-Template aus dem Arztbrief zu verwenden.

Id	1.2.276.0.76.10.2006	Gültigkeit	gültig ab 2013‑10‑11
Status	Entwurf	Versions-Label
Name	Header​Record​TargetNotifiableDisease	Anzeigename	CDA recordTarget Meldepflichtige Krankheiten
Beschreibung
Label	hrtnd
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt	Benutzt von 3 Templates, Benutzt 0 Templates Benutzt von Template-Id als Name Version 1.2.276.0.76.10.1010 Arztmeldung nach §6 IfSG 2013‑07‑15 1.2.276.0.76.10.1011 Labormeldung nach §7 Abs. 1, 2 und 3 IfSG 2014‑07‑13 1.2.276.0.76.10.1011 Labormeldung nach §7 Abs. 1 und 2 IfSG 2013‑07‑15
Beziehung	Spezialisierung: Template 1.2.276.0.76.10.2001 (DYNAMIC) Spezialisierung: Template 2.16.840.1.113883.10.12.101 (DYNAMIC)
Beispiel	Beispiel <recordTarget contextControlCode="OP">   <patientRole classCode="PAT">     <id root="1.2.276.0.76.3.1.14.4711.1011.1.1" extension="OF011089M0"/>     <addr>       <streetName>Abc-Strasse</streetName>      <houseNumber>42</houseNumber>      <postalCode>44801</postalCode>      <city>Bochum</city>    </addr>    <telecom use="HP" value="tel:0234"/>     <patient classCode="PSN" determinerCode="INSTANCE">       <name use="A">         <given>Micky</given>        <family>Maus</family>      </name>      <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>       <birthTime value="19891001"/>     </patient>  </patientRole></recordTarget>
Item DT Kard Konf Beschreibung Label hl7:recordTarget hrtnd @typeCode 0 … 1 F RCT @context​Control​Code 0 … 1 F OP   Beispiel <recordTarget typeCode="RCT" contextControlCode="OP">   <patientRole classCode="PAT">     <!-- ... -->   </patientRole></recordTarget> hl7:patientRole 1 … 1 hrtnd @classCode 0 … 1 F PAT   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> hl7:id II 1 … * hrtnd   Beispiel <art:placeholder>   <id extension="6245" root="2.16.840.1.113883.3.933"/>   <id extension="1543627549" root="1.2.276.0.76.4.1"/> </art:placeholder> hl7:addr AD 1 … * Adresse des Patienten hrtnd   Beispiel <addr use="HP">   <streetName>Dorfstraße</streetName>  <houseNumber>54</houseNumber>  <postalCode>51371</postalCode>  <city>Leverkusen</city></addr> hl7:telecom TEL 0 … * Kontaktdaten des Patienten hrtnd   Beispiel <art:placeholder>   <telecom use="H" value="tel:+49.30.140400"/>   <telecom use="MC" value="tel:+49.221.1234567"/>   <telecom value="mailto:herberthannes.mustermann@provider.de"/> </art:placeholder> hl7:patient 0 … 1 hrtnd @classCode 0 … 1 F PSN @determiner​Code 0 … 1 F INSTANCE   Beispiel <patient classCode="PSN" determinerCode="INSTANCE">   <name>     <!-- ... -->   </name>  <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>   <birthTime value="19541223"/> </patient> hl7:name PN 1 … 1 M hrtnd   Beispiel <name>   <given>Johannes</given>  <family>Tremener</family></name> hl7:administrative​Gender​Code CE 1 … 1 R Geschlecht (administrativ) des Patienten hrtnd   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"/> hl7:birthTime TS.​DATE.​MIN 1 … 1 R Geburtsdatum des Patienten hrtnd   Beispiel <birthTime value="19491224"/>

Bemerkungen

• Der Name des Patienten ist anzugeben
  • bei namentlicher Meldung des Patienten mit seinem vollen Namen,
  • bei nichtnamentlicher Meldung des Patienten mit einem Pseudonym. Der Aufbau des Pseudonyms ist verpflichtend in § 10 Abs. 2 IfSG geregelt.

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 - spezifisch) pseudonymisierter Patient

Template ID	<OID für das Template>
genutztes Template	recordTarget generisch: cdaab2:Patient_(recordTarget)_(Template)
abgeleitete Templates	keines
General Description	Dieses Template spezifiziert, wie ein Patient in pseudonymisierter Form angegeben werden kann.
Erweiterbarkeit	geschlossen

Beschreibung des Headertemplates "Patient"

Das recordTarget repräsentiert die Person, über die dokumentiert wird. recordTarget ist Teil des CDA-Headers.

Wichtig ist hier die Information, dass die Angaben selbst pseudonymisiert sind, d.h. auch wenn ein Name angegeben ist, so ist damit nicht der "echte" Name des Patienten gemeint. Dies wird über ein constraint auf name.use mit dem Wert "A" (pseudonym) realisiert.

Die meisten Informationen sind optional und können weggelassen werden. Sie sind aber in diesem Template dennoch enthalten, da mitunter bei pseudonymisierten Patienten durchaus Detailangaben (wie bspe. Name, Geschlecht und Adresse) notwendig sind. So kann dieses Template bspw. bei Meldungen verwendet werden, die in pseudonymisierter Form geschehen müssen, aber trotzdem Angaben zum Wohnort oder dem Alter des Patienten enthalten sollen.

Folgende Pseudonyme werden vorgesehen:

1. "Umkehrbar eindeutige Pseudonyme" (Angabe von Identifikator + Quellsystem)
   Anwendungsbeispiele: Identifikation über Nachsorgepass Bayern, Identifikation im Tumorzentrum Xy, Identifikation in Organzentrumssystem Xyz => OID mit Extension!
2. "Stochastische Pseudonyme" (Kontrollnummern)
   Bestimmte Attribute wie Namen oder Geburtsdatum sind dann optional, die dann in ganz definierten Kommunikationskontexten durch Kontrollnummern ersetzt werden.

Die Identifikatoren unter 1. wären in jedem Fall sinnvoll für das automatisierte Record Linkage im Zielsystem, wenn es hier nicht geht, dann woanders.

Einordnung im CDA R-MIM - Identifikation des Patienten

Abbildung xx: Identifikation des pseudonymisierten Patienten (Auszug aus dem CDA R-MIM)

Attribute

In dieser Tabelle werden die constarints zur generischen Tabelle angegeben.

Lvl	RIM	XPath	DT	Kard	Conf	Änderungen zum generischen Model
3	role	recordTarget.patientRole.id	II.DE	1..*	M	Identifikation des Patienten: Im Attribut @extension wird die Id des Patienten selbst angegeben, während @root auf das die Identifikation ausgebende Vertrauensstelle hinweist.
3	role	recordTarget.patientRole.telecom	TEL	0..0	NP	Darf nicht verwendet werden
4	ent	recordTarget.patientRole.patient.name	PN.DE	0..*	O	name.use="A" Gibt an, dass es sich um ein Pseudonym handelt
4	role	recordTarget.patientRole.patient.guardian		0..0	NP	Darf nicht verwendet werden
4	lang	recordTarget.patientRole.patient.languageCommunication		0..0	NP	Darf nicht verwendet werden

Beispiel für die CDA-Repräsentation

<!-- Pseudonymisierte Patienten Daten -->
<recordTarget typeCode="RCT" >
    <patientRole classCode="PAT" >
        <id root="1.2.276.0.76.4.5.100400853" extension="0815" />
        <patient>
             <name use="A">
                 <given>Dagobert</given>
                 <family>Duck</family>
             </name>
        </patient>
    </patientRole>
</recordTarget>

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 pseudonymisiert (recordTarget - spezialisiert)

Beschreibung

Bei einer nichtnamentlichen Meldung (§ 10 IfSG) ist eine Spezialisierung des Templates für den pseudonymisierten Patienten zu verwenden.

Die nichtnamentliche Meldung ist nur bei Labormeldungen nach § 7 Abs. 3 IfSG zu verwenden. Aktuell fällt darunter der direkte oder indirekte Nachweis folgender Krankheitserreger: Treponema pallidum, HIV, Echinococcus sp., Plasmodium sp., Toxoplasma gondii

Der Aufbau entspricht dem Pseudonymisierter Patient jedoch ergänzt durch folgende Bedingungen:

Id	1.2.276.0.76.10.2014	Gültigkeit	gültig ab 2013‑10‑11
Status	Entwurf	Versions-Label
Name	Header​Record​TargetPseudonymNotifiableDisease	Anzeigename	CDA recordTarget Meldepflichtige Krankheiten Pseudonym
Label	hrtpsnnd
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt	Benutzt von 1 Template, Benutzt 0 Templates Benutzt von Template-Id als Name Version 1.2.276.0.76.10.1011 Labormeldung nach §7 Abs. 1, 2 und 3 IfSG 2014‑07‑13
Beziehung	Spezialisierung: Template 1.2.276.0.76.10.2001 (DYNAMIC) Spezialisierung: Template 1.2.276.0.76.10.2006 (DYNAMIC)
Item DT Kard Konf Beschreibung Label hl7:recordTarget hrtpsnnd @typeCode 0 … 1 F RCT @context​Control​Code 0 … 1 F OP   Beispiel <recordTarget typeCode="RCT" contextControlCode="OP">   <patientRole classCode="PAT">     <id extension="186245" root="1.2.276.0.76.3.1.139.3.871"/>     <patient classCode="PSN" determinerCode="INSTANCE">       <!-- ... -->     </patient>  </patientRole></recordTarget> hl7:patientRole 1 … 1 hrtpsnnd @classCode 0 … 1 F PAT hl7:id II 1 … * hrtpsnnd   Beispiel <id extension="6245" root="2.16.840.1.113883.3.933"/> <id extension="1543627549" root="1.2.276.0.76.4.1"/> <id root="1.2.276.0.76.4.5.100400853" extension="0815"/> hl7:patient 0 … 1 hrtpsnnd @classCode 0 … 1 F PSN @determiner​Code 0 … 1 F INSTANCE   Beispiel <patient classCode="PSN" determinerCode="INSTANCE">   <name>     <!-- ... -->   </name>  <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>   <birthTime value="19541223"/> </patient> hl7:name PN 1 … 1 M hrtpsnnd @use 1 … 1 F A   Beispiel <name use="A">   <given>Dagobert</given>  <family>Duck</family></name>

Bemerkung

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 .

Meldende Person / Meldende Stelle (author)

Beschreibung

Mit dem Element author wird die Meldende Person oder Meldende Stelle definiert.

Id	1.2.276.0.76.10.2002	Gültigkeit	2013‑07‑10
Status	Entwurf	Versions-Label
Name	HeaderAuthor	Bezeichnung	CDA author
Beschreibung	Die 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.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt	Benutzt 2 Templates Benutzt als Name Version 1.2.276.0.76.10.90010 Inklusion CDA Person Elements DYNAMIC 1.2.276.0.76.10.90011 Inklusion CDA Organization Elements DYNAMIC
Beziehung	Spezialisierung: 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>
Item DT Kard Konf Beschreibung Label hl7:author (Hea...hor) @typeCode 0 … 1 F AUT @context​Control​Code 0 … 1 F OP   Beispiel <author typeCode="AUT" contextControlCode="OP">   <time value="201306101654"/>  <assignedAuthor classCode="ASSIGNED">     <!-- ... -->   </assignedAuthor></author> hl7:functionCode CE 0 … 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) hl7:time TS.​DATE.​MIN 1 … 1 gibt 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) hl7:assignedAuthor 1 … 1 (Hea...hor) @classCode 0 … 1 F ASSIGNED hl7:id II 1 … * (Hea...hor) hl7:code CE 0 … 1 Fachgebiet/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) hl7:telecom TEL 0 … * (Hea...hor) Auswahl 1 … 1 Elemente in der Auswahl: hl7:assigned​Person hl7:assigned​Authoring​Device hl7:assigned​Person  … 1 (Hea...hor) Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC) @classCode 0 … 1 F PSN @determiner​Code 0 … 1 F INSTANCE hl7:name PN 1 … 1 M (Hea...hor) hl7:assigned​Authoring​Device  … 1 (Hea...hor) @classCode 0 … 1 F DEV @determiner​Code 0 … 1 F INSTANCE hl7:manufacturer​Model​Name SC 1 … 1 (Hea...hor) hl7:softwareName SC 1 … 1 (Hea...hor) hl7:represented​Organization 1 … 1 M (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) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 0 … * (Hea...hor) hl7:name ON 1 … 1 M (Hea...hor) hl7:telecom TEL 0 … * (Hea...hor) hl7:addr AD 0 … 1 (Hea...hor)

Bemerkungen

• In author.time wird der Meldungszeitpunkt vermerkt
• author.assignedAuthor.id enthält die eindeutige Identifizierung der meldenden Person.

• author.assignedAuthor.assignedPerson spiegelt die Meldende Person wider. Diese Angaben sind Pflicht, da laut Gesetz eine Person (Arzt/Leiter bei Labor) die Meldung auslösen kann. Hierbei sind Vor- und Nachname ausreichend (assignedPerson.name), das Aufnehmen einer Telefonnummer (assignedPerson.telecom) sinnvoll.

• author.assignedAuthor.representedOrganization stellt die Meldende Einrichtung dar. Für das Gesundheitsamt ist einzig die Einrichtung als Melder relevant, eine Person nur sekundär (und Angaben zur IT irrelevant). representedOrganization.id enthält die eindeutige Identifizierung und representedOrganization.name Bezeichnung der meldenden Einrichtung.

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: Die das Dokument verwaltende Organisation (custodian)

Id	1.2.276.0.76.10.2004	Gültigkeit	2020‑03‑29 Andere Versionen mit dieser Id: HeaderCustodian vom 2013‑07‑17 HeaderCustodian vom 2013‑07‑07
Status	Aktiv	Versions-Label
Name	HeaderCustodian	Bezeichnung	CDA custodian
Beschreibung	Verantwortliche Organisation für ein erstelltes Dokument (die das Dokument verwaltende Organisation). In der Regel ist es die erstellende Institution des Dokumentes.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Item DT Kard Konf Beschreibung Label hl7:custodian (Hea...ian) @typeCode 0 … 1 F CST   Beispiel <custodian typeCode="CST">   <assignedCustodian classCode="ASSIGNED">     <representedCustodianOrganization classCode="ORG" determinerCode="INSTANCE">       <!-- ... -->     </representedCustodianOrganization>  </assignedCustodian></custodian> hl7:assignedCustodian 1 … 1 M (Hea...ian) @classCode 0 … 1 F ASSIGNED hl7:represented​Custodian​Organization 1 … 1 M (Hea...ian) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 1 … 1 M (Hea...ian) hl7:name ON 1 … 1 M (Hea...ian) hl7:telecom TEL 0 … 1 (Hea...ian) hl7:addr AD 0 … 1 (Hea...ian)

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 .

Empfangendes Gesundheitsamt (informationRecipient)

Beschreibung

Im informationRecipient wird das zuständige Gesundheitsamt als Empfänger definiert. Bei Abweichung zwischen Hauptwohnsitz und Aufenthaltsort sind ggf. mehrere Empfänger sinnvoll - dies sollte langfristig vorgesehen werden.

Id	1.2.276.0.76.10.2005	Gültigkeit	2013‑07‑10
Status	Aktiv	Versions-Label
Name	Header​Information​Recipient	Bezeichnung	CDA 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).
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt	Benutzt 2 Templates Benutzt als Name Version 1.2.276.0.76.10.90010 Inklusion CDA Person Elements DYNAMIC 1.2.276.0.76.10.90011 Inklusion CDA Organization Elements DYNAMIC
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>
Item DT Kard Konf Beschreibung Label hl7:information​Recipient 0 … * (Hea...ent) @typeCode cs 0 … 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 hl7:intended​Recipient 1 … 1 M (Hea...ent) hl7:id II 1 … * R (Hea...ent) Auswahl 1 … * 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 hl7:information​Recipient 0 … 1 (Hea...ent) Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC) @classCode 0 … 1 F PSN @determiner​Code 0 … 1 F INSTANCE hl7:name PN 1 … 1 M (Hea...ent) hl7:received​Organization 0 … 1 (Hea...ent) Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 0 … * (Hea...ent) hl7:name ON 1 … 1 M (Hea...ent) hl7:telecom TEL 0 … * (Hea...ent) hl7:addr AD 0 … 1 (Hea...ent)

Bemerkungen

• Für den typeCode ist bis auf Weiteres konstant PRCP (Primary Recipient) zu verwenden.
• Das intendedRecipient.id enthält die eindeutige Identifizierung des adressierten Gesundheitsamts

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 .

Anhang

Liste der Value Sets

Id	2.16.840.1.113883.1.11.1	Gültigkeit	2014‑03‑26
Status	Definitiv	Versions-Label	DEFN=UV=VO=1360-20160323
Name	AdministrativeGender	Bezeichnung	AdministrativeGender
Beschreibung	History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26 description: The gender of a person used for adminstrative purposes (as opposed to clinical gender)
Quell-Codesystem	2.16.840.1.113883.5.1 - Administrative Gender - http://terminology.hl7.org/CodeSystem/v3-AdministrativeGender
Level/ Typ Code Bezeichnung Codesystem 0‑L F Female Administrative Gender 0‑L M Male Administrative Gender 0‑L UN Undifferentiated Administrative Gender
Legende: Typ L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors werden im @nullFlavor Attribut statt in @code angegeben. NullFlavor OTH (other) schlägt Text in originalText vor.

• ICD-10 GM 2013 1.2.276.0.76.11.413 oder aktueller