Cdaepb:Statisches Modell

Aus Hl7wiki
(Teildokument von )
Wechseln zu: Navigation, Suche
(→‎Attribute)
(→‎Attribute)
Zeile 728: Zeile 728:
 
| 0..*
 
| 0..*
 
| optional
 
| optional
−
| <syntaxhighlight lang="xml">
+
| {{fmbox
−
{{WorkBox|Soll die Telefonnummer verpflichtend angegeben werden?}}
+
| image = [[Bild: Question_icon.svg|50px]]
−
</syntaxhighlight>
+
| text = Soll die Angabe einer Telefonnummer verpflichtend erfolgen?
 +
}}  
  
 
|-
 
|-

Version vom 6. Juni 2013, 14:59 Uhr

Statisches Modell

Header

Die grundlegenden Spezifikationen eines CDA R2 Dokuments und Headers aus dem elektronischen Arztbrief werden auch auf den elektronischen Pflegebericht übertragen. Dies gilt sowohl für die Dokumentenstruktur, die Konformanz-Anforderungen, sowie die CDA-Header-Elemente, deren Datentypen bzw. Bedeutung und deren Kardinalitäten. Auch die im Arztbrief genannten Regeln werden für den Pflegebericht übernommen.

Conformance.svg Regel EPBH: Grundsätzlich werden die Inhalte und Spezifikationen des CDA-Headers des elektronischen Arztbriefes und die dort genannten Regeln übernommen und auf diese verwiesen. Domänenspezifische Ergänzungen oder Spezifikationen werden anhand der im Arztbrief verwendeten Gliederung erläutert.


In Abweichung zum Arztbrief werden folgende Elemente für den CDA-Header des elektronischen Pflegeberichts spezifiziert bzw. ergänzt:

Typisierung des Dokuments

< Element DT Card Conf Beschreibung
code CE CWE 1..1 M Dokumententyp


Über das code Modellattribut der ClinicalDocument Klasse wird eine Typisierung des Dokuments vorgenommen. Zur eindeutigen Identifikation der Typisierung wird das Codesystem LOINC (Logical Observation Identifiers Names and Codes \[LOINC\]) verwendet. Im XML @code Attribute steht der eigentliche Code, @codeSystem ist die OID des LOINC Systems (2.16.840.1.113883.6.1).

Conformance.svg Regel CDCD: Beim ClinicalDocument.code ist die Angabe von @code und @codeSystem verpflichtend.
Conformance.svg Regel CDLN: Als Codesystem für ClinicalDocument.code ist LOINC zu verwenden.

Der optionale @displayName kann die klartextliche Bedeutung wiedergeben, darf aber von der empfangenden Anwendung selbst nicht ausgewertet werden.

Für den elektronischen Pflegebericht gelten hier folgender Codes:

Conformance.svg @code MUSS gewählt werden aus "28651-8" - "Pflegerischer Verlegungsbericht" oder "34745-0" - "Pflegerischer Entlassungsbericht" STATIC 2012-12-15 
<code code="28651-8" codeSystem="2.16.840.1.113883.6.1"
      displayName="Pflegerischer Verlegungsbericht"/>

Religionszugehörigkeit des Patienten

Im Umfeld von Pflege spielen Religion und Spirituaität immer wieder eine Rolle. In diesem Zusammengang sind auch für die Pflegekräfte und andere an der Versorgung beteiligte Personen Informationen dazu von Bedeutung. Aus diesem Grund wird für den ePflegebericht auf folgende Spezifikation im Bereich Religion hingewiesen:

In der PatientClass ermöglicht das Element ReligiousAffiliation die Zuordnung einer Glaubensgemeinschaft.

Hier muss das Bild noch eingefügt werden.

< Element DT Card Conf Beschreibung
religiousAffiliationCode CE CWE 0..1 O Religionszugehörigkeit
Conformance.svg @religiousAffiliationCode MUSS gewählt werden aus ValueSet 2.16.840.1.113883.5.1076 religiousAffiliationCode STATIC 2012-12-15

Die Glaubensgemeinschaft ist codiert aus dem entsprechenden HL7 Vokabular anzugeben. Im @code Attribut wird der Code angegeben. Die im @CodeSystem anzugebende OID ist hier konstant 2.16.840.1.113883.5.1076.


Mitgliedschaft in einer Gemeinde

Talk.svg Diese ausführliche Beschreibung einer Mitgliedschaft in einer Kirchengemeinde ist nicht Teil der CDA. Somit müssen die folgenden Klassen (member.RoleClass, religious.Organization) und ihre Elemente in XML mit einem foreign namespace dargestellt werden.


Soll der Patient darüber hinaus als Mitglied einer konkreten Gemeinde beschrieben werden, kann dem Patient die Rolle als Miltglied einer religiösen Organisation zugeordnet werden.

< Element DT Card Conf Beschreibung
member 0..1 O Mitgliedschaft
Conformance.svg @roleClassCode MUSS im Zusammenhang mit der Zugehörigkeit zu Glaubensgemeinschaften auf MBR aus dem HL7 Vokabular RoleClass beschränkt werden STATIC 2012-12-15


Kirchliche Gemeinde

Die Gemeinde der Religionsgemeinschaft, zu der der Patient gehört, wird als Organisation dargestellt.

< Element DT Card Conf Beschreibung
Organization 0..1 O Gemeinde als Organisation
Conformance.svg @entityClassCode MUSS im Zusammenhang mit der Zugehörigkeit zu Glaubensgemeinschaften auf ORG aus dem HL7 Vokabular EntityClass beschränkt werden STATIC 2012-12-15


Um die Organisation als religiöse Institution zu spezifizieren, wird der EntityCode auf RELIG festgelegt.

< Element DT Card Conf Beschreibung
code CE CWE 1..1 M Klassifzierung der Organisation
Conformance.svg @entityCode MUSS im Zusammenhang mit der Zugehörigkeit zu Glaubensgemeinschaften auf RELIG aus dem HL7 Vokabular EntityCode beschränkt werden STATIC 2012-12-15


Um eine Kontaktaufnahme zu erleichtern, kann analog zur Darstellung einer Organisation aus dem Arztbrief eine ID, ein Name der Gemeinde, eine Adresse oder ein Telekommunikationskontakt angegeben werden.

Herr Schimanski ist Mitglied der katholischen St. Matthias Gemeinde Halle. 

<patient>
    <name>
        <given>Heinz</given>
        <family>Schimanski</family>
    </name>
    <administrativGenderCode code="M" codeSystem="2.16.840.1.113883.5.1" displayName="männlich"/>
    <birthTime value="19390427"/>
    <religiousAffiliationCode="1041" codeSystem="2.16.840.1.113883.5.1076" displayName="römisch-katholisch"/>
    <member code="MBR" classCode="2.16.840.1.113883.5.110">
        <organization code="ORG" codeSystem="2.16.840.1.113883.5.41">
            <code code="RELIG" codeSystem="2.16.840.1.113883.5.1060"/>
            <name>St. Matthias</name>
            <telecom>0123/12345</telecom>
            <addr>
                <streetName>Matthiasstrasse</streetName>
                <houseNumber>1</houseNumber>
                <postalCode>32323</postalCode>
                <city>Halle</city>
            </addr>
        </organization>
    </member>
</patient>

Sprachfertigkeiten des Patienten

Vor dem Hintergrund einer zunehmenden Zahl älterer und damit pflegebedrüftiger Menschen mit Migrationshintergrund können sowohl die Sprache als auch die Staatsbürgerschaft für die Pflege eine Rolle spielen. Die Sprachfertigkeiten eines Patienten zu der genannten Sprache können in der Klasse LanguageCommunication wiedergegeben werden.

< Element DT Card Conf Beschreibung
languageCommunication 0..1 Sprachfertigkeiten des Patienten


Folgende Elemente gehören zur LanguageCommunicationClass:

< Element DT Card Conf Beschreibung
languageCode CE CWE 1..1 M Identifzierung der Sprache analog zur Regel CDLC des Arztbriefes
Conformance.svg Das Format ist entsprechend ss-CC, mit ss, zwei Kleinbuchstaben für den Sprachencode gemäß ISO-639-1, und CC, zwei Großbuchstaben für den Ländercode gemäß ISO 3166 (Tabelle mit zwei Buchstaben) anzugeben


Die Sprachfertigkeiten können über die Elemente modeCode und profiencyLevelCode und preferenceInd näher spezifiziert werden.

@ Attribut DT Card Conf Beschreibung
modeCode CE CWE 0..1 O Typisierung der Sprachfertigkeit
Conformance.svg @languageAbilityModeCode MUSS gewählt werden aus dem HL7 ValueSet languageAbilityMode STATIC 2012-12-15


@ Attribut DT Card Conf Beschreibung
proficiencyLevelCode CE CWE 0..1 O Qualifizierung der Sprachfertigkeit
Conformance.svg @languageAbilityProficiencyCode MUSS gewählt werden aus dem HL7 ValueSet languageAbilityProficiency STATIC 2012-12-15


< Element DT Card Conf Beschreibung
preferenceInd BL 0..1 O Indikator für bevorzugte Sprache


Ist der optionale preferenceInd auf true gesetzt, bedeutet dies, dass die zugehörige Sprache (angegeben über languageCode), für die angegebene Sprachfertigkeit (modeCode) der bevorzugten Sprache des Patienten entspricht. Für den gegenteiligen Fall wird der preferenceInd auf false gesetzt.


Herr Schimanski spricht sowohl polnisch als auch deutsch. Seine bevorzugte Sprache ist deutsch. 

<patient>
    <name>
        <given>Heinz</given>
        <family>Schimanski</family>
    </name>
    <administrativGenderCode code="M" codeSystem="2.16.840.1.113883.5.1" displayName="männlich"/>
    <birthTime value="19390427"/>
    <religiousAffiliationCode="1041" codeSystem="2.16.840.1.113883.5.1076" displayName="römisch-katholisch"/>
    <languageCommunication>
        <languageCode code="de-DE"/>
        <modeCode code="ESP" codeSystem="2.16.840.1.113883.5.60"/>
        <profiencyLevelCode code="E" codeSystem="2.16.840.1.113883.5.61"/>
        <preferenceInd value="true"/>
        <languageCode code="pl-PL"/>
        <modeCode code="ESP" codeSystem="2.16.840.1.113883.5.60"/>
        <profiencyLevelCode code="E" codeSystem="2.16.840.1.113883.5.61"/>
        <preferenceInd value="false"/>        
    </languageCommunication>
</patient>


Vormundschaft für den Patienten

Hat der Patient eine gesetzliche Betreuung, ist dies für die an der Versorgung beteiligten Pflegekräfte eine wichtige Information. Da der eArztbrief diese Information zunächst nicht darstellt, wird diese optionale Angabe aus diesem Grund an dieser Stelle beschrieben.

Guardian

Ausgehend von der Patientenklasse verweist die RoleClass guardian auf eine Person als gesetzlicher Betreuer.

< Element DT Card Conf Beschreibung
guardian 0..1 O Vormundschaft
Conformance.svg @roleClassCode MUSS im Zusammenhang mit der Rolle einer Person als gesetzlicher Betreuer auf GUARD aus dem HL7 Vokabular RoleClass beschränkt werden STATIC 2012-12-15

Die RoleClass guardian kann Angaben zur Identifikationsnummer, zur Adresse und zu den Telekommunikationsdaten des gesetzlichen Betreuers enthalten.

Person als Betreuer

Die roleClass guardian verweist auf die EntityClasses Person und Organization. Da die gesetzliche Betreuung von einer Person übernommen werden muss, ist für den Fall, dass eine Angabe zum gesetzlichen Betreuer gemacht wird, die Angabe einer Person verpflichtend. Sollte diese Person zu einer Träger-Organisation (z.B. kirchlicher Träger) gehörn, kann diese optional benannt werden.

< Element DT Card Conf Beschreibung
person 1..1 M Assoziation mit Person als Betreuer
< Element DT Card Conf Beschreibung
organization 1..1 M Assoziation mit Organisation des Betreuers

Für die Beschreibungen der EntityClasses Person und Organization wird auf den eArztbrief verwiesen.

Frau Getrud Schimanski ist als gesetzliche Betreuerin eingesetzt worden. 

<patient>
    <name>
        <given>Heinz</given>
        <family>Schimanski</family>
    </name>
    <administrativGenderCode code="M" codeSystem="2.16.840.1.113883.5.1" displayName="männlich"/>
    <birthTime value="19390427"/>
    <religiousAffiliationCode="1041" codeSystem="2.16.840.1.113883.5.1076" displayName="römisch-katholisch"/>
    <guardian code="GUARD" classCode="2.16.840.1.113883.5.110">
        <addr>
            <streetName>Gerade Straße</streetName>
            <houseNumber>16</houseNumber>
            <postalCode>32132</postalCode>
            <city>Halle</city>
        </addr>
        <person>
            <name>
                <given>Gertrud</given>
                <family>Schimanski</family> 
            </name>
        </person>
    </guardian>
</patient>


Staatsbürgerschaft des Patienten

Da es im pflegerischen Bereich sinnvoll sein kann die Nationalität des Patienten anzugeben, wird die Darstellung der Informationen zur Nationalität des Patienten aus dem Implementierungsleitfaden zur Patientenidentifikation in den Pflegebericht übernommen.

Dieses Material ist Teil des Leitfadens [[Category:|Cdaepb:Statisches Modell]].
  • 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: [[:Category:|hier]], Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Weitere Beteiligte (participant)

Template ID <OID für das Template>
General Description Dieses Template spezifiziert, wie die Daten zu weiteren Beteiligten grundsätzlich angegeben werden.
Opt. Description
required Dies ist das Grundlagentemplate zur Angabe von Weiteren Beteiligten im CDA-Header.


Beschreibung des Headertemplates "Weitere Beteiligte"

Mit dieser Assoziation und den entsprechenden Klassen können weitere für die Dokumentation wichtige beteiligte Personen oder Organisationen wie Angehörige, Verwandte, Versicherungsträger sowie weitere in Beziehung zum Patienten stehende Parteien genannt werden.

Faq.svg Die unterschiedlichen Spezialisierungen für:
  • Versicherungsnummer (DRV- Entlassbericht)
  • Versichertendaten und Kostenträger (cdaonk)
  • Angehörige/Wohnpartner (cdaepb)
  • Einsender (cdapath)
  • Behandlungsort (cdatb)
sind jeweils durch eigene Templates zu repräsentieren (s.u.).

Einordnung im CDA R-MIM - Identifikation des "Weiteren Beteiligten"

Weitere Beteiligte

Abbildung xx: Identifikation weiterer Beteiligter (Auszug aus dem CDA R-MIM)


Attribute

Lvl RIM Name Desc DT Kard Conf Beschreibung
0 act ClinicalDocument Dokument 1..1 M
1 part participant weitere Beteiligte 0..* optional Weitere für die Dokumentation wichtige Personen oder Organisationen
2 part @typeCode Typisierung der Beteiligung CS CNE 1..1 M aus participationType (KodeSystem)
2 part @contextControlCode "OP" 1..1 requiered fix

Übertragung einer Beteiligung des gleichen @typeCodes an untergeordnete Acts, die eine solche Übernahme erlauben; "OP": Die Beteiligung an übergeordneten ActClasses wird nicht übernommen. Gleichzeitig wird aber die beschriebene Beteiligung an untergeordnete ActClasses vererbt.

2 part functionCode Funktion der beteiligten Person/Organisation CE 0..1 optional aus ParticipationFunction (ValueSet)
2 part time IVL<TS> 0..1 optional Zeitraum der Beteiligung
2 role associatedEntity Assoziation 0..1 optional
3 role @classCode Klassifizierung der Beteiligung CS CNE 1..1 M aus RoleClassAssociative (ValueSet)
3 role id Identifikation des Beteiligten II 0..* optional Hier kann die Identifikation des Beteiligten im zugehörigen Kontext angegeben werden.

Im Attribut @extension wird die Id selbst angegeben, während @root auf das die Identifikation ausgebende Anwendungssystem bzw. den dazugehörigen Nummernkreis hinweist, das mittels Object Identifier (OID) beschrieben wird.

3 role roleCode Spezifizierung der Beteiligung CE 0..1 optional aus RoleCode (CodeSystem)
3 role addr Adresse der beteiligten Entität AD.DE 0..* optional
3 role telecom Telekommuikationskontakte der beteiligten Entität TEL 0..* optional
4 ent associatedPerson beteiligte Person 0..1 optional
5 ent @classCode "PSN" CS CNE 1..1 M fix
5 ent name Name PN.DE 0..* optional Name der beteiligten Person
4 ent scopingOrganization beteiligte Organisation 0..1 optional
5 ent @classCode "ORG" CS CNE 1..1 M fix
5 ent id Identifikation II 0..* optional Identifikation der beteiligten Organisation

Im Attribut @extension wird die Id selbst angegeben, während @root auf das die Identifikation ausgebende Anwendungssystem bzw. den dazugehörigen Nummernkreis hinweist, das mittels Object Identifier (OID) beschrieben wird.

5 ent name Name ON 1..1 M Name der beteiligten Organisation
5 ent addr Adresse AD.DE 0..* optional Adresse der beteiligten Organisation
5 ent telecom Telekommuikationskontakte TEL 0..* optional Telekommuikationskontakte der beteiligten Organisation

Beispiel für die CDA Repräsentation

<participant typeCode="..." contextControlCode="OP">
    <fucntionCode code="..." codeSystem="2.16.840.1.113883.5.88"/>
    <time>
        <low value="..."/>
        <high value="..."/>
    </time>
    <associatedEntity classCode="...">
        <id extension="..." root="..."/>
        <code code="..." codeSystem="2.16.840.1.113883.5.111"/>
        <addr>
          <streetName>...</streetName>
          <houseNumber>...</houseNumber>
          <postalCode>...</postalCode>
          <city>...</city>
        </addr>
        <telecom use=".." value="..."/>
        <associatedPerson classCode="PSN">
            <name>
                <given>...</given>
                <family>...</family>
            </name>
        </associatedPerson>
        <scopingOrganization classCode="ORG">
            <id extension="..." root="..."/>
            <name>...</name>
            <addr>
                <streetName>...</streetName>
                <houseNumber>...</houseNumber>
                <postalCode>...</postalCode>
                <city>...</city>
            </addr>
            <telecom use=".." value="..."/>
        </scopingOrganization>
    </associatedEntity>
</participant>

Einschränkungen des generischen templates

Faq.svg Es ist zu beachten, dass es unterschiedliche Spezialisierungen geben kann: Diese sind jeweils durch eigene Templates repräsentiert.
Under construction icon-blue.svg Muss das template "Versichertendaten und Kostenträger" noch um die Familienversicherung ergänzt werden?

Weitere Beteiligte (Angehörige)

Die Darstellung von Angehörigen oder Wohnpartnern stellt eine Einschränkung des generischen Headertemplates "weitere Beteiligte (participant).

Attribute

Lvl RIM Name Desc DT Kard Conf Beschreibung
0 act ClinicalDocument Dokument 1..1 M
1 part participant weitere Beteiligte 0..* optional Weitere für die Dokumentation wichtige Personen oder Organisationen
2 part @typeCode IND CS CNE 1..1 M fix
2 part @contextControlCode "OP" 1..1 requiered fix

Übertragung einer Beteiligung des gleichen @typeCodes an untergeordnete Acts, die eine solche Übernahme erlauben; "OP": Die Beteiligung an übergeordneten ActClasses wird nicht übernommen. Gleichzeitig wird aber die beschriebene Beteiligung an untergeordnete ActClasses vererbt.


2 role associatedEntity Assoziation 1..1 M
3 role @classCode PRS CS CNE 1..1 M fix
3 role roleCode Spezifizierung der Beteiligung CE 0..1 optional aus PersonalRelationshipRoleType (ValueSet)
3 role addr Adresse der beteiligten Entität AD.DE 0..* optional
3 role telecom Telekommuikationskontakte der beteiligten Entität TEL 0..* optional
Question icon.svg Soll die Angabe einer Telefonnummer verpflichtend erfolgen?
4 ent associatedPerson beteiligte Person 1..1 M
5 ent @classCode "PSN" CS CNE 1..1 M fix
5 ent name Name PN.DE 1..1 M Name der beteiligten Person
4 ent scopingOrganization beteiligte Organisation 0..1 optional
5 ent @classCode "ORG" CS CNE 1..1 M fix
5 ent id Identifikation II 0..* optional Identifikation der beteiligten Organisation

Im Attribut @extension wird die Id selbst angegeben, während @root auf das die Identifikation ausgebende Anwendungssystem bzw. den dazugehörigen Nummernkreis hinweist, das mittels Object Identifier (OID) beschrieben wird.

5 ent name Name ON 1..1 M Name der beteiligten Organisation
5 ent addr Adresse AD.DE 0..* optional Adresse der beteiligten Organisation
5 ent telecom Telekommuikationskontakte TEL 0..* optional Telekommuikationskontakte der beteiligten Organisation

Weitere Spezifikationen des Headers

Information icon.svg Weitere Spezifikationen des CDA- Headers ergeben sich aus dem ePflegebericht nicht.



Body

Talk.svg Die allgemeinen Angaben zu einem CDA- Body, die im eArztbrief ausführlich beschrieben werden, gelten auch für den CDA- Body des ePflegeberichts. Es handelt sich hierbei um die Spezifikationen zu:
Conformance.svg Die im Arztbrief definierte Regel SCLN zur Verwendung von LOINC- Codes für sectionCodes wird für den ePflegebericht übernommen.

Der Body des ePflegeberichts setzt sich aus einzelnen CDA- Section- Level- Templates und CDA Entry Level- Templates zusammen, die im weiteren beschrieben werden.

Pflegeprozess

Beschreibung:

Under construction icon-blue.svg Hier fehlt sowohl eine schematische Abbildung der verwendeten Sections, als auch die XML- Darstellung des templates. Diese werden eingebaut, sobald die SectionCodes abgestimmt sind.

In diesem CDA Section Level-template werden die pflegespezifischen Informationen anhand des Pflegeprozesses dargestellt. Die Informationen aus dem Pflegeprozess können grundsätzlich in drei Stufen unterschieden werden. Es gibt zum einen befundorientierte Informationen zu Score- Werten bzw. Assessments, Pflegediagnosen bzw. Pflegeproblemen und Pflegezielen. Eine Information in einem dieser Konzepte kann optional eine Information in dem Konzept Pflegemaßnahmen auslösen. Letztlich wird so dargestellt, dass jeder pflegerischen Handlung mindestens ein Grund oder Auslöser zugeordnet werden muss. Eine pflegerische Maßnahme kann somit nicht isoliert stehen. Gleichzeitig kann jedem Grund oder Auslöser eine oder mehrere pflegerische Maßnahmen zugeordnet werden. Als dritte Stufe kann jeder pflegerischen Maßnahme eine Information zum Ergebnis folgen. Auch hiermit wird wieder gewährleistet, dass ein pflegerisches Ergebnis nicht alleine steht, sondern nur in Verbindung mit einer Maßnahme existiert.

Soziale Informationen

Beschreibung: Soziale und insbesondere biographische Informationen spielen für Pflegende speziell im Bereich der Versorgung von Demenzkranken eine wichtige Rolle. Aus diesem Grund umfasst der Pflegebericht eine Section für die sozialen Informationen. Die DocSectionClass SocialInformation beinhaltet die Informationen zur Biographie des Patienten. Von dieser Klasse geht eine SubsectionsClasses OccupationHeld aus.


Homecare Status

Beschreibung: Für die ambulante Pflegeversorgung sind Informationen zu den Wohnverhältnissen von Bedeutung. Dies umfasst sowohl Informationen zu Hilfsmitteln, wie auch zur Barrierefreiheit oder dem barrierefreien Zugang zur Wohnung.


Sozialrechtliche Informationen

Beschreibung: Im Umfeld der pflegerischen Versorgung sind auch sozialrechtliche Informationen für die Beteiligten aus den unterschiedlichen Berufsgruppen von Bedeutung. Aus diesem Grund ermöglicht der ePflegebericht den Transport entsprechender Informationen. Dieser Abschnitt dient aber nicht zur Weiterleitung des Inhalts der unterschiedlichen Dokumente (z.B. einer Patientenverfügung). Hier sollen nur die administrativen Informationen weitergeleitet werden, also z.B. die reine Existenz eines solchen Dokuments bzw. Bescheids.

Abgerufen von „https://wiki.hl7.de/index.php?title=Cdaepb:Statisches_Modell&oldid=13394“