Hl7wiki - Benutzerbeiträge [de]

Segment PR1

2025-10-01T19:02:29Z

Foemig:

==PR1 – Massnahmen (Procedures)==

{{GermanText|
In diesem Segment werden die durchgeführten Maßnahmen dokumentiert.
}}

{{EnglishText|
This segment transmits information about performed procedures and treatments.
}}

{| class="hl7table"
!Lfd. Nr.!!Beschreibung!!Kard.!!Verwendung!!Tab.!!Data Item!!DT!!Länge!!Kap.
|-
|1||Set ID – PR1/ PR1-Segmentnummer||[1..1]||R||||00391||SI||||6.5.4.1
|-
|2||Procedure Coding Method/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0089||00392||IS||||6.5.4.2
|-
|3||Procedure Code/ Maßnahmen- / Operationsschlüssel||[1..1]||R||0088||00393|| bgcolor="BBFFFF" |CNE (CE)||||4.5.3.44
|-
|4||Procedure Beschreibung/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00394||ST||||6.5.4.4
|-
|5||Procedure Date/Time/ Zeitpunkt der Maßnahme||[1..1]||R||||00395||TS||||6.5.4.5
|-
|6||Procedure Functional Type/ Art der Maßnahme||[0..1]||O||0230||00396||IS||||6.5.4.6
|-
|7||Procedure Minutes/ Dauer der Maßnahme in Minuten||[0..1]||O||||00397||NM||||6.5.4.7
|-
|8||Anesthesiologist/ nicht verwendet (veraltet; PR1-12 benutzen)||[0..0]|| bgcolor="BBFFFF" |X (B)||0010||00398||XCN||||6.5.4.8
|-
|9||Anesthesia Code/ nicht verwendet (veraltet; PR1-3 benutzen)||[0..0]|| bgcolor="BBFFFF" |X (O)||0019||00399||IS||||6.5.4.9
|-
|10||Anesthesia Minutes/ nicht verwendet (veraltet; PR1-7 benutzen)||[0..0]|| bgcolor="BBFFFF" |X (O)||||00400||NM||||6.5.4.10
|-
|11||Surgeon/ nicht verwendet (veraltet; PR1-12 benutzen)||[0..0]|| bgcolor="BBFFFF" |X (B)||0010||00401||XCN||||6.5.4.11
|-
|12||Procedure Practitioner/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0010||00402||XCN||||6.5.4.12
|-
|13||Consent Code/ Zustimmung des Patienten||[0..1]||O||0059||00403||CE||||6.5.4.13
|-
|14||Procedure Priority/ Priorität der Maßnahme||[0..1]|| bgcolor="BBFFFF" |RE (O)||0418||00404||ID||||6.5.4.14
|-
|15||Associated Diagnosis Code/ Zugehörige Diagnose||[0..1]||O||0051||00772||CE||||6.5.4.15
|-
|16||Procedure Code Modifier/ Modifikator zum Prozedurcode||[0..\*]||O||0340||01316||CE||||4.5.3.45
|-
|17||Procedure DRG Type/ Prioritätseinstufung für DRG||[0..1]||O||0416||01501||IS||||6.5.4.17
|-
|18||Tissue Type Code/ Art des entnommenen Gewebes||[0..1]||O||0417||01502||CE||||6.5.4.18
|-
|19||Procedure Identifier/ ID der Maßnahme||[0..1]||C||||01848||EI||||6.5.4.19
|-
|20||Procedure Action Code/ Maßnahme Aktionscode||[0..1]||C||0206||01849||ID||||6.5.4.20
|-
|}

===PR1-1 Segmentnummer===

{{GermanText|
In diesem Feld wird eine fortlaufende Nummer für jede Wiederholung dieses Segmentes eingetragen.
}}

{{EnglishText|
This field contains a consecutive number identifying each repetition of this segment within a message uniquely.
}}

===PR1-3 Maßnahmen/Operationsschlüssel===

{{GermanText|
Die eigentliche Maßnahme besteht aus einer kodierten Information und/oder einer textuellen Beschreibung.
}}

{{EnglishText|
This field contains the performed procedure which consist of coded information and a textual description.
}}

Beispiel 1: Koronarangiographie ohne weitere Maßnahmen
1-275.0^Koronarangiographie ohne weitere Maßnahmen^O301-2004

Beispiel 2: Native Computertomographie des Thorax
3-202^Native Computertomographie des Thorax^O301-2004

{{GermanText|
Zur Kodierung der Prozeduren stehen folgende OPS-Kataloge zur Verfügung:
}}

{{EnglishText|
The following tables shall be used for coding the procedures:
}}

{| class="hl7table"
!Code!!Bedeutung
|-
|O301-2004||OPS-Katalog 2004
|-
|O301-2005||OPS-Katalog 2005
|-
|O301-2006||OPS-Katalog 2006
|-
| ... || ...
|-
|OPS2007||OPS-Katalog 2007
|-
| ... || ...
|-
|OPS2022||OPS-Katalog 2022
|-
|OPS2023||OPS-Katalog 2023
|-
|OPS2024||OPS-Katalog 2024
|-
|OPS2025||OPS-Katalog 2025
|-
|OPS2026||OPS-Katalog 2026
|-
| ... || ...
|}

{{GermanText|
Dieser Katalog kann erweitert werden.
}}

{{EnglishText|
This table can be extended.
}}

====Lokalisation====

{{GermanText|
Die Lokalisation kann folgende Werte annehmen:
}}

{{EnglishText|
The localisation can use the following values:
}}

{| class="hl7table"
!Code!!Bedeutung
|-
|R||rechts
|-
|L||links
|-
|B||beidseitig
|-
|}

{{GermanText|
Der Wert für die Lokalisation wird an den Prozedurcode (mit einem Leerzeichen als Trenner) angehängt.
}}

{{EnglishText|
The value for the localisation shall be appended to the procedure code separated by a blank.
}}

Beispiel: Therapeutische perkutane Punktion eines Gelenkes: Zehengelenk rechts
8-158.r R^Therapeutische perkutane Punktion eines Gelenkes: Zehengelenk^O301-2004

{{GermanText|
Anmerkung: Die InEK verlangt für die Übertragung zu einem Grouper als Trennzeichen den Doppelpunkt (":"). Eine Konfigurationsmöglichkeit ist deshalb empfehlenswert.
}}

{{EnglishText|
Note: The InEK requires a doubble point (":") as a separator for transmitting the data to the grouping software. Having the opportunity to configure this is recommended.
}}

===PR1-5 Zeitpunkt der Maßnahme===

{{GermanText|
In diesem Feld wird der Zeitpunkt festgehalten, wann die Maßnahme durchgeführt wurde.
}}

{{EnglishText|
This field contains the timestamp when this procedure/treatment was performed.
}}

===PR1-6 Art der Maßnahme===

{{GermanText|
In diesem Feld wird die Arte der Maßnahme angegeben.
}}

{{EnglishText|
This field contains information about the type of the procedure.
}}

====Tabelle 0230: Procedure Functional Type====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|A||Anesthesia||Narkose
|-
|D||Diagnostic procedure||Diagnosestellung
|-
|I||Invasive procedure not classified elsewhere (e.g., IV, catheter, etc.)||operativer Eingriff
|-
|P||Procedure for treatment (therapeutic, including operations)||Behandlung
|-
|}

===PR1-14 Priorität der Maßnahme===

{{GermanText|
In diesem Feld wird die Unterscheidung zwischen Haupt- und Nebenmaßnahmen getroffen. Die Hauptprozedur erhält den Wert "1". Alle weiteren Maßnahmen erhalten mit absteigender Priorität weitere Ziffern beginnend mit "2".
}}

{{EnglishText|
This field contains the priority of the procedure. It must be separated between primary and secondary treatment. The primary procedure contain the value "1". All subsequent procedure with descending priority are getting the next numbers starting with "2".
}}

====Tabelle 0418: Procedure Priority====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|1||the primary procedure||Hauptprozedur
|-
|2||for ranked secondary procedures||klassifizierte Nebenprozeduren
|-
|…||Weitere Codes||
|-
|}

===PR1-19 ID der Maßnahme===

{{GermanText|
Jede Maßnahme soll eine eindeutige Identifikation für eine spätere Referenzierung erhalten. Die Eindeutigkeit ist innerhalb des gesamten Systems über alle Fälle sicherzustellen, da die IDs auch nach einem Merge von unterschiedlichen Fällen immer noch eindeutig sein müssen.

Dieses Feld ist in der P12-Nachricht zwingend notwendig.
}}

{{EnglishText|
Each procedure/treatment shall get a unique identifier allowing for a later referencing. The uniqueness shall be given within the whole system across all cases/visits, because they shall still be unique after a merge of patient records.

This field is required for a P12 message.
}}

===PR1-20 Maßnahme Aktionscode===

{{GermanText|
Der Aktionscode gibt an, was mit der Information im PR1-Segment zu geschehen hat.

Diese Feld ist in der P12-Nachricht zwingend notwendig.
}}

{{EnglishText|
The action code defines what shall be done with the information in the PR1 segment.

This field is required for a P12 message.
}}

[[Kategorie:Segmente|PR1]]
[[Kategorie:v2profile|PR1]]

Segment DG1

2025-10-01T19:01:29Z

Foemig:

==DG1 – Diagnosen (Diagnosis)==

{{ GermanText |
In diesem Feld werden die einzelnen Diagnosen inklusive ihrer Attribute übermittelt.
}}

{{EnglishText |
This field contains the individual diagnoses as well as their attributes.
}}

{| class="hl7table"
!Lfd. Nr.!!Beschreibung!!Kard.!!Verwendung!!Tab.!!Data Item!!DT!!Länge!!Kap.
|-
|1||Set ID – DG1/ DG1-Segmentnummer||[1..1]||R||||00375||SI||||6.5.2.1
|-
|2||Diagnosis Coding Method/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0053||00376||ID||||6.5.2.2
|-
|3||Diagnosis Code – DG1/ Diagnoseschlüssel||[1..1]|| bgcolor="BBFFFF" |R (O)||0051||00377|| bgcolor="BBFFFF" |CNE (CE)||||6.5.2.3
|-
|4||Diagnosis Beschreibung/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00378||ST||||6.5.2.4
|-
|5||Diagnosis Date/Time/ Zeitpunkt der Diagnosestellung|| bgcolor="BBFFFF" |[0..1]|| bgcolor="BBFFFF" |C (O)||||00379||TS||||6.5.2.5
|-
|6||Diagnosis Type/ Diagnosetyp||[1..1]||R||0052||00380||IS||2||6.5.2.6
|-
|7||Major Diagnostic Category/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0118||00381||CE||||6.5.2.7
|-
|8||Diagnostic Related Group/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0055||00382||CE||||6.5.2.8
|-
|9||DRG Approval Indicator/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0136||00383||ID||||6.5.2.9
|-
|10||DRG Grouper Review Code/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0056||00384||IS||||6.5.2.10
|-
|11||Outlier Type/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0083||00385||CE||||6.5.2.11
|-
|12||Outlier Days/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00386||NM||||6.5.2.12
|-
|13||Outlier Cost/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00387||CP||||6.5.2.13
|-
|14||Grouper Version And Type/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00388||ST||||6.5.2.14
|-
|15||Diagnosis Priority/ Diagnosepriorität (1 = Hauptdiagnose, 2..n = weitere Diagnosen)|| bgcolor="BBFFFF" |[1..1]|| bgcolor="BBFFFF" |R (O)||0359||00389||ID|| bgcolor="BBFFFF" |3(2)||6.5.2.15
|-
|16||Diagnosing Clinician/ Verantwortlicher Arzt||[0..*]|| bgcolor="BBFFFF" |RE (O)||||00390||XCN|| ||6.5.2.16
|-
|17||Diagnosis Classification/ Art der Diagnose||[0..1]||O||0228||00766||IS|| ||6.5.2.17
|-
|18||Confidential Indicator/ Merkmal der Vertraulichkeit der Diagnose||[0..1]||O||0136||00767||ID|| ||6.5.2.18
|-
|19||Attestation Date/Time/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (O)|| ||00768||TS|| ||6.5.2.19
|-
|20||Diagnosis Identifier/ ID der Diagnose||[1..1]|| bgcolor="BBFFFF" |R (C)|| ||01850||EI|| ||6.5.2.20
|-
|21||Diagnosis Action Code/ Diagnose Aktionscode||[1..1]|| bgcolor="BBFFFF" |R (C)||0206||01894||ID||||6.5.2.21
|-
|}

===DG1-1 Segmentnummer===

{{ GermanText |
Die Segmentnummer dient der fortlaufenden Nummerierung aller DG1-Segmente unabhängig vom Vorkommen in der Nachricht.
}}

{{EnglishText |
The purpose of the segment number is the sequential numbering of all DG1 segments independently of their occurrence within a message.
}}

===DG1-3 Diagnoseschlüssel===

{{ GermanText |
Die eigentliche Diagnose besteht aus einer kodierten Information und/oder einer textuellen Beschreibung.
}}

{{EnglishText |
The actual diagnosis is composed out of a coded information and/or a textual description.
}}

Beispiel 1: "Blinddarmentzündung" als Text, 1. Komponente bleibt leer
^Blinddarmentzündung

Beispiel 2: "K57.1: Appendizitis" als kodierte Information
K57.1^Appendizitis^ICD10GM2023

{{ GermanText |
Zur Kodierung der Diagnosen stehen folgende Kataloge für ICD-10, Alpha-Id und OrphaId für das jeweilige Jahr zur Verfügung:
}}

{{ EnglishText |
The coding system for ICD-10, Alpha-Id and OrphaId according to the year may be determined by the following table:
}}

{| class="hl7table"
!Jahr!! ICD-10-Katalog!!Alpha-Id-Katalog!!Orpha-Id-Katalog!!MDC!!G-DRG
|-
|2004||I10G2004|| - || || GMDC2004 || GDRG2004
|-
|2005||I10G2005|| - || || GMDC2005 || GDRG2005
|-
|2006||I10G2006||ALPHAID2006|| || GMDC2006 || GDRG2006
|-
|2007||ICD10GM2007||ALPHAID2007|| || GMDC2007 || GDRG2007
|-
| ... || ... || ...
|-
|2023||ICD10GM2023||ALPHAID2023|| || GMDC2023 || GDRG2023
|-
|2024||ICD10GM2024||ALPHAID2024|| || GMDC2024 || GDRG2024
|-
|2025||ICD10GM2025||ALPHAID2025|| || GMDC2025 || GDRG2025
|-
|2026||ICD10GM2026||ALPHAID2026|| || GMDC2026 || GDRG2026
|-
| ... || ...
|}

{{ GermanText |
Neben den ICD-10-Diagnosen können aber auch andere Codesysteme wie Alpha-ID oder Orpha-Id genutzt werden.
Dafür sind die entsprechenden Identifikationen aus Tabelle 0396 zu verwenden.
}}

{{EnglishText |
Beside ICD-10 diagnosis codes, other codesystems like Alpha-ID or Orpha-Id can be used.
Therefore, the identifications from table 0396 shall be used.
}}

{{ GermanText |
Neben dem eigentlichen Diagnoseschlüssel gibt es noch Diagnosezusätze und eine Lokalisation, die an die Kodes angehängt werden. Als Trennung wird ein Leerzeichen verwendet.
}}

{{EnglishText |
Besides the actual diagnosis key there are diagnosis supplements and a localization that are appended to the codes.
As a delimiter a blank space is used.
}}

====Diagnosezusatz====
Der Diagnosezusatz wird wie folgt kodiert:

{| class="hl7table"
!Code!!Beschreibung!!Interpretation
|-
|V|| Verdacht auf ||Verdachtsdiagnose
|-
|Z|| Zustand nach ||Zustand nach der betreffenden Diagnose
|-
|A|| ausgeschlossen ||Ausgeschlossene Diagnose
|-
|G|| gesichert ||gesicherte Diagnose
|-
|}

====Lokalisation====
Die Lokalisation kann folgende Werte annehmen:

{| class="hl7table"
!Code!!Beschreibung!!Interpretation
|-
|R||right||rechts
|-
|L||left||links
|-
|B||both sides||beidseitig
|-
|}

{{ GermanText |
Die Werte für den Diagnosezusatz und die Lokalisation werden an den Diagnosecode in beliebiger Reihenfolge (mit einem Leerzeichen als Trenner) angehängt.
}}

{{EnglishText |
The values for the diagnosis type and for the localization are added to the diagnosis code (separated by blanks) in an arbitrary way.
}}

Beispiel: Schnittwunde am linken Unterarm
S51.- L^^I10-2004

Beispiel: Ausgeschlossene, beidseitige Alterskatarakt:
H25.- BA^^I10-2004

====Fallhauptdiagnose====

{{ GermanText |
Die Kennzeichnung der Fallhauptdiagnose erfolgt über eine Markierung in dem Alternativcode. Dazu wird die Diagnose in der Alternativcodierung wiederholt, allerdings wird dann an den Code eine "1" und an den Katalog "ext" angehängt.
}}

{{EnglishText |
The main diagnosis of the case is marked by an alternate code. For that purpose the diagnosis is repeated in the alternate coding system, but a “1” is added to the code and an “ext” to the catalog.
}}

Beispiel: Die Entlassdiagnose bestätigt nochmals die Appendizitis und wird als Hauptdiagnose für den Krankenhausaufenthalt gewertet.
K37^Nicht näher bezeichnete Appendizitis^I10-2004^K37'''1'''^Nicht näher bezeichnete Appendizitis^I10-2004'''ext'''

===DG1-5 Zeitpunkt der Diagnosestellung===

{{ GermanText |
In diesem Feld wird übermittelt, wann die Diagnose gestellt wurde.
Dieses Feld ist erforderlich, aber ggf. leer ("RE" (required, but may be empty)), wenn es sich um eine Einweisungsdiagnose handelt. Bei allen anderen Diagnosetypen ist dieses Feld "R" (required).
}}

{{EnglishText |
In diesem Feld wird übermittelt, wann die Diagnose gestellt wurde.
This field is required, but may be empty (“RE”) if the diagnosis is an admitting diagnosis. For all other diagnosis types this field is required (“R”).
}}

===DG1-6 Diagnosetyp===

{{ GermanText |
Der Diagnosetyp legt die Art der Diagnose fest.
}}

{{EnglishText |
The diagnosis type indicates the type of the diagnosis.
}}

====Tabelle 0052: Diagnosis Type====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|AD|| admitting diagnosis||Aufnahmediagnose
|-
|BD|| treating diagnosis||Behandlungsdiagnose
|-
|ED|| referral diagnosis||Einweisungsdiagnose
|-
|EL|| discharge/transfer diagnosis||Entlassungs- / Verlegungsdiagnose
|-
|ND|| ||Nachfolgediagnose
|-
|NO|| ||Nachfolgediagnose Operieren
|-
|NU|| ||Nachfolgediagnose, die die Arbeitsunfähigkeit allein begründet hat
|-
|UD|| ||Überweisungsdiagnose
|-
|VO|| ||Präoperative Diagnose
|-
|ZD|| ||Neben- / Zusatzdiagnose
|-
|}

===DG1-15 Diagnosepriorität===

{{ GermanText |
Die Diagnosepriorität dient der Unterscheidung zwischen Haupt- und Nebendiagnosen. Die Hauptdiagnose erhält den Wert "1". Alle Nebendiagnosen erhalten mit absteigender Priorität weitere Ziffern beginnend mit "2".
}}

{{EnglishText |
The priority of a diagnosis distinguishes between primary and secondary diagnoses. The primary diagnosis has the value “1”. All other diagnoses get a higher number starting with 2 in a decreasing ranking.
}}

====Tabelle 0359: Diagnosis Priority====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|1||The primary diagnosis||Hauptdiagnose
|-
|1.1||main diagnosis (primary) ||Hauptdiagnose (primär, Kreuz)
|-
|1.2||main diagnosis (secondary) ||Hauptdiagnose (sekundär, Stern)
|-
|2||For ranked secondary diagnoses||Nebendiagnose
|-
|2.1|| ||Nebendiagnose (primär, Kreuz)
|-
|2.2|| ||Nebendiagnose (sekundär, Stern)
|-
|...|| ||
|-
|}

=====Kreuz-Stern-Notation=====

{{ GermanText |
Die Primärdiagnose bezieht sich auf die Ätiologie und wird mit "+" gekennzeichnet. Die Sekundärdiagnose hingegen definiert die Manifestation, welche mit "*" gekennzeichnet wird.

Diese beiden Informationen werden über die Diagnosepriorität kodiert. Hierzu wird als Nachkommastelle eine "1" für die Primärdiagnose und eine "2" für die Sekundärdiagnose verwendet.
}}

{{EnglishText |
The primary diagnosis refers to the etiology and shall be marked with "+". The secondary diagnosis refers to the manifestation which is marked by "*".

Both information will be coded by the diagnosis priority. Therefore, the primary diagnosis will get a "1" at the first position after decimal point, the secondary diagnosis will get "2".
}}

DG1|1||E11.5^...^I1020|||BD|||||||||1.1| Hauptdiagnose - Primärdiagnose - Kreuz-Diagnose
DG1|2||I79.2^...^I1020|||BD|||||||||1.2| Hauptdiagnose - Sekundärdiagnose - Stern-Diagnose
DG1|3||S42.41 R^...^I1020|||BD|||||||||2.1| Nebendiagnose - Primärdiagnose - (ebenfalls als Kreuz-Diagnose)
DG1|4||V99^...^I1020|||BD|||||||||2.2| Nebendiagnose - Sekundärdiagnose - (ebenfalls als Stern-Diagnose)
DG1|5||xyz^...^...|||BD|||||||||3| weitere Nebendiagnose (keine Kreuz-Stern-Diagnose)

===DG1-16 Verantwortlicher Arzt===

{{ GermanText |
In diesem Feld wird der Arzt übertragen, der für die Stellung der Diagnose verantwortlich ist.
}}

{{EnglishText |
This field contains the physician who is responsible for declaring the diagnosis.
}}

===DG1-17 Art der Diagnose===

{{ GermanText |
Dieses Feld dient der Klassifikation der Diagnose.
}}

{{EnglishText |
This field is used for the classification of the diagnosis.
}}

====Tabelle 0228: Diagnosis Classification====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|C||Consultation||Behandlung
|-
|D||Diagnosis||Diagnose
|-
|I||Invasive procedure not classified elsewhere (I.V., catheter, etc.)||Maßnahme
|-
|M||Medication (antibiotic)||Medikation
|-
|O||Other||andere
|-
|R||Radiological scheduling (not using ICDA codes)||Planung von radiologischen Untersuchungen
|-
|S||Sign and symptom||Symptome
|-
|T||Tissue diagnosis||Gewebebestimmung
|-
|}

===DG1-20 ID der Diagnose===

{{ GermanText |
Jede Diagnose soll eine eindeutige Identifikation für eine spätere Referenzierung erhalten. Die Eindeutigkeit ist innerhalb des gesamten Systems über alle Fälle sicherzustellen, da die IDs auch nach einem Merge von unterschiedlichen Fällen immer noch eindeutig sein müssen.

Dieses Feld ist in der P12-Nachricht zwingend notwendig.
}}

{{EnglishText |
Each diagnosis shall get a unique identification allowing for a subsequent referencing. The uniqueness within the whole system across all visis/cases shall be given because it should still be unique after a merge of visits.
}}

===DG1-21 Diagnose Aktionscode===

{{ GermanText |
Auszuführende Aktion mit dieser Diagnose. In der P12-Nachricht muss dieses Feld gefüllt sein.
}}

{{EnglishText |
This field contains the transaction which shall be performed with this diagnosis. This field is required for a P12 message.
}}

====Tabelle 0206: Segment action code====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|U||Update||Ändern
|-
|A||Add/Insert||Hinzufügen
|-
|D||Delete||Löschen
|-
|}

[[Kategorie:Segmente|DG1]]
[[Kategorie:v2profile|DG1]]

ZULIP-Chats

2023-12-04T07:34:21Z

Foemig: weitere STreams

{{BeginGreenBox|ZULIP-Chat-Channels}}
Zur Kommunikation verwenden wir Zulip (https://chat.fhir.org). Die bisherige allgemeine Plattform wurde dorthin migriert. Anmeldungen können direkt über die Webseite oder die App vorgenommen werden.

<table border="0" cellspacing="0" cellpadding="4" width=100%>
<tr>
<th align=left>FHIR</th>
<th align=left>CDA</th>
<th align=left>Terminologien</th>
<th align=left>v2</th>
</tr>
<tr>
<td valign=top>
* [https://chat.fhir.org/#narrow/stream/179183-german-(d-a-ch) german-(d-a-ch)] dt. Fragen zu CDA
* [https://chat.fhir.org/#narrow/stream/287581-german.2Fisik ISiK]
* [https://chat.fhir.org/#narrow/stream/311712-german.2Fisip ISiP]
* [https://chat.fhir.org/#narrow/stream/208065-german.2Fkbv german/KBV]
* [https://chat.fhir.org/#narrow/stream/179307-german.2Fmi-initiative german/mi-initiative]
* [https://chat.fhir.org/#narrow/stream/224719-german.2Foncology Tumordokumentation]
* [https://chat.fhir.org/#narrow/stream/232208-german.2Frki german/rki]
* [https://chat.fhir.org/#narrow/stream/232208-german.2Frki german/messaging] Fragen zu Nachrichten
</td>
<td valign=top>
* [https://chat.fhir.org/#narrow/stream/229921-CDA CDA]
* [https://chat.fhir.org/#narrow/stream/232925-cda-German.20(d-a-ch) CDA German (d-a-ch)]
</td>
<td valign=top>
* [https://chat.fhir.org/#narrow/stream/179316-german.2Fterminologien Terminologien]
* [https://chat.fhir.org/#narrow/stream/351594-terminology-.2F-v2-content-in-THO V2 Inhalte in THO]
</td>
<td valign=top>
* [https://chat.fhir.org/#narrow/stream/229447-V2 V2]
* [https://chat.fhir.org/#narrow/stream/232924-v2-German.20(d-a-ch) V2 German (d-a-ch)]
* [https://chat.fhir.org/#narrow/stream/179188-v2-to.20FHIR v2 to FHIR]
</td>
</tr>
</table>

{{EndGreenBox}}

HL7-D ADT & IHE PAM Ergebnisse

2023-11-09T12:01:19Z

Foemig: Festlegung von Optionen

=Deutsche Profile und IHE PAM=
Zwischen den [http://wiki.hl7.de/index.php?title=Kategorie:V2profile deutschen Profilen] (Ausgabe 2013) und [http://wiki.hl7.de/index.php?title=ihecb:PAM IHE PAM] (ITI TF-4 Rev. 11, 2014) bestehen einige Überschneidungen.

Folgende PAM-Optionen decken sich '''vollständig''' mit Trigger-Events aus deutschen Profilen:
* PAM ITI-31 Basic (ohne Optionen)
* PAM ITI-31 Inpatient/Outpatient Encounter Management
* PAM ITI-31 Historic Movement
Diese Optionsnamen sind in der nachstehenden Übersichtstabelle blau hinterlegt.

Folgende PAM-Optionen decken sich '''größtenteils''' mit Trigger-Events aus deutschen Profilen:
* PAM ITI-31 Temporary Patient Transfers Tracking
* PAM ITI-30 Merge
* PAM ITI-30 Link
Diese Optionsnamen sind in der nachstehenden Übersichtstabelle weiß hinterlegt

Alle anderen PAM-Optionen sind/waren kein Gegenstand der Harmonisierung.

=IHE ITI National Extension Germany=

Die Beschreibung der deutschen Profile aus der Sicht von IHE (Domain IT Infrastructure) ist in der National Extension formuliert.
Die aktuelle Fassung (Stand 18.09.2015: Rev. 12.0) steht auf den Seiten von[http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol4.pdf IHE International] zum Herunterladen bereit.

=Online Validierungsmöglichkeit=

Die Profildateien sind online im [http://gazelle.ihe.net/EVSClient/hl7v2/validator.seam?extension=IHE%20Germany Bereich 'IHE Germany'] des IHE-Tools External Validator Service (EVS) innerhalb der Gazelle-Plattform hinterlegt.

=Übersicht der Trigger-Events=
{| class="hl7table"
!Profile Deutschland:
Trigger-Event
!PAM ITI-31
Basic - ohne Optionen
!PAM ITI-31
Inpatient/Outpatient
Encounter Management
!PAM ITI-31
Temporary Patient
Transfers Tracking
!PAM ITI-31
Historic Movement
!PAM ITI-31
Maintain Demographics
!PAM ITI-30
Merge
!PAM ITI-30
Link

|-
!ADT^A01 Aufnahme (Standard)
|X
|X
|X
|X
|X
|
|

|-
!ADT^A02 Verlegung (Standard)
|
|X
|
|X
|
|
|

|-
!ADT^A03 Entlassung (Standard)
|X
|X
|X
|X
|X
|
|

|-
!ADT^A04 Besuchsmeldung
|X
|X
|X
|X
|X
|
|

|-
!ADT^A05 Voraufnahme
|
|X
|
|X
|
|
|
|-
!ADT^A06 Fallartwechsel - stat. zu amb.
|
|X
|
|X
|
|
|
|-
!ADT^A07 Fallartwechsel - amb. zu stat.
|
|X
|
|X
|
|
|

|-
!ADT^A08 Aenderung Patient (Standard)
|
|
|
|
|X
|
|

|-
!ADT^A09 Abwesenheit Einrichtung - verlaesst
|
|
|X
|
|
|
|

|-
!ADT^A10 Abwesenheit Einrichtung - erreicht
|
|
|X
|
|
|
|

|-
!ADT^A11 Aufnahme storno
|X
|X
|X
|X
|X
|
|

|-
!ADT^A12 Verlegung storno
|
|X
|
|X
|
|
|

|-
!ADT^A13 Entlassung storno
|X
|X
|X
|X
|X
|
|

|-
!ADT^A21 Abwesenheit Urlaub - Beginn
|
|
|
|X
|
|
|

|-
!ADT^A22 Abwesenheit Urlaub - Ende
|
|
|
|X
|
|
|

|-
!ADT^A24 Verknuepfung
|
|
|
|
|
|
|X
|-
!ADT^A28 Person hinz.
|
|
|
|
|
|X
|X

|-
!ADT^A31 Aenderung Person
|
|
|
|
|
|X
|X

|-
!ADT^A32 Abwesenheit verlaesst - Storno
|
|
|X
|
|
|
|

|-
!ADT^A33 Abwesenheit erreicht - Storno
|
|
|X
|
|
|
|

|-
!ADT^A37 Verknuepfung - aufloesen
|
|
|
|
|
|
|X

|-
!ADT^A38 Voraufnahme Storno
|
|X
|
|X
|
|
|

|-
!ADT^A40 Patient Merge
|
|
|
|
|X
|X
|

|-
!ADT^A47 Aenderung PatId
|
|
|
|
|
|X
|X

|-
!ADT^Z99 Historische Bewegung
|
|
|
|X
|
|
|

|}

=Optionen in der Umsetzung=

{| class="hl7table"
!Option
!Beschreibung
!PAM ITI-31

|-
!Insurance
|Nutzung der Insurance Group in ADT
|O

|-
!Diagnosis
|Nutzung von Diagnosen in ADT
|O

|-
!Befunde
|Nutzung von weiteren Informationen in OBX-Segmenten in ADT
|O

|}

Hersteller haben dann anzugeben, welche Option(en) sie unterstützen.

Segment DG1

2023-11-09T11:56:02Z

Foemig: Klärung Kreuz-Stern-Diagnose

==DG1 – Diagnosen (Diagnosis)==

{{ GermanText |
In diesem Feld werden die einzelnen Diagnosen inklusive ihrer Attribute übermittelt.
}}

{{EnglishText |
This field contains the individual diagnoses as well as their attributes.
}}

{| class="hl7table"
!Lfd. Nr.!!Beschreibung!!Kard.!!Verwendung!!Tab.!!Data Item!!DT!!Länge!!Kap.
|-
|1||Set ID – DG1/ DG1-Segmentnummer||[1..1]||R||||00375||SI||||6.5.2.1
|-
|2||Diagnosis Coding Method/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0053||00376||ID||||6.5.2.2
|-
|3||Diagnosis Code – DG1/ Diagnoseschlüssel||[1..1]|| bgcolor="BBFFFF" |R (O)||0051||00377|| bgcolor="BBFFFF" |CNE (CE)||||6.5.2.3
|-
|4||Diagnosis Beschreibung/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00378||ST||||6.5.2.4
|-
|5||Diagnosis Date/Time/ Zeitpunkt der Diagnosestellung|| bgcolor="BBFFFF" |[0..1]|| bgcolor="BBFFFF" |C (O)||||00379||TS||||6.5.2.5
|-
|6||Diagnosis Type/ Diagnosetyp||[1..1]||R||0052||00380||IS||2||6.5.2.6
|-
|7||Major Diagnostic Category/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0118||00381||CE||||6.5.2.7
|-
|8||Diagnostic Related Group/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0055||00382||CE||||6.5.2.8
|-
|9||DRG Approval Indicator/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0136||00383||ID||||6.5.2.9
|-
|10||DRG Grouper Review Code/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0056||00384||IS||||6.5.2.10
|-
|11||Outlier Type/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0083||00385||CE||||6.5.2.11
|-
|12||Outlier Days/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00386||NM||||6.5.2.12
|-
|13||Outlier Cost/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00387||CP||||6.5.2.13
|-
|14||Grouper Version And Type/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00388||ST||||6.5.2.14
|-
|15||Diagnosis Priority/ Diagnosepriorität (1 = Hauptdiagnose, 2..n = weitere Diagnosen)|| bgcolor="BBFFFF" |[1..1]|| bgcolor="BBFFFF" |R (O)||0359||00389||ID|| bgcolor="BBFFFF" |3(2)||6.5.2.15
|-
|16||Diagnosing Clinician/ Verantwortlicher Arzt||[0..*]|| bgcolor="BBFFFF" |RE (O)||||00390||XCN|| ||6.5.2.16
|-
|17||Diagnosis Classification/ Art der Diagnose||[0..1]||O||0228||00766||IS|| ||6.5.2.17
|-
|18||Confidential Indicator/ Merkmal der Vertraulichkeit der Diagnose||[0..1]||O||0136||00767||ID|| ||6.5.2.18
|-
|19||Attestation Date/Time/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (O)|| ||00768||TS|| ||6.5.2.19
|-
|20||Diagnosis Identifier/ ID der Diagnose||[1..1]|| bgcolor="BBFFFF" |R (C)|| ||01850||EI|| ||6.5.2.20
|-
|21||Diagnosis Action Code/ Diagnose Aktionscode||[1..1]|| bgcolor="BBFFFF" |R (C)||0206||01894||ID||||6.5.2.21
|-
|}

===DG1-1 Segmentnummer===

{{ GermanText |
Die Segmentnummer dient der fortlaufenden Nummerierung aller DG1-Segmente unabhängig vom Vorkommen in der Nachricht.
}}

{{EnglishText |
The purpose of the segment number is the sequential numbering of all DG1 segments independently of their occurrence within a message.
}}

===DG1-3 Diagnoseschlüssel===

{{ GermanText |
Die eigentliche Diagnose besteht aus einer kodierten Information und/oder einer textuellen Beschreibung.
}}

{{EnglishText |
The actual diagnosis is composed out of a coded information and/or a textual description.
}}

Beispiel 1: "Blinddarmentzündung" als Text, 1. Komponente bleibt leer
^Blinddarmentzündung

Beispiel 2: "K57.1: Appendizitis" als kodierte Information
K57.1^Appendizitis^ICD10GM2023

{{ GermanText |
Zur Kodierung der Diagnosen stehen folgende Kataloge für ICD-10, Alpha-Id und OrphaId für das jeweilige Jahr zur Verfügung:
}}

{{ EnglishText |
The coding system for ICD-10, Alpha-Id and OrphaId according to the year may be determined by the following table:
}}

{| class="hl7table"
!Jahr!! ICD-10-Katalog!!Alpha-Id-Katalog!!Orpha-Id-Katalog!!MDC!!G-DRG
|-
|2004||I10G2004|| - || || GMDC2004 || GDRG2004
|-
|2005||I10G2005|| - || || GMDC2005 || GDRG2005
|-
|2006||I10G2006||ALPHAID2006|| || GMDC2006 || GDRG2006
|-
|2007||ICD10GM2007||ALPHAID2007|| || GMDC2007 || GDRG2007
|-
| ... || ... || ...
|-
|2023||ICD10GM2023||ALPHAID2023|| || GMDC2023 || GDRG2023
|-
|2024||ICD10GM2024||ALPHAID2024|| || GMDC2024 || GDRG2024
|-
| ... || ...
|}

{{ GermanText |
Neben den ICD-10-Diagnosen können aber auch andere Codesysteme wie Alpha-ID oder Orpha-Id genutzt werden.
Dafür sind die entsprechenden Identifikationen aus Tabelle 0396 zu verwenden.
}}

{{EnglishText |
Beside ICD-10 diagnosis codes, other codesystems like Alpha-ID or Orpha-Id can be used.
Therefore, the identifications from table 0396 shall be used.
}}

{{ GermanText |
Neben dem eigentlichen Diagnoseschlüssel gibt es noch Diagnosezusätze und eine Lokalisation, die an die Kodes angehängt werden. Als Trennung wird ein Leerzeichen verwendet.
}}

{{EnglishText |
Besides the actual diagnosis key there are diagnosis supplements and a localization that are appended to the codes.
As a delimiter a blank space is used.
}}

====Diagnosezusatz====
Der Diagnosezusatz wird wie folgt kodiert:

{| class="hl7table"
!Code!!Beschreibung!!Interpretation
|-
|V|| Verdacht auf ||Verdachtsdiagnose
|-
|Z|| Zustand nach ||Zustand nach der betreffenden Diagnose
|-
|A|| ausgeschlossen ||Ausgeschlossene Diagnose
|-
|G|| gesichert ||gesicherte Diagnose
|-
|}

====Lokalisation====
Die Lokalisation kann folgende Werte annehmen:

{| class="hl7table"
!Code!!Beschreibung!!Interpretation
|-
|R||right||rechts
|-
|L||left||links
|-
|B||both sides||beidseitig
|-
|}

{{ GermanText |
Die Werte für den Diagnosezusatz und die Lokalisation werden an den Diagnosecode in beliebiger Reihenfolge (mit einem Leerzeichen als Trenner) angehängt.
}}

{{EnglishText |
The values for the diagnosis type and for the localization are added to the diagnosis code (separated by blanks) in an arbitrary way.
}}

Beispiel: Schnittwunde am linken Unterarm
S51.- L^^I10-2004

Beispiel: Ausgeschlossene, beidseitige Alterskatarakt:
H25.- BA^^I10-2004

====Fallhauptdiagnose====

{{ GermanText |
Die Kennzeichnung der Fallhauptdiagnose erfolgt über eine Markierung in dem Alternativcode. Dazu wird die Diagnose in der Alternativcodierung wiederholt, allerdings wird dann an den Code eine "1" und an den Katalog "ext" angehängt.
}}

{{EnglishText |
The main diagnosis of the case is marked by an alternate code. For that purpose the diagnosis is repeated in the alternate coding system, but a “1” is added to the code and an “ext” to the catalog.
}}

Beispiel: Die Entlassdiagnose bestätigt nochmals die Appendizitis und wird als Hauptdiagnose für den Krankenhausaufenthalt gewertet.
K37^Nicht näher bezeichnete Appendizitis^I10-2004^K37'''1'''^Nicht näher bezeichnete Appendizitis^I10-2004'''ext'''

===DG1-5 Zeitpunkt der Diagnosestellung===

{{ GermanText |
In diesem Feld wird übermittelt, wann die Diagnose gestellt wurde.
Dieses Feld ist erforderlich, aber ggf. leer ("RE" (required, but may be empty)), wenn es sich um eine Einweisungsdiagnose handelt. Bei allen anderen Diagnosetypen ist dieses Feld "R" (required).
}}

{{EnglishText |
In diesem Feld wird übermittelt, wann die Diagnose gestellt wurde.
This field is required, but may be empty (“RE”) if the diagnosis is an admitting diagnosis. For all other diagnosis types this field is required (“R”).
}}

===DG1-6 Diagnosetyp===

{{ GermanText |
Der Diagnosetyp legt die Art der Diagnose fest.
}}

{{EnglishText |
The diagnosis type indicates the type of the diagnosis.
}}

====Tabelle 0052: Diagnosis Type====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|AD|| admitting diagnosis||Aufnahmediagnose
|-
|BD|| treating diagnosis||Behandlungsdiagnose
|-
|ED|| referral diagnosis||Einweisungsdiagnose
|-
|EL|| discharge/transfer diagnosis||Entlassungs- / Verlegungsdiagnose
|-
|ND|| ||Nachfolgediagnose
|-
|NO|| ||Nachfolgediagnose Operieren
|-
|NU|| ||Nachfolgediagnose, die die Arbeitsunfähigkeit allein begründet hat
|-
|UD|| ||Überweisungsdiagnose
|-
|VO|| ||Präoperative Diagnose
|-
|ZD|| ||Neben- / Zusatzdiagnose
|-
|}

===DG1-15 Diagnosepriorität===

{{ GermanText |
Die Diagnosepriorität dient der Unterscheidung zwischen Haupt- und Nebendiagnosen. Die Hauptdiagnose erhält den Wert "1". Alle Nebendiagnosen erhalten mit absteigender Priorität weitere Ziffern beginnend mit "2".
}}

{{EnglishText |
The priority of a diagnosis distinguishes between primary and secondary diagnoses. The primary diagnosis has the value “1”. All other diagnoses get a higher number starting with 2 in a decreasing ranking.
}}

====Tabelle 0359: Diagnosis Priority====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|1||The primary diagnosis||Hauptdiagnose
|-
|1.1||main diagnosis (primary) ||Hauptdiagnose (primär, Kreuz)
|-
|1.2||main diagnosis (secondary) ||Hauptdiagnose (sekundär, Stern)
|-
|2||For ranked secondary diagnoses||Nebendiagnose
|-
|2.1|| ||Nebendiagnose (primär, Kreuz)
|-
|2.2|| ||Nebendiagnose (sekundär, Stern)
|-
|...|| ||
|-
|}

=====Kreuz-Stern-Notation=====

{{ GermanText |
Die Primärdiagnose bezieht sich auf die Ätiologie und wird mit "+" gekennzeichnet. Die Sekundärdiagnose hingegen definiert die Manifestation, welche mit "*" gekennzeichnet wird.

Diese beiden Informationen werden über die Diagnosepriorität kodiert. Hierzu wird als Nachkommastelle eine "1" für die Primärdiagnose und eine "2" für die Sekundärdiagnose verwendet.
}}

{{EnglishText |
The primary diagnosis refers to the etiology and shall be marked with "+". The secondary diagnosis refers to the manifestation which is marked by "*".

Both information will be coded by the diagnosis priority. Therefore, the primary diagnosis will get a "1" at the first position after decimal point, the secondary diagnosis will get "2".
}}

DG1|1||E11.5^...^I1020|||BD|||||||||1.1| Hauptdiagnose - Primärdiagnose - Kreuz-Diagnose
DG1|2||I79.2^...^I1020|||BD|||||||||1.2| Hauptdiagnose - Sekundärdiagnose - Stern-Diagnose
DG1|3||S42.41 R^...^I1020|||BD|||||||||2.1| Nebendiagnose - Primärdiagnose - (ebenfalls als Kreuz-Diagnose)
DG1|4||V99^...^I1020|||BD|||||||||2.2| Nebendiagnose - Sekundärdiagnose - (ebenfalls als Stern-Diagnose)
DG1|5||xyz^...^...|||BD|||||||||3| weitere Nebendiagnose (keine Kreuz-Stern-Diagnose)

===DG1-16 Verantwortlicher Arzt===

{{ GermanText |
In diesem Feld wird der Arzt übertragen, der für die Stellung der Diagnose verantwortlich ist.
}}

{{EnglishText |
This field contains the physician who is responsible for declaring the diagnosis.
}}

===DG1-17 Art der Diagnose===

{{ GermanText |
Dieses Feld dient der Klassifikation der Diagnose.
}}

{{EnglishText |
This field is used for the classification of the diagnosis.
}}

====Tabelle 0228: Diagnosis Classification====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|C||Consultation||Behandlung
|-
|D||Diagnosis||Diagnose
|-
|I||Invasive procedure not classified elsewhere (I.V., catheter, etc.)||Maßnahme
|-
|M||Medication (antibiotic)||Medikation
|-
|O||Other||andere
|-
|R||Radiological scheduling (not using ICDA codes)||Planung von radiologischen Untersuchungen
|-
|S||Sign and symptom||Symptome
|-
|T||Tissue diagnosis||Gewebebestimmung
|-
|}

===DG1-20 ID der Diagnose===

{{ GermanText |
Jede Diagnose soll eine eindeutige Identifikation für eine spätere Referenzierung erhalten. Die Eindeutigkeit ist innerhalb des gesamten Systems über alle Fälle sicherzustellen, da die IDs auch nach einem Merge von unterschiedlichen Fällen immer noch eindeutig sein müssen.

Dieses Feld ist in der P12-Nachricht zwingend notwendig.
}}

{{EnglishText |
Each diagnosis shall get a unique identification allowing for a subsequent referencing. The uniqueness within the whole system across all visis/cases shall be given because it should still be unique after a merge of visits.
}}

===DG1-21 Diagnose Aktionscode===

{{ GermanText |
Auszuführende Aktion mit dieser Diagnose. In der P12-Nachricht muss dieses Feld gefüllt sein.
}}

{{EnglishText |
This field contains the transaction which shall be performed with this diagnosis. This field is required for a P12 message.
}}

====Tabelle 0206: Segment action code====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|U||Update||Ändern
|-
|A||Add/Insert||Hinzufügen
|-
|D||Delete||Löschen
|-
|}

[[Kategorie:Segmente|DG1]]
[[Kategorie:v2profile|DG1]]

Segment ARV

2023-07-11T08:46:57Z

Foemig: Initial Draft

==ARV - Segment ARV: Access Restriction (Zugriffsbeschränkung)==

{{GermanText|
Das Segment ARV ist für Informationen vorgesehen, die eine Zugriffsbeschränkung regeln.
}}

{{EnglishText|
This segment is designated for information about access restrictions to patient-related data.
}}

{| class="hl7table"
!Lfd. Nr.!!Beschreibung!!Kard.!!Verwendung!!Tab.!!Data Item!!DT!!Länge!!Kap.
|-
|1 ||Set ID / ARV-Segmentnummer ||1..4 || bgcolor="BBFFFF" | R (O) || ||02143 ||SI || ||3.4.14.1
|-
|2 ||Access Restriction Action Code / Aktionscode || || R ||0206 || 02144 ||CNE || ||3.4.14.2
|-
|3 ||Access Restriction Value / Zugriffsbeschränkung auf || || R || 0717 ||02145 ||CWE || ||3.4.14.3
|-
|4 ||Access Restriction Reason / Grund für Zugriffsbeschränkung || Y || O ||0719 || 02146 ||CWE || ||3.4.14.4
|-
|5 ||Special Access Restriction Instructions / Spezielle Handlungsanweisungen für Zugriffsbeschränkung || Y ||O || ||02147 ||ST || 250= ||3.4.14.5
|-
|6 ||Access Restriction Date Range / Gültigkeit Zugriffsbeschränkung || ||O || || 02148 ||DR || ||3.4.14.6
|-
|7 ||Security Classification Tag|| || R || 0952 ||03512 ||CWE || ||3.4.14.7
|-
|8 ||Security Handling Instructions || Y || O || 0953 || 03513 ||CWE || ||3.4.14.8
|-
|9 ||Access Restriction Message Location || Y ||O || ||03514 ||ERL || ||3.4.14.9
|-
|10 ||Access Restriction Instance Identifier || || C || || 02470 ||EI || ||3.4.14.10
|-
|}

===ARV-1 - Set ID / ARV-Segmentnummer ===
{{GermanText|
In diesem Feld wird eine fortlaufende Nummer für jede Wiederholung dieses Segmentes unabhängig vom Vorkommen in der Nachricht eingetragen.
}}

{{EnglishText|
tbd
}}

===ARV-2 - Access Restriction Action Code / Aktionscode ===
{{GermanText|
tbd
}}

{{EnglishText|
tbd
}}

===ARV-3 - Access Restriction Value / Zugriffsbeschränkung auf ===
{{GermanText|
tbd
}}

{{EnglishText|
tbd
}}

{| class="hl7table"
!Wert!!Beschreibung
|-
| ? || Ehepartner
|-
| ? || Pförtner
|-
| ? || Pfarrer
|-
| ? || Betriebsrat
|-
| ? || Arbeitgeber
|-
| ? || kein Besuch
|-
|}

===ARV-7 - Security Classification Tag ===
{{GermanText|
tbd
}}

{{EnglishText|
Values to be taken from https://terminology.hl7.org/CodeSystem-v3-Confidentiality.html
}}

{| class="hl7table"
!Wert!!Beschreibung
|-
| ? || ??
|-
|}

[[Kategorie:Segmente|ARV]]
[[Kategorie:v2profile|ARV]]

Segment PV2

2023-07-11T08:10:46Z

Foemig: Verlegungsgrund für tagesstationäre Behandlung in PV2-4

==PV2 – Patient Visit – Additional Information==

{{GermanText|
Das Segment PV2 ist für Informationen vorgesehen, die nur gelegentlich zu übertragen sind.
}}

{{EnglishText|
This segment is designated for information about the patients visit, which are rarely necessary.
}}

{| class="hl7table"
!Lfd. Nr.!!Beschreibung!!Kard.!!Verwendung!!Tab.!!Data Item!!DT!!Länge!!Kap.
|-
|1||Prior Pending Location/ Vorheriger vorgesehener Aufenthaltsort||[0..1]|| bgcolor="BBFFFF" |O (C)|| ||00181||PL||||3.4.4.1
|-
|2||Accommodation Code/ Unterbringungsart||[0..1]||O||0129||00182||CE||||3.4.4.2
|-
|3||Admit Reason/ Aufnahmegrund (Schlüssel 1 GSG)||[0..1]|| bgcolor="BBFFFF" |O (C) || ||00183||CE||4 (250)||3.4.4.3
|-
|4||Transfer Reason/ Verlegungsgrund||[0..1]||O|| ||00184||CE||||3.4.4.4
|-
|5||Patient Valuables/ Wertgegenstände des Patienten||[0..*]||O|| ||00185||ST||||3.4.4.5
|-
|6||Patient Valuables Location/ Aufbewahrungsort der Wertgegenstände||[0..1]||O|| ||00186||ST||||3.4.4.6
|-
|7||Visit User Code/ Zusätzliche Fallkategorisierung||[0..*]||O||0130||00187||IS||||3.4.4.7
|-
|8||Expected Admit Date/Time/ Voraussichtlicher Aufnahmezeitpunkt||[0..1]||O|| ||00188||TS||||3.4.4.8
|-
|9||Expected Discharge Date/Time/ Voraussichtlicher Entlassungszeitpunkt||[0..1]||O|| ||00189||TS||||3.4.4.9
|-
|10||Estimated Length of Inpatient Stay/ Voraussichtliche Dauer des stationären Aufenthaltes||[0..1]||O||||00711||NM||||3.4.4.10
|-
|11||Actual Länge of Inpatient Stay/ Tatsächliche Dauer des stationären Aufenthaltes||[0..1]||O||||00712||NM||||3.4.4.11
|-
|12||Visit Beschreibung/ Fallbeschreibung||[0..1]||O||||00713||ST||||3.4.4.12
|-
|13||Referral Source Code/ Überweisende Einrichtung||[0..*]||O||||00714||XCN||||3.4.4.13
|-
|14||Previous Service Date/ Datum der letzten Behandlung aus demselben Grund||[0..1]||O||||00715||DT||||3.4.4.14
|-
|15||Employment Illness Related Indicator/ Merkmal berufsbedingte Krankheit||[0..1]||O||0136||00716||ID||||3.4.4.15
|-
|16||Purge Status Code/ Buchungsabschlußcode||[0..1]||O||0213||00717||IS||||3.4.4.16
|-
|17||Purge Status Date/ Buchungsabschlußdatum||[0..1]||O||||00718||DT||||3.4.4.17
|-
|18||Special Program Code/ Codes für spezielle Gesundheitsprogramme||[0..1]||O||0214||00719||IS||||3.4.4.18
|-
|19||Retention Indicator/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X O||0136||00720||ID||||3.4.4.19
|-
|20||Expected Number of Insurance Plans/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X O||||00721||NM||||3.4.4.20
|-
|21||Visit Publicity Code/ Auskunftsbeschränkung||[0..1]||O||0215||00722||IS||||3.4.4.21
|-
|22||Visit Protection Indicator/ Merkmal besonderer Vertrauensschutz||[0..1]||O||0136||00723||ID||||3.4.4.22
|-
|23||Clinic Organization Name/ Mitbehandelnde Leistungstelle||[0..1]||O||||00724||XON||||3.4.4.23
|-
|24||Patient Status Code/ Fallstatus||[0..1]||O||0216||00725||IS||||3.4.4.24
|-
|25||Visit Priority Code/ nicht verwendet (s. PV1-4 Admission Type)||[0..0]|| bgcolor="BBFFFF" |X O||0217||00726||IS||||3.4.4.25
|-
|26||Previous Treatment Date/ Datum der letzten Behandlung||[0..1]||O||||00727||DT||||3.4.4.26
|-
|27||Expected Discharge Disposition/ Erwartete Entlassungsart||[0..1]||O||0112||00728||IS||||3.4.4.27
|-
|28||Signature on File Date/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X O||||00729||DT||||3.4.4.28
|-
|29||First Similar Illness Date/ Datum erster ähnlicher Erkrankung||[0..1]||O||||00730||DT||||3.4.4.29
|-
|30||Patient Charge Adjustment Code/ Sonderkonditionen für Patienten||[0..1]||O||0218||00731||CE||||3.4.4.30
|-
|31||Recurring Service Code/ Fortlaufende Behandlung||[0..1]||O||0219||00732||IS||||3.4.4.31
|-
|32||Billing Media Code/ Merkmal Rechnung nicht über (elektronischen) Datenaustausch||[0..1]||O||0136||00733||ID||||3.4.4.32
|-
|33||Expected Surgery Date and Time/ Vorgesehener Zeitpunkt eines (operativen) Eingriffs||[0..1]||O||||00734||TS||||3.4.4.33
|-
|34||Military Partnership Code/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (O)||0136||00735||ID||||3.4.4.34
|-
|35||Military Non-Availability Code/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (O)||0136||00736||ID||||3.4.4.35
|-
|36||Newborn Baby Indicator/ Merkmal Neugeborenes||[0..1]||O||0136||00737||ID||||3.4.4.36
|-
|37||Baby Detained Indicator/ Merkmal Weiterbehandlung des Neugeborenen||[0..1]||O||0136||00738||ID||||3.4.4.37
|-
|38||Mode of Arrival Code/ Transportart bei Ankunft||[0..1]||O||0430||01543||CE||||3.4.4.38
|-
|39||Recreational Drug Use Code/ Drogengebrauch||[0..*]||O||0431||01544||CE||||3.4.4.39
|-
|40||Admission Level of Care Code/ Charakterisierung des Krankheitszustandes||[0..1]||O||0432||01545||CE||||3.4.4.40
|-
|41||Precaution Code/ Hinweise für Vorsichtsmaßnahmen||[0..*]||O||0433||01546||CE||||3.4.4.41
|-
|42||Patient Condition Code/ Zustand des Patienten||[0..1]||O||0434||01547||CE||||3.4.4.42
|-
|43||Living Will Code/ letzter Wille||[0..1]||O||0315||00759||IS||||3.4.4.43
|-
|44||Organ Donor Code/ Einwilligung zur Organspende||[0..1]||O||0316||00760||IS||||3.4.4.44
|-
|45||Advance Directive Code/ Verfügung des Patienten||[0..*]||O||0435||01548||CE||||3.4.4.45
|-
|46||Patient Status Effective Date/ Gültigkeitsdatum für Fallstatus||[0..1]||O||||01549||DT||||3.4.4.46
|-
|47||Expected LOA Return Date/ Time/ erwarteter Rückkehrzeitpunkt bei Abwesenheit||[0..1]|| bgcolor="BBFFFF" |C(R/O) (C)||||01550||TS||||3.4.4.47
|-
|48||Expected Pre-admission Testing Date/Time/ erwarteter Zeitpunkt der Voruntersuchungen||[0..1]||O||||01841||TS||||3.4.4.48
|-
|49||Notify Clergy Code/ Benachrichtigung Geistlicher||[0..*]||O||0534||01842||IS||||3.4.4.49
|-
|}

===PV2-1 Vorheriger vorgesehener Aufenthaltsort===
{{GermanText|
Dieses Feld kann auf optional gesetzt werden, da es nur dann required wäre, wenn es sich um eine A26 (cancel pending transfer) handeln würde.
}}

{{EnglishText|
This field is optional.
}}

===PV2-3 Aufnahmegrund (Schlüssel 1 GSG)===
{{GermanText|
In diesem Feld wird der Aufnahmegrund gemäß dem 1. Schlüssel des Gesundheitsstrukturgesetzes (GSG) übermittelt. Als Codiersystem ist hier "GSG0001" anzugeben.

Dieser Schlüssel ist wie folgt aufgebaut:
}}

{{EnglishText|
This field contains the admission reason according to the first key of the Gesundheitsstrukturgesetzes (GSG). "GSG0001" shall be used as the coding system.
}}

{| class="hl7table"
!Stelle!!Wert!!Beschreibung
|-
|1. u. 2.||01||Krankenhausbehandlung, vollstationär
|-
| ||02||Krankenhausbehandlung vollstationär mit vorausgegangener vorstationärer Behandlung
|-
| ||03||Krankenhausbehandlung, teilstationär
|-
| ||04||Vorstationäre Behandlung ohne anschließende vollstationäre Behandlung
|-
| ||05||Entbindungsanstaltspflege
|-
| ||06||Übergang Krankenhausbehandlung/Entbindungsanstaltspflege
|-
| ||07||Übergang Entbindungsanstaltspflege/Krankenhausbehandlung
|-
| ||08||Nicht rechtswidrige Sterilisation (§ 24 b SGB V)
|-
| ||09||Nicht rechtswidriger Schwangerschaftsabbruch (§ 24 b SGB V)
|-
|3. u. 4.||01||Normalfall
|-
| ||02||Arbeitsunfall / Wegeunfall / Berufskrankheit
|-
| ||03||Verkehrsunfall / Sportunfall / Sonstiger Unfall
|-
| ||04||Hinweis auf Mord / Totschlag / Raufhändel
|-
| ||05||Hinweis auf Selbstmord / Selbstbeschädigung
|-
| ||06||Kriegsbeschädigten-Leiden / BVG-Leiden
|-
| ||07||Notfall
|-
| ||21 – 27||Bei Zuständigkeit des Leistungsträgers: anstelle von 01 bis 07
|-
|}

{{NoteBox|
Bei Aufnahmegrund 05 bis 09 (1. und 2. Stelle) dürfen die 3. und 4. Stelle nur 01 oder 21 enthalten.
}}

===PV2-4 Verlegungsgrund===

{{GermanText|
In diesem Feld wird der Grund für die Verlegung übermittelt.
Der Schlüssel 5 aus dem GSG bietet sich hier nicht an, da dort nur Verlegungen in andere Krankenhäuser spezifiziert sind.

Im Falle einer tagesstationären Behandlung, d.h. der Patient geht bei einer vollstationäern Behandlung nachts nach Hause, wird in diesem Feld - in einer A21/A22-Ereignisse/Nachricht der entsprechende Grund übermittelt.
}}

{{EnglishText|
This field conveys the reason of the transfer.
The key "5" from GSG is not applicable here, as it only applies to transfers to other hospitals.

In case of an inpatient treatment, where the patient will leave the hospital for the night, this field is used to convey the appropriate reason in combination with A21/A22 events/messages.
}}

{| class="hl7table"
!Wert!!Beschreibung
|-

|31||Beginn eines externen Aufenthaltes bei tagesstationärer Behandlung
|-

|32||reguläre Beendigung eines externen Aufenthaltes bei tagesstationärer Behandlung
|-

|33||ungeplante Beendigung eines externen Aufenthaltes bei tagesstationärer Behandlung - Notfall
|-

|34||ungeplante Beendigung eines externen Aufenthaltes bei tagesstationärer Behandlung - medizinischer Behandlungsbedarf
|-

|35||ungeplante Beendigung eines externen Aufenthaltes bei tagesstationärer Behandlung - Wunsch des Patienten
|-

|}

===PV2-8 voraussichtlicher Aufnahmezeitpunkt===

{{GermanText|
In diesem Feld wird der Zeitpunkt der voraussichtlichen/geplanten Aufnahme übermittelt.
}}

{{EnglishText|
This field contains the timestamp of the planned admission.
}}

===PV2-9 voraussichtlicher Entlassungszeitpunkt===

{{GermanText|
In diesem Feld wird der Zeitpunkt der voraussichtlichen/geplanten Entlassung übermittelt.
}}

{{EnglishText|
This field contains the timestamp of the planned discharge.
}}

===PV2-10 voraussichtliche Aufenthaltsdauer===

{{GermanText|
In diesem Feld wird die voraussichtliche Aufenthaltsdauer in Tagen übermittelt. Urlaubs-/Abwesenheitstage werden dabei nicht mitgezählt.
}}

{{EnglishText|
This field transmits the foreseen days of visit. Vacation and leave of absence are not counted.
}}

===PV2-11 Aufenthaltsdauer===

{{GermanText|
In diesem Feld wird die tatsächliche Aufenthaltsdauer in Tagen übermittelt. Urlaubs-/Abwesenheitstage werden dabei nicht mitgezählt.
}}

{{EnglishText|
This field contains the real days of the visit. Vacation and leave of absence are not counted.
}}

===PV2-47 erwarteter Rückkehrzeitpunkt bei Abwesenheit===

{{GermanText|
Dieses Feld enthält den geplanten Zeitpunkt der Rückkehr bei Abwesenheiten (Urlaub) und ist dort (A21) required. Bei allen anderen Nachrichten kann es von optional nach Erfordernis weiter eingeschränkt werden.
}}

{{EnglishText|
This field contains the timestamp for the intended return from leave of absence and is required thereof (A21). For all other message this field can be constrained further.
}}

[[Kategorie:Segmente|PV2]]
[[Kategorie:v2profile|PV2]]

Segment PR1

2022-12-22T08:36:36Z

Foemig: Codes ergänzt

==PR1 – Massnahmen (Procedures)==

{{GermanText|
In diesem Segment werden die durchgeführten Maßnahmen dokumentiert.
}}

{{EnglishText|
This segment transmits information about performed procedures and treatments.
}}

{| class="hl7table"
!Lfd. Nr.!!Beschreibung!!Kard.!!Verwendung!!Tab.!!Data Item!!DT!!Länge!!Kap.
|-
|1||Set ID – PR1/ PR1-Segmentnummer||[1..1]||R||||00391||SI||||6.5.4.1
|-
|2||Procedure Coding Method/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0089||00392||IS||||6.5.4.2
|-
|3||Procedure Code/ Maßnahmen- / Operationsschlüssel||[1..1]||R||0088||00393|| bgcolor="BBFFFF" |CNE (CE)||||4.5.3.44
|-
|4||Procedure Beschreibung/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00394||ST||||6.5.4.4
|-
|5||Procedure Date/Time/ Zeitpunkt der Maßnahme||[1..1]||R||||00395||TS||||6.5.4.5
|-
|6||Procedure Functional Type/ Art der Maßnahme||[0..1]||O||0230||00396||IS||||6.5.4.6
|-
|7||Procedure Minutes/ Dauer der Maßnahme in Minuten||[0..1]||O||||00397||NM||||6.5.4.7
|-
|8||Anesthesiologist/ nicht verwendet (veraltet; PR1-12 benutzen)||[0..0]|| bgcolor="BBFFFF" |X (B)||0010||00398||XCN||||6.5.4.8
|-
|9||Anesthesia Code/ nicht verwendet (veraltet; PR1-3 benutzen)||[0..0]|| bgcolor="BBFFFF" |X (O)||0019||00399||IS||||6.5.4.9
|-
|10||Anesthesia Minutes/ nicht verwendet (veraltet; PR1-7 benutzen)||[0..0]|| bgcolor="BBFFFF" |X (O)||||00400||NM||||6.5.4.10
|-
|11||Surgeon/ nicht verwendet (veraltet; PR1-12 benutzen)||[0..0]|| bgcolor="BBFFFF" |X (B)||0010||00401||XCN||||6.5.4.11
|-
|12||Procedure Practitioner/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0010||00402||XCN||||6.5.4.12
|-
|13||Consent Code/ Zustimmung des Patienten||[0..1]||O||0059||00403||CE||||6.5.4.13
|-
|14||Procedure Priority/ Priorität der Maßnahme||[0..1]|| bgcolor="BBFFFF" |RE (O)||0418||00404||ID||||6.5.4.14
|-
|15||Associated Diagnosis Code/ Zugehörige Diagnose||[0..1]||O||0051||00772||CE||||6.5.4.15
|-
|16||Procedure Code Modifier/ Modifikator zum Prozedurcode||[0..\*]||O||0340||01316||CE||||4.5.3.45
|-
|17||Procedure DRG Type/ Prioritätseinstufung für DRG||[0..1]||O||0416||01501||IS||||6.5.4.17
|-
|18||Tissue Type Code/ Art des entnommenen Gewebes||[0..1]||O||0417||01502||CE||||6.5.4.18
|-
|19||Procedure Identifier/ ID der Maßnahme||[0..1]||C||||01848||EI||||6.5.4.19
|-
|20||Procedure Action Code/ Maßnahme Aktionscode||[0..1]||C||0206||01849||ID||||6.5.4.20
|-
|}

===PR1-1 Segmentnummer===

{{GermanText|
In diesem Feld wird eine fortlaufende Nummer für jede Wiederholung dieses Segmentes eingetragen.
}}

{{EnglishText|
This field contains a consecutive number identifying each repetition of this segment within a message uniquely.
}}

===PR1-3 Maßnahmen/Operationsschlüssel===

{{GermanText|
Die eigentliche Maßnahme besteht aus einer kodierten Information und/oder einer textuellen Beschreibung.
}}

{{EnglishText|
This field contains the performed procedure which consist of coded information and a textual description.
}}

Beispiel 1: Koronarangiographie ohne weitere Maßnahmen
1-275.0^Koronarangiographie ohne weitere Maßnahmen^O301-2004

Beispiel 2: Native Computertomographie des Thorax
3-202^Native Computertomographie des Thorax^O301-2004

{{GermanText|
Zur Kodierung der Prozeduren stehen folgende OPS-Kataloge zur Verfügung:
}}

{{EnglishText|
The following tables shall be used for coding the procedures:
}}

{| class="hl7table"
!Code!!Bedeutung
|-
|O301-2004||OPS-Katalog 2004
|-
|O301-2005||OPS-Katalog 2005
|-
|O301-2006||OPS-Katalog 2006
|-
| ... || ...
|-
|OPS2007||OPS-Katalog 2007
|-
| ... || ...
|-
|OPS2022||OPS-Katalog 2022
|-
| ... || ...
|}

{{GermanText|
Dieser Katalog kann erweitert werden.
}}

{{EnglishText|
This table can be extended.
}}

====Lokalisation====

{{GermanText|
Die Lokalisation kann folgende Werte annehmen:
}}

{{EnglishText|
The localisation can use the following values:
}}

{| class="hl7table"
!Code!!Bedeutung
|-
|R||rechts
|-
|L||links
|-
|B||beidseitig
|-
|}

{{GermanText|
Der Wert für die Lokalisation wird an den Prozedurcode (mit einem Leerzeichen als Trenner) angehängt.
}}

{{EnglishText|
The value for the localisation shall be appended to the procedure code separated by a blank.
}}

Beispiel: Therapeutische perkutane Punktion eines Gelenkes: Zehengelenk rechts
8-158.r R^Therapeutische perkutane Punktion eines Gelenkes: Zehengelenk^O301-2004

{{GermanText|
Anmerkung: Die InEK verlangt für die Übertragung zu einem Grouper als Trennzeichen den Doppelpunkt (":"). Eine Konfigurationsmöglichkeit ist deshalb empfehlenswert.
}}

{{EnglishText|
Note: The InEK requires a doubble point (":") as a separator for transmitting the data to the grouping software. Having the opportunity to configure this is recommended.
}}

===PR1-5 Zeitpunkt der Maßnahme===

{{GermanText|
In diesem Feld wird der Zeitpunkt festgehalten, wann die Maßnahme durchgeführt wurde.
}}

{{EnglishText|
This field contains the timestamp when this procedure/treatment was performed.
}}

===PR1-6 Art der Maßnahme===

{{GermanText|
In diesem Feld wird die Arte der Maßnahme angegeben.
}}

{{EnglishText|
This field contains information about the type of the procedure.
}}

====Tabelle 0230: Procedure Functional Type====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|A||Anesthesia||Narkose
|-
|D||Diagnostic procedure||Diagnosestellung
|-
|I||Invasive procedure not classified elsewhere (e.g., IV, catheter, etc.)||operativer Eingriff
|-
|P||Procedure for treatment (therapeutic, including operations)||Behandlung
|-
|}

===PR1-14 Priorität der Maßnahme===

{{GermanText|
In diesem Feld wird die Unterscheidung zwischen Haupt- und Nebenmaßnahmen getroffen. Die Hauptprozedur erhält den Wert "1". Alle weiteren Maßnahmen erhalten mit absteigender Priorität weitere Ziffern beginnend mit "2".
}}

{{EnglishText|
This field contains the priority of the procedure. It must be separated between primary and secondary treatment. The primary procedure contain the value "1". All subsequent procedure with descending priority are getting the next numbers starting with "2".
}}

====Tabelle 0418: Procedure Priority====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|1||the primary procedure||Hauptprozedur
|-
|2||for ranked secondary procedures||klassifizierte Nebenprozeduren
|-
|…||Weitere Codes||
|-
|}

===PR1-19 ID der Maßnahme===

{{GermanText|
Jede Maßnahme soll eine eindeutige Identifikation für eine spätere Referenzierung erhalten. Die Eindeutigkeit ist innerhalb des gesamten Systems über alle Fälle sicherzustellen, da die IDs auch nach einem Merge von unterschiedlichen Fällen immer noch eindeutig sein müssen.

Dieses Feld ist in der P12-Nachricht zwingend notwendig.
}}

{{EnglishText|
Each procedure/treatment shall get a unique identifier allowing for a later referencing. The uniqueness shall be given within the whole system across all cases/visits, because they shall still be unique after a merge of patient records.

This field is required for a P12 message.
}}

===PR1-20 Maßnahme Aktionscode===

{{GermanText|
Der Aktionscode gibt an, was mit der Information im PR1-Segment zu geschehen hat.

Diese Feld ist in der P12-Nachricht zwingend notwendig.
}}

{{EnglishText|
The action code defines what shall be done with the information in the PR1 segment.

This field is required for a P12 message.
}}

[[Kategorie:Segmente|PR1]]
[[Kategorie:v2profile|PR1]]

Segment DG1

2022-12-22T08:34:07Z

Foemig: Codes ergänzt

==DG1 – Diagnosen (Diagnosis)==

{{ GermanText |
In diesem Feld werden die einzelnen Diagnosen inklusive ihrer Attribute übermittelt.
}}

{{EnglishText |
This field contains the individual diagnoses as well as their attributes.
}}

{| class="hl7table"
!Lfd. Nr.!!Beschreibung!!Kard.!!Verwendung!!Tab.!!Data Item!!DT!!Länge!!Kap.
|-
|1||Set ID – DG1/ DG1-Segmentnummer||[1..1]||R||||00375||SI||||6.5.2.1
|-
|2||Diagnosis Coding Method/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0053||00376||ID||||6.5.2.2
|-
|3||Diagnosis Code – DG1/ Diagnoseschlüssel||[1..1]|| bgcolor="BBFFFF" |R (O)||0051||00377|| bgcolor="BBFFFF" |CNE (CE)||||6.5.2.3
|-
|4||Diagnosis Beschreibung/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00378||ST||||6.5.2.4
|-
|5||Diagnosis Date/Time/ Zeitpunkt der Diagnosestellung|| bgcolor="BBFFFF" |[0..1]|| bgcolor="BBFFFF" |C (O)||||00379||TS||||6.5.2.5
|-
|6||Diagnosis Type/ Diagnosetyp||[1..1]||R||0052||00380||IS||2||6.5.2.6
|-
|7||Major Diagnostic Category/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0118||00381||CE||||6.5.2.7
|-
|8||Diagnostic Related Group/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0055||00382||CE||||6.5.2.8
|-
|9||DRG Approval Indicator/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0136||00383||ID||||6.5.2.9
|-
|10||DRG Grouper Review Code/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0056||00384||IS||||6.5.2.10
|-
|11||Outlier Type/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0083||00385||CE||||6.5.2.11
|-
|12||Outlier Days/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00386||NM||||6.5.2.12
|-
|13||Outlier Cost/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00387||CP||||6.5.2.13
|-
|14||Grouper Version And Type/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00388||ST||||6.5.2.14
|-
|15||Diagnosis Priority/ Diagnosepriorität (1 = Hauptdiagnose, 2..n = weitere Diagnosen)|| bgcolor="BBFFFF" |[1..1]|| bgcolor="BBFFFF" |R (O)||0359||00389||ID|| bgcolor="BBFFFF" |3(2)||6.5.2.15
|-
|16||Diagnosing Clinician/ Verantwortlicher Arzt||[0..*]|| bgcolor="BBFFFF" |RE (O)||||00390||XCN|| ||6.5.2.16
|-
|17||Diagnosis Classification/ Art der Diagnose||[0..1]||O||0228||00766||IS|| ||6.5.2.17
|-
|18||Confidential Indicator/ Merkmal der Vertraulichkeit der Diagnose||[0..1]||O||0136||00767||ID|| ||6.5.2.18
|-
|19||Attestation Date/Time/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (O)|| ||00768||TS|| ||6.5.2.19
|-
|20||Diagnosis Identifier/ ID der Diagnose||[1..1]|| bgcolor="BBFFFF" |R (C)|| ||01850||EI|| ||6.5.2.20
|-
|21||Diagnosis Action Code/ Diagnose Aktionscode||[1..1]|| bgcolor="BBFFFF" |R (C)||0206||01894||ID||||6.5.2.21
|-
|}

===DG1-1 Segmentnummer===

{{ GermanText |
Die Segmentnummer dient der fortlaufenden Nummerierung aller DG1-Segmente unabhängig vom Vorkommen in der Nachricht.
}}

{{EnglishText |
The purpose of the segment number is the sequential numbering of all DG1 segments independently of their occurrence within a message.
}}

===DG1-3 Diagnoseschlüssel===

{{ GermanText |
Die eigentliche Diagnose besteht aus einer kodierten Information und/oder einer textuellen Beschreibung.
}}

{{EnglishText |
The actual diagnosis is composed out of a coded information and/or a textual description.
}}

Beispiel 1: Blinddarmentzündung
^BlinddarmentzündungBeispiel 2: K57.1: Appendizitis
K57.1^Appendizitis^I10-2004

Zur Kodierung der Diagnosen stehen folgende Kataloge für ICD-10, Alpha-Id und OrphaId zur Verfügung:

{| class="hl7table"
!Jahr!! ICD-10-Katalog!!Alpha-Id-Katalog!!Orpha-Id-Katalog!!MDC!!G-DRG
|-
|2004||I10G2004|| - || || GMDC2004 || GDRG2004
|-
|2005||I10G2005|| - || || GMDC2005 || GDRG2005
|-
|2006||I10G2006||ALPHAID2006|| || GMDC2006 || GDRG2006
|-
| ... || ... || ...
|-
|2007||ICD10GM2007||ALPHAID2007|| || GMDC2007 || GDRG2007
|-
| ... || ... || ...
|-
|2022||ICD10GM2022||ALPHAID2022|| || GMDC2022 || GDRG2022
|-
| ... || ...
|}

{{ GermanText |
Neben den ICD-10-Diagnosen können aber auch andere Codesysteme wie Alpha-ID oder Orpha-Id genutzt werden.
Dafür sind die entsprechenden Identifikationen aus Tabelle 0396 zu verwenden.
}}

{{EnglishText |
Beside ICD-10 diagnosis codes, other codesystems like Alpha-ID or Orpha-Id can be used.
Therefore, the identifications from table 0396 shall be used.
}}

{{ GermanText |
Neben dem eigentlichen Diagnoseschlüssel gibt es noch Diagnosezusätze und eine Lokalisation.
}}

{{EnglishText |
Besides the actual diagnosis key there are diagnosis supplements and a localization.
}}

====Diagnosezusatz====
Der Diagnosezusatz wird wie folgt kodiert:

{| class="hl7table"
!Code!!Beschreibung!!Interpretation
|-
|V|| Verdacht auf ||Verdachtsdiagnose
|-
|Z|| Zustand nach ||Zustand nach der betreffenden Diagnose
|-
|A|| ausgeschlossen ||Ausgeschlossene Diagnose
|-
|G|| gesichert ||gesicherte Diagnose
|-
|}

====Lokalisation====
Die Lokalisation kann folgende Werte annehmen:

{| class="hl7table"
!Code!!Beschreibung!!Interpretation
|-
|R||right||rechts
|-
|L||left||links
|-
|B||both sides||beidseitig
|-
|}

{{ GermanText |
Die Werte für den Diagnosezusatz und die Lokalisation werden an den Diagnosecode in beliebiger Reihenfolge (mit einem Leerzeichen als Trenner) angehängt.
}}

{{EnglishText |
The values for the diagnosis type and for the localization are added to the diagnosis code (separated by blanks) in an arbitrary way.
}}

Beispiel: Schnittwunde am linken Unterarm
S51.- L^^I10-2004

Beispiel: Ausgeschlossene, beidseitige Alterskatarakt:
H25.- BA^^I10-2004

====Fallhauptdiagnose====

{{ GermanText |
Die Kennzeichnung der Fallhauptdiagnose erfolgt über eine Markierung in dem Alternativcode. Dazu wird die Diagnose in der Alternativcodierung wiederholt, allerdings wird dann an den Code eine "1" und an den Katalog "ext" angehängt.
}}

{{EnglishText |
The main diagnosis of the case is marked by an alternate code. For that purpose the diagnosis is repeated in the alternate coding system, but a “1” is added to the code and an “ext” to the catalog.
}}

Beispiel: Die Entlassdiagnose bestätigt nochmals die Appendizitis und wird als Hauptdiagnose für den Krankenhausaufenthalt gewertet.
K37^Nicht näher bezeichnete Appendizitis^I10-2004^K37'''1'''^Nicht näher bezeichnete Appendizitis^I10-2004'''ext'''

===DG1-5 Zeitpunkt der Diagnosestellung===

{{ GermanText |
In diesem Feld wird übermittelt, wann die Diagnose gestellt wurde.
Dieses Feld ist erforderlich, aber ggf. leer ("RE" (required, but may be empty)), wenn es sich um eine Einweisungsdiagnose handelt. Bei allen anderen Diagnosetypen ist dieses Feld "R" (required).
}}

{{EnglishText |
In diesem Feld wird übermittelt, wann die Diagnose gestellt wurde.
This field is required, but may be empty (“RE”) if the diagnosis is an admitting diagnosis. For all other diagnosis types this field is required (“R”).
}}

===DG1-6 Diagnosetyp===

{{ GermanText |
Der Diagnosetyp legt die Art der Diagnose fest.
}}

{{EnglishText |
The diagnosis type indicates the type of the diagnosis.
}}

====Tabelle 0052: Diagnosis Type====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|AD|| admitting diagnosis||Aufnahmediagnose
|-
|BD|| treating diagnosis||Behandlungsdiagnose
|-
|ED|| referral diagnosis||Einweisungsdiagnose
|-
|EL|| discharge/transfer diagnosis||Entlassungs- / Verlegungsdiagnose
|-
|ND|| ||Nachfolgediagnose
|-
|NO|| ||Nachfolgediagnose Operieren
|-
|NU|| ||Nachfolgediagnose, die die Arbeitsunfähigkeit allein begründet hat
|-
|UD|| ||Überweisungsdiagnose
|-
|VO|| ||Präoperative Diagnose
|-
|ZD|| ||Neben- / Zusatzdiagnose
|-
|}

===DG1-15 Diagnosepriorität===

{{ GermanText |
Die Diagnosepriorität dient der Unterscheidung zwischen Haupt- und Nebendiagnosen. Die Hauptdiagnose erhält den Wert "1". Alle Nebendiagnosen erhalten mit absteigender Priorität weitere Ziffern beginnend mit "2".
}}

{{EnglishText |
The priority of a diagnosis distinguishes between primary and secondary diagnoses. The primary diagnosis has the value “1”. All other diagnoses get a higher number starting with 2 in a decreasing ranking.
}}

====Tabelle 0359: Diagnosis Priority====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|1||The primary diagnosis||Hauptdiagnose
|-
|1.1||main diagnosis (primary) ||Hauptdiagnose (primär)
|-
|1.2||main diagnosis (secondary) ||Hauptdiagnose (sekundär)
|-
|2||For ranked secondary diagnoses||Nebendiagnose
|-
|2.1|| ||Nebendiagnose (primär)
|-
|2.2|| ||Nebendiagnose (sekundär)
|-
|...|| ||
|-
|}

=====Kreuz-Stern-Notation=====

{{ GermanText |
Die Primärdiagnose bezieht sich auf die Ätiologie und wird mit "+" gekennzeichnet. Die Sekundärdiagnose hingegen definiert die Manifestation, welche mit "*" gekennzeichnet wird.

Diese beiden Informationen werden über die Diagnosepriorität kodiert. Hierzu wird als Nachkommastelle eine "1" für die Primärdiagnose und eine "2" für die Sekundärdiagnose verwendet.
}}

{{EnglishText |
The primary diagnosis refers to the etiology and shall be marked with "+". The secondary diagnosis refers to the manifestation which is marked by "*".

Both information will be coded by the diagnosis priority. Therefore, the primary diagnosis will get a "1" at the first position after decimal point, the secondary diagnosis will get "2".
}}

DG1|1||E11.5^...^I1020|||BD|||||||||1.1| Hauptdiagnose - Primärdiagnose
DG1|2||I79.2^...^I1020|||BD|||||||||1.2| Hauptdiagnose - Sekundärdiagnose
DG1|3||S42.41 R^...^I1020|||BD|||||||||2.1| Nebendiagnose - Primärdiagnose
DG1|4||V99^...^I1020|||BD|||||||||2.2| Nebendiagnose - Sekundärdiagnose

===DG1-16 Verantwortlicher Arzt===

{{ GermanText |
In diesem Feld wird der Arzt übertragen, der für die Stellung der Diagnose verantwortlich ist.
}}

{{EnglishText |
This field contains the physician who is responsible for declaring the diagnosis.
}}

===DG1-17 Art der Diagnose===

{{ GermanText |
Dieses Feld dient der Klassifikation der Diagnose.
}}

{{EnglishText |
This field is used for the classification of the diagnosis.
}}

====Tabelle 0228: Diagnosis Classification====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|C||Consultation||Behandlung
|-
|D||Diagnosis||Diagnose
|-
|I||Invasive procedure not classified elsewhere (I.V., catheter, etc.)||Maßnahme
|-
|M||Medication (antibiotic)||Medikation
|-
|O||Other||andere
|-
|R||Radiological scheduling (not using ICDA codes)||Planung von radiologischen Untersuchungen
|-
|S||Sign and symptom||Symptome
|-
|T||Tissue diagnosis||Gewebebestimmung
|-
|}

===DG1-20 ID der Diagnose===

{{ GermanText |
Jede Diagnose soll eine eindeutige Identifikation für eine spätere Referenzierung erhalten. Die Eindeutigkeit ist innerhalb des gesamten Systems über alle Fälle sicherzustellen, da die IDs auch nach einem Merge von unterschiedlichen Fällen immer noch eindeutig sein müssen.

Dieses Feld ist in der P12-Nachricht zwingend notwendig.
}}

{{EnglishText |
Each diagnosis shall get a unique identification allowing for a subsequent referencing. The uniqueness within the whole system across all visis/cases shall be given because it should still be unique after a merge of visits.
}}

===DG1-21 Diagnose Aktionscode===

{{ GermanText |
Auszuführende Aktion mit dieser Diagnose. In der P12-Nachricht muss dieses Feld gefüllt sein.
}}

{{EnglishText |
This field contains the transaction which shall be performed with this diagnosis. This field is required for a P12 message.
}}

====Tabelle 0206: Segment action code====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|U||Update||Ändern
|-
|A||Add/Insert||Hinzufügen
|-
|D||Delete||Löschen
|-
|}

[[Kategorie:Segmente|DG1]]
[[Kategorie:v2profile|DG1]]

Segment DG1

2022-12-21T14:33:00Z

Foemig: Diagnosezusatz ergänzt

==DG1 – Diagnosen (Diagnosis)==

{{ GermanText |
In diesem Feld werden die einzelnen Diagnosen inklusive ihrer Attribute übermittelt.
}}

{{EnglishText |
This field contains the individual diagnoses as well as their attributes.
}}

{| class="hl7table"
!Lfd. Nr.!!Beschreibung!!Kard.!!Verwendung!!Tab.!!Data Item!!DT!!Länge!!Kap.
|-
|1||Set ID – DG1/ DG1-Segmentnummer||[1..1]||R||||00375||SI||||6.5.2.1
|-
|2||Diagnosis Coding Method/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0053||00376||ID||||6.5.2.2
|-
|3||Diagnosis Code – DG1/ Diagnoseschlüssel||[1..1]|| bgcolor="BBFFFF" |R (O)||0051||00377|| bgcolor="BBFFFF" |CNE (CE)||||6.5.2.3
|-
|4||Diagnosis Beschreibung/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00378||ST||||6.5.2.4
|-
|5||Diagnosis Date/Time/ Zeitpunkt der Diagnosestellung|| bgcolor="BBFFFF" |[0..1]|| bgcolor="BBFFFF" |C (O)||||00379||TS||||6.5.2.5
|-
|6||Diagnosis Type/ Diagnosetyp||[1..1]||R||0052||00380||IS||2||6.5.2.6
|-
|7||Major Diagnostic Category/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0118||00381||CE||||6.5.2.7
|-
|8||Diagnostic Related Group/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0055||00382||CE||||6.5.2.8
|-
|9||DRG Approval Indicator/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0136||00383||ID||||6.5.2.9
|-
|10||DRG Grouper Review Code/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0056||00384||IS||||6.5.2.10
|-
|11||Outlier Type/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0083||00385||CE||||6.5.2.11
|-
|12||Outlier Days/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00386||NM||||6.5.2.12
|-
|13||Outlier Cost/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00387||CP||||6.5.2.13
|-
|14||Grouper Version And Type/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00388||ST||||6.5.2.14
|-
|15||Diagnosis Priority/ Diagnosepriorität (1 = Hauptdiagnose, 2..n = weitere Diagnosen)|| bgcolor="BBFFFF" |[1..1]|| bgcolor="BBFFFF" |R (O)||0359||00389||ID|| bgcolor="BBFFFF" |3(2)||6.5.2.15
|-
|16||Diagnosing Clinician/ Verantwortlicher Arzt||[0..*]|| bgcolor="BBFFFF" |RE (O)||||00390||XCN|| ||6.5.2.16
|-
|17||Diagnosis Classification/ Art der Diagnose||[0..1]||O||0228||00766||IS|| ||6.5.2.17
|-
|18||Confidential Indicator/ Merkmal der Vertraulichkeit der Diagnose||[0..1]||O||0136||00767||ID|| ||6.5.2.18
|-
|19||Attestation Date/Time/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (O)|| ||00768||TS|| ||6.5.2.19
|-
|20||Diagnosis Identifier/ ID der Diagnose||[1..1]|| bgcolor="BBFFFF" |R (C)|| ||01850||EI|| ||6.5.2.20
|-
|21||Diagnosis Action Code/ Diagnose Aktionscode||[1..1]|| bgcolor="BBFFFF" |R (C)||0206||01894||ID||||6.5.2.21
|-
|}

===DG1-1 Segmentnummer===

{{ GermanText |
Die Segmentnummer dient der fortlaufenden Nummerierung aller DG1-Segmente unabhängig vom Vorkommen in der Nachricht.
}}

{{EnglishText |
The purpose of the segment number is the sequential numbering of all DG1 segments independently of their occurrence within a message.
}}

===DG1-3 Diagnoseschlüssel===

{{ GermanText |
Die eigentliche Diagnose besteht aus einer kodierten Information und/oder einer textuellen Beschreibung.
}}

{{EnglishText |
The actual diagnosis is composed out of a coded information and/or a textual description.
}}

Beispiel 1: Blinddarmentzündung
^BlinddarmentzündungBeispiel 2: K57.1: Appendizitis
K57.1^Appendizitis^I10-2004

Zur Kodierung der Diagnosen stehen folgende ICD-Kataloge zur Verfügung:

{| class="hl7table"
!Code!!Beschreibung!!Interpretation
|-
|I10-2004||ICD 10-Katalog 2004
|-
|I10-2005||ICD 10-Katalog 2005
|-
|I10-2006||ICD 10-Katalog 2006
|-
| ... || ...
|-
|icd10gm2014||ICD 10-Katalog 2014
|-
|icd10gm2015||ICD 10-Katalog 2015
|-
| ... || ...
|}

{{ GermanText |
Neben den ICD-10-Diagnosen können aber auch andere Codesysteme wie Alpha-ID oder Orpha-Id genutzt werden.
Dafür sind die entsprechenden Identifikationen aus Tabelle 0396 zu verwenden.
}}

{{EnglishText |
Beside ICD-10 diagnosis codes, other codesystems like Alpha-ID or Orpha-Id can be used.
Therefore, the identifications from table 0396 shall be used.
}}

{{ GermanText |
Neben dem eigentlichen Diagnoseschlüssel gibt es noch Diagnosezusätze und eine Lokalisation.
}}

{{EnglishText |
Besides the actual diagnosis key there are diagnosis supplements and a localization.
}}

====Diagnosezusatz====
Der Diagnosezusatz wird wie folgt kodiert:

{| class="hl7table"
!Code!!Beschreibung!!Interpretation
|-
|V|| Verdacht auf ||Verdachtsdiagnose
|-
|Z|| Zustand nach ||Zustand nach der betreffenden Diagnose
|-
|A|| ausgeschlossen ||Ausgeschlossene Diagnose
|-
|G|| gesichert ||gesicherte Diagnose
|-
|}

====Lokalisation====
Die Lokalisation kann folgende Werte annehmen:

{| class="hl7table"
!Code!!Beschreibung!!Interpretation
|-
|R||right||rechts
|-
|L||left||links
|-
|B||both sides||beidseitig
|-
|}

{{ GermanText |
Die Werte für den Diagnosezusatz und die Lokalisation werden an den Diagnosecode in beliebiger Reihenfolge (mit einem Leerzeichen als Trenner) angehängt.
}}

{{EnglishText |
The values for the diagnosis type and for the localization are added to the diagnosis code (separated by blanks) in an arbitrary way.
}}

Beispiel: Schnittwunde am linken Unterarm
S51.- L^^I10-2004

Beispiel: Ausgeschlossene, beidseitige Alterskatarakt:
H25.- BA^^I10-2004

====Fallhauptdiagnose====

{{ GermanText |
Die Kennzeichnung der Fallhauptdiagnose erfolgt über eine Markierung in dem Alternativcode. Dazu wird die Diagnose in der Alternativcodierung wiederholt, allerdings wird dann an den Code eine "1" und an den Katalog "ext" angehängt.
}}

{{EnglishText |
The main diagnosis of the case is marked by an alternate code. For that purpose the diagnosis is repeated in the alternate coding system, but a “1” is added to the code and an “ext” to the catalog.
}}

Beispiel: Die Entlassdiagnose bestätigt nochmals die Appendizitis und wird als Hauptdiagnose für den Krankenhausaufenthalt gewertet.
K37^Nicht näher bezeichnete Appendizitis^I10-2004^K37'''1'''^Nicht näher bezeichnete Appendizitis^I10-2004'''ext'''

===DG1-5 Zeitpunkt der Diagnosestellung===

{{ GermanText |
In diesem Feld wird übermittelt, wann die Diagnose gestellt wurde.
Dieses Feld ist erforderlich, aber ggf. leer ("RE" (required, but may be empty)), wenn es sich um eine Einweisungsdiagnose handelt. Bei allen anderen Diagnosetypen ist dieses Feld "R" (required).
}}

{{EnglishText |
In diesem Feld wird übermittelt, wann die Diagnose gestellt wurde.
This field is required, but may be empty (“RE”) if the diagnosis is an admitting diagnosis. For all other diagnosis types this field is required (“R”).
}}

===DG1-6 Diagnosetyp===

{{ GermanText |
Der Diagnosetyp legt die Art der Diagnose fest.
}}

{{EnglishText |
The diagnosis type indicates the type of the diagnosis.
}}

====Tabelle 0052: Diagnosis Type====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|AD|| admitting diagnosis||Aufnahmediagnose
|-
|BD|| treating diagnosis||Behandlungsdiagnose
|-
|ED|| referral diagnosis||Einweisungsdiagnose
|-
|EL|| discharge/transfer diagnosis||Entlassungs- / Verlegungsdiagnose
|-
|ND|| ||Nachfolgediagnose
|-
|NO|| ||Nachfolgediagnose Operieren
|-
|NU|| ||Nachfolgediagnose, die die Arbeitsunfähigkeit allein begründet hat
|-
|UD|| ||Überweisungsdiagnose
|-
|VO|| ||Präoperative Diagnose
|-
|ZD|| ||Neben- / Zusatzdiagnose
|-
|}

===DG1-15 Diagnosepriorität===

{{ GermanText |
Die Diagnosepriorität dient der Unterscheidung zwischen Haupt- und Nebendiagnosen. Die Hauptdiagnose erhält den Wert "1". Alle Nebendiagnosen erhalten mit absteigender Priorität weitere Ziffern beginnend mit "2".
}}

{{EnglishText |
The priority of a diagnosis distinguishes between primary and secondary diagnoses. The primary diagnosis has the value “1”. All other diagnoses get a higher number starting with 2 in a decreasing ranking.
}}

====Tabelle 0359: Diagnosis Priority====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|1||The primary diagnosis||Hauptdiagnose
|-
|1.1||main diagnosis (primary) ||Hauptdiagnose (primär)
|-
|1.2||main diagnosis (secondary) ||Hauptdiagnose (sekundär)
|-
|2||For ranked secondary diagnoses||Nebendiagnose
|-
|2.1|| ||Nebendiagnose (primär)
|-
|2.2|| ||Nebendiagnose (sekundär)
|-
|...|| ||
|-
|}

=====Kreuz-Stern-Notation=====

{{ GermanText |
Die Primärdiagnose bezieht sich auf die Ätiologie und wird mit "+" gekennzeichnet. Die Sekundärdiagnose hingegen definiert die Manifestation, welche mit "*" gekennzeichnet wird.

Diese beiden Informationen werden über die Diagnosepriorität kodiert. Hierzu wird als Nachkommastelle eine "1" für die Primärdiagnose und eine "2" für die Sekundärdiagnose verwendet.
}}

{{EnglishText |
The primary diagnosis refers to the etiology and shall be marked with "+". The secondary diagnosis refers to the manifestation which is marked by "*".

Both information will be coded by the diagnosis priority. Therefore, the primary diagnosis will get a "1" at the first position after decimal point, the secondary diagnosis will get "2".
}}

DG1|1||E11.5^...^I1020|||BD|||||||||1.1| Hauptdiagnose - Primärdiagnose
DG1|2||I79.2^...^I1020|||BD|||||||||1.2| Hauptdiagnose - Sekundärdiagnose
DG1|3||S42.41 R^...^I1020|||BD|||||||||2.1| Nebendiagnose - Primärdiagnose
DG1|4||V99^...^I1020|||BD|||||||||2.2| Nebendiagnose - Sekundärdiagnose

===DG1-16 Verantwortlicher Arzt===

{{ GermanText |
In diesem Feld wird der Arzt übertragen, der für die Stellung der Diagnose verantwortlich ist.
}}

{{EnglishText |
This field contains the physician who is responsible for declaring the diagnosis.
}}

===DG1-17 Art der Diagnose===

{{ GermanText |
Dieses Feld dient der Klassifikation der Diagnose.
}}

{{EnglishText |
This field is used for the classification of the diagnosis.
}}

====Tabelle 0228: Diagnosis Classification====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|C||Consultation||Behandlung
|-
|D||Diagnosis||Diagnose
|-
|I||Invasive procedure not classified elsewhere (I.V., catheter, etc.)||Maßnahme
|-
|M||Medication (antibiotic)||Medikation
|-
|O||Other||andere
|-
|R||Radiological scheduling (not using ICDA codes)||Planung von radiologischen Untersuchungen
|-
|S||Sign and symptom||Symptome
|-
|T||Tissue diagnosis||Gewebebestimmung
|-
|}

===DG1-20 ID der Diagnose===

{{ GermanText |
Jede Diagnose soll eine eindeutige Identifikation für eine spätere Referenzierung erhalten. Die Eindeutigkeit ist innerhalb des gesamten Systems über alle Fälle sicherzustellen, da die IDs auch nach einem Merge von unterschiedlichen Fällen immer noch eindeutig sein müssen.

Dieses Feld ist in der P12-Nachricht zwingend notwendig.
}}

{{EnglishText |
Each diagnosis shall get a unique identification allowing for a subsequent referencing. The uniqueness within the whole system across all visis/cases shall be given because it should still be unique after a merge of visits.
}}

===DG1-21 Diagnose Aktionscode===

{{ GermanText |
Auszuführende Aktion mit dieser Diagnose. In der P12-Nachricht muss dieses Feld gefüllt sein.
}}

{{EnglishText |
This field contains the transaction which shall be performed with this diagnosis. This field is required for a P12 message.
}}

====Tabelle 0206: Segment action code====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|U||Update||Ändern
|-
|A||Add/Insert||Hinzufügen
|-
|D||Delete||Löschen
|-
|}

[[Kategorie:Segmente|DG1]]
[[Kategorie:v2profile|DG1]]

Segment DG1

2022-12-21T14:31:41Z

Foemig: ALpha-ID + Orpha-Id hinzugefügt.

==DG1 – Diagnosen (Diagnosis)==

{{ GermanText |
In diesem Feld werden die einzelnen Diagnosen inklusive ihrer Attribute übermittelt.
}}

{{EnglishText |
This field contains the individual diagnoses as well as their attributes.
}}

{| class="hl7table"
!Lfd. Nr.!!Beschreibung!!Kard.!!Verwendung!!Tab.!!Data Item!!DT!!Länge!!Kap.
|-
|1||Set ID – DG1/ DG1-Segmentnummer||[1..1]||R||||00375||SI||||6.5.2.1
|-
|2||Diagnosis Coding Method/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0053||00376||ID||||6.5.2.2
|-
|3||Diagnosis Code – DG1/ Diagnoseschlüssel||[1..1]|| bgcolor="BBFFFF" |R (O)||0051||00377|| bgcolor="BBFFFF" |CNE (CE)||||6.5.2.3
|-
|4||Diagnosis Beschreibung/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00378||ST||||6.5.2.4
|-
|5||Diagnosis Date/Time/ Zeitpunkt der Diagnosestellung|| bgcolor="BBFFFF" |[0..1]|| bgcolor="BBFFFF" |C (O)||||00379||TS||||6.5.2.5
|-
|6||Diagnosis Type/ Diagnosetyp||[1..1]||R||0052||00380||IS||2||6.5.2.6
|-
|7||Major Diagnostic Category/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0118||00381||CE||||6.5.2.7
|-
|8||Diagnostic Related Group/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0055||00382||CE||||6.5.2.8
|-
|9||DRG Approval Indicator/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0136||00383||ID||||6.5.2.9
|-
|10||DRG Grouper Review Code/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0056||00384||IS||||6.5.2.10
|-
|11||Outlier Type/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||0083||00385||CE||||6.5.2.11
|-
|12||Outlier Days/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00386||NM||||6.5.2.12
|-
|13||Outlier Cost/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00387||CP||||6.5.2.13
|-
|14||Grouper Version And Type/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (B)||||00388||ST||||6.5.2.14
|-
|15||Diagnosis Priority/ Diagnosepriorität (1 = Hauptdiagnose, 2..n = weitere Diagnosen)|| bgcolor="BBFFFF" |[1..1]|| bgcolor="BBFFFF" |R (O)||0359||00389||ID|| bgcolor="BBFFFF" |3(2)||6.5.2.15
|-
|16||Diagnosing Clinician/ Verantwortlicher Arzt||[0..*]|| bgcolor="BBFFFF" |RE (O)||||00390||XCN|| ||6.5.2.16
|-
|17||Diagnosis Classification/ Art der Diagnose||[0..1]||O||0228||00766||IS|| ||6.5.2.17
|-
|18||Confidential Indicator/ Merkmal der Vertraulichkeit der Diagnose||[0..1]||O||0136||00767||ID|| ||6.5.2.18
|-
|19||Attestation Date/Time/ nicht verwendet||[0..0]|| bgcolor="BBFFFF" |X (O)|| ||00768||TS|| ||6.5.2.19
|-
|20||Diagnosis Identifier/ ID der Diagnose||[1..1]|| bgcolor="BBFFFF" |R (C)|| ||01850||EI|| ||6.5.2.20
|-
|21||Diagnosis Action Code/ Diagnose Aktionscode||[1..1]|| bgcolor="BBFFFF" |R (C)||0206||01894||ID||||6.5.2.21
|-
|}

===DG1-1 Segmentnummer===

{{ GermanText |
Die Segmentnummer dient der fortlaufenden Nummerierung aller DG1-Segmente unabhängig vom Vorkommen in der Nachricht.
}}

{{EnglishText |
The purpose of the segment number is the sequential numbering of all DG1 segments independently of their occurrence within a message.
}}

===DG1-3 Diagnoseschlüssel===

{{ GermanText |
Die eigentliche Diagnose besteht aus einer kodierten Information und/oder einer textuellen Beschreibung.
}}

{{EnglishText |
The actual diagnosis is composed out of a coded information and/or a textual description.
}}

Beispiel 1: Blinddarmentzündung
^BlinddarmentzündungBeispiel 2: K57.1: Appendizitis
K57.1^Appendizitis^I10-2004

Zur Kodierung der Diagnosen stehen folgende ICD-Kataloge zur Verfügung:

{| class="hl7table"
!Code!!Beschreibung!!Interpretation
|-
|I10-2004||ICD 10-Katalog 2004
|-
|I10-2005||ICD 10-Katalog 2005
|-
|I10-2006||ICD 10-Katalog 2006
|-
| ... || ...
|-
|icd10gm2014||ICD 10-Katalog 2014
|-
|icd10gm2015||ICD 10-Katalog 2015
|-
| ... || ...
|}

{{ GermanText |
Neben den ICD-10-Diagnosen können aber auch andere Codesysteme wie Alpha-ID oder Orpha-Id genutzt werden.
Dafür sind die entsprechenden Identifikationen aus Tabelle 0396 zu verwenden.
}}

{{EnglishText |
Beside ICD-10 diagnosis codes, other codesystems like Alpha-ID or Orpha-Id can be used.
Therefore, the identifications from table 0396 shall be used.
}}

{{ GermanText |
Neben dem eigentlichen Diagnoseschlüssel gibt es noch Diagnosezusätze und eine Lokalisation.
}}

{{EnglishText |
Besides the actual diagnosis key there are diagnosis supplements and a localization.
}}

====Diagnosezusatz====
Der Diagnosezusatz wird wie folgt kodiert:

{| class="hl7table"
!Code!!Beschreibung!!Interpretation
|-
|V|| ||Verdachtsdiagnose
|-
|Z|| ||Zustand nach der betreffenden Diagnose
|-
|A|| ||Ausgeschlossene Diagnose
|-
|G|| ||gesicherte Diagnose
|-
|}

====Lokalisation====
Die Lokalisation kann folgende Werte annehmen:

{| class="hl7table"
!Code!!Beschreibung!!Interpretation
|-
|R||right||rechts
|-
|L||left||links
|-
|B||both sides||beidseitig
|-
|}

{{ GermanText |
Die Werte für den Diagnosezusatz und die Lokalisation werden an den Diagnosecode in beliebiger Reihenfolge (mit einem Leerzeichen als Trenner) angehängt.
}}

{{EnglishText |
The values for the diagnosis type and for the localization are added to the diagnosis code (separated by blanks) in an arbitrary way.
}}

Beispiel: Schnittwunde am linken Unterarm
S51.- L^^I10-2004

Beispiel: Ausgeschlossene, beidseitige Alterskatarakt:
H25.- BA^^I10-2004

====Fallhauptdiagnose====

{{ GermanText |
Die Kennzeichnung der Fallhauptdiagnose erfolgt über eine Markierung in dem Alternativcode. Dazu wird die Diagnose in der Alternativcodierung wiederholt, allerdings wird dann an den Code eine "1" und an den Katalog "ext" angehängt.
}}

{{EnglishText |
The main diagnosis of the case is marked by an alternate code. For that purpose the diagnosis is repeated in the alternate coding system, but a “1” is added to the code and an “ext” to the catalog.
}}

Beispiel: Die Entlassdiagnose bestätigt nochmals die Appendizitis und wird als Hauptdiagnose für den Krankenhausaufenthalt gewertet.
K37^Nicht näher bezeichnete Appendizitis^I10-2004^K37'''1'''^Nicht näher bezeichnete Appendizitis^I10-2004'''ext'''

===DG1-5 Zeitpunkt der Diagnosestellung===

{{ GermanText |
In diesem Feld wird übermittelt, wann die Diagnose gestellt wurde.
Dieses Feld ist erforderlich, aber ggf. leer ("RE" (required, but may be empty)), wenn es sich um eine Einweisungsdiagnose handelt. Bei allen anderen Diagnosetypen ist dieses Feld "R" (required).
}}

{{EnglishText |
In diesem Feld wird übermittelt, wann die Diagnose gestellt wurde.
This field is required, but may be empty (“RE”) if the diagnosis is an admitting diagnosis. For all other diagnosis types this field is required (“R”).
}}

===DG1-6 Diagnosetyp===

{{ GermanText |
Der Diagnosetyp legt die Art der Diagnose fest.
}}

{{EnglishText |
The diagnosis type indicates the type of the diagnosis.
}}

====Tabelle 0052: Diagnosis Type====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|AD|| admitting diagnosis||Aufnahmediagnose
|-
|BD|| treating diagnosis||Behandlungsdiagnose
|-
|ED|| referral diagnosis||Einweisungsdiagnose
|-
|EL|| discharge/transfer diagnosis||Entlassungs- / Verlegungsdiagnose
|-
|ND|| ||Nachfolgediagnose
|-
|NO|| ||Nachfolgediagnose Operieren
|-
|NU|| ||Nachfolgediagnose, die die Arbeitsunfähigkeit allein begründet hat
|-
|UD|| ||Überweisungsdiagnose
|-
|VO|| ||Präoperative Diagnose
|-
|ZD|| ||Neben- / Zusatzdiagnose
|-
|}

===DG1-15 Diagnosepriorität===

{{ GermanText |
Die Diagnosepriorität dient der Unterscheidung zwischen Haupt- und Nebendiagnosen. Die Hauptdiagnose erhält den Wert "1". Alle Nebendiagnosen erhalten mit absteigender Priorität weitere Ziffern beginnend mit "2".
}}

{{EnglishText |
The priority of a diagnosis distinguishes between primary and secondary diagnoses. The primary diagnosis has the value “1”. All other diagnoses get a higher number starting with 2 in a decreasing ranking.
}}

====Tabelle 0359: Diagnosis Priority====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|1||The primary diagnosis||Hauptdiagnose
|-
|1.1||main diagnosis (primary) ||Hauptdiagnose (primär)
|-
|1.2||main diagnosis (secondary) ||Hauptdiagnose (sekundär)
|-
|2||For ranked secondary diagnoses||Nebendiagnose
|-
|2.1|| ||Nebendiagnose (primär)
|-
|2.2|| ||Nebendiagnose (sekundär)
|-
|...|| ||
|-
|}

=====Kreuz-Stern-Notation=====

{{ GermanText |
Die Primärdiagnose bezieht sich auf die Ätiologie und wird mit "+" gekennzeichnet. Die Sekundärdiagnose hingegen definiert die Manifestation, welche mit "*" gekennzeichnet wird.

Diese beiden Informationen werden über die Diagnosepriorität kodiert. Hierzu wird als Nachkommastelle eine "1" für die Primärdiagnose und eine "2" für die Sekundärdiagnose verwendet.
}}

{{EnglishText |
The primary diagnosis refers to the etiology and shall be marked with "+". The secondary diagnosis refers to the manifestation which is marked by "*".

Both information will be coded by the diagnosis priority. Therefore, the primary diagnosis will get a "1" at the first position after decimal point, the secondary diagnosis will get "2".
}}

DG1|1||E11.5^...^I1020|||BD|||||||||1.1| Hauptdiagnose - Primärdiagnose
DG1|2||I79.2^...^I1020|||BD|||||||||1.2| Hauptdiagnose - Sekundärdiagnose
DG1|3||S42.41 R^...^I1020|||BD|||||||||2.1| Nebendiagnose - Primärdiagnose
DG1|4||V99^...^I1020|||BD|||||||||2.2| Nebendiagnose - Sekundärdiagnose

===DG1-16 Verantwortlicher Arzt===

{{ GermanText |
In diesem Feld wird der Arzt übertragen, der für die Stellung der Diagnose verantwortlich ist.
}}

{{EnglishText |
This field contains the physician who is responsible for declaring the diagnosis.
}}

===DG1-17 Art der Diagnose===

{{ GermanText |
Dieses Feld dient der Klassifikation der Diagnose.
}}

{{EnglishText |
This field is used for the classification of the diagnosis.
}}

====Tabelle 0228: Diagnosis Classification====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|C||Consultation||Behandlung
|-
|D||Diagnosis||Diagnose
|-
|I||Invasive procedure not classified elsewhere (I.V., catheter, etc.)||Maßnahme
|-
|M||Medication (antibiotic)||Medikation
|-
|O||Other||andere
|-
|R||Radiological scheduling (not using ICDA codes)||Planung von radiologischen Untersuchungen
|-
|S||Sign and symptom||Symptome
|-
|T||Tissue diagnosis||Gewebebestimmung
|-
|}

===DG1-20 ID der Diagnose===

{{ GermanText |
Jede Diagnose soll eine eindeutige Identifikation für eine spätere Referenzierung erhalten. Die Eindeutigkeit ist innerhalb des gesamten Systems über alle Fälle sicherzustellen, da die IDs auch nach einem Merge von unterschiedlichen Fällen immer noch eindeutig sein müssen.

Dieses Feld ist in der P12-Nachricht zwingend notwendig.
}}

{{EnglishText |
Each diagnosis shall get a unique identification allowing for a subsequent referencing. The uniqueness within the whole system across all visis/cases shall be given because it should still be unique after a merge of visits.
}}

===DG1-21 Diagnose Aktionscode===

{{ GermanText |
Auszuführende Aktion mit dieser Diagnose. In der P12-Nachricht muss dieses Feld gefüllt sein.
}}

{{EnglishText |
This field contains the transaction which shall be performed with this diagnosis. This field is required for a P12 message.
}}

====Tabelle 0206: Segment action code====

{| class="hl7table"
!Wert!!Beschreibung!!Interpretation
|-
|U||Update||Ändern
|-
|A||Add/Insert||Hinzufügen
|-
|D||Delete||Löschen
|-
|}

[[Kategorie:Segmente|DG1]]
[[Kategorie:v2profile|DG1]]

IHE DE ValueSets Action Items

2022-08-19T12:05:49Z

Foemig: Änderungen akzeptiert

'''Tabelle Änderungsanfragen'''

:{|class="hl7table sortable"
|-
! align="left" | Anfrage ID
! align="left" | Anfrage eingegangen am
! align="left" | Anfrage
! align="center" | betrifft Codesystem
! align="center" | Autor der Anfrage
! align="center" | Diskussion
! align="center" | Entscheidung
! align="center" | Action Item
! align="center" | Bearbeitungsstand
! align="center" | zuletzt bearbeitet am

|- valign="top"
| Anfrage ID| 4
| Anfrage eingegangen am|
| Anfrage| Arbeitsgruppe „Weiterentwicklung Klinische Dokumentenklassenliste (KDL)“.
Am 22. August 2019 fand eine Telefonkonferenz statt, bei der auch das Mapping auf die Value Sets classCode und typeCode von IHE-D thematisiert wurde.
Das aktuelle Mapping liegt der Geschäftsstelle vor und ist bisher mit Angela Merzweiler gemeinsam abgestimmt wurden.
Aktuelle Erfahrungen im Rahmen der IHE-konformen Langzeitarchivierung haben gezeigt, dass die granularen Informationen zum Dokumententyp verloren gehen, sobald nur der ClassCode und TypeCode in die Langzeitarchivierung übernommen werden.
Beispiel:
Ich möchte daher anregen bzw. beantragen, dass die KDL im ersten Schritt offiziell als CodeSystem in das Value Set „EventCodeList“ aufgenommen wird.
Damit haben Hersteller von IHE-konformen Archiven, o. ä. die Möglichkeit, wenigstens die Klassifizierung des Dokuments mittels KDL offiziell abzubilden.
· Code System Name: Klinische Dokumentenklassen Liste (KDL)
· Code System ID: 1.2.276.0.76.3.1.191.0.1.1, versionsabhängig
· Kommentar: Klassifizierung von Dokumenten und Daten als Beispiele für die Value Sets classCode und typeCode
Mittelfristig soll die KDL zu einem terminologischen System mit ontologischem Ansatz ausgebaut werden.
Hier möchten wir uns als Arbeitsgruppe mit der Ihrer Arbeitsgruppe austauschen, inwieweit die KDL weiter in Richtung IHE, SNOMED, LOINC, etc. ausgebaut werden kann.
Ich freue mich, wenn wir es gemeinsam schaffen, dazu einen persönlichen Termin für ein Arbeitstreffen zu finden.
| betrifft Codesystem | eventCode
| Autor der Anfrage | AMü
| Diskussion| EventCode eigentlich als Kontext der Dokumentenerstellung gedacht, als Interimslösung für KDL geeignet, soll aber unbedingt zur Ontologie weiterentwickelt werden. Fokus soll weiterhin auf Metadaten für Document Sharing liegen. Gemeinsame Telko zur weiteren Abstimmung mit KDL Arbeitsgruppe. Semantik der Codes muss definiert werden. Das in Simplifier eingetragene Valueset enthält das gesamte Codesystem. Als Valueset sollen nur Codes auf dritter Hierarchiestufe erlaubt sein. Einbindung soll dynamisch erfolgen. Das Valueset ist closed. Annett beantragt bei DIMDI eine OID für den DVMD. Dann können OIDs für das Codesystem und das Valueset vergeben werden. Achtung: KDL ist eine Klassifikation, für jede Version eine neue OID notwendig. DVMD benötigt OID Konzept. Eigene Projektseit im HL7wiki eingerichtet
24.4. OIDs für KDL2019 und KDL2020 vorhanden, aber keine eindeutigen URNs, Filterung auf dritter Ebene für ValueSet war erfolgreich, aber Beschreibung im Simplifier fehlerhaft, Mapping KDL2020 auf XDS Class und TypeCodes in Simplifier vorhanden (noch keine Rückmeldungen von uns)
übergeordnetes Valueset KDL in ArtDecor als Codesystem eingetragen, da der Eintrag als Valueset technisch nicht möglich war.
12.11.2021 erneute Diskussion, ob Eintrag als Codesystem sinnvoll war
| Entscheidung | grundsätzlich zugestimmt, neues Valueset
| Action Item | alle=> Mapping prüfen
| Bearbeitungsstand | in Bearbeitung
| zuletzt bearbeitet am| 12.11.2021

|- valign="top"
| Anfrage ID| 6
| Anfrage eingegangen am| 31.10.2019
| Anfrage| Ansatz Canonical URLs diskutieren
| betrifft Codesystem | alle
| Autor der Anfrage | Tarik Idris
| Diskussion| Ziel: Gute Einfügung in FHIR Umgebung
| Entscheidung | Für V3 alle URNs durch URLs ersetzen
| Action Item | Für V3 alle URNs, die wir selbst unter Kontrolle haben, durch folgendes URLs mit Präfix http://ihe-d.de/CodeSystems/ + Name CodeSystem ersetzen ==> erledigt, warum in ArtDecor nicht sichtbar? ==> Angela, bei Fremdcodesystem nach entsprechenden URLs suchen ==> betrifft nur DICOM Codesysteme (in den Valuesets eventcode und formatCode) ==> Sven kümmert sich
| Bearbeitungsstand | für ValueSets erledigt (Angela)
| zuletzt bearbeitet am| 14.11.2021

|- valign="top"
| Anfrage ID| 7
| Anfrage eingegangen am| 31.10.2019
| Anfrage| Deutscher Implementation Guide für MHD Profile mit Verweis auf unsere Valuesets
| betrifft Codesystem | alle
| Autor der Anfrage | SH über Tarik
| Diskussion| 3.4.2020 Kosten stehen nicht im Verhältnis zum Nutzen, Codes werden weiterhin in ArtDecor gepflegt, In Implementation Guide der Deutschen Basisprofile gibt es schon Referenzen auf class und type Code
| Entscheidung | kein Implementation Guide für MHD, aber stattdessen Aufnahme der Codes in Simplifier, um höhere Aufmerksamkeit bei der FHIR Community zu bekommen, die Pflege der Codesysteme / Valuesets soll weiterhin über ArtDecor erfolgen. Nach Diskussion vom 03.04.2020 wird Beantragung des SimplifierKontos storniert
| Action Item | Simone um Referenz der Codes in Deutschen Basisprofilguideline bitten
| Bearbeitungsstand | als Issues in Gitlab eingetragen, im Simplifier sichtbar https://simplifier.net/basisprofil-de-r4/~resources?category=ValueSet&sortBy=RankScore_desc ==> (Angela)
| zuletzt bearbeitet am| 10.12.2020

|- valign="top"
| Anfrage ID| 19
| Anfrage eingegangen am| 10.07.2020
| Anfrage| Hintergrund: Verzeichnisdienst in der TI soll mit den Angaben der ambulanten Praxen zu befüllen. Dabei soll auch die Fachgruppe als Merkmal aufgenommen werden. Die gematik hat als Wertebereich für die Fachgruppe dabei das ValueSet „practiceSettingCode“ vorgesehen. In den Arztregistern der Kassenärztlichen Vereinigungen – woher die Daten stammen – ist die Fachgruppe hingegen nach einer anderen Systematik hinterlegt: https://applications.kbv.de/S_BAR2_ARZTNRFACHGRUPPE_V1.01.xhtm
Wir haben versucht eine Zuordnungstabelle zu schaffen, in der wir von unserer Systematik in den „practiceSettingCode“ übersetzen. Dabei ist uns aufgefallen, dass wir einige unserer Fachgruppen nicht valide zuordnen können. (z.B. 51 – Nervenheilkunde oder 69 – Kinder- und Jugendlichenpsychotherapeut). Das betrifft relativ wenige Fachgruppen, die allerdings teils sehr viele Ärzte enthalten. Um alle in der Versorgung vorkommenden Fachgruppen sauber abbilden zu können, würden wir das ValueSet „practiceSettingCode“ gerne um folgende Ausprägungen erweitern:
Bestehenden Code ALLG - „Allgemeinmedizin“ neu bezeichnen als „Facharzt für Allgemeinmedizin
(Hausarzt)“
2. Neuen Code einführen für „Praktischer Arzt/Arzt (Hausarzt)“. Vorschlag: PRAK
3. Neuen Code einführen für „Hausärztlich tätiger Internist (Hausarzt)“. Vorschlag: HINT
4. Bestehenden Codes ORTH neu bezeichnen als „Orthopädie und Unfallchirurgie“.
5. Neuen Code einführen für „Rheumatologie (Orthopädie)“. Vorschlag: ORRH.
6. Neuen Code einführen für „Infektiologie“. Vorschlag: INFK
7. Neuen Code einführen für „Kinder-Pneumologie“. Vorschlag: KIPN
8. Neuen Code einführen für „Nervenheilkunde/Neurologie und Psychiatrie“. Vorschlag: NERV
9. Neuen Code einführen für „Psychotherapeutisch tätiger Arzt“. Vorschlag: PTAR
10. Neuen Code einführen für „Psychologischer Psychotherapeut“. Vorschlag: PPTH
11.Neuen Code einführen für „Kinder- und Jugendlichen-Psychotherapeut“. Vorschlag: KJPP
| betrifft Codesystem | Practice Setting Code
| Autor der Anfrage | SR (KBV)
| Diskussion| Practice Setting Code gibt nur das Fachgebiet der Praxis an, die Qualifikation der Beschäftigten wird durch die Author speciality ausgedrückt. Daher gibt es bereits im Implementation Guide ein Mapping einiger Praxen nichtärztlicher Berufe auf diese Fachbereiche.
| Entscheidung | Implementation Guide wird um Mapping S_BAR2_ARZTNRFACHGRUPPE auf practice Setting Code ergänzt, KBV kann für Ihren speziellen Einsatzweck (nicht als XDS Metadatum) für bestimmte Praxen auch zwei Codes verwenden (z.B. Neurologie + Psychiatrie), Psychotherapie wird bei nichtärztlichen PracticeSettingCodes hinzugefügt, Bei Allgemeinmedizin wird Nutzungshinweis ", Streichen des Satzes: "In Deutschland ist die Weiterbildung zu einem entsprechenden Facharzt die Grundlage dafür, dass ein Arzt als "Hausarzt" tätig werden kann." Stattdessen Ergänzung Nutzungshinweis, dass Code auch für hausärztlich tätige Praxen genutzt werden kann (auch bei Innere Medizin).
| Action Item | Mapping prüfen und in Implementation Guide eintragen.
| Bearbeitungsstand | Mapping geprüft, Psychotherapie bei nichtärztlichen PracticeSettingCodes hinzugefügt, Eintrag in ImplementationGuide fehlt noch (Angela), Nutzungshinweise bei Innere Medizin und Allgemeinmedizin ergänzt.
| zuletzt bearbeitet am| 10.12.2020

|- valign="top"
| Anfrage ID| 29
| Anfrage eingegangen am| 22.01.2021
| Anfrage| Problem mit ArtDecor bei FHIR
| betrifft Codesystem | alle
| Autor der Anfrage | Axel
| Diskussion|
| Entscheidung |
| Action Item | Axel meldet Issues an Kai
| Bearbeitungsstand | in Bearbeitung
| zuletzt bearbeitet am| 22.01.2021

|- valign="top"
| Anfrage ID| 31
| Anfrage eingegangen am| 18.02.2021
| Anfrage| Für das eHDSI-Projekt soll ein neuer LOINC-Code beantragen, der in etwa unserem IHEXDSclassCode "BIL" entspricht. Können wir morgen in dem Arbeitstreffen kurz um konstruktive Kritik dazu bitten? Term Description: This concept summarizes all documents, the aim of which is to visually represent a situation using a clinical image. Examples are X-ray, MRI, CT images or photos of wounds, body parts or the like.
| betrifft Codesystem | ClassCode
| Autor der Anfrage | CG
| Diskussion|
| Entscheidung |
| Action Item |
| Bearbeitungsstand | offen
| zuletzt bearbeitet am|

|- valign="top"
| Anfrage ID| 33
| Anfrage eingegangen am| 22.12.2021
| Anfrage| Bei der Umsetzung der ePA durch die Konsortien, wie auch bei weiteren angedachten digitalen Anwendungen, zeigen sich nun einige Schwierigkeiten bei der Darstellung von Psychotherapeut*innen, die sich durch die erfolgte Einordnung im IHE ergeben. Mit den bisher vorgenommenen Änderungen sind zwar alle Berufsbezeichnungen von Psychotherapeut*innen korrekt abbildbar, allerdings lässt die hierarchische Einordnung keine Abbildung als approbierter Heilberuf zu. Um die Qualifikationen der Psychotherapeut*innen in den verschiedenen Anwendungen der TI adäquat abbilden zu können, ist daher aus unserer Sicht eine weitere Anpassung in den ArtDecor Value Sets erforderlich.
| betrifft Codesystem | AuthorSpecialty
| Autor der Anfrage | BPtK
| Diskussion|
Potentieller Ansatz:
"Umhängen" der versch. Codes (s.o.) in eine neu zu schaffende Gruppe für "Psychotherapie" (Code z.B. 189 mit Inhalt, 76, 82, 183, 184, 185), eine weitere neue Gruppe "Psychologische Analyse, Beratung, Therapie (ohne Psychotherapeuten)" (Code z.B. 190, beinhaltet 75, 77, 78, 79, 80, 81, 83, 84, 85)
* 74
** 189
*** 76
*** 82
*** 183
**** 184
**** 185
** 190
*** 75
*** 77
*** 78
*** 79
*** 80
*** 81
*** 83
*** 84
*** 85

Betroffenen Systemen und Use Cases
* Suche KIM-Teilnehmer
** Kammer/HBA-Herausgeber
*** z.B. Landesärztekammern und BPtk, prüfen ob der Gruppen-Code 74 verwendet werden, wahrscheinlich werden eher die konkreten Codes verwendet
** Verzeichnisdienst
*** VZD macht keine Umsetzung von Gruppe zu konkreten Codes, d.h. kein Änderungsbedarf
** AIS / KIS / weitere Primärsysteme
*** Könnten ggf. Umsetzungen von Gruppe auf konkrete Codes im Rahmen von Suchen durchführen. Falls dies der Fall ist, würden nach der Änderung die selben Antworten kommen - sie hätten aber die Option detaillierter über codes 189 vs. 190 zu suchen (Annahme: Update-Fähigkeit)
* ePA-Dokumentenmetadaten: authorSpeciality
** ePA-Aktensystem
*** Auch im Aktensystem wird keine Umsetzung von Gruppe zu konkreten Codes gemacht. Im ePA-Aktensystem sind in den Metadaten für Dokumente ggf. auch Gruppen wie 74 als authorSpeciality hinterlegt. Die bestehenden Daten können nicht trivial System-weit verändert werden. Dies ist aber im jetzigen Vorschlag auch nicht mehr nötig, da der code weiterhin valide wäre und die selbe Semantik hat. Update der DM-spec und ValueSets gematik-seitig notwendig.
** ePA-FdV
*** Kann im AS nicht danach suchen, aber auf dem Gerät danach filtern. Anpassung der ValueSets nötig. Könnten ggf. Umsetzungen von Gruppe auf konkrete Codes im Rahmen von Suchen durchführen - aber sehr unwahrscheinlich. Falls dies der Fall ist, würden nach der Änderung die selben Antworten kommen - sie hätten aber die Option detaillierter über codes 189 vs. 190 zu suchen.
** Primärsystem
*** Können Dokumente mit den Codes kennzeichnen. Gff. könnten lokale Mappings anzupassen sein (z.B. von LDAP-Gruppen auf authorSpecialty) - eher unwahrscheinlich. Mapping könnte dann durch Unterscheidung zwischen 189 und 190 verbessert werden. Anpassung der ValueSets nötig. Könnten ggf. Umsetzungen von Gruppe auf konkrete Codes im Rahmen von Suchen durchführen. Falls dies der Fall ist, würden nach der Änderung die selben Antworten kommen - sie hätten aber die Option detaillierter über codes 189 vs. 190 zu suchen.

* XDS Affinity Domains (nicht-ePA)
** Document Source
*** wie bei ePA
** Document Registry
*** wie bei ePA, auch wenn Updates einfacher zu realisieren sind
** Document Consumer
*** Suche nach AuthorSpecialty möglich, Mapping Thematik wie bei ePA

* Auswirkungen auf ISIK
Umsetzung nach Wunsch BPtK

BPtK müsste eigenes Codessystem auf jeden Fall selbst pflegen
Impact auf andere Systeme müssen noch genau analysiert werden

| Entscheidung | Wenn BPtK eigenes Codesystem erstellt pflegen wir es ein
| Action Item | BPtK beantragt OID
| Bearbeitungsstand | in Bearbeitung
| zuletzt bearbeitet am| 18.03.2022

|- valign="top"

| Anfrage ID| 37
| Anfrage eingegangen am| 04.03.2022
| Anfrage| Displaynames Gender konform gestalten
| betrifft Codesystem | v.a. author role, authorspecialty
| Autor der Anfrage | Gematik
| Diskussion| Displaynames sollten nicht verpflichtend bei Anzeige sein, entscheidend ist der Code in Kombination mit Codesystem, Impact Analyse: Gendern der Displaynames ist vor allem Aufwand für uns, das Gendern externer Codesystem muss durch andere Nutzer erfolgen;
| Entscheidung | Gendern wird prinzipiell befürwortet, Ziel sind angepasste Displaynames für das nächste Release, Folgende Texten sollten geändert werden: authorRole, authorSpecialty, healthcareFacilityTypeCode, practiceSetting, typeCode
| Action Item | Änderung wird befürwortet, wie und wann wird noch festgelegt
| Bearbeitungsstand | in Bearbeitung
| zuletzt bearbeitet am| 29.04.2022
|- valign="top"

| Anfrage ID| 38
| Anfrage eingegangen am| 25.3.2022
| Anfrage| KDL Mapping kontrollieren
| betrifft Codesystem | class code, type code,
| Autor der Anfrage | DVMD
| Diskussion|
| Entscheidung | Das Mapping wird bis in vier Wochen von Raik, Tarik, Arnold und eventuell Sven gereviewed. Angela teilt das Mappingdokument auf ihrem onedrive.
| Action Item | Review bis in vier Wochen
| Bearbeitungsstand | in Bearbeitung
| zuletzt bearbeitet am| 29.04.2022
|- valign="top"

| Anfrage ID| 40
| Anfrage eingegangen am| 28.04.2022
| Anfrage| passender eventCode bei stationärer Wiederaufnahme nach Unterbrechung
| betrifft Codesystem | eventCode
| Autor der Anfrage | AM (UKHD)
| Diskussion|
| Entscheidung | E216 Wiederaufnahme vollstationär nach kurzzeitiger Unterbrechung wird hinzugefügt
| Action Item |
| Bearbeitungsstand | in ArtDecor eingetragen
| zuletzt bearbeitet am| 29.04.2022
|- valign="top"

| Anfrage ID| 42
| Anfrage eingegangen am| 27.05.2022
| Anfrage|neue Dokumentenformate für gematik "urn:gematik:ig:DMP-Rheuma:v1
eDMP" displayName: "Rheumatoide Arthritis (gematik)"
| betrifft Codesystem | formatCode
| Autor der Anfrage | gematik
| Diskussion|
| Entscheidung |Major Revisions werden aufgenommen
| Action Item |
| Bearbeitungsstand | in Art Decor eingetragen
| zuletzt bearbeitet am| 27.05.2022
|- valign="top"

|- valign="top"
| Anfrage ID| 43
| Anfrage eingegangen am| 10.06.2022
| Anfrage| Im Zuge des KDL-Mapping-Reviews waren sich die Reviewer einig, dass eine Klarstellung der Beschreibung des Befundberichts sinnvoll wäre, um Befundberichte besser von Durchführungsprotokollen abzugrenzen.
| betrifft Codesystem | classCode
| Autor der Anfrage | Raik
| Diskussion|
Brief: Alle Varianten von Briefen wie Arztbriefe, Überweisungsbriefe, Entlassbriefe, etc. sowie weitere zusammenfassende Dokumente mit einer ärztlichen oder pflegerischen Bewertung der Fakten. Haben typischerweise einen Absender und einen oder mehrere Empfänger (gerichtet an einen abstrakten Empfänger z.B. Facharzt oder adressiert an eine bestimmte Person). Befundberichte werden über das Konzept "BEF" (Befundbericht) abgedeckt.

Befundbericht: Befundberichte enthalten Ergebnisse und Interpretationen einer oder mehrerer diagnostischen Untersuchungen. Beispiele sind Befundberichte über bildgebende Diagnostik (CT, MRT), Funktionsdiagnostik (EEG, EKG), sowie manueller Diagnostik. Eine weitere Differenzierung der Befundberichte (z.B. Histopathologie) kann über den typeCode bzw. practiceSettingCode oder über passendere classCodes (z.B LAB "Laborergebnisse") realisiert werden.

Durchführungsprotokoll: Maschinell oder von Menschen erstellte Protokolle durchgeführter Anamnese, Diagnostik oder Therapie, z.B. Anamnesebogen, OP-Berichte, Medikamentenverabreichungen ohne Interpretation; hierzu zählen auch ausgefüllte Checklisten die das prozesskonforme Vorgehen während einer Untersuchung oder OP dokumentieren. Die Protokolle können auch Handlungsanweisungen bzw. Empfehlungen beinhalten, z.B. Visitenprotokoll, Konsilbericht. Dazu gehören auch Messdaten (oft auch als Quelldaten oder Rohdaten bezeichnet) ohne menschliche Bewertung wie Temperaturkurven, Blutdruck-Messungen, Blutzuckerkurven, unbefundete EKGs, Herz-Tonaufnahmen, Bestrahlungsprotokoll, Dosiswerte, etc. mit Ausnahme von Bilddaten und Videodaten. Der Begriff "Patientenkurve" wird in einigen Fällen für eine Sammlung von Temperatur-, Blutdruck- und weiteren pflegerischen Beobachtungen verwendet und sollte dann auch über das Konzept DUR ("Durchführungsprotokoll") abgedeckt werden. Da der Begriff "Patientenkurve" auch für andere Dokumente (bzw. Dokumentenkombinationen) verwendet wird, sollte vor einer solchen Abbildung eine Analyse der so bezeichneten Dokumente durchgeführt und das entsprechende Konzept verwendet werden.
Dokumente die mit diesem Konzept bezeichnet werden können maschinenlesbar sein, müssen es jedoch nicht (z.B. sowohl EKG-Kurve wie auch eingescanntes EKG sind abgedeckt). Ursprungs- und Zwischenformate (wie z.B. Diktat eines Arztbriefes) werden mit dem inhaltlich sinnvollen classCode gekennzeichnet (Brief in diesem Beispiel).
| Entscheidung |
| Action Item |
| Bearbeitungsstand | in Bearbeitung
| zuletzt bearbeitet am| 19.08.2022

|- valign="top"
| Anfrage ID| 44
| Anfrage eingegangen am| 22.07.2022
| Anfrage| Versionen in FormatCode Display names aufnehmen, da einige Hersteller die FormatCodes an Hand von Displaynames suchen
| betrifft Codesystem | formatCode
| Autor der Anfrage | Raik
| Diskussion|
| Entscheidung | Display Names werden geändert
| Action Item |
| Bearbeitungsstand | in Bearbeitung
| zuletzt bearbeitet am| 22.07.2022

|}

'''Tabelle abgeschlossene Änderungsanfragen'''

:{|class="hl7table sortable"
|-
! align="left" | Anfrage ID
! align="left" | Anfrage eingegangen am
! align="left" | Anfrage
! align="center" | betrifft Codesystem
! align="center" | Autor der Anfrage
! align="center" | Diskussion
! align="center" | Entscheidung
! align="center" | Action Item
! align="center" | Bearbeitungsstand
! align="center" | zuletzt bearbeitet am

|- valign="top"
| Anfrage ID| 1
| Anfrage eingegangen am|
| Anfrage| wir sind hier gerade im Kontext des AOK Gesundheitsnetzwerks (GeN-Flavour) auf ein kleines Problem mit der Nutzung der von HL7 und IHE Deutschland definierten classCodes und typeCodes gelaufen:
Einige der angebundenen Häuser haben ihre IHE XDS Lösungen mehr oder minder extra für das Gesundheitsnetzwerk neu beschafft und setzen ausschließlich die von IHE-D definierten Codes um, da wir dies so vorgegeben hatten
Andere Häuser haben schon seit Längerem XDS Lösungen und/oder orientieren sich ausschließlich an den IHE Frameworks. Hier kommen die vor allem von IHE PCC und IHE LAB festgesetzen classCodes und typeCodes (zum Beispiel für bestimmte Labordokumente) zum Einsatz.
Wir haben somit eine Mischung aus IHE-D-Codes und IHE-PCC/LAB-LOINC-Codes. Inhaltlich/semantisch überschneidet sich das recht munter. Fragen:
Gibt es irgendwo eine Mapping-Tabelle, wie Dokumente gemäß der von IHE PCC und IHE LAB definierten CDA Dokumentenschablonen mit den IHE-D-Metadaten auszuzeichnen sind?
Macht es vielleicht Sinn, ein weiteres Value Set zu definieren (und über das IOP-Forum oder Vesta als nationale Empfehlung zu positionieren), das sowohl die IHE-D Codes als auch die von IHE International für dort definierte Dokumente vorgegebenen class- und typeCodes enthält?
Folgende Codes werden vermisst:
im AOK-Projekt haben wir in Ergänzung zu den IHE-D-Codes die folgenden LOINC-Codes als typeCodes verwendet:
77603-9: Bundeseinheitlicher Medikationsplan – Die explizite Typisierung wurde vorgenommen, damit Dokumente dieses Typs an geeigneter Stelle zwischen Document Source und Document Repository automatisch vorverarbeitet werden (Barcode erkennen, prüfen und parsen)
11502-2: Laboratory Report – Dieser Code ist von IHE PCC für aggregierte Laborbefunde vorgegeben und sollte auch in Deutschland alternativ zu LAB+BEFU nutzbar sein
26436-6: Laboratory Studies – Dieser Code ist von IHE PCC für Laborbefunde vorgegeben und sollte auch in Deutschland alternativ zu LAB+BEFU nutzbar sein
Verschiedene Ausprägungen des Entlassbriefs, um hier anhand der typeCodes eine bessere Sortierung für den Patienten zu ermöglichen:
11490-0: Ärztlicher Entlassbrief
34105-7: Krankenhausentlassbrief (vorläufige/gekürzte Fassung für den Patienten bei der Entlassung)
18842-5: Finales Krankenhausentlassbrief
57059-8: Mutterpass – Das ganze Thema „Schwangerschaft und Geburt“ war mit den IHE-D Codes nur unzureichend abbildbar. Beispielsweise haben wir auch Geburtsbericht und Stillprotokoll nicht vernünftig differenzieren können.
Verschiedene Spezialisierungen von Laborbefunden – Diese werden u. a. auch für Anfragen nach On-Demand-Dokumenten benötigt, um so z. B. die verfügbaren Werte eines Blutbilds aus verschiedenen Einzellaboren zusammenstellen zu können. Im GeN-Projekt brauchen wir das, da die ODD Document Sources für Laborwerte FHIR Strores sind.
58410-2: Vollständiges Blutbild
55429-5: Kleines Blutbild
| betrifft Codesystem | class codes, type codes
| Autor der Anfrage | JC
| Diskussion| Einige IHE Profile nutzen den LOINC Code im CDA als ClinicalDocument/code. Es wird nicht vorgeschrieben, dass der ClinicalDocument/code als XDS-TypeCode verwendet wird. Die Empfehlung spricht eher von einem Mapping (siehe PCC, Vol. 2, S. 45) The typeCode should be mapped from the ClinicalDocument/code element to a set of document type codes configured in the affinity domain. One suggested coding system to use for typeCode is LOINC, in which case the mapping step can be omitted. ==> Empfehlung ClinicalDocument/code eher als eventCode nutzen. Auswahl IHE-D class und type Codes basierend auf LOINC Codes, original LOINC Code als EventCode hinzufügen. Konsistent mit bisherigem Vorgehen bei KDL. ==> Antragsteller einverstanden
Mutterpass kann mit ClassCode Medizinischer Ausweis und TypeCode Schwangerschafts- und Geburtsverlauf gut abgebildet werden. (In der KDL gibt es einen Code für "Mutterpass (Kopie)" ==> die Ergänzung Kopie ist historisch gewachsen, sollte gestrichen werden, da alle eingescannten Dokumente auch nur Kopien sind. Geburtsbericht und Stillprotokoll sind auch in der KDL nicht unterscheidbar. Stillprotokoll kann mit ClassCode Durchführungsprotokoll und typeCode "Schwangerschafts - und Geburtsverlauf" dokumentiert werden, da Stillprotokolle vor allem während der ersten Tage nach der Geburt angelegt werden. Um diese Zuordnung eindeutig zu klären wird "Stillprotokoll" als Beispiel bei dem entsprechenden typeCode hinterlegt.

| Entscheidung |"Stillprotokoll" wird als Beispiel bei typeCode "Schwangerschafts- und Geburtsverlauf" eingefügt, Scope der ValueSets ist es nicht, möglichst granulare typeCodes zu definieren, sondern die Dokumente an Hand der Kombination von vielen verschiedenen Metadaten beschreiben zu können und die Dokumente möglichst einfach an Hand der Metadaten wiederauffindbar zu machen. Ob das Dokument von einem Arzt oder einem Patienten geschrieben ist, kann man an der AuthorRole erkennen. Zudem hat man noch die Möglichkeit in der eventCodeList anzugeben, dass dies ein vom Patienten mitgebrachtes Dokument ist.
| Action Item |"Stillprotokoll" als Beispiel bei typeCode "Schwangerschafts- und Geburtsverlauf" einfügen ==> Angela; Scope der Granularität der XDS Metadaten genauer beschreiben ==> Sven; in Wiki FAQ Fragen zu Valuesets ergänzen (hinter Einleitung) ==> Angela
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am|21.2.2020

|- valign="top"
| Anfrage ID| 2
| Anfrage eingegangen am|
| Anfrage| es scheint in Deutschland Bestrebungen zu geben, Unfallchirurgie mit der Orthopädie zusammenzulegen.
Ab August 2019 wird es im UKD nur noch die „Klinik für Orthopädie und Unfallchirurgie“ geben.
Ist die Einführung einer weiteren Fachabteilung im DocumentEntry.practiseSettingCode geplant?
In DocumentEntry.authorSpecialty findet sie sich:
Code 512 Anzeigename FA Orthopädie und Unfallchirurgie
| betrifft Codesystem | practiceSettingCode
| Autor der Anfrage | SB
| Diskussion| evtl. practiceSettingCode Chirurgie verwenden, deckt beides ab
| Entscheidung |
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 29.11.2019

|- valign="top"
| Anfrage ID| 3
| Anfrage eingegangen am|
| Anfrage| wie letztens angekündigt, möchten wir neben dem Notfalldatensatz auch den „Datensatz für persönliche Erklärungen“ (Ablageorte für Einwilligung Notfalldatensatz, Organspendeerklärung, Vorsorgevollmacht sowie Patientenverfügung) in der Elektronischen Patientenakte speichern lassen können.
Dazu möchten wir das Value Set für XDS-Metadatenattribut formatCode um den folgenden Wert erweitern: urn:gematik:ig:DatensatzPersoenlicheErklaerungen:r3.1
Als Anzeigename sollte „Datensatz für persönliche Erklärungen (gematik)“ verwendet werden. Das bisherige Code-System „Deutsche Dokumentenformate“ (1.3.6.1.4.1.19376.3.276.1.5.6) passt hierfür sicherlich ganz gut als Quellsystem.
| betrifft Codesystem | formatCode
| Autor der Anfrage | RK
| Diskussion| keine Einwände
| Entscheidung | wir fügen Code hinzu
| Action Item | in ArtDecor eintragen
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am|13.12.2019

|- valign="top"
| Anfrage ID| 5
| Anfrage eingegangen am| 31.10.2019
| Anfrage| Freischaltung der FHIR Schnittstelle in ArtDecor
| betrifft Codesystem | alle
| Autor der Anfrage | SH über Tarik Idris
| Diskussion|
| Entscheidung | wird gemacht
| Action Item | Tarik: FHIR Schnittstelle in ArtDecor freischalten
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 15.11.2019

|- valign="top"
| Anfrage ID| 8
| Anfrage eingegangen am| 15.11.2019
| Anfrage| Vorgehensweise für V3 auf eigener WikiSeite beschreiben
| betrifft Codesystem | alle
| Autor der Anfrage | SL
| Diskussion| befürwortet
| Entscheidung | befürwortet
| Action Item | Anlegen neue Seite im HL7 Wiki ==> Angela, Ziele ==> Angela, allgemeine Weiterentwicklung als Ziel hinzufügen
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 13.12.2019

|- valign="top"
| Anfrage ID| 9
| Anfrage eingegangen am| 13.12.2019
| Anfrage| Bericht Treffen BVITG, Interopforum, Gematik, Vorabstimmung EPA Version 1.2.2022
| betrifft Codesystem | alle
| Autor der Anfrage | TI
| Diskussion| Bericht: Gematik plant zentralen Server für Bereitstellung der Gematik ValueSets (die fast identisch sind mit unseren Value Sets) ValueSets sollen per SVS abgerufen werden können, Governance soll bei IHE Gruppe bleiben, Registry soll prüfen, ob bestimmte Kombination von Codes erlaubt ist (sieht IHE nicht vor), bei FormatCodes sollen zwei ValueSets gebildet werden: VS1 umfasst alle FormatCode, VS2 umfasst FormatCodes für Dokumente, die nur einmal vorhanden sein dürfen (z.B. Impfpass)
| Entscheidung | über konstruktive Zusammenarbeit wird sich gefreut
| Action Item | keine
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 13.12.2019

|- valign="top"
| Anfrage ID| 10
| Anfrage eingegangen am| 12.01.2020
| Anfrage| diese Woche ist ja die Dokument Ontology bei LOINC erschienen. Sind unsere Value Sets bereits darauf abgebildet? Wir hatten ja bereits einen ersten Vorstoß Richtung SNOMED gewagt. Wir sollten die LOINC-Codes (Anzahl: 11096) vervollständigen und ggf mit dem MDM (Münster) abgleichen, damit es international sauber bleibt.
https://loinc.org/file-access/download-id/8994/
| betrifft Codesystem | alle
| Autor der Anfrage | ST
| Diskussion|
| Entscheidung | Gemeinsame Strategietelko zur Zusammenführung LOINC, SNOMED CT, XDT, QMS, KDL deutsche XDS Value Sets am 28.5.2020 10-12 Uhr geplant
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 24.04.2020

|- valign="top"
| Anfrage ID| 11
| Anfrage eingegangen am| 07.02.2020
| Anfrage| Zusammenarbeit KBV
| betrifft Codesystem | alle, v.a. format Code
| Autor der Anfrage | RK
| Diskussion| Den MIOs müssen XDS Metadaten zugeordnet werden, v.a. formatCodes
| Entscheidung | Arbeitsgruppe bietet proaktiv Hilfe bzgl. der Metadaten bei KBV an
| Action Item | Mail an Vorstand ==> Mail an KBV (H. Tenkow)
| Bearbeitungsstand | Mail an Vorstand gesendet
| zuletzt bearbeitet am| 07.02.2020

|- valign="top"
| Anfrage ID| 12
| Anfrage eingegangen am| 21.02.2020
| Anfrage| Aufnahme neuer formatCodes für ePA Stufe 2.0, urn:gematik:ig:Impfausweis:r4.0, urn:gematik:ig:Mutterpass:r4.0, urn:gematik:ig:Kinderuntersuchungsheft:r4.0, urn:gematik:ig:Zahnbonusheft:r4.0
| betrifft Codesystem | format Code
| Autor der Anfrage | RK
| Diskussion| keine Einwände
| Entscheidung | werden aufgenommen
| Action Item | Aufnahme in ArtDecor ==> Angela
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 24.02.2020

|- valign="top"
| Anfrage ID| 13
| Anfrage eingegangen am| 06.03.2020
| Anfrage| Übersetzung der Metadatenbezeichnungen ins Englische
| betrifft Codesystem | format Code
| Autor der Anfrage | SL
| Diskussion| ValueSets sind nur für Deutschland, jeder Dokumentierende sollte über ausreichende Deutschkenntisse verfügen
| Entscheidung | abgelehnt
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 06.03.2020
|- valign="top"

|- valign="top"
| Anfrage ID| 14
| Anfrage eingegangen am| 24.04.2020
| Anfrage| Neuer FormatCode für eRezept (Daten elektronischer Verordnung) der Gematik
| betrifft Codesystem | format Code
| Autor der Anfrage | RK
| Diskussion| evtl. besser drei Dokumente definieren: Rezept, Abgabe (evtl. von anderer Firma), Abrechnung, komplette Spezifikation darauf Basis von CDA liegt vor, hier geht es nur um den nicht signierten Teil, der in der EPA gespeichert wird. MimeType application/fHir+xml, evtl. zweiter FormatCode für Dokument inkl.Signatur
| Entscheidung | urn:gematik:ig:VerordnungsdatensatzMedikation:r4.0
| Action Item | in Art Decor eintragen
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 26.06.2020

|- valign="top"

| Anfrage ID| 15
| Anfrage eingegangen am| 14.05.2020
| Anfrage| Kommentierung EPA XDS Metadaten
| betrifft Codesystem | fast alle
| Autor der Anfrage | TI
| Diskussion|
| Entscheidung | Es werden folgende Kommentare an gematik gesendet: bei Vertraulichkeitseinschätzung des Versicherten sollte das passende Codesystem verwendet werden, EGA sollte als EventCode aufgenommen werden nicht als ReferenceID, ein Copy Paste Fehler bei FormatCode
| Action Item | Tarik==> Kommentar an gematik
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 18.05.2020

|- valign="top"
| Anfrage ID| 16
| Anfrage eingegangen am| 14.05.2020
| Anfrage| Passender Type Code für Genetische Befunde?; Es gibt Befunde aus dem molekulargenetischen Labor der medizinischen Klinik. zytopathologische Untersuchungen aus der Pathologie, Zytogenetische Befunde / Vererbungsschema aus der Humangenetik und Gendiagnostik von der Frauenklinik.
| betrifft Codesystem | TypeCode
| Autor der Anfrage | VK
| Diskussion|
| Entscheidung | wird als Beispiel in pathologische Befunde aufgenommen
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 26.06.2020
|- valign="top"

| Anfrage ID| 17
| Anfrage eingegangen am| 14.05.2020
| Anfrage| Am UKHD gibt es ein Zentrum für Seltene Erkrankungen. Dort werden Patienten jeglichen Alters behandelt.
| betrifft Codesystem | PracticeSettingCode
| Autor der Anfrage | VK
| Diskussion|
| Entscheidung | Es gibt einen neuen Code interdisziplinäre Zusammenarbeit. INTZ, unter dem alle interdisziplinären Fachrichtungen zusammengefasst werden (INTO, INTS, Transplantationszentrum), Zusätzlich Code SELT für seltene Erkrankungen
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 26.06.2020

|- valign="top"
| Anfrage ID| 18
| Anfrage eingegangen am| 26.06.2020
| Anfrage| Code für Erfassung Fall- /Bewegungsdaten
| betrifft Codesystem | Class Code, Type Code
| Autor der Anfrage | AM
| Diskussion| evtl. ClassCode administrative Dokumente oder Durchführungsprotokoll hängt vom Use Case ab, Type Code Einweisungs und Aufnahmedokumente oder administrative Checklisten Alles nicht optimal, aber keine klassischen Patientendokumente
| Entscheidung | keine zusätzlichen Codes
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 26.06.2020

|- valign="top"
| Anfrage ID| 20
| Anfrage eingegangen am| 10.07.2020
| Anfrage| Der Bedarf stammt aus der Festlegung der elektronischen Patientenakte gemäß PDSG, Versicherten die Möglichkeit zu geben, auf „Daten zu Befunden, Diagnosen, durchgeführten und geplanten Therapiemaßnahmen, Früherkennungsuntersuchungen, zu Behandlungsberichten und sonstige untersuchungs- und behandlungsbezogene medizinische Informationen“ (§ 341 Abs. 2 Nr. 1a PDSG) Zugriffsberechtigungen auszusprechen. Die entsprechenden Dokumente sollen danach kategorisiert werden, ob sie aus einer der folgenden Fachgebiete/Institutionstypen entstammen:

Unterkategorien von 1a - Code

Hausarzt/ Hausärztin - practitioner

Krankenhaus - hospital

Labor und Humangenetik - laboratory

Physiotherapeuten - physiotherapy

Psychotherapeuten - psychotherapy

Dermatologie - dermatology

Urologie/Gynäkologie - gynaecology_urology

Zahnheilkunde und Mund-Kiefer-Gesichtschirurgie - dentistry_oms

Weitere Fachärzte/ Fachärztinnen - other_medical

Weitere nicht-ärztliche Berufe - other_non_medical

Für diesen ValueSet wäre es für die Spezifikationen der elektronischen Patientenakte und den Foldern, zu denen die entsprechend kategorisierten Dokumente gehören, von Vorteil, eine geeignete Codesystem-OID anführen zu können. Auf solche Dokumentenkategorien erteilen Versicherte Zugriffsrechte auf die ePA. Diese Kategorien sollen exklusiv Dokumenten zugeordnet werden können.

Zusätzlich soll für den Code „ega“ eine Kategorie von Dokumenten bezeichnen, für die gilt: Die Kategorie wird für Dokumente vergeben, die aus einer bestehenden eGA (gemäß Paragraph §41 Absatz 2 Satz 7 PDSG, bzw. Paragraph 68 SGB V) importiert worden sind.

Für diesen Code soll ein Code-System "Sonstige Berechtigungen ePA" genutzt werden.
| betrifft Codesystem | Anfrage neues Codesystem / ValueSet für Folder
| Autor der Anfrage | JG (Gematik)
| Diskussion| Überschneidungen bei Konzepten, keine Definitionen, Kategorien sollen zur Zugriffsberechtigung in der ePA verwendet werden, sie sollen Folder der ePA beschreiben es wäre sinnvoll gewesen, IHE Deutschland in die Abstimmung des Codesystems einzubeziehen
| Entscheidung |Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte
| Action Item | Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte
| Bearbeitungsstand | erledigt, Gematik hat OIDs für ValueSet (1.2.276.0.76.11.466, 1.2.276.0.76.11.467) und Codesystems (1.2.276.0.76.5.511, 1.2.276.0.76.5.512, 1.2.276.0.76.5.513) beantragt, reservierte OID 1.3.6.1.4.1.19376.3.276.1.5.17 wird nicht mehr benötigt
| zuletzt bearbeitet am| 18.09.2020

|- valign="top"
| Anfrage ID| 21
| Anfrage eingegangen am| 31.07.2020
| Anfrage| In Absprache mit der KBV ist es für die Verarbeitung von Medizinischen Informationsobjekten in der ePA für die beteiligten Komponenten nötig, die folgenden FormatCodes verarbeiten zu können:

"urn:gematik:ig:KinderuntersuchungsheftUntersuchungen:r4.0"
"urn:gematik:ig:KinderuntersuchungsheftTeilnahmekarte:r4.0"
"urn:gematik:ig:KinderuntersuchungsheftNotizen:r4.0"
Für diesen Zweck möchten wir Sie bitten, diese Werte in die IHE-ValueSet-Arbeitsgruppe zur Diskussion einer Aufnahme in die Deutschen Dokumentenformate des FormatCode-ValueSets einzubringen.

Als Anzeigename schlage ich vor:

· Untersuchungen Kinderuntersuchungsheft

· Teilnahmekarte Kinderuntersuchungsheft

· Notizen Kinderuntersuchungsheft
| betrifft Codesystem | FormatCodes
| Autor der Anfrage | Gematik
| Diskussion|
| Entscheidung | wird aufgenommen
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 18.09.2020

|- valign="top"
| Anfrage ID| 22
| Anfrage eingegangen am| 16.09.2020
| Anfrage| Patientenverfügung als Beispiel für administratives Dokument aufnehmen
| betrifft Codesystem | classCode
| Autor der Anfrage | VB (Uniklinik HD)
| Diskussion| entspricht Mapping in KDL
| Entscheidung | wird als Beispiel hinzugefügt
| Action Item | in ArtDecor eintragen
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 18.09.2020

|- valign="top"
| Anfrage ID| 23
| Anfrage eingegangen am| 18.09.2020
| Anfrage| TypeCode für mikroskopische Bilder
| betrifft Codesystem | typeCode
| Autor der Anfrage | VB (Uniklinik HD)
| Diskussion| wenn Ergebnis Mikrobiologie oder Pathologie, dann diesen Code verwenden, ansonsten BILD
| Entscheidung | wenn Ergebnis Mikrobiologie (MKRO) oder Pathologie (PATH) dann diesen Code verwenden, ansonsten BILD
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 18.09.2020

|- valign="top"
| Anfrage ID| 24
| Anfrage eingegangen am| 5.11.2020
| Anfrage| * Beruf ‚Psychotherapeut*in‘: dieser Beruf wurde mit dem Psychotherapeutenausbildungsreformgesetz (2019) geschaffen und ist wirksam ab 01.09.2020. Der neue Beruf des ‚Psychotherapeut*in‘ hat Fachgebiete.
Die Berufe PP und KJP wird es weiterhin daneben geben, diese haben aber keine Fachgebiete, und sind selbst keine Fachgebiete sondern jeweils eigenständige Berufe.
HL7 bildet die Berufsgruppen PP (2 L 82) und KJP (2-L 76) falsch ab, nämlich als Spezialisierung, nicht als Grundberufe.
Die Fachgebiete des neuen Berufs ‚Psychotherapeut*in‘ sind im HL7 nicht abgebildet.
| betrifft Codesystem | authorspecialty
| Autor der Anfrage | BPtK
| Diskussion|
| Entscheidung |Neue Berufsgruppen werden in Authorspecialty aufgenommen.
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 10.12.2020

|- valign="top"
| Anfrage ID| 25
| Anfrage eingegangen am| 5.11.2020
| Anfrage| Übernahme der Facharzt- und Schwerpunktscodes aus dem Codesystem der BAEK, da relevante Facharzt - und Schwerpunktscodes fehlen.
| betrifft Codesystem | authorspecialty
| Autor der Anfrage | BAEK
| Diskussion| Bisher wurden die Facharzt und Schwerpunktcodes aus dem Codesystem der KBV übernommen. Wichtig ist, dass uns eine zuverlässig gepflegte Liste von Codes zu Verfügung steht. FW (Fachliche Weiterbildung) und FK Codes sind nicht notwendig.
| Entscheidung |Die BAeK stellt uns die Codes möglichst als CSV oder Excelfile zur Verfügung. Die BAek übernimmt die Pflege und Bereitstellung der Codes, so dass sie von uns in ArtDecor eingetragen werden können. Auch TG Codes, BAEK beantragt OID
| Action Item | Konzept zur Pflege, Mapping BAEK Codes auf practice Setting Codes wird auch bei KBV veröffentlicht (als FHIR concept map)
| Bearbeitungsstand |erledigt
| zuletzt bearbeitet am| 01.02.2021

|- valign="top"
| Anfrage ID| 26
| Anfrage eingegangen am| 13.11.2020
| Anfrage| Prozeduren zu Fertilitätsbehandlung in Gebu aufnehmen?
| betrifft Codesystem | typeCode
| Autor der Anfrage | UKHD
| Diskussion|
| Entscheidung |nein
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 01.02.2020

|- valign="top"
| Anfrage ID| 27
| Anfrage eingegangen am| 13.11.2020
| Anfrage| Typecode für Erfassung der Dauer der Gebärdendolmetscherunterstützung
| betrifft Codesystem | typeCode
| Autor der Anfrage | UKHD
| Diskussion|
| Entscheidung |Abrechnungsdokumente
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 01.02.2020

|- valign="top"
| Anfrage ID| 28
| Anfrage eingegangen am| 10.12.2020
| Anfrage| Classcode für Diagnosenübersichtsblatt
| betrifft Codesystem | classCode
| Autor der Anfrage | UKHD
| Diskussion|
| Entscheidung |hängt vom UseCase ab
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 01.02.2020
|- valign="top"
| Anfrage ID| 30
| Anfrage eingegangen am| 04.02.2021
| Anfrage| Nutzung von XDS Value Sets für den digitalen Austausch medizinischer Unterlagen mit den Medizinischen Diensten.
| betrifft Codesystem | alle
| Autor der Anfrage | AMue
| Diskussion|
| Entscheidung |
| Action Item | Annett lädt Herrn Dr. Eckardt vom MD Westfalen-Lippe zur nächsten Telko ein
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am|

|- valign="top"
| Anfrage ID| 32
| Anfrage eingegangen am| 09.2021
| Anfrage| Aufnahme von Pflegefachmann/-fachfrau, da neuer Ausbildungsberuf
| betrifft Codesystem | Authorspecialty
| Autor der Anfrage | FP
| Diskussion| Der BPflV hat auf Nachfrage per mail bestätigt, dass folgende Beruf im ValueSet fehlen: Pflegefachmann/-frau, Fachgesundheits- und krankenpfleger für Onkologie, Fachgesundheits- und krankenpfleger für Psychiatrie. Desweiteren sollten alle Fachkrankenpflegeberufsbezeichnungen in Fachgesundheits- und krankenpflegerbezeichnungen umbenannt.
| Entscheidung | Konzepte werden wie vorgeschlagen ergänzt, bzw. - bezeichnungen geändert.
| Action Item | Eröffnung version 4 draft des Value Sets ==> Anpassungen in ArtDecor erfolgt
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 15.10.2021

|- valign="top"
| Anfrage ID| 34
| Anfrage eingegangen am| 22.12.2021
| Anfrage| Laut Implementierungsleitfaden ePA Version 1.8.0 vom 2. Juni 2021 (S. 99/100) soll der NFD mit den folgenden IHE-XDS Metadaten versehen werden:
• IHE-XDS classCode = AUS
• IHE-XDS typeCode = BESC
Dies widerspricht den Kodiervorgaben von IHE Deutschland Dort ist festgelegt, dass der Notfalldatensatz mit typeCode PATD dokumentiert werden soll.
PATD Patienteneigene Dokumente Dokumententypen Dokumente, welche der Patient zu seinem Kontakt in der Gesundheitseinrichtung mitbringt, die aber nicht in unmittelbarem Zusammenhang mit dem aktuellen Kontakt stehen müssen. Sowie Dokumente, in denen das mitgebrachte Patienteneigentum festgehalten wird.
Beispiele: Ausweise, Vorsorgevollmacht, Patientenverfügung, Wertgegenständeverwaltung, , Patiententagebuch

| betrifft Codesystem | TypeCode
| Autor der Anfrage | AMue
| Diskussion|
| Entscheidung | Missverständnis konnte geklärt werden
| Action Item | keine
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am|

|- valign="top"
| Anfrage ID| 35
| Anfrage eingegangen am| 14.02.2022
| Anfrage| Die gematik möchte wieder Aktualisierungen für MIO-Versionen zu den Format Codes einbringen.

neu (die DisplayNames sind dieselben der Vorgänger)

· urn:gematik:ig:KinderuntersuchungsheftUntersuchungen:v1.0.1

· urn:gematik:ig:KinderuntersuchungsheftTeilnahmekarte:v1.0.1

· urn:gematik:ig:KinderuntersuchungsheftNotizen:v1.0.1

· urn:gematik:ig:Mutterpass:v1.1.0

· urn:gematik:ig:VerordnungsdatensatzMedikation:v1.0.2

deprecated/obsolet

· urn:gematik:ig:VerordnungsdatensatzMedikation:r4.0

· urn:gematik:ig:Kinderuntersuchungsheft:v1.0.0

| betrifft Codesystem | FormatCode
| Autor der Anfrage | RK
| Diskussion| Versionsänderungen auf 3. Ebene (Patch) sollten in Zukunft keine Änderungen am Formatcode verursachen
| Entscheidung | Änderung wird diesmal zugestimmt, RK soll aber MIOs/Gematik darum bitten, in Zukunft nur neue Formatcodes zu beantragen, wenn es mindestens minor changes an der der Spezifikation gibt.
| Action Item | Art-Decor anpassen, RK Kommunikation des Wunschs der AG an die Gematik
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 18.03.2022

|- valign="top"
| Anfrage ID| 36
| Anfrage eingegangen am| 18.02.2022
| Anfrage| Pflege des Mappings der KDL auf ClassCode TypeCode mit Arbeitsgruppe abstimmen

| betrifft Codesystem | eventCodeList, classCode, typeCode
| Autor der Anfrage | AM
| Diskussion|
| Entscheidung | Review des Mappings können wir machen, aber Verantwortung liegt bei DVMD, sobald neues Mapping vorliegt, erfolgt Review als neue Anfrage
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 18.02.2022

|- valign="top"
| Anfrage ID| 39
| Anfrage eingegangen am| 31.03.2022
| Anfrage| neue FormatCodes, neue eventCodes
DiGA

documentEntry.formatCode.code: "urn:gematik:ig:diga:v1.0"

documentEntry.formatCode.displayName: "DiGA (gematik)"

Weiterhin sollen aufgrund einer gesetzlichen Vorgabe eDMP-Datensätze in der ePA gespeichert werden können. Das Regelsystem der ePA braucht dazu konkrete Codes, um die DMPs erkennen zu können. Wir schlagen daher die folgenden Format Codes für die DMPs vor, die die Implementierungsleitfäden der KBV unter https://update.kbv.de/ita-update/Medizinische-Dokumentationen/ widerspiegeln:

DMP Asthma bronchiale

documentEntry.formatCode.code: "urn:gematik:ig:DMP-Asthma:v4.45"

documentEntry.formatCode.displayName: "eDMP Asthma (gematik)"

DMP Brustkrebs

documentEntry.formatCode.code: "urn:gematik:ig:DMP-BRK:v4.23"

documentEntry.formatCode.displayName: "eDMP Brustkrebs (gematik)"

DMP Chronische Herzinsuffizienz

documentEntry.formatCode.code: "urn:gematik:ig:DMP-HI:v1.1"

documentEntry.formatCode.displayName: "eDMP Herzinsuffizienz (gematik)"

DMP Chronischer Rückenschmerz

documentEntry.formatCode.code: "urn:gematik:ig:DMP-Rueckenschmerz:v1.0"

documentEntry.formatCode.displayName: "eDMP Rückenschmerz (gematik)"

DMP COPD

documentEntry.formatCode.code: "urn:gematik:ig:DMP-COPD:v4.4"

documentEntry.formatCode.displayName: "eDMP Chronic Obstrusive Pulmonary Disease (gematik)"

DMP Depressionen

documentEntry.formatCode.code: "urn:gematik:ig:DMP-Depression:v1.1"

documentEntry.formatCode.displayName: "eDMP Depression (gematik)"

DMP Diabetes mellitus Typ 1

documentEntry.formatCode.code: "urn:gematik:ig:DMP-DM1:v5.5"

documentEntry.formatCode.displayName: "eDMP Diabetes mellitus Typ 1 (gematik)"

DMP Diabetes mellitus Typ 2

documentEntry.formatCode.code: "urn:gematik:ig:DMP-DM2:v6.5"

documentEntry.formatCode.displayName: "eDMP Diabetes mellitus Typ 2 (gematik)"

DMP Koronare Herzkrankheit

documentEntry.formatCode.code: "urn:gematik:ig:DMP-KHK:v4"

documentEntry.formatCode.displayName: "eDMP Koronare Herzkrankheit (gematik)"

DMP Osteoporose

documentEntry.formatCode.code: "urn:gematik:ig:DMP-OST:v1.0"

documentEntry.formatCode.displayName: "eDMP Osteoporose (gematik)
Leider unterliegen diese Versionen historisch bedingt, keinem Semantic Versioning. Das möchten wir sehr gerne diskutieren, da es möglicherweise unpraktikabel hinsichtlich der Pflege des Value Sets werden kann.

Weiterhin möchten wir gerne diskutieren, neben den Format Codes, versionsunabhängige Event Codes der DMP-Programme aufzunehmen, um die spezifische Suche nach einem Programm zu gewährleisten. Die KBV hat schon das entsprechende Code-System in verschiedenen Formaten spezifiziert und es wird auch in den HL7 FHIR Basisprofilen berücksichtigt (https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP). Dieses könnte „herkömmlich“ über die OID 1.2.276.0.76.5.223 in das Value Set für Event Codes eingebunden werden.
| betrifft Codesystem |formatCodes
| Autor der Anfrage | Gematik
| Diskussion| Die Display names des KBV CodeSystems sind ziemlich uneindeutig. Beispiel: HI könnte nicht nur Herzinsuffizienz sondern auch Hinterwandinfarkt oder Harnwegsinfekt bedeuten.
| Entscheidung | Das Codesystem https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP wird dem eventCode ValueSet hinzugefügt. Der KBV wird geraten, in der nächsten Version des Codesystems bei den Displaynamen geeignetere Bezeichnungen zu verwenden. Die Major version der formatCodes wird in das entsprechende ValueSet aufgenommen z.B. "urn:gematik:ig:DMP-Asthma:v4" statt "urn:gematik:ig:DMP-Asthma:v4.45", da sonst der Pflegeaufwand zu hoch ist.
| Action Item | Raik gibt entsprechende Rückmeldung an KBV, Angela fügt eventCOdes und formatCodes den entsprechende ValueSets hinzu
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 27.05.2022
|- valign="top"

| Anfrage ID| 41
| Anfrage eingegangen am| 28.04.2022
| Anfrage|neue Dokumentenformate für EPA: code: "urn:gematik:ig:Telemedizinisches-Monitoring:v1.0" displayName: " Telemedizinisches Monitoring (gematik)", code: "urn:gematik:ig:Pflegeueberleitungsbogen:v1.0"
displayName: " Pflegeüberleitungsbogen (gematik)"
| betrifft Codesystem | formatCode
| Autor der Anfrage | gematik
| Diskussion|
| Entscheidung | Major Revisions werden als FormatCodes aufgenommen
| Action Item | Feedback an Gematik ==> positiv
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 27.05.2022
|- valign="top"

|}

'''Tabelle Aktueller Stand'''

:{|class="hl7table sortable"
|-
! width="25%" align="left" | Codesystem
! align="center" | Stand Konzepte
! align="center" | ArtDecor
! align="center" | WikiText
! align="center" | Review durch

|- valign="top"
| Codesystem | Einleitung
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Sven, Frank

|- valign="top"
| Codesystem | Vokabular Management
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Sven, Frank

|- valign="top"
| Codesystem | Confidentiality Code
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Sven, Frank

|- valign="top"
| Codesystem | AuthorRole
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Angela, Sven

|- valign="top"
| Codesystem | AuthorSpeciality
| Stand Konzepte | n/a
| ArtDecor | offen
| WikiText | offen
| Review durch | ''Tarik?''

|- valign="top"
| Codesystem | EventCodeList
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Angela

|- valign="top"
| Codesystem | ContentTypeCode
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Axel

|- valign="top"
| Codesystem | ClassCode
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Arnold, Antje

|- valign="top"
| Codesystem | TypeCode
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Arnold, Antje

|- valign="top"
| Codesystem | FormatCode
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Axel

|- valign="top"
| Codesystem | HealthcareFacilityTypeCode
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | ''Tarik?''

|- valign="top"
| Codesystem | PracticeSettingCode
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Antje, Arnold

|- valign="top"
| Codesystem | Folder.codeList
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Angela, Sven

|- valign="top"
| Valuesets/ generell| EPA Verwendung
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Erstellung durch | Raik, Christof

|}

'''Schritte zur Veröffentlichung v3'''
# Zeitplan (draft) erstellen
#* Anfang Februar Ankündigung
#* Anfang März Kommentierungsstart
#* Anfang April Ende Kommentierung, Anfang Kommentarauflösungs
#* Anfang Juni Veröffentlichung
# Rückfrage an gematik, KBV, BAEK, BPTK ob die mit ihnen abgestimmten Änderungen an v3 so finalisiert werden können - Hinweis auf unseren vorläufigen Zeitplan geben
# Ankündigung formulieren
# Kapitel zur Verwendung der ValueSets in der EPA schreiben
# Review der Wiki-Texte und AuthorSpecialty Code anpassen
# Change Liste erstellen
# PDF erstellen
# PDF in Wiki und auf IHE-D Seite hochladen/referenzieren
# Kommentare sammeln
# Kommentare auflösen
# Abstimmung zur Veröffentlichung
# Finale Version erstellen und in Wiki und IHE-D Seite hochladen

Optional:
* Erläuterung zum Zusammenspiel mit FHIR
* Hinweis/kurze Erläuterung der nicht behandelten XDS Metadaten

'''IG Struktur'''

# [[ihevs:Einleitung]] (Vorgehen, Ziele, Umgang mit v1, normativ, Delta-Liste?, Änderungen/Pflege)
# [[Ihevs:Vokabular-Management]]
# [[ihevs:DocumentEntry.authorRole]]
#* Erläuterungstext
#* ValueSet aus ART Decor
# [[ihevs:DocumentEntry.authorSpecialty]]
#* Erläuterungstext
#* ValueSet aus ART Decor
# [[ihevs:DocumentEntry.classCode]]
#* Erläuterungstext (mit Link auf ART Decor)
#* ValueSet aus ART Decor
# [[ihevs:DocumentEntry.confidentialityCode]]
#* Erläuterungstext
#* ValueSet aus ART Decor
# [[ihevs:DocumentEntry.eventCodeList]]
#* Erläuterungstext
#* ValueSet aus ART Decor
# [[ihevs:DocumentEntry.formatCode]]
#* Erläuterungstext (mit Link auf ART Decor)
#* ValueSet aus ART Decor
# [[ihevs:DocumentEntry.healthcareFacilityTypeCode]]
#* Erläuterungstext (mit Link auf ART Decor)
#* ValueSet aus ART Decor
# [[ihevs:DocumentEntry.languageCode]]
#* Erläuterungstext
#* ValueSet aus ART Decor
# [[ihevs:DocumentEntry.practiceSettingCode]]
#* Erläuterungstext (mit Link auf ART Decor)
#* ValueSet aus ART Decor
# [[ihevs:DocumentEntry.typeCode]]
#* Erläuterungstext (mit Link auf ART Decor)
#* ValueSet aus ART Decor
# [[ihevs:SubmissionSet.contentTypeCode]]
#* Erläuterungstext
#* ValueSet aus ART Decor
# [[ihevs:Folder.codeList]]
#* Erläuterungstext
#* ValueSet aus ART Decor

[[Kategorie:ihevs]]

IHE DE ValueSets Action Items

2022-08-19T11:16:13Z

Foemig: Änderungen akzeptiert

'''Tabelle Änderungsanfragen'''

:{|class="hl7table sortable"
|-
! align="left" | Anfrage ID
! align="left" | Anfrage eingegangen am
! align="left" | Anfrage
! align="center" | betrifft Codesystem
! align="center" | Autor der Anfrage
! align="center" | Diskussion
! align="center" | Entscheidung
! align="center" | Action Item
! align="center" | Bearbeitungsstand
! align="center" | zuletzt bearbeitet am

|- valign="top"
| Anfrage ID| 4
| Anfrage eingegangen am|
| Anfrage| Arbeitsgruppe „Weiterentwicklung Klinische Dokumentenklassenliste (KDL)“.
Am 22. August 2019 fand eine Telefonkonferenz statt, bei der auch das Mapping auf die Value Sets classCode und typeCode von IHE-D thematisiert wurde.
Das aktuelle Mapping liegt der Geschäftsstelle vor und ist bisher mit Angela Merzweiler gemeinsam abgestimmt wurden.
Aktuelle Erfahrungen im Rahmen der IHE-konformen Langzeitarchivierung haben gezeigt, dass die granularen Informationen zum Dokumententyp verloren gehen, sobald nur der ClassCode und TypeCode in die Langzeitarchivierung übernommen werden.
Beispiel:
Ich möchte daher anregen bzw. beantragen, dass die KDL im ersten Schritt offiziell als CodeSystem in das Value Set „EventCodeList“ aufgenommen wird.
Damit haben Hersteller von IHE-konformen Archiven, o. ä. die Möglichkeit, wenigstens die Klassifizierung des Dokuments mittels KDL offiziell abzubilden.
· Code System Name: Klinische Dokumentenklassen Liste (KDL)
· Code System ID: 1.2.276.0.76.3.1.191.0.1.1, versionsabhängig
· Kommentar: Klassifizierung von Dokumenten und Daten als Beispiele für die Value Sets classCode und typeCode
Mittelfristig soll die KDL zu einem terminologischen System mit ontologischem Ansatz ausgebaut werden.
Hier möchten wir uns als Arbeitsgruppe mit der Ihrer Arbeitsgruppe austauschen, inwieweit die KDL weiter in Richtung IHE, SNOMED, LOINC, etc. ausgebaut werden kann.
Ich freue mich, wenn wir es gemeinsam schaffen, dazu einen persönlichen Termin für ein Arbeitstreffen zu finden.
| betrifft Codesystem | eventCode
| Autor der Anfrage | AMü
| Diskussion| EventCode eigentlich als Kontext der Dokumentenerstellung gedacht, als Interimslösung für KDL geeignet, soll aber unbedingt zur Ontologie weiterentwickelt werden. Fokus soll weiterhin auf Metadaten für Document Sharing liegen. Gemeinsame Telko zur weiteren Abstimmung mit KDL Arbeitsgruppe. Semantik der Codes muss definiert werden. Das in Simplifier eingetragene Valueset enthält das gesamte Codesystem. Als Valueset sollen nur Codes auf dritter Hierarchiestufe erlaubt sein. Einbindung soll dynamisch erfolgen. Das Valueset ist closed. Annett beantragt bei DIMDI eine OID für den DVMD. Dann können OIDs für das Codesystem und das Valueset vergeben werden. Achtung: KDL ist eine Klassifikation, für jede Version eine neue OID notwendig. DVMD benötigt OID Konzept. Eigene Projektseit im HL7wiki eingerichtet
24.4. OIDs für KDL2019 und KDL2020 vorhanden, aber keine eindeutigen URNs, Filterung auf dritter Ebene für ValueSet war erfolgreich, aber Beschreibung im Simplifier fehlerhaft, Mapping KDL2020 auf XDS Class und TypeCodes in Simplifier vorhanden (noch keine Rückmeldungen von uns)
übergeordnetes Valueset KDL in ArtDecor als Codesystem eingetragen, da der Eintrag als Valueset technisch nicht möglich war.
12.11.2021 erneute Diskussion, ob Eintrag als Codesystem sinnvoll war
| Entscheidung | grundsätzlich zugestimmt, neues Valueset
| Action Item | alle=> Mapping prüfen
| Bearbeitungsstand | in Bearbeitung
| zuletzt bearbeitet am| 12.11.2021

|- valign="top"
| Anfrage ID| 6
| Anfrage eingegangen am| 31.10.2019
| Anfrage| Ansatz Canonical URLs diskutieren
| betrifft Codesystem | alle
| Autor der Anfrage | Tarik Idris
| Diskussion| Ziel: Gute Einfügung in FHIR Umgebung
| Entscheidung | Für V3 alle URNs durch URLs ersetzen
| Action Item | Für V3 alle URNs, die wir selbst unter Kontrolle haben, durch folgendes URLs mit Präfix http://ihe-d.de/CodeSystems/ + Name CodeSystem ersetzen ==> erledigt, warum in ArtDecor nicht sichtbar? ==> Angela, bei Fremdcodesystem nach entsprechenden URLs suchen ==> betrifft nur DICOM Codesysteme (in den Valuesets eventcode und formatCode) ==> Sven kümmert sich
| Bearbeitungsstand | für ValueSets erledigt (Angela)
| zuletzt bearbeitet am| 14.11.2021

|- valign="top"
| Anfrage ID| 7
| Anfrage eingegangen am| 31.10.2019
| Anfrage| Deutscher Implementation Guide für MHD Profile mit Verweis auf unsere Valuesets
| betrifft Codesystem | alle
| Autor der Anfrage | SH über Tarik
| Diskussion| 3.4.2020 Kosten stehen nicht im Verhältnis zum Nutzen, Codes werden weiterhin in ArtDecor gepflegt, In Implementation Guide der Deutschen Basisprofile gibt es schon Referenzen auf class und type Code
| Entscheidung | kein Implementation Guide für MHD, aber stattdessen Aufnahme der Codes in Simplifier, um höhere Aufmerksamkeit bei der FHIR Community zu bekommen, die Pflege der Codesysteme / Valuesets soll weiterhin über ArtDecor erfolgen. Nach Diskussion vom 03.04.2020 wird Beantragung des SimplifierKontos storniert
| Action Item | Simone um Referenz der Codes in Deutschen Basisprofilguideline bitten
| Bearbeitungsstand | als Issues in Gitlab eingetragen, im Simplifier sichtbar https://simplifier.net/basisprofil-de-r4/~resources?category=ValueSet&sortBy=RankScore_desc ==> (Angela)
| zuletzt bearbeitet am| 10.12.2020

|- valign="top"
| Anfrage ID| 19
| Anfrage eingegangen am| 10.07.2020
| Anfrage| Hintergrund: Verzeichnisdienst in der TI soll mit den Angaben der ambulanten Praxen zu befüllen. Dabei soll auch die Fachgruppe als Merkmal aufgenommen werden. Die gematik hat als Wertebereich für die Fachgruppe dabei das ValueSet „practiceSettingCode“ vorgesehen. In den Arztregistern der Kassenärztlichen Vereinigungen – woher die Daten stammen – ist die Fachgruppe hingegen nach einer anderen Systematik hinterlegt: https://applications.kbv.de/S_BAR2_ARZTNRFACHGRUPPE_V1.01.xhtm
Wir haben versucht eine Zuordnungstabelle zu schaffen, in der wir von unserer Systematik in den „practiceSettingCode“ übersetzen. Dabei ist uns aufgefallen, dass wir einige unserer Fachgruppen nicht valide zuordnen können. (z.B. 51 – Nervenheilkunde oder 69 – Kinder- und Jugendlichenpsychotherapeut). Das betrifft relativ wenige Fachgruppen, die allerdings teils sehr viele Ärzte enthalten. Um alle in der Versorgung vorkommenden Fachgruppen sauber abbilden zu können, würden wir das ValueSet „practiceSettingCode“ gerne um folgende Ausprägungen erweitern:
Bestehenden Code ALLG - „Allgemeinmedizin“ neu bezeichnen als „Facharzt für Allgemeinmedizin
(Hausarzt)“
2. Neuen Code einführen für „Praktischer Arzt/Arzt (Hausarzt)“. Vorschlag: PRAK
3. Neuen Code einführen für „Hausärztlich tätiger Internist (Hausarzt)“. Vorschlag: HINT
4. Bestehenden Codes ORTH neu bezeichnen als „Orthopädie und Unfallchirurgie“.
5. Neuen Code einführen für „Rheumatologie (Orthopädie)“. Vorschlag: ORRH.
6. Neuen Code einführen für „Infektiologie“. Vorschlag: INFK
7. Neuen Code einführen für „Kinder-Pneumologie“. Vorschlag: KIPN
8. Neuen Code einführen für „Nervenheilkunde/Neurologie und Psychiatrie“. Vorschlag: NERV
9. Neuen Code einführen für „Psychotherapeutisch tätiger Arzt“. Vorschlag: PTAR
10. Neuen Code einführen für „Psychologischer Psychotherapeut“. Vorschlag: PPTH
11.Neuen Code einführen für „Kinder- und Jugendlichen-Psychotherapeut“. Vorschlag: KJPP
| betrifft Codesystem | Practice Setting Code
| Autor der Anfrage | SR (KBV)
| Diskussion| Practice Setting Code gibt nur das Fachgebiet der Praxis an, die Qualifikation der Beschäftigten wird durch die Author speciality ausgedrückt. Daher gibt es bereits im Implementation Guide ein Mapping einiger Praxen nichtärztlicher Berufe auf diese Fachbereiche.
| Entscheidung | Implementation Guide wird um Mapping S_BAR2_ARZTNRFACHGRUPPE auf practice Setting Code ergänzt, KBV kann für Ihren speziellen Einsatzweck (nicht als XDS Metadatum) für bestimmte Praxen auch zwei Codes verwenden (z.B. Neurologie + Psychiatrie), Psychotherapie wird bei nichtärztlichen PracticeSettingCodes hinzugefügt, Bei Allgemeinmedizin wird Nutzungshinweis ", Streichen des Satzes: "In Deutschland ist die Weiterbildung zu einem entsprechenden Facharzt die Grundlage dafür, dass ein Arzt als "Hausarzt" tätig werden kann." Stattdessen Ergänzung Nutzungshinweis, dass Code auch für hausärztlich tätige Praxen genutzt werden kann (auch bei Innere Medizin).
| Action Item | Mapping prüfen und in Implementation Guide eintragen.
| Bearbeitungsstand | Mapping geprüft, Psychotherapie bei nichtärztlichen PracticeSettingCodes hinzugefügt, Eintrag in ImplementationGuide fehlt noch (Angela), Nutzungshinweise bei Innere Medizin und Allgemeinmedizin ergänzt.
| zuletzt bearbeitet am| 10.12.2020

|- valign="top"
| Anfrage ID| 29
| Anfrage eingegangen am| 22.01.2021
| Anfrage| Problem mit ArtDecor bei FHIR
| betrifft Codesystem | alle
| Autor der Anfrage | Axel
| Diskussion|
| Entscheidung |
| Action Item | Axel meldet Issues an Kai
| Bearbeitungsstand | in Bearbeitung
| zuletzt bearbeitet am| 22.01.2021

|- valign="top"
| Anfrage ID| 31
| Anfrage eingegangen am| 18.02.2021
| Anfrage| Für das eHDSI-Projekt soll ein neuer LOINC-Code beantragen, der in etwa unserem IHEXDSclassCode "BIL" entspricht. Können wir morgen in dem Arbeitstreffen kurz um konstruktive Kritik dazu bitten? Term Description: This concept summarizes all documents, the aim of which is to visually represent a situation using a clinical image. Examples are X-ray, MRI, CT images or photos of wounds, body parts or the like.
| betrifft Codesystem | ClassCode
| Autor der Anfrage | CG
| Diskussion|
| Entscheidung |
| Action Item |
| Bearbeitungsstand | offen
| zuletzt bearbeitet am|

|- valign="top"
| Anfrage ID| 33
| Anfrage eingegangen am| 22.12.2021
| Anfrage| Bei der Umsetzung der ePA durch die Konsortien, wie auch bei weiteren angedachten digitalen Anwendungen, zeigen sich nun einige Schwierigkeiten bei der Darstellung von Psychotherapeut*innen, die sich durch die erfolgte Einordnung im IHE ergeben. Mit den bisher vorgenommenen Änderungen sind zwar alle Berufsbezeichnungen von Psychotherapeut*innen korrekt abbildbar, allerdings lässt die hierarchische Einordnung keine Abbildung als approbierter Heilberuf zu. Um die Qualifikationen der Psychotherapeut*innen in den verschiedenen Anwendungen der TI adäquat abbilden zu können, ist daher aus unserer Sicht eine weitere Anpassung in den ArtDecor Value Sets erforderlich.
| betrifft Codesystem | AuthorSpecialty
| Autor der Anfrage | BPtK
| Diskussion|
Potentieller Ansatz:
"Umhängen" der versch. Codes (s.o.) in eine neu zu schaffende Gruppe für "Psychotherapie" (Code z.B. 189 mit Inhalt, 76, 82, 183, 184, 185), eine weitere neue Gruppe "Psychologische Analyse, Beratung, Therapie (ohne Psychotherapeuten)" (Code z.B. 190, beinhaltet 75, 77, 78, 79, 80, 81, 83, 84, 85)
* 74
** 189
*** 76
*** 82
*** 183
**** 184
**** 185
** 190
*** 75
*** 77
*** 78
*** 79
*** 80
*** 81
*** 83
*** 84
*** 85

Betroffenen Systemen und Use Cases
* Suche KIM-Teilnehmer
** Kammer/HBA-Herausgeber
*** z.B. Landesärztekammern und BPtk, prüfen ob der Gruppen-Code 74 verwendet werden, wahrscheinlich werden eher die konkreten Codes verwendet
** Verzeichnisdienst
*** VZD macht keine Umsetzung von Gruppe zu konkreten Codes, d.h. kein Änderungsbedarf
** AIS / KIS / weitere Primärsysteme
*** Könnten ggf. Umsetzungen von Gruppe auf konkrete Codes im Rahmen von Suchen durchführen. Falls dies der Fall ist, würden nach der Änderung die selben Antworten kommen - sie hätten aber die Option detaillierter über codes 189 vs. 190 zu suchen (Annahme: Update-Fähigkeit)
* ePA-Dokumentenmetadaten: authorSpeciality
** ePA-Aktensystem
*** Auch im Aktensystem wird keine Umsetzung von Gruppe zu konkreten Codes gemacht. Im ePA-Aktensystem sind in den Metadaten für Dokumente ggf. auch Gruppen wie 74 als authorSpeciality hinterlegt. Die bestehenden Daten können nicht trivial System-weit verändert werden. Dies ist aber im jetzigen Vorschlag auch nicht mehr nötig, da der code weiterhin valide wäre und die selbe Semantik hat. Update der DM-spec und ValueSets gematik-seitig notwendig.
** ePA-FdV
*** Kann im AS nicht danach suchen, aber auf dem Gerät danach filtern. Anpassung der ValueSets nötig. Könnten ggf. Umsetzungen von Gruppe auf konkrete Codes im Rahmen von Suchen durchführen - aber sehr unwahrscheinlich. Falls dies der Fall ist, würden nach der Änderung die selben Antworten kommen - sie hätten aber die Option detaillierter über codes 189 vs. 190 zu suchen.
** Primärsystem
*** Können Dokumente mit den Codes kennzeichnen. Gff. könnten lokale Mappings anzupassen sein (z.B. von LDAP-Gruppen auf authorSpecialty) - eher unwahrscheinlich. Mapping könnte dann durch Unterscheidung zwischen 189 und 190 verbessert werden. Anpassung der ValueSets nötig. Könnten ggf. Umsetzungen von Gruppe auf konkrete Codes im Rahmen von Suchen durchführen. Falls dies der Fall ist, würden nach der Änderung die selben Antworten kommen - sie hätten aber die Option detaillierter über codes 189 vs. 190 zu suchen.

* XDS Affinity Domains (nicht-ePA)
** Document Source
*** wie bei ePA
** Document Registry
*** wie bei ePA, auch wenn Updates einfacher zu realisieren sind
** Document Consumer
*** Suche nach AuthorSpecialty möglich, Mapping Thematik wie bei ePA

* Auswirkungen auf ISIK
Umsetzung nach Wunsch BPtK

BPtK müsste eigenes Codessystem auf jeden Fall selbst pflegen
Impact auf andere Systeme müssen noch genau analysiert werden

| Entscheidung | Wenn BPtK eigenes Codesystem erstellt pflegen wir es ein
| Action Item | BPtK beantragt OID
| Bearbeitungsstand | in Bearbeitung
| zuletzt bearbeitet am| 18.03.2022

|- valign="top"

| Anfrage ID| 37
| Anfrage eingegangen am| 04.03.2022
| Anfrage| Displaynames Gender konform gestalten
| betrifft Codesystem | v.a. author role, authorspecialty
| Autor der Anfrage | Gematik
| Diskussion| Displaynames sollten nicht verpflichtend bei Anzeige sein, entscheidend ist der Code in Kombination mit Codesystem, Impact Analyse: Gendern der Displaynames ist vor allem Aufwand für uns, das Gendern externer Codesystem muss durch andere Nutzer erfolgen;
| Entscheidung | Gendern wird prinzipiell befürwortet, Ziel sind angepasste Displaynames für das nächste Release, Folgende Texten sollten geändert werden: authorRole, authorSpecialty, healthcareFacilityTypeCode, practiceSetting, typeCode
| Action Item | Änderung wird befürwortet, wie und wann wird noch festgelegt
| Bearbeitungsstand | in Bearbeitung
| zuletzt bearbeitet am| 29.04.2022
|- valign="top"

| Anfrage ID| 38
| Anfrage eingegangen am| 25.3.2022
| Anfrage| KDL Mapping kontrollieren
| betrifft Codesystem | class code, type code,
| Autor der Anfrage | DVMD
| Diskussion|
| Entscheidung | Das Mapping wird bis in vier Wochen von Raik, Tarik, Arnold und eventuell Sven gereviewed. Angela teilt das Mappingdokument auf ihrem onedrive.
| Action Item | Review bis in vier Wochen
| Bearbeitungsstand | in Bearbeitung
| zuletzt bearbeitet am| 29.04.2022
|- valign="top"

| Anfrage ID| 40
| Anfrage eingegangen am| 28.04.2022
| Anfrage| passender eventCode bei stationärer Wiederaufnahme nach Unterbrechung
| betrifft Codesystem | eventCode
| Autor der Anfrage | AM (UKHD)
| Diskussion|
| Entscheidung | E216 Wiederaufnahme vollstationär nach kurzzeitiger Unterbrechung wird hinzugefügt
| Action Item |
| Bearbeitungsstand | in ArtDecor eingetragen
| zuletzt bearbeitet am| 29.04.2022
|- valign="top"

| Anfrage ID| 42
| Anfrage eingegangen am| 27.05.2022
| Anfrage|neue Dokumentenformate für gematik "urn:gematik:ig:DMP-Rheuma:v1
eDMP" displayName: "Rheumatoide Arthritis (gematik)"
| betrifft Codesystem | formatCode
| Autor der Anfrage | gematik
| Diskussion|
| Entscheidung |Major Revisions werden aufgenommen
| Action Item |
| Bearbeitungsstand | in Art Decor eingetragen
| zuletzt bearbeitet am| 27.05.2022
|- valign="top"

|- valign="top"
| Anfrage ID| 43
| Anfrage eingegangen am| 10.06.2022
| Anfrage| Im Zuge des KDL-Mapping-Reviews waren sich die Reviewer einig, dass eine Klarstellung der Beschreibung des Befundberichts sinnvoll wäre, um Befundberichte besser von Durchführungsprotokollen abzugrenzen.
| betrifft Codesystem | classCode
| Autor der Anfrage | Raik
| Diskussion|
| Entscheidung |
| Action Item |
| Bearbeitungsstand | in Bearbeitung
| zuletzt bearbeitet am| 10.06.2022

|- valign="top"
| Anfrage ID| 44
| Anfrage eingegangen am| 22.07.2022
| Anfrage| Versionen in FormatCode Display names aufnehmen, da einige Hersteller die FormatCodes an Hand von Displaynames suchen
| betrifft Codesystem | formatCode
| Autor der Anfrage | Raik
| Diskussion|
| Entscheidung | Display Names werden geändert
| Action Item |
| Bearbeitungsstand | in Bearbeitung
| zuletzt bearbeitet am| 22.07.2022

|}

'''Tabelle abgeschlossene Änderungsanfragen'''

:{|class="hl7table sortable"
|-
! align="left" | Anfrage ID
! align="left" | Anfrage eingegangen am
! align="left" | Anfrage
! align="center" | betrifft Codesystem
! align="center" | Autor der Anfrage
! align="center" | Diskussion
! align="center" | Entscheidung
! align="center" | Action Item
! align="center" | Bearbeitungsstand
! align="center" | zuletzt bearbeitet am

|- valign="top"
| Anfrage ID| 1
| Anfrage eingegangen am|
| Anfrage| wir sind hier gerade im Kontext des AOK Gesundheitsnetzwerks (GeN-Flavour) auf ein kleines Problem mit der Nutzung der von HL7 und IHE Deutschland definierten classCodes und typeCodes gelaufen:
Einige der angebundenen Häuser haben ihre IHE XDS Lösungen mehr oder minder extra für das Gesundheitsnetzwerk neu beschafft und setzen ausschließlich die von IHE-D definierten Codes um, da wir dies so vorgegeben hatten
Andere Häuser haben schon seit Längerem XDS Lösungen und/oder orientieren sich ausschließlich an den IHE Frameworks. Hier kommen die vor allem von IHE PCC und IHE LAB festgesetzen classCodes und typeCodes (zum Beispiel für bestimmte Labordokumente) zum Einsatz.
Wir haben somit eine Mischung aus IHE-D-Codes und IHE-PCC/LAB-LOINC-Codes. Inhaltlich/semantisch überschneidet sich das recht munter. Fragen:
Gibt es irgendwo eine Mapping-Tabelle, wie Dokumente gemäß der von IHE PCC und IHE LAB definierten CDA Dokumentenschablonen mit den IHE-D-Metadaten auszuzeichnen sind?
Macht es vielleicht Sinn, ein weiteres Value Set zu definieren (und über das IOP-Forum oder Vesta als nationale Empfehlung zu positionieren), das sowohl die IHE-D Codes als auch die von IHE International für dort definierte Dokumente vorgegebenen class- und typeCodes enthält?
Folgende Codes werden vermisst:
im AOK-Projekt haben wir in Ergänzung zu den IHE-D-Codes die folgenden LOINC-Codes als typeCodes verwendet:
77603-9: Bundeseinheitlicher Medikationsplan – Die explizite Typisierung wurde vorgenommen, damit Dokumente dieses Typs an geeigneter Stelle zwischen Document Source und Document Repository automatisch vorverarbeitet werden (Barcode erkennen, prüfen und parsen)
11502-2: Laboratory Report – Dieser Code ist von IHE PCC für aggregierte Laborbefunde vorgegeben und sollte auch in Deutschland alternativ zu LAB+BEFU nutzbar sein
26436-6: Laboratory Studies – Dieser Code ist von IHE PCC für Laborbefunde vorgegeben und sollte auch in Deutschland alternativ zu LAB+BEFU nutzbar sein
Verschiedene Ausprägungen des Entlassbriefs, um hier anhand der typeCodes eine bessere Sortierung für den Patienten zu ermöglichen:
11490-0: Ärztlicher Entlassbrief
34105-7: Krankenhausentlassbrief (vorläufige/gekürzte Fassung für den Patienten bei der Entlassung)
18842-5: Finales Krankenhausentlassbrief
57059-8: Mutterpass – Das ganze Thema „Schwangerschaft und Geburt“ war mit den IHE-D Codes nur unzureichend abbildbar. Beispielsweise haben wir auch Geburtsbericht und Stillprotokoll nicht vernünftig differenzieren können.
Verschiedene Spezialisierungen von Laborbefunden – Diese werden u. a. auch für Anfragen nach On-Demand-Dokumenten benötigt, um so z. B. die verfügbaren Werte eines Blutbilds aus verschiedenen Einzellaboren zusammenstellen zu können. Im GeN-Projekt brauchen wir das, da die ODD Document Sources für Laborwerte FHIR Strores sind.
58410-2: Vollständiges Blutbild
55429-5: Kleines Blutbild
| betrifft Codesystem | class codes, type codes
| Autor der Anfrage | JC
| Diskussion| Einige IHE Profile nutzen den LOINC Code im CDA als ClinicalDocument/code. Es wird nicht vorgeschrieben, dass der ClinicalDocument/code als XDS-TypeCode verwendet wird. Die Empfehlung spricht eher von einem Mapping (siehe PCC, Vol. 2, S. 45) The typeCode should be mapped from the ClinicalDocument/code element to a set of document type codes configured in the affinity domain. One suggested coding system to use for typeCode is LOINC, in which case the mapping step can be omitted. ==> Empfehlung ClinicalDocument/code eher als eventCode nutzen. Auswahl IHE-D class und type Codes basierend auf LOINC Codes, original LOINC Code als EventCode hinzufügen. Konsistent mit bisherigem Vorgehen bei KDL. ==> Antragsteller einverstanden
Mutterpass kann mit ClassCode Medizinischer Ausweis und TypeCode Schwangerschafts- und Geburtsverlauf gut abgebildet werden. (In der KDL gibt es einen Code für "Mutterpass (Kopie)" ==> die Ergänzung Kopie ist historisch gewachsen, sollte gestrichen werden, da alle eingescannten Dokumente auch nur Kopien sind. Geburtsbericht und Stillprotokoll sind auch in der KDL nicht unterscheidbar. Stillprotokoll kann mit ClassCode Durchführungsprotokoll und typeCode "Schwangerschafts - und Geburtsverlauf" dokumentiert werden, da Stillprotokolle vor allem während der ersten Tage nach der Geburt angelegt werden. Um diese Zuordnung eindeutig zu klären wird "Stillprotokoll" als Beispiel bei dem entsprechenden typeCode hinterlegt.

| Entscheidung |"Stillprotokoll" wird als Beispiel bei typeCode "Schwangerschafts- und Geburtsverlauf" eingefügt, Scope der ValueSets ist es nicht, möglichst granulare typeCodes zu definieren, sondern die Dokumente an Hand der Kombination von vielen verschiedenen Metadaten beschreiben zu können und die Dokumente möglichst einfach an Hand der Metadaten wiederauffindbar zu machen. Ob das Dokument von einem Arzt oder einem Patienten geschrieben ist, kann man an der AuthorRole erkennen. Zudem hat man noch die Möglichkeit in der eventCodeList anzugeben, dass dies ein vom Patienten mitgebrachtes Dokument ist.
| Action Item |"Stillprotokoll" als Beispiel bei typeCode "Schwangerschafts- und Geburtsverlauf" einfügen ==> Angela; Scope der Granularität der XDS Metadaten genauer beschreiben ==> Sven; in Wiki FAQ Fragen zu Valuesets ergänzen (hinter Einleitung) ==> Angela
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am|21.2.2020

|- valign="top"
| Anfrage ID| 2
| Anfrage eingegangen am|
| Anfrage| es scheint in Deutschland Bestrebungen zu geben, Unfallchirurgie mit der Orthopädie zusammenzulegen.
Ab August 2019 wird es im UKD nur noch die „Klinik für Orthopädie und Unfallchirurgie“ geben.
Ist die Einführung einer weiteren Fachabteilung im DocumentEntry.practiseSettingCode geplant?
In DocumentEntry.authorSpecialty findet sie sich:
Code 512 Anzeigename FA Orthopädie und Unfallchirurgie
| betrifft Codesystem | practiceSettingCode
| Autor der Anfrage | SB
| Diskussion| evtl. practiceSettingCode Chirurgie verwenden, deckt beides ab
| Entscheidung |
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 29.11.2019

|- valign="top"
| Anfrage ID| 3
| Anfrage eingegangen am|
| Anfrage| wie letztens angekündigt, möchten wir neben dem Notfalldatensatz auch den „Datensatz für persönliche Erklärungen“ (Ablageorte für Einwilligung Notfalldatensatz, Organspendeerklärung, Vorsorgevollmacht sowie Patientenverfügung) in der Elektronischen Patientenakte speichern lassen können.
Dazu möchten wir das Value Set für XDS-Metadatenattribut formatCode um den folgenden Wert erweitern: urn:gematik:ig:DatensatzPersoenlicheErklaerungen:r3.1
Als Anzeigename sollte „Datensatz für persönliche Erklärungen (gematik)“ verwendet werden. Das bisherige Code-System „Deutsche Dokumentenformate“ (1.3.6.1.4.1.19376.3.276.1.5.6) passt hierfür sicherlich ganz gut als Quellsystem.
| betrifft Codesystem | formatCode
| Autor der Anfrage | RK
| Diskussion| keine Einwände
| Entscheidung | wir fügen Code hinzu
| Action Item | in ArtDecor eintragen
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am|13.12.2019

|- valign="top"
| Anfrage ID| 5
| Anfrage eingegangen am| 31.10.2019
| Anfrage| Freischaltung der FHIR Schnittstelle in ArtDecor
| betrifft Codesystem | alle
| Autor der Anfrage | SH über Tarik Idris
| Diskussion|
| Entscheidung | wird gemacht
| Action Item | Tarik: FHIR Schnittstelle in ArtDecor freischalten
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 15.11.2019

|- valign="top"
| Anfrage ID| 8
| Anfrage eingegangen am| 15.11.2019
| Anfrage| Vorgehensweise für V3 auf eigener WikiSeite beschreiben
| betrifft Codesystem | alle
| Autor der Anfrage | SL
| Diskussion| befürwortet
| Entscheidung | befürwortet
| Action Item | Anlegen neue Seite im HL7 Wiki ==> Angela, Ziele ==> Angela, allgemeine Weiterentwicklung als Ziel hinzufügen
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 13.12.2019

|- valign="top"
| Anfrage ID| 9
| Anfrage eingegangen am| 13.12.2019
| Anfrage| Bericht Treffen BVITG, Interopforum, Gematik, Vorabstimmung EPA Version 1.2.2022
| betrifft Codesystem | alle
| Autor der Anfrage | TI
| Diskussion| Bericht: Gematik plant zentralen Server für Bereitstellung der Gematik ValueSets (die fast identisch sind mit unseren Value Sets) ValueSets sollen per SVS abgerufen werden können, Governance soll bei IHE Gruppe bleiben, Registry soll prüfen, ob bestimmte Kombination von Codes erlaubt ist (sieht IHE nicht vor), bei FormatCodes sollen zwei ValueSets gebildet werden: VS1 umfasst alle FormatCode, VS2 umfasst FormatCodes für Dokumente, die nur einmal vorhanden sein dürfen (z.B. Impfpass)
| Entscheidung | über konstruktive Zusammenarbeit wird sich gefreut
| Action Item | keine
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 13.12.2019

|- valign="top"
| Anfrage ID| 10
| Anfrage eingegangen am| 12.01.2020
| Anfrage| diese Woche ist ja die Dokument Ontology bei LOINC erschienen. Sind unsere Value Sets bereits darauf abgebildet? Wir hatten ja bereits einen ersten Vorstoß Richtung SNOMED gewagt. Wir sollten die LOINC-Codes (Anzahl: 11096) vervollständigen und ggf mit dem MDM (Münster) abgleichen, damit es international sauber bleibt.
https://loinc.org/file-access/download-id/8994/
| betrifft Codesystem | alle
| Autor der Anfrage | ST
| Diskussion|
| Entscheidung | Gemeinsame Strategietelko zur Zusammenführung LOINC, SNOMED CT, XDT, QMS, KDL deutsche XDS Value Sets am 28.5.2020 10-12 Uhr geplant
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 24.04.2020

|- valign="top"
| Anfrage ID| 11
| Anfrage eingegangen am| 07.02.2020
| Anfrage| Zusammenarbeit KBV
| betrifft Codesystem | alle, v.a. format Code
| Autor der Anfrage | RK
| Diskussion| Den MIOs müssen XDS Metadaten zugeordnet werden, v.a. formatCodes
| Entscheidung | Arbeitsgruppe bietet proaktiv Hilfe bzgl. der Metadaten bei KBV an
| Action Item | Mail an Vorstand ==> Mail an KBV (H. Tenkow)
| Bearbeitungsstand | Mail an Vorstand gesendet
| zuletzt bearbeitet am| 07.02.2020

|- valign="top"
| Anfrage ID| 12
| Anfrage eingegangen am| 21.02.2020
| Anfrage| Aufnahme neuer formatCodes für ePA Stufe 2.0, urn:gematik:ig:Impfausweis:r4.0, urn:gematik:ig:Mutterpass:r4.0, urn:gematik:ig:Kinderuntersuchungsheft:r4.0, urn:gematik:ig:Zahnbonusheft:r4.0
| betrifft Codesystem | format Code
| Autor der Anfrage | RK
| Diskussion| keine Einwände
| Entscheidung | werden aufgenommen
| Action Item | Aufnahme in ArtDecor ==> Angela
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 24.02.2020

|- valign="top"
| Anfrage ID| 13
| Anfrage eingegangen am| 06.03.2020
| Anfrage| Übersetzung der Metadatenbezeichnungen ins Englische
| betrifft Codesystem | format Code
| Autor der Anfrage | SL
| Diskussion| ValueSets sind nur für Deutschland, jeder Dokumentierende sollte über ausreichende Deutschkenntisse verfügen
| Entscheidung | abgelehnt
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 06.03.2020
|- valign="top"

|- valign="top"
| Anfrage ID| 14
| Anfrage eingegangen am| 24.04.2020
| Anfrage| Neuer FormatCode für eRezept (Daten elektronischer Verordnung) der Gematik
| betrifft Codesystem | format Code
| Autor der Anfrage | RK
| Diskussion| evtl. besser drei Dokumente definieren: Rezept, Abgabe (evtl. von anderer Firma), Abrechnung, komplette Spezifikation darauf Basis von CDA liegt vor, hier geht es nur um den nicht signierten Teil, der in der EPA gespeichert wird. MimeType application/fHir+xml, evtl. zweiter FormatCode für Dokument inkl.Signatur
| Entscheidung | urn:gematik:ig:VerordnungsdatensatzMedikation:r4.0
| Action Item | in Art Decor eintragen
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 26.06.2020

|- valign="top"

| Anfrage ID| 15
| Anfrage eingegangen am| 14.05.2020
| Anfrage| Kommentierung EPA XDS Metadaten
| betrifft Codesystem | fast alle
| Autor der Anfrage | TI
| Diskussion|
| Entscheidung | Es werden folgende Kommentare an gematik gesendet: bei Vertraulichkeitseinschätzung des Versicherten sollte das passende Codesystem verwendet werden, EGA sollte als EventCode aufgenommen werden nicht als ReferenceID, ein Copy Paste Fehler bei FormatCode
| Action Item | Tarik==> Kommentar an gematik
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 18.05.2020

|- valign="top"
| Anfrage ID| 16
| Anfrage eingegangen am| 14.05.2020
| Anfrage| Passender Type Code für Genetische Befunde?; Es gibt Befunde aus dem molekulargenetischen Labor der medizinischen Klinik. zytopathologische Untersuchungen aus der Pathologie, Zytogenetische Befunde / Vererbungsschema aus der Humangenetik und Gendiagnostik von der Frauenklinik.
| betrifft Codesystem | TypeCode
| Autor der Anfrage | VK
| Diskussion|
| Entscheidung | wird als Beispiel in pathologische Befunde aufgenommen
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 26.06.2020
|- valign="top"

| Anfrage ID| 17
| Anfrage eingegangen am| 14.05.2020
| Anfrage| Am UKHD gibt es ein Zentrum für Seltene Erkrankungen. Dort werden Patienten jeglichen Alters behandelt.
| betrifft Codesystem | PracticeSettingCode
| Autor der Anfrage | VK
| Diskussion|
| Entscheidung | Es gibt einen neuen Code interdisziplinäre Zusammenarbeit. INTZ, unter dem alle interdisziplinären Fachrichtungen zusammengefasst werden (INTO, INTS, Transplantationszentrum), Zusätzlich Code SELT für seltene Erkrankungen
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 26.06.2020

|- valign="top"
| Anfrage ID| 18
| Anfrage eingegangen am| 26.06.2020
| Anfrage| Code für Erfassung Fall- /Bewegungsdaten
| betrifft Codesystem | Class Code, Type Code
| Autor der Anfrage | AM
| Diskussion| evtl. ClassCode administrative Dokumente oder Durchführungsprotokoll hängt vom Use Case ab, Type Code Einweisungs und Aufnahmedokumente oder administrative Checklisten Alles nicht optimal, aber keine klassischen Patientendokumente
| Entscheidung | keine zusätzlichen Codes
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 26.06.2020

|- valign="top"
| Anfrage ID| 20
| Anfrage eingegangen am| 10.07.2020
| Anfrage| Der Bedarf stammt aus der Festlegung der elektronischen Patientenakte gemäß PDSG, Versicherten die Möglichkeit zu geben, auf „Daten zu Befunden, Diagnosen, durchgeführten und geplanten Therapiemaßnahmen, Früherkennungsuntersuchungen, zu Behandlungsberichten und sonstige untersuchungs- und behandlungsbezogene medizinische Informationen“ (§ 341 Abs. 2 Nr. 1a PDSG) Zugriffsberechtigungen auszusprechen. Die entsprechenden Dokumente sollen danach kategorisiert werden, ob sie aus einer der folgenden Fachgebiete/Institutionstypen entstammen:

Unterkategorien von 1a - Code

Hausarzt/ Hausärztin - practitioner

Krankenhaus - hospital

Labor und Humangenetik - laboratory

Physiotherapeuten - physiotherapy

Psychotherapeuten - psychotherapy

Dermatologie - dermatology

Urologie/Gynäkologie - gynaecology_urology

Zahnheilkunde und Mund-Kiefer-Gesichtschirurgie - dentistry_oms

Weitere Fachärzte/ Fachärztinnen - other_medical

Weitere nicht-ärztliche Berufe - other_non_medical

Für diesen ValueSet wäre es für die Spezifikationen der elektronischen Patientenakte und den Foldern, zu denen die entsprechend kategorisierten Dokumente gehören, von Vorteil, eine geeignete Codesystem-OID anführen zu können. Auf solche Dokumentenkategorien erteilen Versicherte Zugriffsrechte auf die ePA. Diese Kategorien sollen exklusiv Dokumenten zugeordnet werden können.

Zusätzlich soll für den Code „ega“ eine Kategorie von Dokumenten bezeichnen, für die gilt: Die Kategorie wird für Dokumente vergeben, die aus einer bestehenden eGA (gemäß Paragraph §41 Absatz 2 Satz 7 PDSG, bzw. Paragraph 68 SGB V) importiert worden sind.

Für diesen Code soll ein Code-System "Sonstige Berechtigungen ePA" genutzt werden.
| betrifft Codesystem | Anfrage neues Codesystem / ValueSet für Folder
| Autor der Anfrage | JG (Gematik)
| Diskussion| Überschneidungen bei Konzepten, keine Definitionen, Kategorien sollen zur Zugriffsberechtigung in der ePA verwendet werden, sie sollen Folder der ePA beschreiben es wäre sinnvoll gewesen, IHE Deutschland in die Abstimmung des Codesystems einzubeziehen
| Entscheidung |Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte
| Action Item | Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte
| Bearbeitungsstand | erledigt, Gematik hat OIDs für ValueSet (1.2.276.0.76.11.466, 1.2.276.0.76.11.467) und Codesystems (1.2.276.0.76.5.511, 1.2.276.0.76.5.512, 1.2.276.0.76.5.513) beantragt, reservierte OID 1.3.6.1.4.1.19376.3.276.1.5.17 wird nicht mehr benötigt
| zuletzt bearbeitet am| 18.09.2020

|- valign="top"
| Anfrage ID| 21
| Anfrage eingegangen am| 31.07.2020
| Anfrage| In Absprache mit der KBV ist es für die Verarbeitung von Medizinischen Informationsobjekten in der ePA für die beteiligten Komponenten nötig, die folgenden FormatCodes verarbeiten zu können:

"urn:gematik:ig:KinderuntersuchungsheftUntersuchungen:r4.0"
"urn:gematik:ig:KinderuntersuchungsheftTeilnahmekarte:r4.0"
"urn:gematik:ig:KinderuntersuchungsheftNotizen:r4.0"
Für diesen Zweck möchten wir Sie bitten, diese Werte in die IHE-ValueSet-Arbeitsgruppe zur Diskussion einer Aufnahme in die Deutschen Dokumentenformate des FormatCode-ValueSets einzubringen.

Als Anzeigename schlage ich vor:

· Untersuchungen Kinderuntersuchungsheft

· Teilnahmekarte Kinderuntersuchungsheft

· Notizen Kinderuntersuchungsheft
| betrifft Codesystem | FormatCodes
| Autor der Anfrage | Gematik
| Diskussion|
| Entscheidung | wird aufgenommen
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 18.09.2020

|- valign="top"
| Anfrage ID| 22
| Anfrage eingegangen am| 16.09.2020
| Anfrage| Patientenverfügung als Beispiel für administratives Dokument aufnehmen
| betrifft Codesystem | classCode
| Autor der Anfrage | VB (Uniklinik HD)
| Diskussion| entspricht Mapping in KDL
| Entscheidung | wird als Beispiel hinzugefügt
| Action Item | in ArtDecor eintragen
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 18.09.2020

|- valign="top"
| Anfrage ID| 23
| Anfrage eingegangen am| 18.09.2020
| Anfrage| TypeCode für mikroskopische Bilder
| betrifft Codesystem | typeCode
| Autor der Anfrage | VB (Uniklinik HD)
| Diskussion| wenn Ergebnis Mikrobiologie oder Pathologie, dann diesen Code verwenden, ansonsten BILD
| Entscheidung | wenn Ergebnis Mikrobiologie (MKRO) oder Pathologie (PATH) dann diesen Code verwenden, ansonsten BILD
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 18.09.2020

|- valign="top"
| Anfrage ID| 24
| Anfrage eingegangen am| 5.11.2020
| Anfrage| * Beruf ‚Psychotherapeut*in‘: dieser Beruf wurde mit dem Psychotherapeutenausbildungsreformgesetz (2019) geschaffen und ist wirksam ab 01.09.2020. Der neue Beruf des ‚Psychotherapeut*in‘ hat Fachgebiete.
Die Berufe PP und KJP wird es weiterhin daneben geben, diese haben aber keine Fachgebiete, und sind selbst keine Fachgebiete sondern jeweils eigenständige Berufe.
HL7 bildet die Berufsgruppen PP (2 L 82) und KJP (2-L 76) falsch ab, nämlich als Spezialisierung, nicht als Grundberufe.
Die Fachgebiete des neuen Berufs ‚Psychotherapeut*in‘ sind im HL7 nicht abgebildet.
| betrifft Codesystem | authorspecialty
| Autor der Anfrage | BPtK
| Diskussion|
| Entscheidung |Neue Berufsgruppen werden in Authorspecialty aufgenommen.
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 10.12.2020

|- valign="top"
| Anfrage ID| 25
| Anfrage eingegangen am| 5.11.2020
| Anfrage| Übernahme der Facharzt- und Schwerpunktscodes aus dem Codesystem der BAEK, da relevante Facharzt - und Schwerpunktscodes fehlen.
| betrifft Codesystem | authorspecialty
| Autor der Anfrage | BAEK
| Diskussion| Bisher wurden die Facharzt und Schwerpunktcodes aus dem Codesystem der KBV übernommen. Wichtig ist, dass uns eine zuverlässig gepflegte Liste von Codes zu Verfügung steht. FW (Fachliche Weiterbildung) und FK Codes sind nicht notwendig.
| Entscheidung |Die BAeK stellt uns die Codes möglichst als CSV oder Excelfile zur Verfügung. Die BAek übernimmt die Pflege und Bereitstellung der Codes, so dass sie von uns in ArtDecor eingetragen werden können. Auch TG Codes, BAEK beantragt OID
| Action Item | Konzept zur Pflege, Mapping BAEK Codes auf practice Setting Codes wird auch bei KBV veröffentlicht (als FHIR concept map)
| Bearbeitungsstand |erledigt
| zuletzt bearbeitet am| 01.02.2021

|- valign="top"
| Anfrage ID| 26
| Anfrage eingegangen am| 13.11.2020
| Anfrage| Prozeduren zu Fertilitätsbehandlung in Gebu aufnehmen?
| betrifft Codesystem | typeCode
| Autor der Anfrage | UKHD
| Diskussion|
| Entscheidung |nein
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 01.02.2020

|- valign="top"
| Anfrage ID| 27
| Anfrage eingegangen am| 13.11.2020
| Anfrage| Typecode für Erfassung der Dauer der Gebärdendolmetscherunterstützung
| betrifft Codesystem | typeCode
| Autor der Anfrage | UKHD
| Diskussion|
| Entscheidung |Abrechnungsdokumente
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 01.02.2020

|- valign="top"
| Anfrage ID| 28
| Anfrage eingegangen am| 10.12.2020
| Anfrage| Classcode für Diagnosenübersichtsblatt
| betrifft Codesystem | classCode
| Autor der Anfrage | UKHD
| Diskussion|
| Entscheidung |hängt vom UseCase ab
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 01.02.2020
|- valign="top"
| Anfrage ID| 30
| Anfrage eingegangen am| 04.02.2021
| Anfrage| Nutzung von XDS Value Sets für den digitalen Austausch medizinischer Unterlagen mit den Medizinischen Diensten.
| betrifft Codesystem | alle
| Autor der Anfrage | AMue
| Diskussion|
| Entscheidung |
| Action Item | Annett lädt Herrn Dr. Eckardt vom MD Westfalen-Lippe zur nächsten Telko ein
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am|

|- valign="top"
| Anfrage ID| 32
| Anfrage eingegangen am| 09.2021
| Anfrage| Aufnahme von Pflegefachmann/-fachfrau, da neuer Ausbildungsberuf
| betrifft Codesystem | Authorspecialty
| Autor der Anfrage | FP
| Diskussion| Der BPflV hat auf Nachfrage per mail bestätigt, dass folgende Beruf im ValueSet fehlen: Pflegefachmann/-frau, Fachgesundheits- und krankenpfleger für Onkologie, Fachgesundheits- und krankenpfleger für Psychiatrie. Desweiteren sollten alle Fachkrankenpflegeberufsbezeichnungen in Fachgesundheits- und krankenpflegerbezeichnungen umbenannt.
| Entscheidung | Konzepte werden wie vorgeschlagen ergänzt, bzw. - bezeichnungen geändert.
| Action Item | Eröffnung version 4 draft des Value Sets ==> Anpassungen in ArtDecor erfolgt
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 15.10.2021

|- valign="top"
| Anfrage ID| 34
| Anfrage eingegangen am| 22.12.2021
| Anfrage| Laut Implementierungsleitfaden ePA Version 1.8.0 vom 2. Juni 2021 (S. 99/100) soll der NFD mit den folgenden IHE-XDS Metadaten versehen werden:
• IHE-XDS classCode = AUS
• IHE-XDS typeCode = BESC
Dies widerspricht den Kodiervorgaben von IHE Deutschland Dort ist festgelegt, dass der Notfalldatensatz mit typeCode PATD dokumentiert werden soll.
PATD Patienteneigene Dokumente Dokumententypen Dokumente, welche der Patient zu seinem Kontakt in der Gesundheitseinrichtung mitbringt, die aber nicht in unmittelbarem Zusammenhang mit dem aktuellen Kontakt stehen müssen. Sowie Dokumente, in denen das mitgebrachte Patienteneigentum festgehalten wird.
Beispiele: Ausweise, Vorsorgevollmacht, Patientenverfügung, Wertgegenständeverwaltung, , Patiententagebuch

| betrifft Codesystem | TypeCode
| Autor der Anfrage | AMue
| Diskussion|
| Entscheidung | Missverständnis konnte geklärt werden
| Action Item | keine
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am|

|- valign="top"
| Anfrage ID| 35
| Anfrage eingegangen am| 14.02.2022
| Anfrage| Die gematik möchte wieder Aktualisierungen für MIO-Versionen zu den Format Codes einbringen.

neu (die DisplayNames sind dieselben der Vorgänger)

· urn:gematik:ig:KinderuntersuchungsheftUntersuchungen:v1.0.1

· urn:gematik:ig:KinderuntersuchungsheftTeilnahmekarte:v1.0.1

· urn:gematik:ig:KinderuntersuchungsheftNotizen:v1.0.1

· urn:gematik:ig:Mutterpass:v1.1.0

· urn:gematik:ig:VerordnungsdatensatzMedikation:v1.0.2

deprecated/obsolet

· urn:gematik:ig:VerordnungsdatensatzMedikation:r4.0

· urn:gematik:ig:Kinderuntersuchungsheft:v1.0.0

| betrifft Codesystem | FormatCode
| Autor der Anfrage | RK
| Diskussion| Versionsänderungen auf 3. Ebene (Patch) sollten in Zukunft keine Änderungen am Formatcode verursachen
| Entscheidung | Änderung wird diesmal zugestimmt, RK soll aber MIOs/Gematik darum bitten, in Zukunft nur neue Formatcodes zu beantragen, wenn es mindestens minor changes an der der Spezifikation gibt.
| Action Item | Art-Decor anpassen, RK Kommunikation des Wunschs der AG an die Gematik
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 18.03.2022

|- valign="top"
| Anfrage ID| 36
| Anfrage eingegangen am| 18.02.2022
| Anfrage| Pflege des Mappings der KDL auf ClassCode TypeCode mit Arbeitsgruppe abstimmen

| betrifft Codesystem | eventCodeList, classCode, typeCode
| Autor der Anfrage | AM
| Diskussion|
| Entscheidung | Review des Mappings können wir machen, aber Verantwortung liegt bei DVMD, sobald neues Mapping vorliegt, erfolgt Review als neue Anfrage
| Action Item |
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 18.02.2022

|- valign="top"
| Anfrage ID| 39
| Anfrage eingegangen am| 31.03.2022
| Anfrage| neue FormatCodes, neue eventCodes
DiGA

documentEntry.formatCode.code: "urn:gematik:ig:diga:v1.0"

documentEntry.formatCode.displayName: "DiGA (gematik)"

Weiterhin sollen aufgrund einer gesetzlichen Vorgabe eDMP-Datensätze in der ePA gespeichert werden können. Das Regelsystem der ePA braucht dazu konkrete Codes, um die DMPs erkennen zu können. Wir schlagen daher die folgenden Format Codes für die DMPs vor, die die Implementierungsleitfäden der KBV unter https://update.kbv.de/ita-update/Medizinische-Dokumentationen/ widerspiegeln:

DMP Asthma bronchiale

documentEntry.formatCode.code: "urn:gematik:ig:DMP-Asthma:v4.45"

documentEntry.formatCode.displayName: "eDMP Asthma (gematik)"

DMP Brustkrebs

documentEntry.formatCode.code: "urn:gematik:ig:DMP-BRK:v4.23"

documentEntry.formatCode.displayName: "eDMP Brustkrebs (gematik)"

DMP Chronische Herzinsuffizienz

documentEntry.formatCode.code: "urn:gematik:ig:DMP-HI:v1.1"

documentEntry.formatCode.displayName: "eDMP Herzinsuffizienz (gematik)"

DMP Chronischer Rückenschmerz

documentEntry.formatCode.code: "urn:gematik:ig:DMP-Rueckenschmerz:v1.0"

documentEntry.formatCode.displayName: "eDMP Rückenschmerz (gematik)"

DMP COPD

documentEntry.formatCode.code: "urn:gematik:ig:DMP-COPD:v4.4"

documentEntry.formatCode.displayName: "eDMP Chronic Obstrusive Pulmonary Disease (gematik)"

DMP Depressionen

documentEntry.formatCode.code: "urn:gematik:ig:DMP-Depression:v1.1"

documentEntry.formatCode.displayName: "eDMP Depression (gematik)"

DMP Diabetes mellitus Typ 1

documentEntry.formatCode.code: "urn:gematik:ig:DMP-DM1:v5.5"

documentEntry.formatCode.displayName: "eDMP Diabetes mellitus Typ 1 (gematik)"

DMP Diabetes mellitus Typ 2

documentEntry.formatCode.code: "urn:gematik:ig:DMP-DM2:v6.5"

documentEntry.formatCode.displayName: "eDMP Diabetes mellitus Typ 2 (gematik)"

DMP Koronare Herzkrankheit

documentEntry.formatCode.code: "urn:gematik:ig:DMP-KHK:v4"

documentEntry.formatCode.displayName: "eDMP Koronare Herzkrankheit (gematik)"

DMP Osteoporose

documentEntry.formatCode.code: "urn:gematik:ig:DMP-OST:v1.0"

documentEntry.formatCode.displayName: "eDMP Osteoporose (gematik)
Leider unterliegen diese Versionen historisch bedingt, keinem Semantic Versioning. Das möchten wir sehr gerne diskutieren, da es möglicherweise unpraktikabel hinsichtlich der Pflege des Value Sets werden kann.

Weiterhin möchten wir gerne diskutieren, neben den Format Codes, versionsunabhängige Event Codes der DMP-Programme aufzunehmen, um die spezifische Suche nach einem Programm zu gewährleisten. Die KBV hat schon das entsprechende Code-System in verschiedenen Formaten spezifiziert und es wird auch in den HL7 FHIR Basisprofilen berücksichtigt (https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP). Dieses könnte „herkömmlich“ über die OID 1.2.276.0.76.5.223 in das Value Set für Event Codes eingebunden werden.
| betrifft Codesystem |formatCodes
| Autor der Anfrage | Gematik
| Diskussion| Die Display names des KBV CodeSystems sind ziemlich uneindeutig. Beispiel: HI könnte nicht nur Herzinsuffizienz sondern auch Hinterwandinfarkt oder Harnwegsinfekt bedeuten.
| Entscheidung | Das Codesystem https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP wird dem eventCode ValueSet hinzugefügt. Der KBV wird geraten, in der nächsten Version des Codesystems bei den Displaynamen geeignetere Bezeichnungen zu verwenden. Die Major version der formatCodes wird in das entsprechende ValueSet aufgenommen z.B. "urn:gematik:ig:DMP-Asthma:v4" statt "urn:gematik:ig:DMP-Asthma:v4.45", da sonst der Pflegeaufwand zu hoch ist.
| Action Item | Raik gibt entsprechende Rückmeldung an KBV, Angela fügt eventCOdes und formatCodes den entsprechende ValueSets hinzu
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 27.05.2022
|- valign="top"

| Anfrage ID| 41
| Anfrage eingegangen am| 28.04.2022
| Anfrage|neue Dokumentenformate für EPA: code: "urn:gematik:ig:Telemedizinisches-Monitoring:v1.0" displayName: " Telemedizinisches Monitoring (gematik)", code: "urn:gematik:ig:Pflegeueberleitungsbogen:v1.0"
displayName: " Pflegeüberleitungsbogen (gematik)"
| betrifft Codesystem | formatCode
| Autor der Anfrage | gematik
| Diskussion|
| Entscheidung | Major Revisions werden als FormatCodes aufgenommen
| Action Item | Feedback an Gematik ==> positiv
| Bearbeitungsstand | erledigt
| zuletzt bearbeitet am| 27.05.2022
|- valign="top"

|}

'''Tabelle Aktueller Stand'''

:{|class="hl7table sortable"
|-
! width="25%" align="left" | Codesystem
! align="center" | Stand Konzepte
! align="center" | ArtDecor
! align="center" | WikiText
! align="center" | Review durch

|- valign="top"
| Codesystem | Einleitung
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Sven, Frank

|- valign="top"
| Codesystem | Vokabular Management
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Sven, Frank

|- valign="top"
| Codesystem | Confidentiality Code
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Sven, Frank

|- valign="top"
| Codesystem | AuthorRole
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Angela, Sven

|- valign="top"
| Codesystem | AuthorSpeciality
| Stand Konzepte | n/a
| ArtDecor | offen
| WikiText | offen
| Review durch | ''Tarik?''

|- valign="top"
| Codesystem | EventCodeList
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Angela

|- valign="top"
| Codesystem | ContentTypeCode
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Axel

|- valign="top"
| Codesystem | ClassCode
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Arnold, Antje

|- valign="top"
| Codesystem | TypeCode
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Arnold, Antje

|- valign="top"
| Codesystem | FormatCode
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Axel

|- valign="top"
| Codesystem | HealthcareFacilityTypeCode
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | ''Tarik?''

|- valign="top"
| Codesystem | PracticeSettingCode
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Antje, Arnold

|- valign="top"
| Codesystem | Folder.codeList
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Review durch | Angela, Sven

|- valign="top"
| Valuesets/ generell| EPA Verwendung
| Stand Konzepte | n/a
| ArtDecor | n/a
| WikiText | offen
| Erstellung durch | Raik, Christof

|}

'''Schritte zur Veröffentlichung v3'''
# Zeitplan (draft) erstellen
#* Anfang Februar Ankündigung
#* Anfang März Kommentierungsstart
#* Anfang April Ende Kommentierung, Anfang Kommentarauflösungs
#* Anfang Juni Veröffentlichung
# Rückfrage an gematik, KBV, BAEK, BPTK ob die mit ihnen abgestimmten Änderungen an v3 so finalisiert werden können - Hinweis auf unseren vorläufigen Zeitplan geben
# Ankündigung formulieren
# Kapitel zur Verwendung der ValueSets in der EPA schreiben
# Review der Wiki-Texte und AuthorSpecialty Code anpassen
# Change Liste erstellen
# PDF erstellen
# PDF in Wiki und auf IHE-D Seite hochladen/referenzieren
# Kommentare sammeln
# Kommentare auflösen
# Abstimmung zur Veröffentlichung
# Finale Version erstellen und in Wiki und IHE-D Seite hochladen

Optional:
* Erläuterung zum Zusammenspiel mit FHIR
* Hinweis/kurze Erläuterung der nicht behandelten XDS Metadaten

'''IG Struktur'''

# [[ihevs:Einleitung]] (Vorgehen, Ziele, Umgang mit v1, normativ, Delta-Liste?, Änderungen/Pflege)
# [[Ihevs:Vokabular-Management]]
# [[ihevs:DocumentEntry.authorRole]]
#* Erläuterungstext
#* ValueSet aus ART Decor
# [[ihevs:DocumentEntry.authorSpecialty]]
#* Erläuterungstext
#* ValueSet aus ART Decor
# [[ihevs:DocumentEntry.classCode]]
#* Erläuterungstext (mit Link auf ART Decor)
#* ValueSet aus ART Decor
# [[ihevs:DocumentEntry.confidentialityCode]]
#* Erläuterungstext
#* ValueSet aus ART Decor
# [[ihevs:DocumentEntry.eventCodeList]]
#* Erläuterungstext
#* ValueSet aus ART Decor
# [[ihevs:DocumentEntry.formatCode]]
#* Erläuterungstext (mit Link auf ART Decor)
#* ValueSet aus ART Decor
# [[ihevs:DocumentEntry.healthcareFacilityTypeCode]]
#* Erläuterungstext (mit Link auf ART Decor)
#* ValueSet aus ART Decor
# [[ihevs:DocumentEntry.languageCode]]
#* Erläuterungstext
#* ValueSet aus ART Decor
# [[ihevs:DocumentEntry.practiceSettingCode]]
#* Erläuterungstext (mit Link auf ART Decor)
#* ValueSet aus ART Decor
# [[ihevs:DocumentEntry.typeCode]]
#* Erläuterungstext (mit Link auf ART Decor)
#* ValueSet aus ART Decor
# [[ihevs:SubmissionSet.contentTypeCode]]
#* Erläuterungstext
#* ValueSet aus ART Decor
# [[ihevs:Folder.codeList]]
#* Erläuterungstext
#* ValueSet aus ART Decor

[[Kategorie:ihevs]]

Abstimmungsverfahren (Regeln)

2021-04-30T08:54:00Z

Foemig: /* Personenzuordnung (alphabetisch) */

=Einleitung=
Innerhalb des Interoperabilitätsforums erarbeiten wir so genannte Konsensus-Standards. Das bedeutet, dass Teile des Standards selbst aber auch abgeleitete Spezifikationen wie zum Beispiel Implementierungsleitfäden in einer Gruppe vom Personen, die dann in der Regel ihre Organisation vertreten, abgestimmt bzw. kommentiert werden. Dies bezeichnet man als Abstimmungs- (ballot) oder Kommentierungsverfahren. Dazu sind ggf. mehrere Runden notwendig, um alle Kommentare qualifiziert mit Konsens auflösen zu können. Ausgangssituation ist in der Regel ein Dokument, das zur Disposition gestellt wird. Nach angemessener Ankündigung der Abstimmung melden sich diejenigen, die abstimmen wollen (voter), zum Verfahren an und liefern Kommentare ab. Zudem wird eine Gesamtbeurteilung erwartet, die negativ, positiv oder auch eine Enthaltung ist.

Das Balloting unterliegt entsprechenden Regeln. Die Grundlagen dazu sind für HL7 Deutschland bei HL7 International (GOM, Bylaws) als auch auf der Ebene der Affiliates (Affiliate Agreement) festgelegt.

==Art des Verfahrens==
Genaugenommen besteht das gesamte Verfahren aus zwei parallel stattfindenden Teilen:

* die Kommentierung
* die Abstimmung

Die '''Kommentierung''' dient dazu, Passagen, Stellen oder Teilbereiche zu identifizieren, die fehlerbehaftet oder noch nicht optimal sind, bzw. mit denen man sich aus bestimmten, dann auch konkret zu benennden Gründen nicht einverstanden ist.

Die '''Abstimmung''' soll als Ergebnis des Prozesses festhalten, ob man mit der Spezifikation als Ganzes einverstanden (Zustimmung), nicht einverstanden (Ablehnung) ist, oder sich enthält.

Als Kommentare dürfen beliebig viele eingereicht werden, während als Stimme nur eine Angabe zulässig ist.

==Feststellung von abgestimmten Definitionen und Kommunikationsszenarien==

=== Verfahren für vorgelegte Materialien===

Vorgelegte Materialien können in einem der folgenden Verfahren zur
Abstimmung bzw. Kommentierung gestellt werden:

{| class="hl7table"
|+
! Verfahren !! Kommentar !! Kommen- tierung !! Ab- stimmung !! Mindest- teil- nehmer- zahl !! Quorum !! Optional/ Verpflichtend !! Internationale Entsprechung
|-
| Informativ/ zur Kommentierung
| Das Material hat informativen Charakter, wird derzeit nicht als normativ angesehen, aber ist dennoch zur allgemeinen Veröffentlichung und Kommentierung gedacht. Die erarbeitende Organisation möchte ein "Stimmungsbild" einfangen, um die generelle Ausrichtung zu überprüfen bzw. grundlegende Meinungen zu bekommen.
| ja
| nein
| n/a
| n/a
| optional
| informative/ comment only
|-
| Standard zur Probe (STU)
| Das Material soll nach Freigabe für einen Zeitraum von (mindestens) zwei Jahren als stabil betrachtet werden, damit es in einer Implementierungsphase auf Tauglichkeit getestet werden kann. Danach muss es nochmal als normativ zur Abstimmung gebracht werden.
| ja
| ja
| 5
| 60%
| optional
| Standard for Trial Use (STU)
|-
| Normativ
| Das Material ist komplett und fertig erarbeitet und soll endgültig angenommen werden. (Es kann nur Material hierzu eingereicht werden, dass vorher schon als STU angenommen worden ist.)
| ja
| ja
| 5
| 80%
| verpflichtend
| normative
|}

===Beteiligung am Prozess===

* Alle Mitglieder des Interoperabilitätsforums sind an der Kommentierung teilnahmeberechtigt, d.h. dürfen Kommentare abgegeben. Juristische Personen müssen sich jeweils durch eine natürliche Person vertreten lassen.

* Simmberechtigt für die Abstimmung sind aber nur Mitglieder der durchführenden Organisation. Jeder in die Liste aufgenommene Person hat eine Stimme.

* Es wird eine Teilnehmerliste geführt, in der wird lediglich der benannte Vertreter aufgenommen. Auf die Aufnahme in die Liste besteht ein Anspruch. Hierbei muss festgehalten werden, ob diese Person ein offizieller Vertreter der durchführenden Organisation ist und die Stimme zählt.

===Durchführung des Prozesses===

* Mindestens 30 Tage vor Beginn des Verfahrens ist ein solches allen Teilnahme- bzw. Stimmberechtigten unter Nennung des Inhalts, Art des Materials und der Fristen anzuzeigen (Ankündigungsphase). Hierbei ist anzugeben, wer die durchführende Organisation ist, damit die Stimmberechtigten ermittelt werden können. Mit Beginn der Ankündigungsphase bis zum Ende der Abstimmungsphase können sich die Teilnahmeberechtigten schriftlich melden, wenn sie im Verfahren abstimmen wollen. Hier reicht eine formlose Email an [mailto:info@interoperabilitaetsforum.de info@interoperabilitaetsforum.de].

* Nach Ablauf der Ankündigungsfrist beginnt das Abstimmungsverfahren. Die Spezifikationen müssen allen gemeldeten Teilnahmeberechtigten in gleicher Weise zur Verfügung gestellt werden. Dies geschieht über unsere Seite [[Abstimmungsverfahren]]. Die Dauer des Abstimmungsverfahrens wird vorab in der Ankündigungsphase bekannt gegeben, hängt vom Umfang des Abstimmungsmaterials ab und liegt im Ermessen des Durchführenden, beträgt aber mindestens 30 Tage. In dieser Zeit können die gemeldeten Teilnahmeberechtigten ihre Kommentare und die Stimmberechtigten ihr Stimme abgeben. Negative Stimmen müssen, um als solche gewertet zu werden, entsprechende sachlich kommentierende Stellungnahmen enthalten, positive Stimmen bzw. Enthaltungen können kommentiert werden. (Das hierfür zu nutzende Spreadsheet ist [http://download.hl7.de//VotenKommentare.xls hier] zu finden.)

* Das Verfahren gilt als erfolgreich durchgeführt, wenn die Mindestteilnehmerzahl (s.o.) und ein ggf. notwendiges Quorum erreicht wurde. (Die Autoren der Materialien sind ebenfalls stimmberechtigt.)

* Nach Ablauf des Abstimmungsverfahrens werden die Stimmen gezählt und die Kommentare zusammengefügt, wiederum kommentiert und im Interoperabilitätsforum veröffentlicht. Negative Kommentare müssen von der erarbeitenden Projektgruppe dabei als „angenommen“, „abgelehnt“ oder „nicht überzeugend“ gekennzeichnet und kommentiert werden. Zur Auflösung negativer Kommentare sind einvernehmliche Vereinbarungen zwischen dem Autor des Kommentars und dem Einreicher der Spezifikation anzustreben, d.h. der Durchführende muss eine Antwort des Kommentierers einholen. Negative Stimmen oder Kommentare können bei Übereinstimmung der weiteren Vorgehensweise und verbunden mit der Verpflichtung der Änderung seitens des Einreichenden der Spezifikation zurückgezogen werden. Dies hat schriftlich zu erfolgen. Kann ein negativer Kommentar nicht einvernehmlich aufgelöst werden, entscheidet der Vorstand der abstimmenden Organisation über die weitere Vorgehensweise. In jedem Fall ist ein nicht aufgelöster negativer Kommentar mit der Spezifikation zu veröffentlichen.

* Abschließend werden den Teilnehmern des Verfahrens alle Kommentare und die vorgenommenen Änderungen der Spezifikation mitgeteilt. Wenn innerhalb einer vorab festgelegten Einspruchsfrist kein Widerspruch erfolgt, gelten die Änderungen als festgestellt. Der Widerspruch muss schriftlich begründet werden und darf sich nur auf die innerhalb des Abstimmungsverfahrens erfolgten Änderungen an der Spezifikation beziehen. Letztlich entscheidet der Vorstand über die Wirksamkeit des Widerspruchs.

* Für die Annahme einer Spezifikation muss das oben angegebene Quorum für das Material erfüllt sein, d.h. hier zählt das Verhältnis von Ja-Stimmen zu der Summe der eingegangenen Ja- und Nein-Stimmen. Als Stimmen zählen alle im Abstimmungsverfahren abgegebenen Ja-Stimmen, soweit der Stimmberechtigte nicht im Verfahren widersprochen hat sowie alle negativen Stimmen im Abstimmungsverfahren, soweit der Stimmberechtigte nicht zusätzlich im Verfahren widersprochen hat sowie alle abgegebenen Enthaltungen. Verliert ein gemeldeter Teilnahmeberechtigter während des Abstimmungsverfahrens die Teilnahmeberechtigung, gilt er als nicht gemeldet.

* Entstehen durch die Auflösung der Kommentare substanzielle Änderungen an der Spezifikation, so ist die Abstimmung zu wiederholen. Hierbei sind teilnahmeberechtigt nur die Teilnehmer aus der vorhergehenden Runde, die eine gültige Stinme abgegeben haben. Dabei dürfen dann nur neue Kommentare abgegeben werden, die sich auf die geänderten Stellen beziehen. (Dieser Zyklus ist ggf. solange zu wiederholen, bis die Spezifikation als angenommen gilt oder gar keine Einigung erzielt werden kann.

* Vor Freigabe der Ergebnisse sind diese zu veröffentlichen.

===Hintergründe zur Verfahrensdurchführung===

Das vorab beschriebene Verfahren wird vielfach als Gängelung bzw. unnötige Zeitverschwendung betitelt. Dabei hat sich dieses Verfahren aus pragmatischen Gründen so entwickelt. Die dazugehörigen Aspekte sollen deshalb kurz aufgeführt werden, damit man:frau es besser einordnen kann:

* Eine offene, transparente Kommentierung mit Einholung einer Antwort vom Kommentierer sorgt dafür, dass eine Diskussion entsteht und der Durchführende nicht willkürlich seine Sicht durchsetzen kann. Damit wäre eine Abstimmung dann obsolet.
* Die Abgabe einer Stimme mit Aufsummation zu einem Gesamtbild dokumentiert die Sicht auf die Spezifikation. Damit werden Zustimmungen explizit gemacht und man kann nicht von fehlenden Ablehnungen auf eine Zustimmung schließen.
* Die beiden vorgenannten Punkte sollen die Qualität es Materials sicherstellen.
* Längere Fristen sind absolut notwendig, damit einer Community ausreichend Gelegenheit gegeben wird, sich das Material anzusehen zu können. (Ein 'über den Zaun werfen und da hast jetzt 10 Tage zur Kommentierung' ist ausgesprochen kontraproduktiv, da wohl so gut wie niemand so kurzfristig genügend Zeit erübrigen kann.)
* Ideal wäre ein Ganzjahreskalender oder zumindest 1 Jahr Vorausplanung, damit man sich Zeit reservieren kann. Dem gegenüber stehen aber meist kurzfristige Notwendigkeiten, eine Spezifikation zu finalisieren. Deshalb eine Ankündigung ein unabdingbares Muss.
* Eine Anmeldeverpflichtung sorgt dafür, dass bekannt ist, wer hinterher eine Stimme abgeben will/wird. Damit ist es möglich, gezielt an eine Stimmabgabe zu erinnern. Eine Anmeldung erlaubt es auch, Fehler im Material noch während des Verfahrens zu korrigieren, ohne dass eine neue Runde notwendig wird. Damit wird eine Beschleunigung insgesamt erzielt.
* Ursprünglich wurde das Material immer gleichwertig, .d.h normativ, kommentiert. Es hat sich aber herausgestellt, dass frühzeitige Rückmeldungen hilfreich sind, um Fehlentwicklungen zu erkennen und entsprechend gegensteuern zu können.
* Änderungen, die aufgrund von Kommentaren vorgenommen wurden und substantiell sind, d.h. Änderungen an der Implementierung zur Folge haben, müssen noch einmal kommentiert werden. Dies begründet sich damit, dass ggf. schon Implementierungen laufen, die von einer Nichtveränderung ausgehen.
* In erneuten Runden dürfen nur geänderte Passagen kommentiert werden, und das auch nur von denjenigen, die bisher teilgenommen haben. Dies garantiert, dass es keinen endlosen Runden ('ping pong'-Effekt) gibt.
* Die Arbeitung des Materials sollte ebenfalls schon offen und transparent erfolgen, um Interessenten frühzeitig ihre Sicht und Informationen einbringen zu lassen. Es ist anzunehmen, dass genau diejenigen das Material später auch kommentieren werden. Insofern spart dieses Vorgehen viel Zeit und unnötige Kommentierungsrunden, so dass die Qualität des Materials steigt und Fristen verkürzt werden können.

'''Damit sorgt die Einhaltung dieser Regeln für eine Beschleunigung insgesamt und führt eben nicht zu der befürchteten Zeitverzögerung!'''

===Qualitätskriterien für Materialien===

Das Material sollte bestimmten Qualitätskriterien genügen. Verschiedene Arbeitsgruppen (https://confluence.hl7.org/display/SGB/Quality+Criteria) bei HL7 International haben dazu Sammlungen verfasst:

* v2.x
** https://confluence.hl7.org/display/INM/Version+2+Quality+Metrics+Document
** https://confluence.hl7.org/display/INM/Approve+V2+Standard+Quality?preview=%2F66928056%2F66928057%2FV2+Standard+Quality.docx
* CDA
** https://confluence.hl7.org/display/SD/CDA+IG+Quality+Criteria
* FHIR
** https://confluence.hl7.org/display/FHIR/1.+FHIR+IG+Quality+Criteria

==[[Bild:Flag_de.svg|border|27px]] HL7 Deutschland==

Für HL7 Deutschland verwendet das o.g. Regelwerk. Stimmberechtigt sind alle Mitglieder bzw. deren benannte Vertreter.

==[[Bild:Flag_de.svg|border|27px]] IHE Deutschland==

IHE Deutschland schließt sich bis auf weiteres diesem Verfahren an. Stimmberechtigt sind ebenfalls Mitglieder bzw. deren benannte Vertreter.

==Andere Organisationen im Interoperabilitätsforum==

Anderen Organisationen steht es frei, sich ebenfalls dem o.g. Regelwerk zu unterwerfen und festzulegen, wer stimmberechtigt ist.

==[[Bild:logo-hl7int.jpg|border|27px]] HL7 International==

Das Verfahren wird bei HL7 International prinzipiell gleich durchgeführt. Neben den direkt Mitgliedern von HL7 International haben auch die Affiliates eine entsprechende Anzahl von Stimmen, die sich nach der Anzahl der jeweiligen Mitglieder richtet. Für HL7-D bedeutet dies derzeit 25 Stimmen. Diese Stimmen werden von sogenannten "Votern" (s.u.) abgegeben, die namentlich benannt und bei HL7 International offiziell gemeldet sein müssen. (Die Voter bekommen dann eine entsprechende Zugangskennung.)

Die Aufgabe der Voter ist es, sich während der Anmeldephase auf der entsprechenden Webseite ([http://www.hl7.org/ctl.cfm?action=ballots.home Ballot Home]) für die jeweiligen Materialien anzumelden (Home: Join a Pool). Welche das sind, wird ihnen über den eMailverteiler ([mailto:voter@hl7.de voter@hl7.de]) mitgeteilt. Kurz vor Ablauf der Ballotphase sollten dann die Ergebnisse mit den Kommentaren feststehen, so dass die Voter dann ihre jeweilige Stimme gemäß dieser Vorgabe abgeben sollten. Hierbei reicht auf der Seite "Vote" ein entsprechendes Kreuz zu machen:

*no Return - Standardeintrag, wenn noch keine Stimme abgegeben wurde
*Affirmative - Zustimmung
*Negative - Ablehnung
*Abstain - Enthaltung

Bei Ablehnung muss noch eine Begründung geliefert werden. Dies geschieht in der Regel durch denjenigen, der sich das Material angesehen hat. Deshalb wird meistens folgender Text unter "Vote Comment" eingetragen: "Please see comments provided by xxxxx". Auf wen dann konkret zu verweisen ist, wird dann ebenfalls mitgeteilt.

Im Zuge der Auflösung der Kommentare (in diesem Prozess ist der Reviewer dann verstärkt eingebunden) wird dann auch mitgeteilt, wann der (negative) Kommentar wieder zurückgezogen werden kann. Dies geschieht ebenfalls über den Emailverteiler.

==[[Bild:Flag_de.svg|border|27px]] IHE International==

Das Balloting internationaler Materialien erfolgt über die individuellen Domänen bei IHE International. teilnahmeberechtigt sind aktive Mitglieder (Details: www.ihe.net).

==Durchsicht der Materialien (Review) vs. Stimmabgabe (Voting)==

Eine immer wieder auftauchende Frage ist nach den Verantwortlichkeiten der beiden Rollen:

{{FAQBox |
'''Voter''' müssen sich die Materialien nicht notwendigerweise ansehen bzw. durcharbeiten und Kommentare erarbeiten. Ihre Hauptaufgabe ist die eigentliche Stimmabgabe. Dies erfordert im Normalfall wenige Minuten Aufwand je Ballot.
 
'''Balloter''' (oder Reviewer) sehen sich die Materialien an und erarbeiten eine qualifizierte Meinung dazu, so dass alle Voter eine entsprechende Stimme abgeben können. Dies ist deutlich aufwändiger und variiert je nach Umfang des Pakets. 
Üblicherweise werden diese Kommentare in einer Exceltabelle standardisiert erfasst, um eine genaue Zuordnung treffen zu können.
}}

Im Prinzip kann jedes Mitglied von HL7 Deutschland sich das Material ansehen (Zugang über die Mitgliederwebseite, http://www.hl7.de/publikationen/abstimmungen.php) und dann kommentieren. Im allgemeinen wird die Ankündigung von diesen Abstimmungsverfahren von HL7 USA an die TC-Liste weitergeleitet, so dass jeder informiert ist und sich auf der Ballotseite umsehen und dann frei entscheiden kann, ob er zu einem bestimmten Paket etwas beitragen kann bzw. möchte.

Sollte sich jemand entscheiden, zu einem Ballot etwas beitragen zu wollen, so sollte er auf die Ankündigungsemail möglichst zügig reagieren und mitteilen, zu welchem Paket dann eine Kommentierung erwartet werden kann. Die Summe aller dieser Meldungen wird dann den Votern zwecks Anmeldung wie oben geschildert mitgeteilt.

{{AlertBox |
Hier sollte berücksichtigt werden, dass Basis-Materialien (Core Principles, RIM, CDA, HL7 v2.x, OID Management, etc.) durchaus signifikante Auswirkungen auf die Entwicklungen in Deutschland haben und von daher kritisch begutachtet werden sollten (müssen).
}}

Zum Ablauf der Frist wäre es dann aber auch toll, wenn dann die Kommentare - oder zumindest die intendierte Stimme - rechtzeitig abgeliefert werden, damit die Voter entsprechend abstimmen können. Der Koordinator (einer der Voter) wird dann die Aufgabe übernehmen, auch die Kommentare auf die Ballot-Seite hochzuladen, so dass alle anderen dann ggf. (im Falle einer negativen Stimme) auf diesen verweisen kann. Das Hochladen der Kommentare kann unabhängig von den Stimmabgaben der Voter geschehen. Sollte also ein Reviewer im Zuge der Durchsicht feststellen, dass es negative Kommentare geben wird und deshalb ein Paket abzulehnen ist, so sollte dies möglichst umgehend mitgeteilt werden, damit möglichst viel Zeit zur Stimmabgabe bleibt.

{{NoteBox |
Um die Arbeit für die Reviewer zu vereinfachen, sind alle Balloter auch gleichzeitig Voter, da sie darüber einen direkten Zugang zu allen Materialien haben.
}}

==Personenzuordnung (alphabetisch)==

Nachfolgend die Liste der (bei HL7 International derzeit gemeldeten) Personen:

{| class="hl7table"
|-
! Person !! Voter (international) !! Balloter (Spezialisierung) !! Kommentar
|-
| Mathias Aschhoff (RZV) || x || CDA ||
|-
| Prof. Dr. Bernd Blobel (e-Health Competence Center) || x || Security, EHR ||
|-
| Dominik Brammen (Uni Magdeburg) || x || Emergency ||
|-
| Daniel Flemming (Katholische Stiftungshochschule München) || x || Pflege (Patient Care), CDA ||
|-
| Dr. Kai U. Heitmann (Heitmann Consulting and Services) || x || CDA, Templates ||
|-
| Dr. Frank Oemig (DTHS) || x || HL7 v2.x, CDA, Conformance, FHIR ||
|-
| Peter Scholz (OSM GmbH) || x || V2, FHIR und LABOR Themen ||
|-
| Prof. Dr. Martin Staemmler (FH Stralsund) || x || Personal Health, Health Records, HL7 v2.x, CDA |-
|}

{{NoteBox |
Da Deutschland derzeit mehr Stimmen abgeben darf als Voter angemeldet sind, besteht hier noch eine Deckungslücke.

Auch sollte davon ausgegangen werden, dass es weitere Experten für bestimmte Domänen gibt. Es wird daher um Rückmeldung gebeten, wer bereits ist, hier aktiv zu werden...
}}

== Legenda und Symbole zur Verwendung ==
{{:Abstimmung_legenda_phasen}}
{{:Abstimmung_legenda_gesamtstimme}}
{{:Abstimmung_legenda_kommentare}}

[[Kategorie:Enzyklopädie]]

IG:Value Sets für XDS

2021-04-13T08:18:35Z

Foemig:

{{Infobox Dokument
|Title = Value Sets für Aktenprojekte im deutschen Gesundheitswesen
|Short = Value Sets für XDS
|Namespace = ihevs
|Type = Implementierungsleitfaden
|Version = 3.0 Draft
|Submitted = IHE Deutschland
|Date = 12.04.2021
|Copyright = 2021
|Status = Draft
|Period = in Review
|Verfahren = STU
|OID = 1.3.6.1.4.1.19376.3.276.1.7.7
|Realm = Deutschland
|Custodian = IHE
}}

{{Infobox Ballot Begin}}
{{Ballot | Version = 0.1 | Date = 23.05.2016 | Status = Draft | Realm = Deutschland| Othericon = x
| Otherdocuments = http://download.hl7.de/documents/ihexdsvs/Value_Sets4XDS-v01.pdf
| Comment =
}}
{{Ballot | Version = 1.0 | Date = 10.11.2016 | Status = Final | Realm = Deutschland| Othericon = x
| Otherdocuments = http://www.ihe-d.de/download/value-sets-fuer-xds-metadaten
| Comment =
}}
{{Ballot | Version = 1.1 | Date = 22.05.2018 | Status = Draft | Realm = Deutschland| Othericon = x
| Otherdocuments = http://wiki.hl7.de/images/Value_Sets4XDS-v11.pdf
| Comment =
}}
{{Ballot | Version = 2.0 | Date = 09.10.2018 | Status = active| Realm = Deutschland| Othericon = x
| Otherdocuments = http://wiki.hl7.de/images/Value_Sets4XDS-v20.pdf
| Comment =
}}
{{Ballot | Version = 3.0 | Date = 12.04.2021 | Status = Draft| Realm = Deutschland| Othericon = x
| Otherdocuments = http://wiki.hl7.de/images/Value_Sets4XDS-30.pdf
| Comment =
}}

{{Infobox Ballot End}}

{{Infobox Contributors Begin}}
{{Contributor | Logo = Logo_ihe.png | Name = IHE Deutschland| Location = Berlin}}
{{Contributor | Logo = Logo_bvitg.JPG | Name = bvitg (Bundesverband Gesundheits-IT) | Location = Berlin}}
{{Contributor | Logo = Logo_icw.jpg | Name = ICW | Location = Walldorf }}
{{Contributor | Logo = Logo-t-systems.jpg | Name = Deutsche Telekom Healthcare and Security Solutions GmbH | Location = Bonn }}
{{Contributor | Logo = Logo-uk-heidelberg.png | Name = Uniklinik Heidelberg (ZIM) | Location = Heidelberg }}
{{Contributor | Logo = Logo-uk-freiburg.png | Name = Uniklinik Freiburg | Location = Freiburg }}
{{Contributor | Logo = Logo-cerner.jpeg | Name = Cerner | Location = Berlin }}
{{Contributor | Logo = Logo-visus.jpg | Name = VISUS Health IT GmbH | Location = Bochum }}
{{Contributor | Logo = FALKO LOGO.jpg | Name = FALKO.NRW gefördert durch EFRE und das Land Nordrhein-Westfalen|Location=}}
{{Contributor | Logo = Logo-rzv.jpg | Name = RZV Rechenzentrum Volmarstein GmbH | Location = Wetter (Ruhr) }}
{{Infobox Contributors End}}

{{HL7transclude| ihevs:Einleitung}}

<div class="landscape">
{{HL7transclude| ihevs:FAQs}}
{{HL7transclude| ihevs:Vokabular-Management}}
{{HL7transclude| ihevs:Value-Set-Tabellen}}
=Value Sets=
{{HL7transclude| ihevs:DocumentEntry.author}}
{{HL7transclude| ihevs:DocumentEntry.classCode}}
{{HL7transclude| ihevs:DocumentEntry.confidentialityCode}}
{{HL7transclude| ihevs:DocumentEntry.eventCodeList}}
{{HL7transclude| ihevs:DocumentEntry.formatCode}}
{{HL7transclude| ihevs:DocumentEntry.healthcareFacilityTypeCode}}
{{HL7transclude| Ihevs:DocumentEntry.languageCode}}
{{HL7transclude| ihevs:DocumentEntry.PracticeSettingCode}}
{{HL7transclude| ihevs:DocumentEntry.typeCode}}
{{HL7transclude| ihevs:SubmissionSet.contentTypeCode}}
{{HL7transclude| ihevs:Folder.codeList}}
</div>

Object Identifier (OID)

2021-04-01T08:35:00Z

Foemig:

==Überblick==

Beim standardisierten Austausch von Gesundheitsinformationen ist es notwendig, Objekt, Nachrichten, Dokumente u.a. eindeutig zu bezeichnen.

Objekt Identifikatoren (OID, Object Identifier) sind Zahlenkentten zur weltweit eindeutigen Kennzeichnung von Objekten aller Art, wie zum Beispiel Institutionen, Dokumente, Nachrichten, Zertifikate, Klassifikationen, Tabellen...

Die Form von OIDs ist eine Kette von Knoten, wobei jeder Knoten durch eine Zahl repräsentiert ist. Die Knoten sind hierarchisch aufgebaut, von jedem Knoten können durch den Knotenverantwortlichen Subknoten erstellt werden. (Siehe ISO/IEC Norm 9834/1)

Das Deutsche Gesundheitswesen hat die OID 1.2.276.0.76.

==Beispiel==

Mit der Klassifikation ICD-10-GM Version 2006 kann die Grippe durch nachgewiesene Vogelgrippe-Viren mit dem Kode J09 in XML - Technologie wie folgt dargestellt werden:

<syntaxhighlight lang="xml">
<value code="J09" codeSystem="1.2.276.0.76.5.311"/>
</syntaxhighlight>

==OID-Konzepte==

*[https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/oid-suche/index.html deutsches Gesundheitswesen (1.2.276.0.76)]
*[[OID-Konzept HL7-D|HL7-D (2.16.840.1.113883.2.6)]]
*[[OID-Konzept IHE-D|IHE-D (1.3.6.1.4.1.19376.3.276)]]
*[[Cdaonk:OID-Konzept|Deutsche Krebsgesellschaft]]
*[[Cdaefa:OID-Konzept|eFA]]

== Einleitung ==

OID ist die Abkürzung für "Objekt-Identifier" und stellen international standardisierte Indexe zur Objektkennung für Informationsobjekte dar. Eine OID entspricht dabei einem ASN.1<ref>ASN.1 (Abkürzung für "Abstract Syntax Notation One") ist eine Beschreibungssprache zur Definition von Datenstrukturen und ist ein gemeinsamer Standard der ITU-T (International Telecommunication Union – Telecommunication Standardization Sector) und der ISO (Internationale Organisation for Standardisation).</ref>-Datentyp. Der Standard selbst wie auch der Umgang mit der Vergabe ist in den folgenden Standards beschrieben:

* ISO/IEC 9834-1 "Kommunikation Offener Systeme - Verfahrensregeln für OSI - Registrierstellen: Allgemeine Verfahren und obere Bögen des ASN.1 Objektkennzeichnungsbaums" beschrieben
* ISO/IEC 9834-2 "Kommunikation Offener Systeme - Verfahrensregeln für OSI - Registrierstellen: Registrierverfahren für OSI-Dokumentenklassen"
* ISO/IEC 9834-3 "Kommunikation Offener Systeme - Verfahrensregeln für OSI - Registrierstellen: Registrierung von gemeinsam von ISO und ITU-T verwalteten Objektkennzeichnungen unter der obersten Bögen des ASN.1 Objektkennzeichnungsbaums"
* ISO/IEC 9834-6 "Kommunikation Offener Systeme - Verfahrensregeln für OSI - Registrierstellen: Anwendungsprozesse und Anwendungsinstanzen"
* ISO/IEC 9834-8 "Kommunikation Offener Systeme - Verfahrensregeln für OSI - Registrierstellen: Generierung und Registrierung universell eindeutiger Kennzeichen (UUIDs) und ihre Verwendung als ASN.1 Objektkennzeichenkomponenten"
* ISO/IEC 9834-9 "Kommunikation Offener Systeme - Verfahrensregeln für OSI - Registrierung von Objektkennzeichnungsbögen für auf ID basierenden Anwendungen und Diensten".

Dokumente, wie sie beispielsweise durch HL7 CDA repräsentiert werden, nutzen OIDs um Kodierungs-Schemas und Identifikationsbereiche zu bezeichnen. Dem Procedere liegt die Idee zugrunde, dass jede Identifikation bzw. jedes Kodierschema Teil des Systems ist, in dem sie definiert wurden. Beispiele hierfür sind die Arzt-Identifikationsnummern der Ärztekammern oder Codes für Laboruntersuchungen, die als LOINC-Codes dargestellt werden. 
Die Kombination aus der eigentlichen Identifikation (extension) und der ausgegebenen Instanz (Root-OID) ist zusammen genommen weltweit eindeutig. Den grundsätzlichen Aufbau des OID-Baums zeigt die nachfolgende Abbildung:

[[Datei:oid-baum.jpg|zentriert|hochkant=4.5|Aufbau des "OID-"Baums]]

Entsprechend dem Baum ist die Root-OID von HL7 2.16.840.1.113883:

<blockquote>
2 = Joint-ISO-ITU-T 
16 = country assignments 
840 = USA 
1 = Organisation 
113883 = HL7 
</blockquote>

Ausgehend von der root "1", welche für die "Common standardization area of ISO/IEC" (= International Organization for Standardization/International Electrotechnical Commission) und ITU-T (= International Telecommunications Union - Telecommunication standardization sector) ist somit aus jeder OID ableitbar, woher sie stammt. Dabei ist die Kombination aus der eigentlichen Identifikation (extension) und der ausgegebenen Instanz (Root-OID) zusammen genommen weltweit eindeutig.

Dementsprechend ist 2.16.840.1.113883.2.6 die Root-OID von HL7 Deutschland, vergeben von HL7 international (113883) an "affiliate" (2) Deutschland (6).

== Gute Praxis bei der Vergabe und Nutzung von OID ==

Die folgenden Empfehlungen und Richtlinien sollten bei der Vergabe und Nutzung von OID beachtet werden<ref>Alle Punkte entnommen aus OBJECT IDENTIFIER (OID) KONZEPT FÜR DAS DEUTSCHE GESUNDHEITSWESEN. Online, verfügbar unter [http://download.hl7.de/documents/oid-konzept/OIDKonzeptDE-v102.pdf http://download.hl7.de/documents/oid-konzept/OIDKonzeptDE-v102.pdf]</ref>: 
* Eine Organisation sollte bestehende OID verwenden, wenn diese bereits registriert sind. Eine lokale OID (innerhalb des OID-Baums der Organisation) sollte für etwas, was bereits registriert ist, nicht erzeugt/genutzt werden.
* Eine Organisation nutzt keine bereits vergebene OID, um damit lokal etwas anderes zu identifizieren.
* Wenn eine Organisation eine OID Registrieranfrage gestellt hat und die verantwortliche ausgebende Instanz verbietet die Erzeugung/Vergabe einer neuen Standard-OID, z. B. weil dafür bereits eine OID existiert, und es wird statt dessen ein alternatives Vorgehen vorgeschlagen, hat die anfragende Organisation die Alternative zu akzeptieren.
* Ausschließlich lokal verwendete OID zwischen zwei kooperierenden Partnern werden in der Regel unter dem OID-Baum eines der Partner registriert. Es sollte angestrebt werden, auch diese OID-Schemas zentral registrieren zu lassen. Für den Fall der Verwendung von lokalen OID kann die Organisation die zentrale Registerstelle z. B. in Zweifelsfällen um Hilfe ersuchen.

==OID-Vergabe im deutschen Gesundheitswesen ==
Die Root-OID (1.2.276.0.76) für das deutsche Gesundheitswesen liegt beim DIMDI<ref>DIMDI: OID. Online, verfügbar unter [https://www.dimdi.de/static/de/klassi/oid/index.htm https://www.dimdi.de/static/de/klassi/oid/index.htm]</ref>. Dementsprechend können OIDs beim DIMDI beantragt <ref>DIMDI: OID-Antrag. Online, verfügbar unter [https://www.dimdi.de/static/de/klassi/oid/oid-antrag/index.htm https://www.dimdi.de/static/de/klassi/oid/oid-antrag/index.htm]</ref> und auch gesucht <ref>DIMDI: OID-Suche. Online, verfügbar unter [https://www.dimdi.de/dynamic/de/klassi/oid/verzeichnis.html https://www.dimdi.de/dynamic/de/klassi/oid/verzeichnis.html]</ref> werden. Den grundlegenden Aufbau der Nutzung von "extensions" im deutschen Gesundheitswesen zeigt nachfolgende Tabelle <ref>Dargestellt in OBJECT IDENTIFIER (OID) KONZEPT FÜR DAS DEUTSCHE GESUNDHEITSWESEN. Online, verfügbar unter [http://download.hl7.de/documents/oid-konzept/OIDKonzeptDE-v102.pdf http://download.hl7.de/documents/oid-konzept/OIDKonzeptDE-v102.pdf]</ref>.

{| class="hl7table"
|-
!Beschreibung !! OID
|-
|Gesundheitswesen Deutschland || 1.2.276.0.76
|-
|Interne Objekte (wie Modelle etc) || 1.2.276.0.76.1
|-
|Interne Organisationsstrukturen || 1.2.276.0.76.2
|-
|Instanzen - Identifikatoren des deutschen Gesundheitswesens || 1.2.276.0.76.3
|-
|Organisationen des deutschen Gesundheitswesens || 1.2.276.0.76.3.1
|-
|Personen || 1.2.276.0.76.3.2
|-
|Allgemein genutzte Identifizierungsmechanismen wie Personalausweis, etc.|| 1.2.276.0.76.4
|-
|Deutsch-spezifische externe Identifikations-Schemas des Gesundheitswesens|| 1.2.276.0.76.5
|-
|Deutsch-spezifische Kodierschemas|| 1.2.276.0.76.6
|-
|Dokumente|| 1.2.276.0.76.7
|-
|Experimental-OID für temporäre, experimentelle Verwendung || 1.2.276.0.76.99
|}
Die Extension „1“ verweist demnach auf „interne Artefacts wie Modelle“ (siehe auch die Beschreibung zu OIDs von HL7 Deutschland<ref>OID Konzept von HL7-Deutschland. Online, verfügbar unter [http://wiki.hl7.de/index.php/OID-Konzept_HL7-D http://wiki.hl7.de/index.php/OID-Konzept_HL7-D]</ref>).
An diesem grundlegendem Aufbau halten sich Organisationen im deutschen Gesundheitswesen bei der eigenen OID-Verwaltung.

==Siehe auch==

*[[Häufig gestellte Fragen, Tipps und Tricks zum Thema OIDs]]

*[[OID-Beispielszenario]]

*[http://www.dimdi.de/static/de/klassi/oid/index.htm OID-Register] (DIMDI)
*[http://www.dimdi.de/static/de/klassi/oid/oidbasis.html Häufig gestellte Fragen] (DIMDI)
*[http://www.dimdi.de/static/de/klassi/oid/oid-antrag/index.htm Neuantrag] (DIMDI)

*[http://www.dimdi.de/static/de/klassi/oid/index.htm DIMDI eHealth zum Thema OID]
*[http://www.dimdi.de/dynamic/de/klassi/oid/verzeichnis.html OID Register Deutschland]
*[http://www.dimdi.de/static/de/klassi/oid/ag-oid/index.htm Arbeitsgruppe OID]

== Weitergehende Informationen zu OIDs==

Weitergehende Informationen zum Thema OIDs finden sich unter (alphabetische Nennung):

* Bundesministerium für Gesundheit (Österreich)
** Objektidentifikatoren (OID) für das Gesundheitswesen. Online, verfügbar unter [http://www.bmg.gv.at/home/Schwerpunkte/E_Health_Elga/E_Health_in_Oesterreich/Objektidentifikatoren_OID_fuer_das_Gesundheitswesen http://www.bmg.gv.at/home/Schwerpunkte/E_Health_Elga/E_Health_in_Oesterreich/Objektidentifikatoren_OID_fuer_das_Gesundheitswesen]
** Objektidentifikatoren (OID) Konzept für das österreichische Gesundheitswesen. online, verfügbar unter [http://www.bmg.gv.at/cms/home/attachments/3/6/7/CH1043/CMS1312448017784/oid-konzept_1-1-0.pdf http://www.bmg.gv.at/cms/home/attachments/3/6/7/CH1043/CMS1312448017784/oid-konzept_1-1-0.pdf]
** Objektidentifikatoren (OID) Leitfaden für das österreichische Gesundheitswesen. online, verfügbar unter [http://www.bmg.gv.at/cms/home/attachments/3/6/7/CH1043/CMS1312448017784/oid-leitfaden_1-0-0.pdf http://www.bmg.gv.at/cms/home/attachments/3/6/7/CH1043/CMS1312448017784/oid-leitfaden_1-0-0.pdf]
* DIMDI (veraltet)
** OID. Online, verfügbar unter [http://www.dimdi.de/static/de/klassi/oid/index.htm http://www.dimdi.de/static/de/klassi/oid/index.htm]
** FAQ Objekt-Identifikatoren, online, verfügbar unter [http://www.dimdi.de/static/de/klassi/oid/oidbasis.html http://www.dimdi.de/static/de/klassi/oid/oidbasis.html]
* BfArM
** OID Antrag: https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/oid-antrag/ (verweist auf DIMDI)
** OID-Suche: https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/oid-suche/
* eHealth Schweiz. OID-Konzept für das Schweizerische Gesundheitswesen. Online, verfügbar unter [http://www.vd.ch/fileadmin/user_upload/themes/sante_social/services_soins/eHealth/OID.pdf http://www.vd.ch/fileadmin/user_upload/themes/sante_social/services_soins/eHealth/OID.pdf]
* Gematik: Spezifikation: Festlegungen von OIDs. Online, verfügbar unter [https://www.gematik.de/cms/de/spezifikation/wirkbetrieb/releaseuebergreifendefestlegungen/release_2_3_4_verwendung_oid_1.jsp https://www.gematik.de/cms/de/spezifikation/wirkbetrieb/releaseuebergreifendefestlegungen/release_2_3_4_verwendung_oid_1.jsp]
* Harald Alvestrand's Website for additional information about Object Identifiers. Online, verfügbar unter [http://www.alvestrand.no/objectid/ http://www.alvestrand.no/objectid/]
* HL7 Deutschland
** Häufig gestellte Fragen, Tipps und Tricks zum Thema OIDs. Online, verfügbar unter [http://wiki.hl7.de/index.php/H%C3%A4ufig_gestellte_Fragen,_Tipps_und_Tricks_zum_Thema_OIDs http://wiki.hl7.de/index.php/H%C3%A4ufig_gestellte_Fragen,_Tipps_und_Tricks_zum_Thema_OIDs]
** Object Identifier (OID). Onilkne, verfügbar unter [http://wiki.hl7.de/index.php/Object_Identifier_(OID) http://wiki.hl7.de/index.php/Object_Identifier_(OID)]
* HL7 International
** HL7 OID Registry Frequently Asked Questions. Online, verfügbar unter [http://wiki.hl7.org/index.php?title=HL7_OID_Registry_Frequently_Asked_Questions http://wiki.hl7.org/index.php?title=HL7_OID_Registry_Frequently_Asked_Questions]
** HL7 Implementation Guidance for Unique Object Identifiers (OIDs), Release 1, online, verfügbar unter [http://www.hl7.org/oid/http://www.hl7.org/implement/standards/product_brief.cfm?product_id=210 http://www.hl7.org/oid/http://www.hl7.org/implement/standards/product_brief.cfm?product_id=210]
** Introduction to OIDs online, verfügbar unter [http://www.hl7.org/Oid/information.cfm http://www.hl7.org/Oid/information.cfm]
* IEEE: What is an Object Identifier (OID)? Online, verfügbar unter [https://standards.ieee.org/develop/regauth/tut/oid.pdf https://standards.ieee.org/develop/regauth/tut/oid.pdf]
* IHE
** NA2011 OID Assignments. Online, verfügbar unter [http://ihewiki.wustl.edu/wiki/index.php/NA2011_OID_Assignments http://ihewiki.wustl.edu/wiki/index.php/NA2011_OID_Assignments]
** PCD OID Management. Online, verfügbar unter [http://wiki.ihe.net/index.php?title=PCD_OID_Management http://wiki.ihe.net/index.php?title=PCD_OID_Management]
* Internet Engineering Task Force
** Request for Comments: 3001 „A URN Namespace of Object Identifiers”, online verfügbar unter [https://www.ietf.org/rfc/rfc3001.txt https://www.ietf.org/rfc/rfc3001.txt]
* Orange SA. Object Identifier (OID) Repository. Online, verfügbar unter [http://www.oid-info.com/ http://www.oid-info.com/]

== Fußnoten ==
<references />

[[Kategorie:Enzyklopädie]]
[[Kategorie:Abkürzungen|OID]]

Ihevs:SubmissionSet.contentTypeCode

2021-03-31T09:02:57Z

Foemig:

{{DocumentPart}}
==SubmissionSet.contentTypeCode==
Das Attribut 'contentTypeCode' ist gemäß IHE verpflichtend für ein SubmissionSet und erlaubt die Angabe des Grundes für die Übermittlung von neuen Daten, wie z.B. Weiterbehandlung, Verlegung, Einweisung.

IHE International spezifiziert, dass der contentTypeCode die klinische Aktivität beinhalten soll (IHE ITI TF-3 Vol 3, Abschnitt 4.2.3.3.4), welche zum Zusammenstellen und Versenden der Daten geführt hat. Jedoch beschränkt sich der contentTypeCode auf einen einzigen Wert. Da die klinische Aktivität oft nicht durch einen einzigen Wert ausreichend beschrieben werden kann, hat sich die Arbeitsgruppe darauf geeinigt, lediglich den Grund der Übermittlung im 'contentTypeCode' zu kodieren. Wir empfehlen, die klinische Aktivität stattdessen über die flexiblere 'eventCodeList' auf Ebene des Dokuments zu kodieren.
Wenn es aufgrund eng umrissener Anwendungsfälle innerhalb einer Affinity Domain möglich ist, die klinische Aktivität ausreichend anhand einer überschaubaren Liste an Codes zu beschreiben, kann dies über ein eigenes Value Set abgebildet werden.

Die Arbeitsgruppe "Value Sets" von IHE Deutschland definiert die möglichen Werte dieses Attributs in einem eigenen Codesystem, da kein adäquates Codesystem existiert, welches die verschiedenen Gründe der Übertragung auf einem grobgranularen Level beschreibt.

Besonders bei Profilen wie IHE XDR oder IHE XDM ist die Verwendung des SubmissionSets von Bedeutung, da hier nicht zwangsweise eine komplette Patientenakte vorliegt und die Visualisierung der Daten anhand der einzelnen Übermittlung, sprich des SubmissionSets, geschieht. Daher ist es besonders bei diesen Profilen von Bedeutung, den Grund der Übermittlung der Daten zu kodieren.

Das ValueSet ist als "open" definiert, damit es um weitere, ggf. projektspezifische Übermittlungsgründe erweitert werden kann.

Die Codes für das ValueSet werden in ART-DECOR zusammen mit den anderen von IHE Deutschland erstellten ValueSets veröffentlicht (http://art-decor.org/art-decor/decor-valuesets--ihede-) und hier eingebunden. Bei Darstellungsproblemen der eingebundenen Wertelisten finden Sie die Inhalte auf [[https://art-decor.org/art-decor/decor-valuesets--ihede-?id=1.2.276.0.76.11.39&effectiveDate=2018-07-13T13:28:16&language=de-DE ART-DECOR]].

{{ :1.2.276.0.76.11.39/dynamic}}

[[Kategorie:Enzyklopädie]]
[[Kategorie:Abkürzungen|contentTypeCode]]
[[Kategorie:ihevs]]

Ihevs:DocumentEntry.formatCode

2021-03-31T09:02:26Z

Foemig:

{{DocumentPart}}
==DocumentEntry.formatCode==

Das Attribut 'formatCode' spezifiziert das Format des Dokumentes. Zusammen mit dem typeCode (und ggf. mit dem mimeType) soll der formatCode für hinreichende Information sorgen, um einem Dokument-Konsumenten die Entscheidung zu ermöglichen, ob und wie er das Dokumentenformat verarbeiten kann.

Der formatCode muss dabei hinreichend eindeutig formuliert sein, um die Verarbeitung/Anzeige des von der Registry angeforderten Dokumentes durch den Dokumentenkonsumenten zu gewährleisten.

===Vergabe von formatCodes===

formatCodes können durch verschiedene Organisationen, insbesondere durch IHE International, IHE Deutschland, HL7 Deutschland oder die Betreiber einer XDS-Domäne definiert werden. Die vergebende Organisation legt den Aufbau des Codes fest. Die einzige Vorgabe für alle vergebenden Organisationen besteht darin, dass eine eindeutige URN verwendet werden soll.

===Umfang des IHE Deutschland formatCode ValueSets===

Das ValueSet hat die OID 1.2.276.0.76.11.35 und setzt sich aus Codes von IHE International, IHE Deutschland, HL7, HL7 Deutschland sowie weiteren Organisationen zusammen.

===Aufbau der formatCodes===
====Aufbau der durch IHE International vergebenen formatCodes====

formatCodes, welche von IHE ITI definiert werden, haben immer das Präfix

urn:ihe:iti:

Beispiel: urn:ihe:iti:xds-sd:pdf:2008. Beipiele hierzu finden sich im Wiki von IHE International (http://wiki.ihe.net/index.php?title=IHE_Format_Codes). Wenn andere IHE Domänen formatCodes definieren, so sollen sie das Präfix

urn:ihe:’domain initials’:

benutzen, wobei „domain initials“ die Domäne selbst repräsentiert.

====Aufbau der durch IHE Deutschland vergebenen formatCodes====

formatCodes, welche von IHE Deutschland definiert werden, haben immer das Präfix

urn:ihe-d:

Von IHE Deutschland festgelegte formatCodes werden wie folgt aufgebaut:

=====Aufbau für CDA-Dokumente=====

{| border=1
|-
|CDA-Dokumente ohne binärem Inhalt
|
urn:ihe-d:ig:'Bezeichner':'Jahr'
|-
|CDA-Dokumente mit einem Body, der aus einem binärem Inhalt besteht
|
urn:ihe-d:ig:'Bezeichner':'Jahr':nonXmlBody
|-
|CDA-Dokumente mit einem Body, der aus einer XML-Inhalten und mind. einer eingebettenen binärem Datei besteht
|
urn:ihe-d:ig:'Bezeichner':'Jahr':crossXmlBody
|}

„ig“ ist die feste Abkürzung für Implementierungsleitfäden (implementation guide). 'Bezeichner' und 'Jahr' sollen Platzhalter für den Inhalt des Dokuments und für das Jahr der Veröffentlichung sein. Sollten innerhalb eines Jahres mehrere Versionen erscheinen, wird der Angabe des Jahres zusätzlich eine zweistellige Monatszahl, getrennt von einem Bindestrich, '-'. hinzugefügt (Beispiel: 2010-07).

Beispiel: Sollte IHE Deutschland 2016 ein eigenes CDA-Dokument für eine Verordnung veröffentlichen, wird dieses entsprechend der obigen Beschreibung wie folgt abgebildet:

a) Verordnung: Level 1-3 ohne binärem Inhalt
urn:ihe-d:ig:Verordnung:2016
b) Verordnung: Level 1 CDA mit Body bestehend aus einer PDF-Datei ([[IG:CDA_und_PDF/A3]])
urn:ihe-d:ig:Verordnung:2016:nonXmlBody
c) Verordnung: sowohl mit XML-Inhalt wie auch mindestens einer eingebetteten binären Datei
urn:ihe-d:ig:Verordnung:2016:crossXmlBody

=====Aufbau für nicht CDA-Dokumente=====

Nicht-CDA-Dokumente sollten über eine möglichst genaue Beschreibung des Dokumentenformats abgebildet werden, sobald der MIME Type allein das Format des Dokuments nicht ausreichend beschreibt.

{| border=1
|-
|IHE Deutschland
|
urn:ihe-d:ig:'Bezeichner':'Jahr'
urn:ihe-d:spec:'Bezeichner':'Jahr'
|}

„ig“ ist die feste Abkürzung für Implementierungsleitfäden (implementation guide), „spec“ für eine Spezifikation (specification). Auch hier sind 'Bezeichner' und 'Jahr' Platzhalter für den Inhalt des Dokumentes bzw. für das Jahr der Veröffentlichung, welches wann immer möglich angegeben werden sollte. Werden innerhalb eines Jahres mehrere Versionen des Formates veröffentlicht, so wird auch hier zusätzlich die zweistellige Monatszahl der Angabe des Jahres hinzugefügt, getrennt von einem Bindestrich '-' (Beispiel: 2010-07).

Falls der MIME Type allein das Format des Dokuments ausreichend beschreibt, wird dies im formatCode durch die fest vorgegebene URN „urn:ihe:iti:xds:2017:mimeTypeSufficient“ ausgedrückt. Der MIME Type selbst wird in den IHE Document Sharing Metadaten bei DocumentEntry.mimeType angegeben. Die URN „urn:ihe:iti:xds:2017:mimeTypeSufficient“ wurde von IHE International im Dezember 2017 festgelegt und ist Teil der Revision 15 des IHE ITI Technical Frameworks. Der äquivalente, von IHE Deutschland eingeführte formatCode "urn:ihe-d:mime" gilt daher als "deprecated" und sollte nicht mehr verwendet werden.

'''Beispiel'''
Um ein gewöhnliches PDF-Dokument in einer Document Registry zu registrieren, über dessen Aufbau (Strukturierung) keine weiteren Informationen vorhanden sind, werden der Format-Code (DocumentEntry.formatCode) „urn:ihe:iti:xds:2017:mimeTypeSufficient“ und der MIME Type (DocumentEntry.mimeType) „application/pdf“ verwendet.

'''Sonderfall'''
Die unterschiedlichen Ausprägungen des PDF Formats (z.B. PDF-A für elektronische Archivierung) benötigen eine gesonderte Behandlung. Da der MIME Type „application/pdf“ diese unterschiedlichen Ausprägungen nicht differenziert, nutzt IHE Deutschland in bestimmten Fällen statt des Codes „urn:ihe:iti:xds:2017:mimeTypeSufficient“ selbst definierte formatCodes. Beispiel: „urn:ihe-d:spec:PDF_A1:2005”.
Wenn IHE Deutschland keinen formatCode für die verwendete PDF Ausprägung definiert hat (wie z.B. für PDF/X), wird der Code „urn:ihe:iti:xds:2017:mimeTypeSufficient“ als formatCode und „application/pdf“ als MIME Type verwendet.

====Empfehlungen von IHE Deutschland für den Aufbau von formatCodes für andere Organisationen====
Wir empfehlen die Verwendung eines IANA-registrierten domain names als Namespace Identifier (NID: der Teil der URN, der auf „urn: “ folgt und bis zum nächsten Doppelpunkt reicht). Definiert beispielsweise die Domäne „Gesundheitsversorgung Deutschland“ formatCodes, lautet das Präfix „urn:gesde.de:“, da die Domäne die URL http://www.gesde.de verwendet. Eine weitere Unterstrukturierung des Namensraums (d.h. nach dem zweiten Doppelpunkt) in Anlehnung an die Vorgehensweise von IHE Deutschland wird empfohlen.

====formatCodes für FHIR Ressourcen====
FHIR Ressourcen die über IHE XDS/XDR/XDM kommuniziert werden sollten die MIME Types "application/fhir+xml" für die XML Repräsentation und "application/fhir+json" für die JSON Repräsentation verwenden. Für einfache Ressourcen ist dies ausreichend, daher kann "urn:ihe:iti:xds:2017:mimeTypeSufficient" als formatCode verwendet werden. Bei Verwendung von FHIR Documents (http://hl7.org/fhir/documents.html) und ähnlichen Repräsentationen mit Dokumentencharakter wird der Einsatz eines spezifischeren formatCodes empfohlen. Von IHE Deutschland definierte formatCodes für FHIR Dokumentenleitfäden werden den oben dargestellten Vorgehen für CDA-Leitfäden ohne binären Inhalt folgen, d.h. urn:ihe-d:ig:'Bezeichner':'Jahr'.

Die Codes für das ValueSet werden in ART-DECOR zusammen mit den anderen von IHE Deutschland erstellten ValueSets veröffentlicht (http://art-decor.org/art-decor/decor-valuesets--ihede-) und hier eingebunden. Bei Darstellungsproblemen der eingebundenen Wertelisten kommen, finden Sie die Inhalte auf [[https://art-decor.org/art-decor/decor-valuesets--ihede-?id=1.2.276.0.76.11.35&effectiveDate=2018-07-13T16:16:59&language=de-DE ART-DECOR]].

{{:1.2.276.0.76.11.35/dynamic}}

===Links===
* RFC 3406 (2002) URN Namespace Definition Mechanisms. Online, verfügbar unter http://tools.ietf.org/html/rfc3406* Internet Assigned Numbers Authority (IANA). Media Types. Online, verfügbar unter http://www.iana.org/assignments/media-types/media-types.xhtml
* RFC 2288 (1998) Using Existing Bibliographic Identifiers as Uniform Resource Names. Online, verfügbar unter http://tools.ietf.org/html/rfc2288
* RFC 2141 (1997).URN Syntax. Online, verfügbar unter https://www.ietf.org/rfc/rfc2141.txt
* RFC 3151 (2001) A URN Namespace for Public Identifiers. Online, verfügbar unter https://tools.ietf.org/html/rfc3151

[[Kategorie:Enzyklopädie]]
[[Kategorie:Abkürzungen|formatCode]]
[[Kategorie:ihevs]]

Ihevs:DocumentEntry.formatCode

2021-03-31T09:01:21Z

Foemig:

{{DocumentPart}}
==DocumentEntry.formatCode==

Das Attribut 'formatCode' spezifiziert das Format des Dokumentes. Zusammen mit dem typeCode (und ggf. mit dem mimeType) soll der formatCode für hinreichende Information sorgen, um einem Dokument-Konsumenten die Entscheidung zu ermöglichen, ob und wie er das Dokumentenformat verarbeiten kann.

Der formatCode muss dabei hinreichend eindeutig formuliert sein, um die Verarbeitung/Anzeige des von der Registry angeforderten Dokumentes durch den Dokumentenkonsumenten zu gewährleisten.

===Vergabe von formatCodes===

formatCodes können durch verschiedene Organisationen, insbesondere durch IHE International, IHE Deutschland, HL7 Deutschland oder die Betreiber einer XDS-Domäne definiert werden. Die vergebende Organisation legt den Aufbau des Codes fest. Die einzige Vorgabe für alle vergebenden Organisationen besteht darin, dass eine eindeutige URN verwendet werden soll.

===Umfang des IHE Deutschland formatCode ValueSets===

Das ValueSet hat die OID 1.2.276.0.76.11.35 und setzt sich aus Codes von IHE International, IHE Deutschland, HL7, HL7 Deutschland sowie weiteren Organisationen zusammen.

===Aufbau der formatCodes===
====Aufbau der durch IHE International vergebenen formatCodes====

formatCodes, welche von IHE ITI definiert werden, haben immer das Präfix

urn:ihe:iti:

Beispiel: urn:ihe:iti:xds-sd:pdf:2008. Beipiele hierzu finden sich im Wiki von IHE International (http://wiki.ihe.net/index.php?title=IHE_Format_Codes). Wenn andere IHE Domänen formatCodes definieren, so sollen sie das Präfix

urn:ihe:’domain initials’:

benutzen, wobei „domain initials“ die Domäne selbst repräsentiert.

====Aufbau der durch IHE Deutschland vergebenen formatCodes====

formatCodes, welche von IHE Deutschland definiert werden, haben immer das Präfix

urn:ihe-d:

Von IHE Deutschland festgelegte formatCodes werden wie folgt aufgebaut:

=====Aufbau für CDA-Dokumente=====

{| border=1
|-
|CDA-Dokumente ohne binärem Inhalt
|
urn:ihe-d:ig:'Bezeichner':'Jahr'
|-
|CDA-Dokumente mit einem Body, der aus einem binärem Inhalt besteht
|
urn:ihe-d:ig:'Bezeichner':'Jahr':nonXmlBody
|-
|CDA-Dokumente mit einem Body, der aus einer XML-Inhalten und mind. einer eingebettenen binärem Datei besteht
|
urn:ihe-d:ig:'Bezeichner':'Jahr':crossXmlBody
|}

„ig“ ist die feste Abkürzung für Implementierungsleitfäden (implementation guide). 'Bezeichner' und 'Jahr' sollen Platzhalter für den Inhalt des Dokuments und für das Jahr der Veröffentlichung sein. Sollten innerhalb eines Jahres mehrere Versionen erscheinen, wird der Angabe des Jahres zusätzlich eine zweistellige Monatszahl, getrennt von einem Bindestrich, '-'. hinzugefügt (Beispiel: 2010-07).

Beispiel: Sollte IHE Deutschland 2016 ein eigenes CDA-Dokument für eine Verordnung veröffentlichen, wird dieses entsprechend der obigen Beschreibung wie folgt abgebildet:

a) Verordnung: Level 1-3 ohne binärem Inhalt
urn:ihe-d:ig:Verordnung:2016
b) Verordnung: Level 1 CDA mit Body bestehend aus einer PDF-Datei ([[IG:CDA_und_PDF/A3]])
urn:ihe-d:ig:Verordnung:2016:nonXmlBody
c) Verordnung: sowohl mit XML-Inhalt wie auch mindestens einer eingebetteten binären Datei
urn:ihe-d:ig:Verordnung:2016:crossXmlBody

=====Aufbau für nicht CDA-Dokumente=====

Nicht-CDA-Dokumente sollten über eine möglichst genaue Beschreibung des Dokumentenformats abgebildet werden, sobald der MIME Type allein das Format des Dokuments nicht ausreichend beschreibt.

{| border=1
|-
|IHE Deutschland
|
urn:ihe-d:ig:'Bezeichner':'Jahr'
urn:ihe-d:spec:'Bezeichner':'Jahr'
|}

„ig“ ist die feste Abkürzung für Implementierungsleitfäden (implementation guide), „spec“ für eine Spezifikation (specification). Auch hier sind 'Bezeichner' und 'Jahr' Platzhalter für den Inhalt des Dokumentes bzw. für das Jahr der Veröffentlichung, welches wann immer möglich angegeben werden sollte. Werden innerhalb eines Jahres mehrere Versionen des Formates veröffentlicht, so wird auch hier zusätzlich die zweistellige Monatszahl der Angabe des Jahres hinzugefügt, getrennt von einem Bindestrich '-' (Beispiel: 2010-07).

Falls der MIME Type allein das Format des Dokuments ausreichend beschreibt, wird dies im formatCode durch die fest vorgegebene URN „urn:ihe:iti:xds:2017:mimeTypeSufficient“ ausgedrückt. Der MIME Type selbst wird in den IHE Document Sharing Metadaten bei DocumentEntry.mimeType angegeben. Die URN „urn:ihe:iti:xds:2017:mimeTypeSufficient“ wurde von IHE International im Dezember 2017 festgelegt und ist Teil der Revision 15 des IHE ITI Technical Frameworks. Der äquivalente, von IHE Deutschland eingeführte formatCode "urn:ihe-d:mime" gilt daher als "deprecated" und sollte nicht mehr verwendet werden.

'''Beispiel'''
Um ein gewöhnliches PDF-Dokument in einer Document Registry zu registrieren, über dessen Aufbau (Strukturierung) keine weiteren Informationen vorhanden sind, werden der Format-Code (DocumentEntry.formatCode) „urn:ihe:iti:xds:2017:mimeTypeSufficient“ und der MIME Type (DocumentEntry.mimeType) „application/pdf“ verwendet.

'''Sonderfall'''
Die unterschiedlichen Ausprägungen des PDF Formats (z.B. PDF-A für elektronische Archivierung) benötigen eine gesonderte Behandlung. Da der MIME Type „application/pdf“ diese unterschiedlichen Ausprägungen nicht differenziert, nutzt IHE Deutschland in bestimmten Fällen statt des Codes „urn:ihe:iti:xds:2017:mimeTypeSufficient“ selbst definierte formatCodes. Beispiel: „urn:ihe-d:spec:PDF_A1:2005”.
Wenn IHE Deutschland keinen formatCode für die verwendete PDF Ausprägung definiert hat (wie z.B. für PDF/X), wird der Code „urn:ihe:iti:xds:2017:mimeTypeSufficient“ als formatCode und „application/pdf“ als MIME Type verwendet.

====Empfehlungen von IHE Deutschland für den Aufbau von formatCodes für andere Organisationen====
Wir empfehlen die Verwendung eines IANA-registrierten domain names als Namespace Identifier (NID: der Teil der URN, der auf „urn: “ folgt und bis zum nächsten Doppelpunkt reicht). Definiert beispielsweise die Domäne „Gesundheitsversorgung Deutschland“ formatCodes, lautet das Präfix „urn:gesde.de:“, da die Domäne die URL http://www.gesde.de verwendet. Eine weitere Unterstrukturierung des Namensraums (d.h. nach dem zweiten Doppelpunkt) in Anlehnung an die Vorgehensweise von IHE Deutschland wird empfohlen.

====formatCodes für FHIR Ressourcen====
FHIR Ressourcen die über IHE XDS/XDR/XDM kommuniziert werden sollten die MIME Types "application/fhir+xml" für die XML Repräsentation und "application/fhir+json" für die JSON Repräsentation verwenden. Für einfache Ressourcen ist dies ausreichend, daher kann "urn:ihe:iti:xds:2017:mimeTypeSufficient" als formatCode verwendet werden. Bei Verwendung von FHIR Documents (http://hl7.org/fhir/documents.html) und ähnlichen Repräsentationen mit Dokumentencharakter wird der Einsatz eines spezifischeren formatCodes empfohlen. Von IHE Deutschland definierte formatCodes für FHIR Dokumentenleitfäden werden den oben dargestellten Vorgehen für CDA-Leitfäden ohne binären Inhalt folgen, d.h. urn:ihe-d:ig:'Bezeichner':'Jahr'.

Die Codes für das ValueSet werden in ART-DECOR zusammen mit den anderen von IHE Deutschland erstellten ValueSets veröffentlicht (http://art-decor.org/art-decor/decor-valuesets--ihede-) und hier eingebunden. Bei Darstellungsproblemen der eingebundenen Wertelisten kommen, finden Sie die Inhalte auf [[https://art-decor.org/art-decor/decor-valuesets--ihede-?id=1.2.276.0.76.11.35&effectiveDate=2018-07-13T16:16:59&language=de-DE ART-DECOR]].

{{:1.2.276.0.76.11.35/dynamic }}

===Links===
* RFC 3406 (2002) URN Namespace Definition Mechanisms. Online, verfügbar unter http://tools.ietf.org/html/rfc3406* Internet Assigned Numbers Authority (IANA). Media Types. Online, verfügbar unter http://www.iana.org/assignments/media-types/media-types.xhtml
* RFC 2288 (1998) Using Existing Bibliographic Identifiers as Uniform Resource Names. Online, verfügbar unter http://tools.ietf.org/html/rfc2288
* RFC 2141 (1997).URN Syntax. Online, verfügbar unter https://www.ietf.org/rfc/rfc2141.txt
* RFC 3151 (2001) A URN Namespace for Public Identifiers. Online, verfügbar unter https://tools.ietf.org/html/rfc3151

[[Kategorie:Enzyklopädie]]
[[Kategorie:Abkürzungen|formatCode]]
[[Kategorie:ihevs]]

Abstimmungsverfahren (Regeln)

2021-03-26T09:06:52Z

Foemig: Überarbeitung

=Einleitung=
Innerhalb des Interoperabilitätsforums erarbeiten wir so genannte Konsensus-Standards. Das bedeutet, dass Teile des Standards selbst aber auch abgeleitete Spezifikationen wie zum Beispiel Implementierungsleitfäden in einer Gruppe vom Personen, die dann in der Regel ihre Organisation vertreten, abgestimmt bzw. kommentiert werden. Dies bezeichnet man als Abstimmungs- (ballot) oder Kommentierungsverfahren. Dazu sind ggf. mehrere Runden notwendig, um alle Kommentare qualifiziert mit Konsens auflösen zu können. Ausgangssituation ist in der Regel ein Dokument, das zur Disposition gestellt wird. Nach angemessener Ankündigung der Abstimmung melden sich diejenigen, die abstimmen wollen (voter), zum Verfahren an und liefern Kommentare ab. Zudem wird eine Gesamtbeurteilung erwartet, die negativ, positiv oder auch eine Enthaltung ist.

Das Balloting unterliegt entsprechenden Regeln. Die Grundlagen dazu sind für HL7 Deutschland bei HL7 International (GOM, Bylaws) als auch auf der Ebene der Affiliates (Affiliate Agreement) festgelegt.

==Art des Verfahrens==
Genaugenommen besteht das gesamte Verfahren aus zwei parallel stattfindenden Teilen:

* die Kommentierung
* die Abstimmung

Die '''Kommentierung''' dient dazu, Passagen, Stellen oder Teilbereiche zu identifizieren, die fehlerbehaftet oder noch nicht optimal sind, bzw. mit denen man sich aus bestimmten, dann auch konkret zu benennden Gründen nicht einverstanden ist.

Die '''Abstimmung''' soll als Ergebnis des Prozesses festhalten, ob man mit der Spezifikation als Ganzes einverstanden (Zustimmung), nicht einverstanden (Ablehnung) ist, oder sich enthält.

Als Kommentare dürfen beliebig viele eingereicht werden, während als Stimme nur eine Angabe zulässig ist.

==Feststellung von abgestimmten Definitionen und Kommunikationsszenarien==

=== Verfahren für vorgelegte Materialien===

Vorgelegte Materialien können in einem der folgenden Verfahren zur
Abstimmung bzw. Kommentierung gestellt werden:

{| class="hl7table"
|+
! Verfahren !! Kommentar !! Kommen- tierung !! Ab- stimmung !! Mindest- teil- nehmer- zahl !! Quorum !! Optional/ Verpflichtend !! Internationale Entsprechung
|-
| Informativ/ zur Kommentierung
| Das Material hat informativen Charakter, wird derzeit nicht als normativ angesehen, aber ist dennoch zur allgemeinen Veröffentlichung und Kommentierung gedacht. Die erarbeitende Organisation möchte ein "Stimmungsbild" einfangen, um die generelle Ausrichtung zu überprüfen bzw. grundlegende Meinungen zu bekommen.
| ja
| nein
| n/a
| n/a
| optional
| informative/ comment only
|-
| Standard zur Probe (STU)
| Das Material soll nach Freigabe für einen Zeitraum von (mindestens) zwei Jahren als stabil betrachtet werden, damit es in einer Implementierungsphase auf Tauglichkeit getestet werden kann. Danach muss es nochmal als normativ zur Abstimmung gebracht werden.
| ja
| ja
| 5
| 60%
| optional
| Standard for Trial Use (STU)
|-
| Normativ
| Das Material ist komplett und fertig erarbeitet und soll endgültig angenommen werden. (Es kann nur Material hierzu eingereicht werden, dass vorher schon als STU angenommen worden ist.)
| ja
| ja
| 5
| 80%
| verpflichtend
| normative
|}

===Beteiligung am Prozess===

* Alle Mitglieder des Interoperabilitätsforums sind an der Kommentierung teilnahmeberechtigt, d.h. dürfen Kommentare abgegeben. Juristische Personen müssen sich jeweils durch eine natürliche Person vertreten lassen.

* Simmberechtigt für die Abstimmung sind aber nur Mitglieder der durchführenden Organisation. Jeder in die Liste aufgenommene Person hat eine Stimme.

* Es wird eine Teilnehmerliste geführt, in der wird lediglich der benannte Vertreter aufgenommen. Auf die Aufnahme in die Liste besteht ein Anspruch. Hierbei muss festgehalten werden, ob diese Person ein offizieller Vertreter der durchführenden Organisation ist und die Stimme zählt.

===Durchführung des Prozesses===

* Mindestens 30 Tage vor Beginn des Verfahrens ist ein solches allen Teilnahme- bzw. Stimmberechtigten unter Nennung des Inhalts, Art des Materials und der Fristen anzuzeigen (Ankündigungsphase). Hierbei ist anzugeben, wer die durchführende Organisation ist, damit die Stimmberechtigten ermittelt werden können. Mit Beginn der Ankündigungsphase bis zum Ende der Abstimmungsphase können sich die Teilnahmeberechtigten schriftlich melden, wenn sie im Verfahren abstimmen wollen. Hier reicht eine formlose Email an [mailto:info@interoperabilitaetsforum.de info@interoperabilitaetsforum.de].

* Nach Ablauf der Ankündigungsfrist beginnt das Abstimmungsverfahren. Die Spezifikationen müssen allen gemeldeten Teilnahmeberechtigten in gleicher Weise zur Verfügung gestellt werden. Dies geschieht über unsere Seite [[Abstimmungsverfahren]]. Die Dauer des Abstimmungsverfahrens wird vorab in der Ankündigungsphase bekannt gegeben, hängt vom Umfang des Abstimmungsmaterials ab und liegt im Ermessen des Durchführenden, beträgt aber mindestens 30 Tage. In dieser Zeit können die gemeldeten Teilnahmeberechtigten ihre Kommentare und die Stimmberechtigten ihr Stimme abgeben. Negative Stimmen müssen, um als solche gewertet zu werden, entsprechende sachlich kommentierende Stellungnahmen enthalten, positive Stimmen bzw. Enthaltungen können kommentiert werden. (Das hierfür zu nutzende Spreadsheet ist [http://download.hl7.de//VotenKommentare.xls hier] zu finden.)

* Das Verfahren gilt als erfolgreich durchgeführt, wenn die Mindestteilnehmerzahl (s.o.) und ein ggf. notwendiges Quorum erreicht wurde. (Die Autoren der Materialien sind ebenfalls stimmberechtigt.)

* Nach Ablauf des Abstimmungsverfahrens werden die Stimmen gezählt und die Kommentare zusammengefügt, wiederum kommentiert und im Interoperabilitätsforum veröffentlicht. Negative Kommentare müssen von der erarbeitenden Projektgruppe dabei als „angenommen“, „abgelehnt“ oder „nicht überzeugend“ gekennzeichnet und kommentiert werden. Zur Auflösung negativer Kommentare sind einvernehmliche Vereinbarungen zwischen dem Autor des Kommentars und dem Einreicher der Spezifikation anzustreben, d.h. der Durchführende muss eine Antwort des Kommentierers einholen. Negative Stimmen oder Kommentare können bei Übereinstimmung der weiteren Vorgehensweise und verbunden mit der Verpflichtung der Änderung seitens des Einreichenden der Spezifikation zurückgezogen werden. Dies hat schriftlich zu erfolgen. Kann ein negativer Kommentar nicht einvernehmlich aufgelöst werden, entscheidet der Vorstand der abstimmenden Organisation über die weitere Vorgehensweise. In jedem Fall ist ein nicht aufgelöster negativer Kommentar mit der Spezifikation zu veröffentlichen.

* Abschließend werden den Teilnehmern des Verfahrens alle Kommentare und die vorgenommenen Änderungen der Spezifikation mitgeteilt. Wenn innerhalb einer vorab festgelegten Einspruchsfrist kein Widerspruch erfolgt, gelten die Änderungen als festgestellt. Der Widerspruch muss schriftlich begründet werden und darf sich nur auf die innerhalb des Abstimmungsverfahrens erfolgten Änderungen an der Spezifikation beziehen. Letztlich entscheidet der Vorstand über die Wirksamkeit des Widerspruchs.

* Für die Annahme einer Spezifikation muss das oben angegebene Quorum für das Material erfüllt sein, d.h. hier zählt das Verhältnis von Ja-Stimmen zu der Summe der eingegangenen Ja- und Nein-Stimmen. Als Stimmen zählen alle im Abstimmungsverfahren abgegebenen Ja-Stimmen, soweit der Stimmberechtigte nicht im Verfahren widersprochen hat sowie alle negativen Stimmen im Abstimmungsverfahren, soweit der Stimmberechtigte nicht zusätzlich im Verfahren widersprochen hat sowie alle abgegebenen Enthaltungen. Verliert ein gemeldeter Teilnahmeberechtigter während des Abstimmungsverfahrens die Teilnahmeberechtigung, gilt er als nicht gemeldet.

* Entstehen durch die Auflösung der Kommentare substanzielle Änderungen an der Spezifikation, so ist die Abstimmung zu wiederholen. Hierbei sind teilnahmeberechtigt nur die Teilnehmer aus der vorhergehenden Runde, die eine gültige Stinme abgegeben haben. Dabei dürfen dann nur neue Kommentare abgegeben werden, die sich auf die geänderten Stellen beziehen. (Dieser Zyklus ist ggf. solange zu wiederholen, bis die Spezifikation als angenommen gilt oder gar keine Einigung erzielt werden kann.

* Vor Freigabe der Ergebnisse sind diese zu veröffentlichen.

===Hintergründe zur Verfahrensdurchführung===

Das vorab beschriebene Verfahren wird vielfach als Gängelung bzw. unnötige Zeitverschwendung betitelt. Dabei hat sich dieses Verfahren aus pragmatischen Gründen so entwickelt. Die dazugehörigen Aspekte sollen deshalb kurz aufgeführt werden, damit man:frau es besser einordnen kann:

* Eine offene, transparente Kommentierung mit Einholung einer Antwort vom Kommentierer sorgt dafür, dass eine Diskussion entsteht und der Durchführende nicht willkürlich seine Sicht durchsetzen kann. Damit wäre eine Abstimmung dann obsolet.
* Die Abgabe einer Stimme mit Aufsummation zu einem Gesamtbild dokumentiert die Sicht auf die Spezifikation. Damit werden Zustimmungen explizit gemacht und man kann nicht von fehlenden Ablehnungen auf eine Zustimmung schließen.
* Die beiden vorgenannten Punkte sollen die Qualität es Materials sicherstellen.
* Längere Fristen sind absolut notwendig, damit einer Community ausreichend Gelegenheit gegeben wird, sich das Material anzusehen zu können. (Ein 'über den Zaun werfen und da hast jetzt 10 Tage zur Kommentierung' ist ausgesprochen kontraproduktiv, da wohl so gut wie niemand so kurzfristig genügend Zeit erübrigen kann.)
* Ideal wäre ein Ganzjahreskalender oder zumindest 1 Jahr Vorausplanung, damit man sich Zeit reservieren kann. Dem gegenüber stehen aber meist kurzfristige Notwendigkeiten, eine Spezifikation zu finalisieren. Deshalb eine Ankündigung ein unabdingbares Muss.
* Eine Anmeldeverpflichtung sorgt dafür, dass bekannt ist, wer hinterher eine Stimme abgeben will/wird. Damit ist es möglich, gezielt an eine Stimmabgabe zu erinnern. Eine Anmeldung erlaubt es auch, Fehler im Material noch während des Verfahrens zu korrigieren, ohne dass eine neue Runde notwendig wird. Damit wird eine Beschleunigung insgesamt erzielt.
* Ursprünglich wurde das Material immer gleichwertig, .d.h normativ, kommentiert. Es hat sich aber herausgestellt, dass frühzeitige Rückmeldungen hilfreich sind, um Fehlentwicklungen zu erkennen und entsprechend gegensteuern zu können.
* Änderungen, die aufgrund von Kommentaren vorgenommen wurden und substantiell sind, d.h. Änderungen an der Implementierung zur Folge haben, müssen noch einmal kommentiert werden. Dies begründet sich damit, dass ggf. schon Implementierungen laufen, die von einer Nichtveränderung ausgehen.
* In erneuten Runden dürfen nur geänderte Passagen kommentiert werden, und das auch nur von denjenigen, die bisher teilgenommen haben. Dies garantiert, dass es keinen endlosen Runden ('ping pong'-Effekt) gibt.
* Die Arbeitung des Materials sollte ebenfalls schon offen und transparent erfolgen, um Interessenten frühzeitig ihre Sicht und Informationen einbringen zu lassen. Es ist anzunehmen, dass genau diejenigen das Material später auch kommentieren werden. Insofern spart dieses Vorgehen viel Zeit und unnötige Kommentierungsrunden, so dass die Qualität des Materials steigt und Fristen verkürzt werden können.

'''Damit sorgt die Einhaltung dieser Regeln für eine Beschleunigung insgesamt und führt eben nicht zu der befürchteten Zeitverzögerung!'''

===Qualitätskriterien für Materialien===

Das Material sollte bestimmten Qualitätskriterien genügen. Verschiedene Arbeitsgruppen (https://confluence.hl7.org/display/SGB/Quality+Criteria) bei HL7 International haben dazu Sammlungen verfasst:

* v2.x
** https://confluence.hl7.org/display/INM/Version+2+Quality+Metrics+Document
** https://confluence.hl7.org/display/INM/Approve+V2+Standard+Quality?preview=%2F66928056%2F66928057%2FV2+Standard+Quality.docx
* CDA
** https://confluence.hl7.org/display/SD/CDA+IG+Quality+Criteria
* FHIR
** https://confluence.hl7.org/display/FHIR/1.+FHIR+IG+Quality+Criteria

==[[Bild:Flag_de.svg|border|27px]] HL7 Deutschland==

Für HL7 Deutschland verwendet das o.g. Regelwerk. Stimmberechtigt sind alle Mitglieder bzw. deren benannte Vertreter.

==[[Bild:Flag_de.svg|border|27px]] IHE Deutschland==

IHE Deutschland schließt sich bis auf weiteres diesem Verfahren an. Stimmberechtigt sind ebenfalls Mitglieder bzw. deren benannte Vertreter.

==Andere Organisationen im Interoperabilitätsforum==

Anderen Organisationen steht es frei, sich ebenfalls dem o.g. Regelwerk zu unterwerfen und festzulegen, wer stimmberechtigt ist.

==[[Bild:logo-hl7int.jpg|border|27px]] HL7 International==

Das Verfahren wird bei HL7 International prinzipiell gleich durchgeführt. Neben den direkt Mitgliedern von HL7 International haben auch die Affiliates eine entsprechende Anzahl von Stimmen, die sich nach der Anzahl der jeweiligen Mitglieder richtet. Für HL7-D bedeutet dies derzeit 25 Stimmen. Diese Stimmen werden von sogenannten "Votern" (s.u.) abgegeben, die namentlich benannt und bei HL7 International offiziell gemeldet sein müssen. (Die Voter bekommen dann eine entsprechende Zugangskennung.)

Die Aufgabe der Voter ist es, sich während der Anmeldephase auf der entsprechenden Webseite ([http://www.hl7.org/ctl.cfm?action=ballots.home Ballot Home]) für die jeweiligen Materialien anzumelden (Home: Join a Pool). Welche das sind, wird ihnen über den eMailverteiler ([mailto:voter@hl7.de voter@hl7.de]) mitgeteilt. Kurz vor Ablauf der Ballotphase sollten dann die Ergebnisse mit den Kommentaren feststehen, so dass die Voter dann ihre jeweilige Stimme gemäß dieser Vorgabe abgeben sollten. Hierbei reicht auf der Seite "Vote" ein entsprechendes Kreuz zu machen:

*no Return - Standardeintrag, wenn noch keine Stimme abgegeben wurde
*Affirmative - Zustimmung
*Negative - Ablehnung
*Abstain - Enthaltung

Bei Ablehnung muss noch eine Begründung geliefert werden. Dies geschieht in der Regel durch denjenigen, der sich das Material angesehen hat. Deshalb wird meistens folgender Text unter "Vote Comment" eingetragen: "Please see comments provided by xxxxx". Auf wen dann konkret zu verweisen ist, wird dann ebenfalls mitgeteilt.

Im Zuge der Auflösung der Kommentare (in diesem Prozess ist der Reviewer dann verstärkt eingebunden) wird dann auch mitgeteilt, wann der (negative) Kommentar wieder zurückgezogen werden kann. Dies geschieht ebenfalls über den Emailverteiler.

==[[Bild:Flag_de.svg|border|27px]] IHE International==

Das Balloting internationaler Materialien erfolgt über die individuellen Domänen bei IHE International. teilnahmeberechtigt sind aktive Mitglieder (Details: www.ihe.net).

==Durchsicht der Materialien (Review) vs. Stimmabgabe (Voting)==

Eine immer wieder auftauchende Frage ist nach den Verantwortlichkeiten der beiden Rollen:

{{FAQBox |
'''Voter''' müssen sich die Materialien nicht notwendigerweise ansehen bzw. durcharbeiten und Kommentare erarbeiten. Ihre Hauptaufgabe ist die eigentliche Stimmabgabe. Dies erfordert im Normalfall wenige Minuten Aufwand je Ballot.
 
'''Balloter''' (oder Reviewer) sehen sich die Materialien an und erarbeiten eine qualifizierte Meinung dazu, so dass alle Voter eine entsprechende Stimme abgeben können. Dies ist deutlich aufwändiger und variiert je nach Umfang des Pakets. 
Üblicherweise werden diese Kommentare in einer Exceltabelle standardisiert erfasst, um eine genaue Zuordnung treffen zu können.
}}

Im Prinzip kann jedes Mitglied von HL7 Deutschland sich das Material ansehen (Zugang über die Mitgliederwebseite, http://www.hl7.de/publikationen/abstimmungen.php) und dann kommentieren. Im allgemeinen wird die Ankündigung von diesen Abstimmungsverfahren von HL7 USA an die TC-Liste weitergeleitet, so dass jeder informiert ist und sich auf der Ballotseite umsehen und dann frei entscheiden kann, ob er zu einem bestimmten Paket etwas beitragen kann bzw. möchte.

Sollte sich jemand entscheiden, zu einem Ballot etwas beitragen zu wollen, so sollte er auf die Ankündigungsemail möglichst zügig reagieren und mitteilen, zu welchem Paket dann eine Kommentierung erwartet werden kann. Die Summe aller dieser Meldungen wird dann den Votern zwecks Anmeldung wie oben geschildert mitgeteilt.

{{AlertBox |
Hier sollte berücksichtigt werden, dass Basis-Materialien (Core Principles, RIM, CDA, HL7 v2.x, OID Management, etc.) durchaus signifikante Auswirkungen auf die Entwicklungen in Deutschland haben und von daher kritisch begutachtet werden sollten (müssen).
}}

Zum Ablauf der Frist wäre es dann aber auch toll, wenn dann die Kommentare - oder zumindest die intendierte Stimme - rechtzeitig abgeliefert werden, damit die Voter entsprechend abstimmen können. Der Koordinator (einer der Voter) wird dann die Aufgabe übernehmen, auch die Kommentare auf die Ballot-Seite hochzuladen, so dass alle anderen dann ggf. (im Falle einer negativen Stimme) auf diesen verweisen kann. Das Hochladen der Kommentare kann unabhängig von den Stimmabgaben der Voter geschehen. Sollte also ein Reviewer im Zuge der Durchsicht feststellen, dass es negative Kommentare geben wird und deshalb ein Paket abzulehnen ist, so sollte dies möglichst umgehend mitgeteilt werden, damit möglichst viel Zeit zur Stimmabgabe bleibt.

{{NoteBox |
Um die Arbeit für die Reviewer zu vereinfachen, sind alle Balloter auch gleichzeitig Voter, da sie darüber einen direkten Zugang zu allen Materialien haben.
}}

==Personenzuordnung (alphabetisch)==

Nachfolgend die Liste der (bei HL7 International derzeit gemeldeten) Personen:

{| class="hl7table"
|-
! Person !! Voter (international) !! Balloter (Spezialisierung) !! Kommentar
|-
| Mathias Aschhoff (RZV) || x || CDA ||
|-
| Thomas Bender (Agfa Healthcare) || x || ||
|-
| Prof. Dr. Bernd Blobel (e-Health Competence Center) || x || Security, EHR ||
|-
| Dominik Brammen (Uni Magdeburg) || x || Emergency ||
|-
| Brad Genereaux (Agfa) || x || ||
|-
| Daniel Flemming (Katholische Stiftungshochschule München) || x || Pflege (Patient Care), CDA ||
|-
| Dr. Christof Gessner (MxDx) || x || ||
|-
| Dr. Christine Haas (DIMDI) || x || ||
|-
| Prof. Dr. Gunter Haroske (Krankenhaus Dresden-Friedrichstadt) || x || Pathologie ||
|-
| Simone Heckmann (Gefyra) || x || v2, FHIR ||
|-
| Diana Lizzhaid Ovelgönne (Siemens) || x || ||
|-
| Dr. Kai U. Heitmann (Heitmann Consulting and Services) || x || CDA, Templates ||
|-
| Sander Jones (Agfa Healthcare) || x || v2 ||
|-
| Stefan Lang (Lang Health IT Consulting) || x || FHIR ||

|-
| Dr. Frank Oemig (DTHS) || x || HL7 v2.x, CDA, Conformance, FHIR ||
|-
| Christian Ohr (ICW) || x || ||
|-
| Verena Ritter (Agfa Healthcare) || x || ||
|-
| Peter Scholz (OSM GmbH) || x || ||

|-
| Prof. Dr. Martin Staemmler (FH Stralsund) || x || Personal Health, Health Records, HL7 v2.x, CDA ||
|-
| Jose Costa Teixeira (Agfa Healthcare) || x || ||
|-
| Prof. Dr. Sylvia Thun (Hochschule Krefeld) || x || ||
|-
|Patrick Werner (Molit gGmbH) || x || FHIR
|}

{{NoteBox |
Da Deutschland derzeit mehr Stimmen abgeben darf als Voter angemeldet sind, besteht hier noch eine Deckungslücke.

Auch sollte davon ausgegangen werden, dass es weitere Experten für bestimmte Domänen gibt. Es wird daher um Rückmeldung gebeten, wer bereits ist, hier aktiv zu werden...
}}

== Legenda und Symbole zur Verwendung ==
{{:Abstimmung_legenda_phasen}}
{{:Abstimmung_legenda_gesamtstimme}}
{{:Abstimmung_legenda_kommentare}}

[[Kategorie:Enzyklopädie]]

Ballotbox FHIR-Basisprofile

2021-03-15T12:30:38Z

Foemig:

{{BallotboxBegin| FHIR Basisprofile | Profile, Extensions und Value Sets für FHIR }}

{{BallotboxItem
|status = vote
|type = STU
|version = 1.0.0
|date = 19.01.2021
|from = 18.02.2021
|to = 31.03.2021
|ballotannouncement = Abstimmungsankündigung_20210119
|ballotstart =
|pdf = https://ig.fhir.de/basisprofile-de/1.0.0-alpha1/
|wiki =
|artdecor = https://github.com/hl7germany/basisprofil-de
}}

{{BallotboxItem
|status = reconc
|type = Informativ
|version = 0.2
|date = 30.01.2019
|from = 17.11.2018
|to = 17.12.2018
|ballotannouncement = Abstimmungsankündigung_20181119
|ballotstart =
|pdf = http://ig.fhir.de/basisprofile-de/0.2
|wiki =
|artdecor = https://github.com/hl7germany/basisprofil-de
}}

{{BallotboxItem
|status = reconc
|type = Informativ
|version = 0.1
|date = 08.07.2017
|from = 07.08.2017
|to = 25.09.2017
|positive = -
|negative = -
|abstain = -
|novote = -
|total = -
|result = -
|comments =
|ballotannouncement = Abstimmungsankündigung_20170708
|pdf = http://ig.fhir.de/basisprofile-de/0.1
|wiki =
|artdecor = https://github.com/hl7germany/basisprofil-de
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]

IF 2021-03-15

2021-03-09T13:24:32Z

Foemig:

{{#CustomTitle:Interoperabilitätsforum / TC-Arbeit 15. und 16. März 2021 Online}}
{{Infobox Dokument
|Title = Interoperabilitätsforum / 15. und 16. März 2021 Online
|Short = Interoperabilitätsforum 2021-03-15
|Type = Agenda
|Version = 1.0
|Copyright = 2021
|Namespace = iopfp
|Status =
|Period =
|OID =
|Realm = Deutschland
}}

= Veranstaltungsort und -zeiten =
15. und 16. März 2021 als Online-Meeting

{{BeginRedBox|Das Treffen wird als '''Online-Meeting''' abgehalten}}

Einwahldaten am ersten Tag zwischen 11 und 17 Uhr und am zweiten Tag zwischen 9 und 14 Uhr

<pre style="background-color:#eef">Interoperabilitätsforum 15. und 16. März 2021

Nehmen Sie an meinem Meeting per Computer, Tablet oder Smartphone teil.
https://global.gotomeeting.com/join/339384629

Sie können sich auch über ein Telefon einwählen.
Deutschland: +49 891 2140 2090

Zugangscode: 339-384-629

Weitere Telefonnummern
Österreich: +43 7 2081 5427
Schweiz: +41 435 5015 61
</pre>
{{EndRedBox}}

Tag 1
* ab 11 Uhr bis ca. 15 Uhr, mit Pause ca. 12:30-13:00
Tag 2
* 9 Uhr bis ca. 12 Uhr, mit Pause ca. 10:30-11:00
Siehe auch Abschnitt [[#Hinweise|Hinweise]].

Das [[Interoperabilitätsforum]] diskutiert und bearbeitet Themen zur Standardisierung der Technischen Komitees der HL7-Benutzergruppe, IHE Deutschland und anderer Standardisierungsaktivitäten im Gesundheitswesen.

=Agenda (Entwurf)=
Die Agenda wird direkt zu Beginn des Meetings finalisiert.

==Administratives==
===Termine 2021 für das Interoperabilitätsforum===
*15. / 16. März 2021 als Online Meeting – Mo/Di
*17. / 18. Juni 2021 – Do/Fr
*13. / 14. September 2021 – Mo/Di (Präsenztermin geplant in Berlin)
* 2. / 3. Dezember 2021 – Do/Fr (Präsenztermin geplant in Köln)
===Neue Webpräsenz des Interoperabilitätsforum===
* seit Januar 2021 online gestellt, weitere Pläne
===Wahl des Stellvertreters zu V2-TC===

==Leitfäden==
===Ergebnis- und Prozessqualität von CDA und FHIR Implementierungsleitfäden===
===Laufende Kommentierungsverfahren===
* HL7 Basisprofile R4
===Abgeschlossene Kommentierungsverfahren===
* ePflegebericht in FHIR (M. Przysucha): Auflösung der Kommentare

==Projekt-Vorstellung==
===Projekte des Nationalen Forschungsnetzwerks NFN (Sylvia Thun)===
* Coordination on mobile pandemic apps best practice and solution sharing COMPASS
* COVID-19 Data Exchange Platform CODEX
* Nationales Pandemie Kohorten Netz NAPKON

==Medizinische Informationsobjekte MIOs (Moderation: Dr. Kai Heitmann, hih), Montag 13-14 Uhr==
===Kurze Einleitung zu MIO und den Planungen für 2021 (Dr. Bernhard Tenckhoff, KBV)===
===International Patient Summary und Patientenkurzakte (Alexander Rosenberger, mio42)===
===Assistierte MIOs (Joana Griesler, mio42)===

==eHealth-Standards in Deutschland und Europa: Zusammenarbeit und Governance (Moderation: Dr. Christof Gessner, gematik)==
===Ergebnisse der Abstimmung und der Dokumente zu Interoperabilität 2025 (Dr. Kai Heitmann, hih)===
===Update gematik "Interoperabilität 2.0" (30 min, Steffen Hennecke, gematik)===
===EHRxF: Austauschformat für EHR-Inhalte - Projektstatus und Perspektiven (Dr. Christof Gessner, gematik)===

=Protokoll=

=Hinweise=
'''Teilnahme:''' An den Sitzungen können alle Interessierten teilnehmen, egal ob Mitglied bei HL7, IHE oder einer der kooperierenden Organisationen oder nicht! Um eine vorherige Anmeldung über https://doodle.com/poll/we2mifvmsd47agna und an [mailto:info@interoperabilitaetsforum.de info@interoperabilitaetsforum.de] wird allerdings gebeten.

'''Zeiten:'''
Tag 1
* ab 11 Uhr bis ca. 17 Uhr
Tag 2
* 9 Uhr bis ca. 14 Uhr

=Medienpartner=

Unsere Medienpartner sind:

{| width="100%"
|-
| [[file:Logo_kma.png|200px|kma]]
| [[file:Logo_EHEALTHCOM.jpg|300px|eHealthcom]]
| [[file:Logo_kh-it.PNG|300px|KH-IT]]
|}


[[Kategorie:IF Treffen]]
[[Kategorie:Interoperabilitätsforum 2021]]

Ihevs:DocumentEntry.typeCode

2021-03-05T10:52:13Z

Foemig:

{{DocumentPart}}
==DocumentEntry.typeCode==
Das Attribut typeCode ist gemäß IHE XDS zwingend gefordert und kann zusätzlich zu (bzw. zusammen mit) dem classCode zur genaueren Klassifizierung des Dokuments genutzt werden, z.B. kann ein Dokument mit classCode "Befundberichte" durch den typeCode als "Pathologiebefundbericht" oder als "Ergebnisse bildgebender Diagnostik" gekennzeichnet werden. Das Attribut typeCode stellt keine Spezialisierung von classCode dar. Somit kann ein bestimmter typeCode mit verschiedenen classCodes zur Beschreibung unterschiedlicher Dokumente kombiniert werden. Zum Beispiel haben ein Röntgenbild und der dazugehörige Radiologie-Befund den gleichen typeCode "Ergebnisse bildgebender Diagnostik" aber zwei unterschiedliche classCodes, "Bilddaten" bzw."Befundberichte". Daraus folgt, dass ein Dokument sowohl einem classCode als auch einem typeCode explizit zugeordnet werden muss; die Zuordnung zu einem typeCode allein reicht nicht aus, weil hierüber kein implizites Mapping auf einen einzigen „übergeordneten“ classCode möglich ist.

Eine noch detailliertere Beschreibung der Dokumentenart kann jederzeit nach Bedarf über das Freitext-Attribut "DocumentEntry.title" erfolgen (z.B. "Röntgen-Thorax-Befund" oder "Anamnesebogen"). Dieses wird in der Regel nicht maschinell ausgewertet (d.h. nicht zur Suche, Filterung, Gliederung herangezogen), sondern dient primär dem Anwender als zusätzliche Information im Benutzerinterface. Auch wird in der Dokumentenquelle bei medizinischen Dokumenten häufig kein anderer Dokumententitel geführt, daher bietet sich eine solche detaillierte Beschreibung der Dokumentenart ("Röntgen-Thorax-Befund") als Titel an.

IHE International empfiehlt, dass eine XDS Affinity Domain die Wertemenge für das Attribut typeCode definiert. Zur Definition der Wertemenge kann auf internationale Codes aus SNOMED CT, LOINC oder auf eigene Codes zurückgegriffen werden. Da die internationalen Codesysteme nicht alle gängigen Dokumententypen in Deutschland abbilden, hat man sich in der Arbeitsgruppe "Value Sets" von IHE Deutschland entschieden, ein eigenes Codesystem zu erstellen. Dieses Codesystem ist nicht hierarchisch aufgebaut, auch wenn dies manchmal den Anschein erweckt. Das Konzept "Ergebnisse Diagnostik" ist beispielsweise nicht der Oberbegriff zu Konzepten wie "Ergebnisse Funktionsdiagnostik" oder "Ergebnisse Mikrobiologie", sondern umfasst nur die Dokumente vom Typ "Ergebnisse Diagnostik", die nicht durch andere Konzepte abgedeckt werden.

Bei Verwendung von [https://wiki.ihe.net/index.php/Advanced_Patient_Privacy_Consents IHE APPC] Dokumenten muss auch der dort fest vorgegebene LOINC Code unterstützt werden. Bei Verwendung von [https://wiki.ihe.net/index.php/Basic_Patient_Privacy_Consents IHE BPPC] Dokumenten dagegen ist der Einsatz von LOINC für den typeCode nicht gefordert, stattdessen gibt es bei IHE BPPC eine Vorgabe für den Einsatz eines LOINC Codes als classCode.

Die Codes für das ValueSet werden in ART-DECOR zusammen mit den anderen von IHE Deutschland erstellten ValueSets veröffentlicht (http://art-decor.org/art-decor/decor-valuesets--ihede-) und hier eingebunden. Sollte es zu Darstellungsproblemen bei den eingebundenen Wertelisten kommen, bitten wir den geneigten Leser direkt auf [[https://art-decor.org/art-decor/decor-valuesets--ihede-?id=1.2.276.0.76.11.38&effectiveDate=2018-07-13T16:22:05&language=de-DE ART-DECOR]] zuzugreifen.

{{:1.2.276.0.76.11.38/dynamic }}

[[Kategorie:Enzyklopädie]]
[[Kategorie:Abkürzungen|typeCode]]
[[Kategorie:ihevs]]

Ihevs:DocumentEntry.classCode

2021-03-05T10:51:17Z

Foemig:

{{DocumentPart}}
==DocumentEntry.classCode==
Das Attribut ,classCode' ist gemäß IHE XDS zwingend gefordert und erlaubt eine erste Klassifizierung der Dokumente in der XDS Document Registry in Dokumentenklassen, wie z.B. Briefe, Befundberichte oder Bilddaten. Die Wertemenge für diese Klassen sollte nicht zu detailliert sein, da im Attribut ‚typeCode‘ eine weitere, verfeinerte Beschreibung der Dokumente erfolgt, die allerdings keine Spezialisierung des ,classCode' darstellen muss.

IHE International empfiehlt, dass eine XDS Affinity Domain die Wertemenge für das Attribut ‚classCode' definiert. Zur Definition der Wertemenge kann auf internationale Codes aus SNOMED CT, LOINC oder auf eigene Codes zurückgegriffen werden.

Da die internationalen Codesysteme nicht alle in Deutschland gängigen Dokumentenklassen abbilden, hat man sich in der Arbeitsgruppe „Value Sets“ von IHE Deutschland entschieden, ein eigenes Codesystem zu erstellen. Zusätzlich muss bei Verwendung von [https://wiki.ihe.net/index.php/Basic_Patient_Privacy_Consents IHE BPPC] Dokumenten auch der dort fest vorgegebene LOINC Code unterstützt werden. Bei Verwendung von [https://wiki.ihe.net/index.php/Advanced_Patient_Privacy_Consents IHE APPC] Dokumenten dagegen ist der Einsatz von LOINC für den classCode nicht gefordert, stattdessen gibt es bei IHE APPC eine Vorgabe für den Einsatz eines LOINC Codes als typeCode.

Die Codes für das ValueSet werden in ART-DECOR zusammen mit den anderen von IHE Deutschland erstellten ValueSets veröffentlicht (http://art-decor.org/art-decor/decor-valuesets--ihede-) und hier eingebunden. Sollte es zu Darstellungsproblemen bei den eingebundenen Wertelisten kommen, bitten wir den geneigten Leser direkt auf [[https://art-decor.org/art-decor/decor-valuesets--ihede-?id=1.2.276.0.76.11.32&effectiveDate=2018-07-13T13:23:15&language=de-DE ART-DECOR]] zuzugreifen.

{{:1.2.276.0.76.11.32/dynamic }}

[[Kategorie:Enzyklopädie]]
[[Kategorie:Abkürzungen|classCode]]
[[Kategorie:ihevs]]

IG:Value Sets für XDS

2021-02-24T19:51:35Z

Foemig:

{{Infobox Dokument
|Title = Value Sets für Aktenprojekte im deutschen Gesundheitswesen
|Short = Value Sets für XDS
|Namespace = ihevs
|Type = Implementierungsleitfaden
|Version = 3.0 Draft
|Submitted = IHE Deutschland
|Date = 09.10.2021
|Copyright = 2021
|Status = Draft
|Period = Final
|Verfahren = STU
|OID = 1.3.6.1.4.1.19376.3.276.1.7.7
|Realm = Deutschland
|Custodian = IHE
}}

{{Infobox Ballot Begin}}
{{Ballot | Version = 0.1 | Date = 23.05.2016 | Status = Draft | Realm = Deutschland| Othericon = x
| Otherdocuments = http://download.hl7.de/documents/ihexdsvs/Value_Sets4XDS-v01.pdf
| Comment =
}}
{{Ballot | Version = 1.0 | Date = 10.11.2016 | Status = Final | Realm = Deutschland| Othericon = x
| Otherdocuments = http://www.ihe-d.de/download/value-sets-fuer-xds-metadaten
| Comment =
}}
{{Ballot | Version = 1.1 | Date = 22.05.2018 | Status = Draft | Realm = Deutschland| Othericon = x
| Otherdocuments = http://wiki.hl7.de/images/Value_Sets4XDS-v11.pdf
| Comment =
}}
{{Ballot | Version = 2.0 | Date = 09.10.2018 | Status = active| Realm = Deutschland| Othericon = x
| Otherdocuments = http://wiki.hl7.de/images/Value_Sets4XDS-v20.pdf
| Comment =
}}

{{Infobox Ballot End}}

{{Infobox Contributors Begin}}
{{Contributor | Logo = Logo_ihe.png | Name = IHE Deutschland| Location = Berlin}}
{{Contributor | Logo = Logo_bvitg.JPG | Name = bvitg (Bundesverband Gesundheits-IT) | Location = Berlin}}
{{Contributor | Logo = Logo_icw.jpg | Name = ICW | Location = Walldorf }}
{{Contributor | Logo = Logo-t-systems.jpg | Name = Deutsche Telekom Healthcare and Security Solutions GmbH | Location = Bonn }}
{{Contributor | Logo = Logo-uk-heidelberg.png | Name = Uniklinik Heidelberg (ZIM) | Location = Heidelberg }}
{{Contributor | Logo = Logo-uk-freiburg.png | Name = Uniklinik Freiburg | Location = Freiburg }}
{{Contributor | Logo = Logo-cerner.jpeg | Name = Cerner | Location = Berlin }}
{{Contributor | Logo = Logo-visus.jpg | Name = VISUS Health IT GmbH | Location = Bochum }}
{{Contributor | Logo = FALKO LOGO.jpg | Name = FALKO.NRW gefördert durch EFRE und das Land Nordrhein-Westfalen|Location=}}
{{Contributor | Logo = Logo-rzv.jpg | Name = RZV Rechenzentrum Volmarstein GmbH | Location = Wetter (Ruhr) }}
{{Infobox Contributors End}}

{{HL7transclude| ihevs:Einleitung}}
<div class="landscape">
{{HL7transclude| ihevs:FAQs}}
{{HL7transclude| ihevs:Vokabular-Management}}
{{HL7transclude| ihevs:Value-Set-Tabellen}}
=Value Sets=
{{HL7transclude| ihevs:DocumentEntry.author}}
{{HL7transclude| ihevs:DocumentEntry.classCode}}
{{HL7transclude| ihevs:DocumentEntry.confidentialityCode}}
{{HL7transclude| ihevs:DocumentEntry.eventCodeList}}
{{HL7transclude| ihevs:DocumentEntry.formatCode}}
{{HL7transclude| ihevs:DocumentEntry.healthcareFacilityTypeCode}}
{{HL7transclude| Ihevs:DocumentEntry.languageCode}}
{{HL7transclude| ihevs:DocumentEntry.PracticeSettingCode}}
{{HL7transclude| ihevs:DocumentEntry.typeCode}}
{{HL7transclude| ihevs:SubmissionSet.contentTypeCode}}
{{HL7transclude| ihevs:Folder.codeList}}
</div>

OID-Konzept IHE-D

2021-02-24T19:49:00Z

Foemig:

{{Infobox Dokument
|Title OID-Konzept von IHE Deutschland
|Short = OID-Konzept IHE-D
|Namespace = cdaab2
|Type = Konzept
|Version = 0.2
|Submitted = .
|Date = 24. Februar 2021
|Copyright = 2012
|Status = Entwurf
|Period = Entwurf
|OID = n.n.
|Realm = Deutschland
}}

[[file:IHE Deutschland final rgb web.jpg|200px|Logo IHE-D]]

=OID Konzept von IHE-Deutschland=

==Root-OID==
Als root-OID für IHE Deutschland wurde 1.3.6.1.4.1.19376.3.276 vergeben: 

<blockquote>
1 = International Organization for Standardization (ISO) 
3 = Organization identification schemes registered according to ISO/IEC 6523-2 
6 = United States Department of Defense (DoD) 
1 = internet 
4 = Internet Assigned Numbers Authority (IANA) 
1 = Private enterprises 
19376 = Integrating the Healthcare Enterprise International 
3 = Organizations 
276 = IHE Deutschland 
</blockquote>

Direkt unter der Root-OID von IHe Deutschland eine Ebene vorgesehen, welche das jeweilige Konzept versioniert. Da das jeweilige OID-Konzept auch in der Zukunft Bestand haben muss, IHE Deutschland aber nicht ausschließen kann, in der Zukunft das OID Konzept ändern oder ein völlig Neues erstellen zu müssen, ist die Einführung einer Versionsnummer die einzige umsetzbare Möglichkeit beiden Anforderungen (Zukunftssicherheit und Anpassbarkeit an künftige Anforderungen) zu genügen. Nach der Versionsnummer erfolgt eine Nutzung der extension entsprechend der für Deutschland empfohlenen Vergabe.

==Aufbau des OID-Baums für IHE-D==
{| class="hl7table"
|-
!Extension (Sub-Branch/Type) !! Beschreibung !! Bemerkung
|-
! *.1 !! OID für das OID Konzept Version 1 !!
|-
|.1.1|| Interne Objekte || interne Artefacts wie Modelle
|-
|.1.1.1 || Ordnertypen ||
|-
|.1.1.2 || Auswahllisten ||
|-
|.1.1.3 || Mitarbeiter ||
|-
! *.1.2 !! interne Organisationsstrukturen !!
|-
! *.1.3 !! Instanzen-Identifikationen !!
|-
|.1.3.1 || Organisationen ||
|-
|.1.3.2 || Personen ||
|-
|.1.3.2.1 || Identifikation des ID-Pools für Patienten ||
|-
|.1.3.2.2 || Identifikation des ID-Pools für Personen allgemein (Ärzte, Betreuer, Kontakte, etc.) ||
|-
|.1.3.3 || Identifikation des ID-Pools für Fälle ||
|-
! *.1.4 !! Identifikation des ID-Pools für Institutionen (Organisationen, Einheiten, etc.) !! Allgemeine Identifikationsmechanismen wie Personalausweis usw.
|-
|.1.4.1 || Krankenhäuser || Wenn möglich, soll ein Krankenhaus eine eigene OID bei DIMDI beantragen
|-
|.1.4.2 || Praxen niedergelassener Ärzte || Unterhalb dieser Praxis-Ebene wird eine Ebene für Fachbereiche (Allgemeinmedizin, ...) eingeführt. Die Praxis jedes niedergelassenen Arztes bekommt eine eigene OID. Unter dieser Ebene werden ggfs. für Ärzte und Systeme eigene Subtypen definiert.
|-
|.1.4.3 || Systeme || Alle angeschlossenen Systeme bekommen eine OID. Unterhalb des Systems werden ggfs. ebenfalls bestimmte Subtypen definiert.
|-
! *.1.5 !! '''Kodierschemas''' !!
|-
|1.3.6.1.4.1.19376.3.276.1.5.1 || derzeit unbenutzt
|-
|1.3.6.1.4.1.19376.3.276.1.5.2 || Healthcare Facility Type Code: patientenversorgende Einrichtung || 1.2.276.0.76.11.58
|-
|1.3.6.1.4.1.19376.3.276.1.5.3 || Healthcare Facility Type Code: sonstige Einrichtung || 1.2.276.0.76.11.59
|-
|1.3.6.1.4.1.19376.3.276.1.5.4 || Practice Setting Code (ärztl. Fachrichtungen) || 1.2.276.0.76.11.69
|-
|1.3.6.1.4.1.19376.3.276.1.5.5 || Practice Setting Code (nicht-ärztl. Fachrichtungen) || 1.2.276.0.76.11.70
|-
|1.3.6.1.4.1.19376.3.276.1.5.6 || XDS formatCode (vgl. URN-Konzept) ||
|-
|1.3.6.1.4.1.19376.3.276.1.5.7 || XDS Folder.codeList || 1.2.276.0.76.11.40
|-
|1.3.6.1.4.1.19376.3.276.1.5.8 || XDS classCode || 1.2.276.0.76.11.32
|-
|1.3.6.1.4.1.19376.3.276.1.5.9 || XDS typeCode || 1.2.276.0.76.11.38
|-
|1.3.6.1.4.1.19376.3.276.1.5.10 || Patienteneinschätzung der Dokumenten-Sensibilität || 1.2.276.0.76.11.33
|-
|1.3.6.1.4.1.19376.3.276.1.5.11 || Authorspecialty (nicht ärztliche Berufe) ||
|-
|1.3.6.1.4.1.19376.3.276.1.5.12 || SubmissionSet Contenttype Code ||
|-
|1.3.6.1.4.1.19376.3.276.1.5.13 || Authorrole Prozessrollen ||
|-
|1.3.6.1.4.1.19376.3.276.1.5.14 || Authorrole Patientenbeziehungsrollen ||
|-
|1.3.6.1.4.1.19376.3.276.1.5.15 || EventCodeList "Hinweise"/"Informationen" /"Warnungen" ||
|-
|1.3.6.1.4.1.19376.3.276.1.5.16 || EventCodeList "Ereignisse CS#1: Aufnahme - Verlegung - Entlassung" ||
|-
|1.3.6.1.4.1.19376.3.276.1.5.17 || retired / bitte nicht verwendet ||
|-
!*.1.6 !! Metadaten !!
|-
|.1.6.1 || Ordner-Metadaten ||
|-
!*.1.7 !! '''Dokumente''' !!
|-
|1.3.6.1.4.1.19376.3.276.1.7.1 || OID-Konzept ||
|-
|1.3.6.1.4.1.19376.3.276.1.7.2 || Identifikation des ID-Pools für CDA-Dokumente ||
|-
|1.3.6.1.4.1.19376.3.276.1.7.3 || Identifikation des ID-Pools für externe Dokumente (in CDAs verlinkt) ||
|-
|1.3.6.1.4.1.19376.3.276.1.7.4 || IHE_D Cookbook ||
|-
|1.3.6.1.4.1.19376.3.276.1.7.5 || Value-Set-Leitfaden (Vers. 1.0, Nov.2016) ||
|-
|1.3.6.1.4.1.19376.3.276.1.7.6 || Value-Set-Leitfaden (Vers. 2.0, Nov.2018) ||
|-
|1.3.6.1.4.1.19376.3.276.1.7.7 || Value-Set-Leitfaden (Vers. 3.0, Nov.2021) ||
|-
! *.1.9 !! Nachrichtenprofile !!
|-
|... || ||
|-
! *.1.10 !! Interne Templates !!
|-
|.1.10.1 || Document Templates ||
|-
|.1.10.1.1 || root-OID für Template-Ids ||
|-
|.1.10.2 || Section Templates ||
|-
|.1.10.2.1 || Identifikation des ID-Pools für CDA-Formularteile ||
|-
|.1.10.3 || Entry Templates ||
|-
! *.1.11 !! '''Value Sets''' !!
|-
|1.3.6.1.4.1.19376.3.276.1.11.1 || ''IHEXDSclassCode: Dokumentenart'' '''deprecated, stattdessen 1.2.276.0.76.11.32 verwenden''' ||
|-
|1.3.6.1.4.1.19376.3.276.1.11.2 || ''Vertraulichkeit des Dokumentes'' '''deprecated, stattdessen 1.2.276.0.76.11.33 verwenden''' ||
|-
|... || ||
|-
! *.1.12 !! Deutsch-spezifische Erweiterungen von seitens der Organisation/Firma verwalteten Kodierschemas !!
|-
|... || ||
|-
! *.1.15 !! Kodierschemas seitens Organisation/Firma verwaltet !!
|-
|... || ||
|-
! *.1.60 !! Projekte !!
|-
|... || ||
|-
! *.1.64 !! Policy !!
|-
|... || ||
|-
! *.1.67 !! Installations-Instanzen von Softwaresystemen !!
|-
|... || ||
|-
!*.1.77 !! ART-DECOR !!
|-
|... || ||
|-
!*.1.99 !! Experimentell / Test !!
|-
|... || ||
|}

== Fußnoten ==
<references />

Ihevs:Einleitung

2021-02-24T19:31:23Z

Foemig:

{{DocumentPart}}
=Einleitung=

== Hintergrund ==

Die IHE Document Sharing Profile (IHE XD*) zum einrichtungsübergreifenden Austausch medizinischer Dokumente und Bilddaten werden in Projekten in ganz Deutschland verwendet. Hierzu zählen u.a. folgende Profile:

* IHE XDS (Cross-enterprise Document Sharing)
* IHE XDS-I (Cross-enterprise Document Sharing for Imaging)
* IHE XDR (Cross-enterprise Reliable Document Interchange)
* IHE XDM (Cross-enterprise Document Media Interchange)

Diese IHE Profile stellen eine moderne, internationale Grundlage für den elektronischen Austausch medizinischer Dokumente im Gesundheitswesen dar. Das [[IHE DE Cookbook]] beschreibt ausführlich, wie verschiedene [[IHE Integrationsprofile]] zu einem komplexen Use Case zusammengebaut und eingesetzt werden können.

Zur besseren Auffindbarkeit, leichteren Anzeige, Auswertung und Archivierung sollten die ausgetauschten Dokumente und Bilddaten standardisiert klassifiziert werden und somit auch semantisch interoperabel sein. Daher schreiben die IHE XD* Profile einen umfangreichen Satz an nutzbaren Attributen (sog. Metadaten), wie z.B. Fachrichtung, Einrichtungsart und Dokumententyp zur Beschreibung der auszutauschenden Daten vor. Die internationalen IHE Profile geben hier jedoch keine konkreten Terminologien vor, um die häufig sehr landestypischen Konzepte (z.B. ein MVZ als Einrichtungsart) durch eine geeignete Festlegung abbilden zu können.

== Aufgaben der IHE XD* Metadaten ==
Die IHE XD* Metadaten erfüllen im Wesentlichen folgende Aufgaben:
* Identifizierung des Patienten, auf den sich das Dokument bezieht
* Beschreibung der Herkunft des Dokuments
* Erfüllung der Anforderungen zu Sicherheit und Vertraulichkeit der Dokumente
* inhaltliche Beschreibung, um die Dokumente möglichst schnell und zuverlässig wiederzufinden und um eine einfach navigierbare Aktensicht aufzubauen
* Beschreibung des Lebenszyklus des Dokumentes, z.B. ob es noch aktuell ist oder durch ein anderes Dokument ersetzt wurde
* Erleichterung der maschinellen Verarbeitung der Dokumente, z.B. zur Entscheidung welcher Viewer für die Anzeige des Dokuments geeignet ist

== Beispiel für die Verwendung und das Zusammenspiel der Metadaten ==

In einem Krankenhaus wird von einem Radiologen ein Radiologie-Befund im Format PDF erstellt. Diesem werden folgende Metadaten zugeordnet:
* DocumentEntry.classCode: Befundbericht (BEF)
* DocumentEntry.typeCode: Ergebnisse Bildgebender Diagnostik (BILD)
* DocumentEntry.healthcareFacilityTypeCode: Krankenhaus (KHS)
* DocumentEntry.practiceSettingCode: Radiologie (RADI)
* DocumentEntry.formatCode: urn:ihe:iti:xds:2017:mimeTypeSufficient
* DocumentEntry.mimeType: application/pdf

Diese Metadaten werden in der XDS Document Registry gespeichert und können für die Suche nach den Dokumenten genutzt werden. Beispielsweise können so alle Radiologie-Befunde gefunden werden, indem in der XDS Document Registry nach XDSDocumentEntry.classCode = „Befund“, XDSDocumentEntry.typeCode = „Ergebnisse Bildgebende Diagnostik“ und XDSDocumentEntry.practiceSettingCode = „Radiologie“ gesucht wird.

Zur korrekten Anzeige der Dokumente sind weitere Informationen über den XDSDocumentEntry.formatCode und den XDSDocumentEntry.mimeType notwendig.

Diese hier definierten ValueSets verstehen sich als eine grobe Klassifizierung der auzutauschenden Dokumente in Kategorien. Eine feinere Unterscheidung der Dokumente ist über den Dokumententitel möglich, welcher frei wählbar ist.

== Ziel des Projekts ==
Ziel des Projektes ist die Erarbeitung gemeinsamer Klassifizierungsvorgaben, damit die unterschiedlichen IHE XDS Projekte in Deutschland in Zukunft auch überregional (bzw. zwischen verschiedenen Affinity Domains) einfacher Dokumente austauschen können und um neuen Projekten einen schnelleren Einstieg zu ermöglichen.

Folgende Value Sets wurden für die erste Version des Leitfadens bereitgestellt:

* DocumentEntry.classCode
* DocumentEntry.typeCode
* DocumentEntry.healthcareFacilityTypeCode
* DocumentEntry.practiceSettingCode
* DocumentEntry.formatCode
* DocumentEntry.languageCode
* Folder.codeList

Folgende Value Sets wurden für die zweite Version des Leitfadens bereitgestellt:
* DocumentEntry.authorRole
* DocumentEntry.authorSpecialty
* DocumentEntry.confidentialityCode
* DocumentEntry.eventCodeList
* SubmissionSet.contentTypeCode

Folgende Value Sets wurden für die dritte Version des Leitfadens bereitgestellt/angepasst:
* DocumentEntry.classCode
* DocumentEntry.typeCode
* DocumentEntry.formatCode
* DocumentEntry.practiceSettingCode
* DocumentEntry.authorSpecialty
* DocumentEntry.eventCodeList

== Vorgehensweise für die erste Version ==

Zur Definition der Value Sets wurde eine Arbeitsgruppe aus Vertretern von Kliniken (Anwendern) und Herstellern von Anwendungssystemen gebildet. Diese Arbeitsgruppe „Value Sets“ ist Teil der „Cookbook“-Initiative von IHE Deutschland, deren Ziel es ist, die Nutzung moderner IHE Profile durch die Beschreibung von „Lösungs-Rezepten“ für Deutschland zu vereinfachen.

Innerhalb der Arbeitsgruppe wurden zunächst die Value Sets identifiziert, deren Abstimmungsbedarf als besonders hoch priorisiert wurde. Dazu zählen:

* Dokumentenklasse (DocumentEntry.classCode) zur Beschreibung des Inhalts
* Dokumententyp (DocumentEntry.typeCode) zur Beschreibung des Inhalts
* Einrichtungsart (DocumentEntry.healthcareFacilityTypeCode) der erstellenden Institution
* Fachrichtung (DocumentEntry.practiceSettingCode) der erstellenden Institution
* Dokumentenformat (DocumentEntry.formatCode) zur leichteren Dokumentenverarbeitung
* Dokumentensprache (DocumentEntry.languageCode) zur Sprache, in dem das Dokumenten hauptsächlich verfasst wurde
* Ordnerklassifizierung (Folder.codeList) zur Kennzeichnung der Inhalte eines Ordners

Zur Erarbeitung der Value Sets wurde ein Use Case erstellt, der beschreibt, welche Dokumente typischerweise während des Krankheitsverlaufes eines Herzinfarkts erstellt werden, und zwischen wem sie ausgetauscht werden. Parallel dazu wurde zunächst recherchiert, ob es bestehende Kodiersysteme (z.B. LOINC) gibt, aus denen die Value Sets gebildet werden können. Dazu wurden bestehende Dokumentenklassen und Dokumententypen aus verschiedenen Kliniken gesammelt. Dabei konnte auch auf Vorarbeiten eines Archivierungsdienstleisters, der für viele Kliniken konsolidierte Dokumentenklassen definiert hat, zurückgegriffen werden. Für die Beschreibung der Fachrichtungen wurde auf die Weiterbildungsordnung für Ärzte zurückgegriffen.
Da in vielen Fällen keine kostenfreien Kodiersysteme die gestellten Anforderungen erfüllen konnten, wurden neue Codesysteme erstellt. Die Arbeitsgruppe verfolgte einen konzeptorientierten Ansatz, d.h. sie identifizierte zuerst die notwendigen Konzepte, entwickelte dann präzise Definitionen für die Konzepte und vergab zuletzt ein eindeutiges Kürzel. Die Praxistauglichkeit dieser Value Sets wurde anhand des Use Cases, sowie anhand vieler Beispiele aus der Berufspraxis der Arbeitsgruppenteilnehmer überprüft und verbessert.

Diese Vorschläge sollten dann national mit allen Interessierten abgestimmt werden. Dafür lud die Arbeitsgruppe dazu ein, sich an der Kommentierung der Value Sets zu beteiligen.

Zur Kommentierung standen vom 23. Mai bis 26.Juni 2016:
* Dokumentenklasse (DocumentEntry.classCode)
* Dokumententyp (DocumentEntry.typeCode)
* Einrichtungsart (DocumentEntry.healthcareFacilityTypeCode)
* Fachrichtung (DocumentEntry.practiceSettingCode)
* Dokumentenformat (DocumentEntry.formatCode)
* Dokumentensprache (DocumentEntry.languageCode)
* Ordnerklassifizierung (Folder.codeList)

Die Arbeitsgruppe hat alle Kommentare gemeinsam mit den Kommentatoren bewertet und anschließend die Value Sets entsprechend überarbeitet.

== Vorgehensweise für die zweite Version ==

Seit Abschluss der Arbeiten an der ersten Version dieses Leitfadens hat die Arbeitsgruppe kontinuierlich an der Verbesserung und Erweiterung der Value Sets gearbeitet. In den alle 2 Wochen stattfindenden Telefonkonferenzen der Arbeitsgruppe wurde das Feedback von Nutzern des Leitfadens aufgenommen und Verbesserungen an den bestehenden Value Sets diskutiert. Die Ergebnisse waren einige Anpassungen an den verwendeten Codes, vor allem um Beschreibungen verständlicher und eindeutiger zu machen, zusätzliche Codes zu definieren und um Beispiele zu verbessern. Eine Änderungsliste findet sich im Anhang dieses Leitfadens.

Die regelmäßigen Telekonferenzen und die unregelmäßigen Arbeitstreffen wurden auch genutzt, um die in der ersten Version noch nicht adressierten Value Sets auszuarbeiten. Dies betraf:
* Autorenrolle (DocumentEntry.authorRole) zur Beschreibung der Rolle eines Autors
* Autorenfachgebiet (DocumentEntry.authorSpecialty) zur Beschreibung der Qualifikation bzw. des Berufs des Autors
* Vertraulichkeitsstufe (DocumentEntry.confidentialityCode) aus Sicht des Autors oder des Betroffenen
* Tätigkeitskennzeichen (DocumentEntry.eventCodeList) zur Beschreibung des Erstellungskontexts des Dokuments
* Inhaltskennzeichen (SubmissionSet.contentTypeCode) zur Beschreibung des Kontexts von gemeinsam eingestellten Dokumenten

Die Änderungen und Erweiterungen sollten national mit allen Interessierten abgestimmt werden. Dafür lud die Arbeitsgruppe dazu ein, sich an der Kommentierung der Value Sets zu beteiligen.

Zur Kommentierung standen vom 22. Mai bis 26.Juni 2018:
* Autorenrolle (DocumentEntry.authorRole)
* Autorenfachgebiet (DocumentEntry.authorSpecialty)
* Vertraulichkeitsstufe (DocumentEntry.confidentialityCode)
* Tätigkeitskennzeichen (DocumentEntry.eventCodeList)
* Inhaltskennzeichen (SubmissionSet.contentTypeCode)
* alle Änderungen an bestehenden Value Sets

Die Arbeitsgruppe hat anschließend alle Kommentare gemeinsam mit den Kommentatoren bewertet und die Value Sets entsprechend überarbeitet.
Ende Oktober 2018 wurde Version 2.0 veröffentlicht.

== Vorgehensweise für die dritte Version ==
Die Arbeiten zur dritten fanden nach dem selben Arbeitsmodus wie vorangegangenen Versionen statt. Alle 2 Wochen wurden in einer Telefonkonferenz eingereichte Themen mit den jeweils beteiligten Personen besprochen und ggf. in die Value Sets eingearbeitet. U.a. wurden folgende Themen in der dritten Version bearbeitet:
* Anpassung der Value Sets für die Gematik ePA
* Integration der KDL des DVMD
* Anpassungen für FHIR
** Hinzufügen von Canonical URIs für Codesysteme und ValueSets
** Publizierung in Simplifier
* allgemeine Weiterentwicklung der ValueSets

== Verbindlichkeit der Value Sets ==

Die in diesem Leitfaden eingeführten Value Sets sind für Deutschland momentan nicht verbindlich, sondern stellen eine Empfehlung von IHE Deutschland dar.

== Änderung und Pflege ==

Änderung und Pflege der hier vorgestellten Value Sets erfolgt durch die IHE Deutschland Arbeitsgruppe "Value Sets".

[[Kategorie:ihevs]]

Abstimmungsankündigung 20201020

2021-02-24T19:27:03Z

Foemig:

=Ankündigung des Abstimmungsverfahrens: ePflegebericht (FHIR-Version)=

Der ePflegebericht als Verlegungs- oder Entlassungsinstrument spielt in der Versorgung von pflegebedürftigen Menschen eine wichtige Rolle, um den kontinuierlichen Informationsfluss zwischen Einrichtungen der Gesundheitsversorgung zu gewährleisten. Nach der erfolgten Abstimmung über den CDA-Leitfaden im Jahr 2019 mit Finalisierung Anfang 2020 soll nun auch der HL7-FHIR-Implementierungsleitfaden, ausgearbeitet von der Forschungsgruppe „Informatik im Gesundheitswesen“ der Hochschule Osnabrück, zur Abstimmung gestellt werden. Der Leitfaden nutzt dabei bestehende Leitfäden, z.B. die Basisprofile oder Leitfäden der Medizininformatik-Initiative, sofern dies möglich und sinnvoll ist.

Der Leitfaden kann vorab unter https://simplifier.net/guide/epflegebericht/home eingesehen werden. Das zugehörige Simplifier-Projekt ist unter https://simplifier.net/epflegebericht auffindbar.

==Allgemeine Hinweise==

Das Dokument wird als Standard zur Probe zur Abstimmung gebracht. Nach einer Erprobungsphase von zwei Jahren mit Einarbeitung der Erfahrungswerte wird die Spezifikation zur normativen Abstimmung erneut vorgelegt. Das Material ist in dem jeweiligen Abschnitt unter Abstimmungsverfahren zu finden. Die Kommentare bitten wir über die Exceltabelle einzureichen.

Wir bitten um rege sowie breite Beteiligung aller Interessierten. Außerdem stehen wir Ihnen für Anregungen und Diskussionen ab sofort zur Verfügung.

Eine formlose Email als Anmeldung zum Abstimmungsverfahren an info@hl7.de oder info@interoperabilitaetsforum.de ist erforderlich. Bitte geben Sie dann nach Eröffnung und vor der Beendigung des Abstimmungsverfahrens Ihre Stimme formlos per Email an info@hl7.de oder info@interoperabilitaetsforum.de ab, wenn Sie zustimmen oder sich enthalten wollen. Bei negativen Kommentaren bitten wir Sie, zur Kommentierung das Excel-Spreadsheet zu nutzen (näheres wird zur Eröffnung des Abstimmungsverfahrens bekanntgegeben).

==Wichtige Zeitangaben==
* Ankündigung des Ballots: 20. Oktober 2020
* Eröffnung des Abstimmungsverfahrens: 23. November 2020
* Schließen des Abstimmungsverfahrens: 10. Januar 2021

[[Kategorie:Abstimmungsankündigungen]]

Abstimmungsverfahren

2021-02-24T19:05:02Z

Foemig:

{{#CustomTitle:| Abstimmungsverfahren |}}

== Abstimmungsregeln==

{{BeginRedBox|Abstimmungsregeln}}
Bitte beachten Sie auch die zugrunde liegenden [[Abstimmungsverfahren_(Regeln)|Abstimmungsregeln]] sowie die für Deutschland registrierten Voter bei HL7 International.
{{EndRedBox}}

==Einreichung von Kommentaren==

{{BeginGreenBox|Einreichung von Kommentaren}}
Bitte nutzen Sie zum Einreichen der Kommentare das folgende Spreadsheet (Excel). Dies erleichtert den Autoren die Bearbeitung Ihrer Voten und Anmerkungen.

Spreadsheet für Abstimmung / Ballot-Kommentare ''' http://download.hl7.de/KommentareAbstimmung.xlsx '''

(Hinweis: das alter Spreadsheet findet sich noch hier im download.hl7.de unter VotenKommentare.xls, sollte aber nicht mehr genutzt werden)
{{EndGreenBox}}

==[[Datei:Si-draft.svg |20px|link=]] [[Datei:Si-vote.svg |20px|link=]] Laufende Abstimmungsverfahren==
{{:Ausklapplegenda}}

Abstimmungsverfahren, die angekündigt sind [[Datei:Si-draft.svg |20px|link=]] oder gerade durchgeführt werden [[Datei:Si-vote.svg |20px|link=]] sind nachfolgend gelistet. Verfahren in der Kommentarauflösungsphase (Abgleich) befinden sich direkt im Anschluss ([[Datei:Si-reconc.svg |20px|link=]]).

{{:Ballotbox_FHIR-Basisprofile}}

==[[Datei:Si-reconc.svg|30px|link=]] Durchgeführte Abstimmungsverfahren in der Phase der Kommentarauflösung==

{{:Ballotbox_Pflegebericht_FHIR}}
{{:Ballotbox_Interoperabilität_2025‎‎}}
{{:Ballotbox_Muster_02}}
{{:Ballotbox_Muster_04}}
{{:Ballotbox_Muster_10}}
{{:Ballotbox_Muster_13}}
{{:Ballotbox_Muster_16}}
{{:Ballotbox_Elektronischer_Impfpass}}
{{:Ballotbox_eMDAF}}
{{:Ballotbox_AnschlussReha}}
{{:Ballotbox_Krankenhausbehandlung}}
{{:Ballotbox_IHE-ValueSet}}
{{:Ballotbox_Überleitungsmanagement}}
{{:Ballotbox_PatTeilnVerz}}
{{:Ballotbox_AusserklinBeatmung}}

{| class="mw-collapsible mw-collapsed" style="float:right;" border="0" cellpadding="7" cellspacing="2" border: 1pt solid #cadcfb;"
! colspan="3" style="background:#cadcfb;" | Legenda 
|-
| style="background:#eff4fd;" |
{{:Abstimmung_legenda_phasen}}
{{:Abstimmung_legenda_gesamtstimme}}
{{:Abstimmung_legenda_kommentare}}

Spalte Ergebnis: Anteil Zustimmungen im Verhältnis zu den kombinierten Ja- und Nein-Stimmen
|-
|}

==[[Datei:Si-confirm.svg|30px|link=]] Abgeschlossene Abstimmungsverfahren==

{{:Ballotbox_Psychotraumatologische Arztbriefe}}
{{:Ballotbox_Einweisungsbrief}}
{{:Ballotbox_DermaKonsilAnfrageBericht}}
{{:Ballotbox_Entlassmanagement}}
{{:Ballotbox_DGUVStationärerEntlassbrief}}
{{:Ballotbox_Pflegebericht}}
{{:Ballotbox_Arbeitsunfähigkeitsbescheinigung}}
{{:Ballotbox_Medikationsplanplus}}
{{:Ballotbox_Arztbriefplus}}
{{:Ballotbox_Medikationsmanagement}}
{{:Ballotbox_MI-I}}

== Nachfolgend noch ältere Abstimmungsverfahren==

{| class=hl7table
! Ergebnis !! Titel !! Abstimmung von bis !! [[Datei:Symbol_support_vote.svg|30px|link=]] Zustimmungen !! [[Datei:Symbol_oppose_vote.svg|30px|link=]] Ablehnungen !! [[Datei:Symbol_neutral_vote.svg|30px|link=]] Enthaltungen !! ohne Votum !! Stimmen !! Ergebnis !! Version !! Finale Version

|-
|[[Datei:Si-confirm.svg |30px|link=]] Bestätigt
|'''Implementierungsleitfaden Traumamodul des Notaufnahmeprotokolls (v1.01)''' ''[[Abstimmungsankündigung_20170504|Beginn der Abstimmung]]'' 
''[[Abstimmungsankündigung_20170403|vorausgegangene Abstimmungsankündigung]]''
|04.05.2017 05.06.2017
| 3 || 0 || 2 || 0 || 5 || 100%
| ''[[Kommentierung_20170706|Kommentare und Auflösungen (6. Juli 2017)]]''
|-
|[[Datei:Si-confirm.svg|30px|link=]] Bestätigt
|'''Patientenbezogener Medikationsplan (PMP)''' ''[[Abstimmungsankündigung_20150106|Abstimmungsankündigung]]''
|06.01.2015 20.02.2015
| 11
| 3
| 0
| 1
| 14
| 79%
|''[[Kommentierung_20170803|Kommentare und Auflösungen (3. August 2017)]]''

|-
|[[Datei:Si-confirm.svg |30px|link=]] Bestätigt
|'''"EFA 2.0 Addendum Offline Token"''' [[Abstimmungsankündigung_20180516|Abstimmungsankündigung vom 4. Mai 2018]]
|bis 13. Juni 2018
| ?
| ?
| ?
| ?
| ?
| ?
| ''[[Kommentierung_20180831|Kommentare und Auflösungen (Start 31. August 2018)]]''
| Finale Version als [http://download.hl7.de/documents/EFA_Offline_Token_Addendum_20181025.pdf PDF]

|-
|[[Datei:Si-confirm.svg |30px|link=]] Bestätigt
|'''"Überweisung"''' (STU) ''[[Abstimmungsankündigung_20180414| Abstimmungsankündigung 14.4.18]] [[Abstimmungsankündigung_20180105| Abstimmungsankündigung 5.1.18]]''
|12. Mai 2018 11. Juni 2018
| 2
| 2
| 2
| -
| -
| -
| -
| [http://hl7de.art-decor.org/vomgt-20180516T122005-ueberweisung.pdf Download PDF Überweisung] (0.9)

|-
|[[Datei:Si-reject.svg|30px|link=]] abgelehnt
|'''Wechselschnittstelle auf Basis von IHE ITI XDM und HL7 FHIR für das deutsche Gesundheitswesen''' ''[[Abstimmungsankündigung_20170414b| Abstimmungsankündigung]]''
|12. Mai 2018 11. Juni 2018
|
|
|
|
|
|
|
| [[Datei:Document_PDF.svg|30px|link=]] [http://download.hl7.de/documents/IG_Wechselschnittstelle-20180516.pdf Download PDF]

|-
|[[Datei:Si-confirm.svg |30px|link=]] Bestätigt
|'''Implementierungsleitfaden Value Sets für XDS''' ''[[Kommentierung_20161203|Kommentare und Auflösungen]]''
|23.05.2015 26.06.2016
|
|
|
|
|
|
| 1.00
| [[Datei:Logo-ihe.svg|30px|link=]] [http://www.ihe-d.de/download/value-sets-fuer-xds-metadaten download (Webseite)]

|-
|[[Datei:Si-confirm.svg |30px|link=]] Bestätigt
|'''"Implementierungsleitfaden Value Sets für XDS(1.1)"'''
|bis 26. Juni 2018
| 7
| 1
| 0
| 2
| 10
| 87,5%
| 2.00
| [[Datei:Logo-ihe.svg|30px|link=]] [http://www.ihe-d.de/download/ihe-valuesets-v2-0 download (Webseite)]

|-
|[[Datei:Si-confirm.svg |30px|link=]] Bestätigt
|'''Überleitungsmanagement''' ''[[Kommentierung_20160307|Kommentare und Auflösungen]]''
|26.01.2016 04.03.2016
|
|
|
|
|
|
| 1.00
| [[Datei:Document_PDF.svg|30px|link=]] [http://download.hl7.de/documents/cdar2-uelmgmt/Ueberleitungsmanagement-v100.pdf download (5.76 MB)]

|-
|[[Datei:Si-confirm.svg |30px|link=]] Bestätigt
|'''Patiententeilnehmerverzeichnis''' ''[[Kommentierung_20160308|Kommentare und Auflösungen]]''
|26.01.2016 04.03.2016
|
|
|
|
|
|
| 1.00
| [[Datei:Document_PDF.svg|30px|link=]] [http://download.hl7.de/documents/sd-ptv/Patiententeilnehmerverzeichnis-v100.pdf download (1.51 MB)]

|-
|[[Datei:Si-confirm.svg|30px|link=]] Bestätigt
|'''Arztbrief 2014/2015''' ''[[Kommentierung_20150715|Kommentare und Auflösungen]]''
|15.10.2014 25.11.2014
|
|
|
|
|
|
| 1.00
| [[Datei:Document_PDF.svg|30px|link=]] [http://download.hl7.de/documents/cdar2-arztbrief/Arztbrief2014-v100.pdf download (19.7 MB)]

|-
|[[Datei:Si-confirm.svg |30px|link=]] Bestätigt
|'''Implementierungsleitfaden Notaufnahmeregister (Basismodul)''' ''[[Kommentierung_20150728|Kommentare und Auflösungen]]''
|03.06.2015 15.07.2015
|
|
|
|
|
|
|1.15
| [[Datei:Document_PDF.svg|30px|link=]] [http://aktin.art-decor.org/aktin-20151014T183845.pdf download (900 kB)]

|-
| [[Datei:Si-confirm.svg|30px|link=]] Bestätigt
| '''ITI PAM-konformane deutsche Nachrichtenprofile für HL7 Version 2.5, Ausgabe 2013'''
| 01.08.2013 15.09.2013
|
|
|
|
|
|
| 0.90
| [[Datei:Document_PDF.svg|30px|link=]] download (7.7 MB)

|-
| [[Datei:Si-confirm.svg|30px|link=]] Bestätigt
| '''Übermittlung meldepflichtiger Krankheiten – Teil 1: Arztmeldung'''
| 01.08.2013 15.09.2013
|
|
|
|
|
|
| 0.90
| [[Datei:Document_PDF.svg|30px|link=]] [http://download.hl7.de/cdamik/Meldepflichtige_Krankheiten_Arztm-v099.pdf download (900 kB)]

|-
| [[Datei:Si-confirm.svg|30px|link=]] Bestätigt
| '''Übermittlung meldepflichtiger Krankheiten – Teil 2: Labormeldung'''
|07.08.2014 30.09.2014
|
|
|
|
|
|
| 0.90
| [[Datei:Document_PDF.svg|30px|link=]] [http://download.hl7.de/cdamik//Meldepflichtige_Krankheiten_Lab-v099.pdf download (1.6 MB)]

|}

{{Hilfeundwerkzeuge}}

Ballotbox AusserklinBeatmung

2021-02-24T19:01:20Z

Foemig: Die Seite wurde neu angelegt: „{{BallotboxBegin| Außerklinische Beatmung| Außerklinische Beatmung}} {{BallotboxItem |status = reconc |type = Normativ |version = 0.90 |date = |from = 06.0…“

{{BallotboxBegin| Außerklinische Beatmung| Außerklinische Beatmung}}

{{BallotboxItem
|status = reconc
|type = Normativ
|version = 0.90
|date =
|from = 06.08.2017
|to = 25.09.2017
|positive = 4
|negative = 2
|abstain = 0
|novote = 0
|total = 7
|result = 67%
|comments = [[Abstimmungsankündigung_20170707]], [[Abstimmungsankündigung_20170704]], [[Kommentierung_20171121]]
|ballotannouncement =
|ballotstart =
|pdf =
|wiki =
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]

Ballotbox MI-I

2021-02-24T19:00:40Z

Foemig:

{{BallotboxBegin| Kerndatensatz Module Medizininformatik Initiative | Profile, Extensions und Value Sets für FHIR (MI-I) }}

{{BallotboxItem
|status = reconc
|type = Informativ
|version = 1.0.0
|date = 01.07.2020
|from = 11.05.2020
|to = 21.06.2020
|ballotannouncement = https://www.medizininformatik-initiative.de/de/kerndatensatzmodule-fall-diagnose-und-prozedur-der-medizininformatik-initiative
|ballotstart =
|pdf = https://simplifier.net/organization/koordinationsstellemii/~projects
|wiki =
|artdecor = https://github.com/medizininformatik-initiative
}}

{{BallotboxItem
|status = reconc
|type = Informativ
|version = 1.0.0
|date = 01.04.2020
|from = 10.02.2020
|to = 23.03.2020
|ballotannouncement = https://www.medizininformatik-initiative.de/de/kommentierung-der-kerndatensatzmodule-person-medikation-und-laborbefund-der-medizininformatik
|ballotstart =
|pdf = https://simplifier.net/organization/koordinationsstellemii/~projects
|wiki =
|artdecor = https://github.com/medizininformatik-initiative
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]

Ballotbox Medikationsmanagement

2021-02-24T19:00:18Z

Foemig:

{{BallotboxBegin| Medikationsmanagement |Medikationsmanagement auf Basis der HL7 Clinical Document Architecture Release 2 für das deutsche Gesundheitswesen}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.11
|date = 20.08.2020
|note = Auf Basis von Implementierungsrückmeldungen wurde im Template "Einzeldosierungen (medmgmt)" (2.16.840.1.113883.3.1937.99.61.48.10.28) die Struktur der Dosierungsangaben synchronisiert mit dem entsprechenden Template aus Projekt mpp- (das u.a. auch im "Arztbrief Plus" verwendet wird):
* Aufnahme des Zeitelements zur Angabe eines einmaligen Einnahmezeitpunkts ohne Wiederholungen, ausgedrückt als Intervall und Ereignis
|wiki = http://wiki.hl7.de/index.php?title=IG:Medikationsmanagement
|artdecor = http://art-decor.org/art-decor/decor-project--medmgmt-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.10
|date = 13.06.2020
|note = Technische Korrektur.
Folgende Anpassungen wurden in dieser Version vorgenommen:
* Das "precondition" Element des Medikationseintrags wurde an die schemakorrekte Position innerhalb des Templates verschoben (Template "Medikation (medmgmt)" mit Id 2.16.840.1.113883.3.1937.99.61.48.10.3)
* Bei Einzeldosierungen des Dosierschemas (Template "Einzeldosierungen (medmgmt)" mit Id 2.16.840.1.113883.3.1937.99.61.48.10.28) wurde korrigiert:
** Das Element "offset" bei Angabe von effectiveTime als SXPR_TS hat nun den korrekten Datentypen IVL_PQ
** Das value Set "Zeiteinheiten UCUM" (Id 1.2.276.0.76.11.452) enthält nun auch Tage als zulässige Zeiteinheiten, somit kann nun auch ein "offset" in Tagen angegeben werden
** Dosiermengen (doseQuantity) können nun auch wie in den Beispielen vorgesehen als Bereichsangaben mit "low" und "high" Element angegeben werden
|wiki = http://wiki.hl7.de/index.php?title=IG:Medikationsmanagement
|artdecor = http://art-decor.org/art-decor/decor-project--medmgmt-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.09
|date = 19.04.2020
|note = Folgende Anpassungen wurden in dieser Version vorgenommen:
* Das Entry-Level-Template "Medikation" (Template-ID 1.2.276.0.76.10.4025) wurde um die optionale Angabe der Chargennummer ergänzt.
|wiki = http://wiki.hl7.de/index.php?title=IG:Medikationsmanagement
|artdecor = http://art-decor.org/art-decor/decor-project--medmgmt-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.08
|date = 15.12.2019
|note = Folgende Anpassungen wurden in dieser Version vorgenommen:
* Die Section "Hinweise" (Template-ID 1.2.276.0.76.10.3042) mit Angaben/Hinweisen für den Patienten wird in Hauskomet nicht mehr verwendet
* Für den Einsatz bei Hauskomet ist eine Autorenangabe des (einzigen) Organizers nicht vorgesehen
|wiki = http://wiki.hl7.de/index.php?title=IG:Medikationsmanagement
|artdecor = http://art-decor.org/art-decor/decor-project--medmgmt-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.07
|date = 22.10.2019
|note = Folgende Anpassungen wurden in dieser Version vorgenommen:
* Korrektur der Kardinalität der Angabe zur Stillzeit (Template-ID 2.16.840.1.113883.3.1937.99.61.48.10.13)
* Zusätzliche Validierungen für die Verwendung in Hauskomet
|wiki = http://wiki.hl7.de/index.php?title=IG:Medikationsmanagement
|artdecor = http://art-decor.org/art-decor/decor-project--medmgmt-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.06
|date = 09.10.2019
|note = Folgende Anpassungen wurden in dieser Version vorgenommen:
* Korrektur des LOINC Codes für die Therapie-Intention einer Medikation (template Id 2.16.840.1.113883.3.1937.777.27.10.17)
* Für die Verwendung in Hauskomet wird die Angabe eines Zeitraums als Einnahmedauer einer Medikation ausgeschlossen
|wiki = http://wiki.hl7.de/index.php?title=IG:Medikationsmanagement
|artdecor = http://art-decor.org/art-decor/decor-project--medmgmt-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.05
|date = 02.10.2019
|note = Folgende Anpassungen wurden in dieser Version vorgenommen:
* Aufnahme von Laborergebnissen (template Id 2.16.840.1.113883.3.1937.99.61.48.10.34) als optionale Elemente der Klinischen Parameter (templateId 2.16.840.1.113883.3.1937.99.61.48.10.10)
* Einführung eines spezialisierten Document Level Templates für Hauskomet (templateId 2.16.840.1.113883.3.1937.99.61.48.10.35) und des Szenarios "Medikationsmanagement Hauskomet"
|wiki = http://wiki.hl7.de/index.php?title=IG:Medikationsmanagement
|artdecor = http://art-decor.org/art-decor/decor-project--medmgmt-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.04
|date = 25.09.2019
|note = Folgende Anpassungen wurden in dieser Version vorgenommen:
* Erweiterung der Sozialanamnese um die Angabe eines (auch historischen) Alkoholabusus (TemplateId "2.16.840.1.113883.3.1937.99.61.48.10.33")
* Die Angabe der BSNR des Pflegearztes ist nun verpflichtend (TemplateId "2.16.840.1.113883.3.1937.99.61.48.10.25")
|wiki = http://wiki.hl7.de/index.php?title=IG:Medikationsmanagement
|artdecor = http://art-decor.org/art-decor/decor-project--medmgmt-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.03
|date = 18.09.2019
|note = Folgende Anpassungen wurden in dieser Version vorgenommen:
* TemplateId "2.16.840.1.113883.3.1937.99.61.48.10.25" zum Element "Pflegearzt (Kurator)" hinzugefügt.
|wiki = http://wiki.hl7.de/index.php?title=IG:Medikationsmanagement
|artdecor = http://art-decor.org/art-decor/decor-project--medmgmt-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.02
|date = 17.09.2019
|note = Folgende Anpassungen wurden in dieser Version vorgenommen:
* Template "Alkoholgebrauch" (Adaption): Text-Element zur Reference in den Text der Section hinzugefügt und den Datentypen des code-Elements auf "CD" geändert.
* Template "Tabakgebrauch" (Adapation): Text-Element zur Reference in den Text der Section hinzugefügt.
* Template "Einzeldosierung" (Adaption): effectiveTime-Element "Einnahmezeitpunkt": Datentypen der Attribute @event & @offset an Hauskomet angeglichen.
|wiki = http://wiki.hl7.de/index.php?title=IG:Medikationsmanagement
|artdecor = http://art-decor.org/art-decor/decor-project--medmgmt-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.01
|date = 27.08.2019
|note = Anpassungen im Zuge der Angleichung an dem Hauskomet-Datenformat (für die Sektion "Medikation"):
* Kategorie wird nicht mehr mittels dem moodCode-Attribut, sondern mittels der Hauskomet Kategorie angegeben.
* Kuratierender Pflegearzt hinzugefügt.
* TemplateId des adaptiereten Elements übernommen.
* Template Mapping wurde angepasst.
|wiki = http://wiki.hl7.de/index.php?title=IG:Medikationsmanagement
|artdecor = http://art-decor.org/art-decor/decor-project--medmgmt-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.00
|date = 27.08.2019
|from = 14.02.2018
|to = 23.04.2019
|positive = 16
|negative = 1
|abstain = 2
|novote = 0
|total = 15
|result = 100%
|comments = [[Kommentierung_20190723]]
|note =
|pdf = http://download.hl7.de/documents/cdar2-medmgmt/Medikationsmanagement-100.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Medikationsmanagement
|artdecor = http://art-decor.org/art-decor/decor-project--medmgmt-
}}

{{BallotboxItem
|status = vote
|type = STU
|version = 0.85c
|date = 14.02.2019
|ballotannouncement = Abstimmungsankündigung_20181207
|ballotstart = Abstimmungsankündigung_20190214
|pdf = http://download.hl7.de/documents/cdar2-medmgmt/Medikationsmanagement-085c.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Medikationsmanagement
|artdecor = http://art-decor.org/art-decor/decor-project--medmgmt-
}}

{{BallotboxItem
|status = vote
|type = STU
|version = 0.85
|date = 11.02.2019
|ballotannouncement = Abstimmungsankündigung_20181207
|ballotstart = Abstimmungsankündigung_20190201
|pdf =
|wiki = http://wiki.hl7.de/index.php?title=IG:Medikationsmanagement
|artdecor = http://art-decor.org/art-decor/decor-project--medmgmt-
}}

{{BallotboxItem
|status = draft
|type = STU
|version = 0.80
|date = 20.11.2018
|ballotannouncement =
|ballotstart =
|pdf =
|wiki = http://wiki.hl7.de/index.php?title=IG:Medikationsmanagement
|artdecor = http://art-decor.org/art-decor/decor-project--medmgmt-
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]

Ballotbox Arztbriefplus

2021-02-24T18:59:40Z

Foemig:

{{BallotboxBegin|Arztbrief PLUS|Arztbrief Plus auf Basis der HL7 Clinical Document Architecture Release 2 für das deutsche Gesundheitswesen}}

{{BallotboxItem
|status = final
|type = STU
|version = 3.15
|date = 24.08.2020
|note = Technische Korrektur zu 3.14
|pdf = https://wiki.hl7.de/images/ArztbriefPlus-v315.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Arztbrief_Plus
|artdecor = http://art-decor.org/art-decor/decor-project--abde-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 3.14
|date = 23.04.2019
|note = Technische Korrektur zu 3.12
|pdf = http://download.hl7.de/documents/cdar2-arztbrief/ArztbriefPlus-v314.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Arztbrief_Plus
|artdecor = http://art-decor.org/art-decor/decor-project--abde-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 3.12
|date = 03.04.2019
|note = Technische Korrektur zu 3.11
|pdf = http://download.hl7.de/documents/cdar2-arztbrief/ArztbriefPlus-v312.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Arztbrief_Plus
|artdecor = http://art-decor.org/art-decor/decor-project--abde-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 3.11
|date = 03.04.2019
|note = Technische Korrektur zu 3.10
|pdf =
|wiki = http://wiki.hl7.de/index.php?title=IG:Arztbrief_Plus
|artdecor = http://art-decor.org/art-decor/decor-project--abde-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 3.10
|date = 07.07.2017
|from = 11.04.2017
|to = 30.05.2017
|positive = 8
|negative = 0
|abstain = 1
|novote = 5
|total = 9
|result = 100%
|comments = [[Kommentierung_20170626]] (Start 26. Juni 2017)
|pdf = http://download.hl7.de/documents/cdar2-arztbrief/ArztbriefPlus-v310.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Arztbrief_Plus
|artdecor = http://art-decor.org/art-decor/decor-project--abde-
}}

{{BallotboxItem
|status = vote
|type = STU
|version = 3.00
|date = 11.04.2017
|ballotannouncement = Abstimmungsankündigung_20170307
|ballotstart = Abstimmungsankündigung_20170411
|pdf = http://download.hl7.de/documents/cdar2-arztbrief/ArztbriefPlus-v300.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Arztbrief_Plus
|artdecor = http://art-decor.org/art-decor/decor-project--abde-
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]

Ballotbox Medikationsplanplus

2021-02-24T18:58:47Z

Foemig:

{{BallotboxBegin|Medikationsplan PLUS|Patientenbezogener Medikationsplan Plus spezifiziert als HL7 Clinical Document Architecture Release 2 / HL7 FHIR / Ultrakurzformat für das deutsche Gesundheitswesen}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.00
|date = 19.08.2018
|from = 09.08.2017
|to = 25.09.2017
|positive = 4
|negative = 5
|abstain = 1
|novote = 0
|total = 10
|result = 44%
|comments = [[Kommentierung_20171215]], siehe auch Issues in [https://github.com/hl7germany/medikationsplanplusplus/issues Github]
|pdf = http://download.hl7.de/documents/cdar2-pmp/Patientenbezogener_Medikationsplan-Plus-v100.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Patientenbezogener_Medikationsplan_Plus
|artdecor = http://art-decor.org/art-decor/decor-project--pmp-
}}

{{BallotboxItem
|status = vote
|type = STU
|version = 0.90
|date = 09.08.2017
|ballotannouncement = Abstimmungsankündigung_20170705
|ballotstart = Abstimmungsankündigung_20170709
|pdf = http://download.hl7.de/documents/cdar2-pmp/Patientenbezogener_Medikationsplan-Plus-v090.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Patientenbezogener_Medikationsplan_Plus
|artdecor = http://art-decor.org/art-decor/decor-project--pmp-
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]

Ballotbox Arbeitsunfähigkeitsbescheinigung

2021-02-24T18:58:14Z

Foemig:

{{BallotboxBegin| Arbeitsunfähigkeitsbescheinigung | Elektronische Arbeitsunfähigkeitsbescheinigung‎ (eAU) auf Basis der HL7 Clinical Document Architecture Release 2 für das deutsche Gesundheitswesen}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.14
|date = 12.08.2020
|note = Technische Korrektur zu 1.13
|pdf = http://hl7de.art-decor.org/vomgt-20200812T163402.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Arbeitsunfähigkeitsbescheinigung
|artdecor = http://art-decor.org/art-decor/decor-project--vomgt-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.13
|date = 24.02.2020
|note = Technische Korrektur zu 1.12
|wiki = http://wiki.hl7.de/index.php?title=IG:Arbeitsunfähigkeitsbescheinigung
|artdecor = http://art-decor.org/art-decor/decor-project--vomgt-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.12
|date = 06.02.2019
|note = Technische Korrektur zu 1.11
|pdf = http://hl7de.art-decor.org/vomgt-20190210T131635.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Arbeitsunfähigkeitsbescheinigung
|artdecor = http://art-decor.org/art-decor/decor-project--vomgt-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.11
|date = 25.10.2018
|note = Technische Korrektur zu 1.10
|pdf = http://hl7de.art-decor.org/vomgt-20181025T161621.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Arbeitsunfähigkeitsbescheinigung
|artdecor = http://art-decor.org/art-decor/decor-project--vomgt-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.10
|date = 31.09.2018
|note = Technische Korrektur zu 1.0
|pdf = http://hl7de.art-decor.org/vomgt-20180921T122450.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Arbeitsunfähigkeitsbescheinigung
|artdecor = http://art-decor.org/art-decor/decor-project--vomgt-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.0
|date = 31.08.2018
|from = 12.05.2018
|to = 11.06.2018
|positive = 4
|negative = 1
|abstain = 3
|novote = 0
|total = 8
|result = 80%
|comments =
|pdf = http://hl7de.art-decor.org/vomgt-20180831T150047.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Arbeitsunfähigkeitsbescheinigung
|artdecor = http://art-decor.org/art-decor/decor-project--vomgt-
}}

{{BallotboxItem
|status = vote
|type = STU
|version = 0.9
|date = 15.05.2018
|ballotannouncement = Abstimmungsankündigung_20180414
|ballotstart =
|pdf = http://hl7de.art-decor.org/vomgt-html-20180516T122005/index.html
|wiki = http://wiki.hl7.de/index.php?title=IG:Arbeitsunfähigkeitsbescheinigung
|artdecor = http://art-decor.org/art-decor/decor-project--vomgt-
}}

{{BallotboxItem
|status = reconc
|type = STU
|version = 0.8
|date = 05.01.2018
|from = 06.01.2018
|to = 07.02.2018
|positive = 7
|negative = 2
|abstain = 0
|novote = 1
|total = 10
|result = 78%
|comments = [[Kommentierung_20180212]], bestätigt, trotzdem wird das Material noch einmal überarbeitet und erneut abgestimmt
|pdf = http://hl7de.art-decor.org/vomgt-20180105T134346.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Arbeitsunfähigkeitsbescheinigung
|artdecor = http://art-decor.org/art-decor/decor-project--vomgt-
}}

{{BallotboxItem
|status = vote
|type = STU
|version = 0.7
|date = 07.12.2017
|ballotannouncement = Abstimmungsankündigung_20171207
|ballotstart = Abstimmungsankündigung_20180105
|pdf = http://hl7de.art-decor.org/vomgt-20180105T134346.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Arbeitsunfähigkeitsbescheinigung
|artdecor = http://art-decor.org/art-decor/decor-project--vomgt-
}}
{{BallotboxEnd}}



[[Kategorie:Ballotbox]]

Ballotbox Pflegebericht

2021-02-24T18:57:13Z

Foemig:

{{BallotboxBegin|Pflegebericht|ePflegebericht auf Basis der HL7 Clinical Document Architecture Release 2 für das deutsche Gesundheitswesen}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.00
|date = 30.06.2020
|note = Nach Auflösung aller Kommentare
|pdf = http://download.hl7.de/documents/cdar2-ePflegebericht/ePflegebericht-100.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Pflegebericht
|artdecor = https://art-decor.org/art-decor/decor-project--epflb-
}}

{{BallotboxItem
|status = reconc
|type = STU
|version = 0.90
|date = 31.07.2019
|from = 22.07.2019
|to = 16.09.2019
|positive = 6
|negative = 2
|abstain = 0
|novote = 0
|total = 8
|result = 75%
|comments = [[Kommentierung_20200630]] [[Kommentierung_Pflegebericht_20191004]], [[Abstimmungsankündigung_20190719]], [[Abstimmungsankündigung_20190722]], [[Abstimmungsankündigung_20190731]]
|ballotannouncement = Abstimmungsankündigung_20190719
|ballotstart = Abstimmungsankündigung_20190731
|pdf = http://download.hl7.de/documents/cdar2-ePflegebericht/ePflegebericht-090.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Pflegebericht
|artdecor = https://art-decor.org/art-decor/decor-project--epflb-
}}

{{BallotboxItem
|status = reconc
|type = STU
|version = 0.80
|date = 13.02.2011
|ballotannouncement =
|ballotstart =
|
|wiki = http://wiki.hl7.de/index.php?title=IG:Pflegebericht
|
}}

{{BallotboxItem
|status = draft
|type = STU
|version = 0.70
|date = 14.03.2011
|ballotannouncement =
|ballotstart =
|
|wiki = http://wiki.hl7.de/index.php?title=IG:Pflegebericht
|
}}

{{BallotboxItem
|status = draft
|type = STU
|version = 0.60
|date = 13.02.2011
|ballotannouncement =
|ballotstart =
|
|wiki = http://wiki.hl7.de/index.php?title=IG:Pflegebericht
|
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]

Ballotbox Psychotraumatologische Arztbriefe

2021-02-24T18:56:03Z

Foemig:

{{BallotboxBegin| Psychosomatisch-psychotherapeutischer Arztbrief | Psychosomatisch-psychotherapeutischer Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2 für das deutsche Gesundheitswesen}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.01
|date = 05.01.2021
|note = Technische Korrektur (Layoutanpassungen) zu 1.00
|pdf = http://download.hl7.de/documents/cdar2-psyab/Psychosomatisch-psychotherapeutischer-Arztbrief-v101.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Psychotraumatologische_Arztbriefe
|artdecor = http://art-decor.org/art-decor/decor-project--teleneps-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.00
|date = 18.12.2020
|from = 06.10.2020
|to = 04.11.2020
|positive = 10
|negative = 1
|abstain = 0
|novote = 0
|total = 11
|result = 91%
|comments = [[Kommentierung_20201208]]
|wiki = http://wiki.hl7.de/index.php?title=IG:Psychotraumatologische_Arztbriefe
|artdecor = http://art-decor.org/art-decor/decor-project--teleneps-
|pdf = http://download.hl7.de/documents/cdar2-psyab/Psychosomatisch-psychotherapeutischer-Arztbrief-v100.pdf
}}

{{BallotboxItem
|status = reconc
|type = STU
|version = 0.90
|date = 08.12.2020
|from = 06.10.2020
|to = 04.11.2020
|positive = 10
|negative = 1
|abstain = 0
|novote = 0
|total = 11
|result = 91%
|comments = [[Kommentierung_20201208]], [[Abstimmungsankündigung_20200908]], [[Abstimmungsankündigung_20201006]]
|ballotannouncement = Abstimmungsankündigung_20200908
|ballotstart = Abstimmungsankündigung_20201006
|pdf = http://download.hl7.de/documents/cdar2-psyab/Psychosomatisch-psychotherapeutischer-Arztbrief-v090.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:Psychotraumatologische_Arztbriefe
|artdecor = http://art-decor.org/art-decor/decor-project--teleneps-
}}

{{BallotboxItem
|status = draft
|type = STU
|version = 0.10
|date = 24.08.2020
|ballotannouncement = Abstimmungsankündigung_20200908
|ballotstart =
|pdf =
|wiki = http://wiki.hl7.de/index.php?title=IG:Psychotraumatologische_Arztbriefe
|artdecor = http://art-decor.org/art-decor/decor-project--teleneps-
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]

Ballotbox DGUVStationärerEntlassbrief

2021-02-24T18:55:19Z

Foemig:

{{BallotboxBegin| DGUV Stationärer Entlassbrief |DGUV Stationärer Entlassbrief auf Basis der HL7 Clinical Document Architecture Release 2}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.00
|date = 10.08.2020
|from = 12.12.2018
|to = 20.01.2019
|positive = 6
|negative = 0
|abstain = 1
|novote = 0
|total = 7
|result = 100%
|comments = [[Kommentierung_20200810]]
|wiki = http://wiki.hl7.de/index.php?title=IG:DGUV_Stationärer_Entlassbrief
|artdecor = http://art-decor.org/art-decor/decor-project--dguvbbr-
|pdf = http://download.hl7.de/documents/cdar2-dguv/DGUV_Stationaerer_Entlassbrief-20200810.pdf
}}

{{BallotboxItem
|status = reconc
|type = STU
|version = 0.80
|date = 20.01.2019
|from = 12.12.2018
|to = 20.01.2019
|positive = 6
|negative = 0
|abstain = 1
|novote = 0
|total = 7
|result = 100%
|comments = [[Kommentierung_20200810]]
|ballotannouncement =
|ballotstart =
|pdf =
|wiki =
|artdecor =
}}

{{BallotboxItem
|status = vote
|type = STU
|version = 0.80
|date = 12.12.2018
|ballotannouncement = Abstimmungsankündigung_20181112
|ballotstart = Abstimmungsankündigung_20181212
|pdf = http://download.hl7.de/documents/cdar2-dguv/DGUV_Stationaerer_Entlassbrief-20181212.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:DGUV_Stationärer_Entlassbrief
|artdecor = http://art-decor.org/art-decor/decor-project--dguvbbr-
}}

{{BallotboxItem
|status = draft
|type = STU
|version =
|date = 12.11.2018
|ballotannouncement =
|ballotstart =
|pdf =
|wiki = http://wiki.hl7.de/index.php?title=IG:DGUV_Stationärer_Entlassbrief
|artdecor = http://art-decor.org/art-decor/decor-project--dguvbbr-
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]

Ballotbox Entlassmanagement

2021-02-24T18:54:53Z

Foemig:

{{BallotboxBegin| Entlassmanagement |Entlassmanagementbrief auf Basis der HL7 Clinical Document Architecture Release 2 für das deutsche Gesundheitswesen}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.1
|date = 04.12.2020
|from = 08.07.2018
|to = 08.09.2020
|positive = 5
|negative = 1
|abstain = 1
|novote = 0
|total = 7
|result = 83%
|comments = folgt
|pdf = https://wiki.hl7.de/images/Entlassmanagementbrief_v101.pdf
|wiki = https://wiki.hl7.de/index.php?title=IG:Entlassmanagementbrief
|artdecor = https://art-decor.org/art-decor/decor-project--elmgmt-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.0
|date = 24.01.2019
|from = 08.07.2018
|to = 08.09.2018
|positive = 5
|negative = 1
|abstain = 1
|novote = 0
|total = 7
|result = 83%
|comments = folgt
|pdf = http://pub.art-decor.org/elmgmt/elmgmt-20201119T125049.pdf
|wiki = https://wiki.hl7.de/index.php?title=IG:Entlassmanagementbrief
|artdecor = https://art-decor.org/art-decor/decor-project--elmgmt-
}}

{{BallotboxItem
|status = vote
|type = STU
|version = 0.10
|date = 08.07.2018
|ballotannouncement = Abstimmungsankündigung_20180608
|ballotstart = Abstimmungsankündigung_20180708
|pdf = https://wiki.hl7.de/images/HL7DE_IG_Entlassmanagementbrief_ballot.pdf
|wiki = https://wiki.hl7.de/index.php?title=IG:Entlassmanagementbrief
|artdecor = https://art-decor.org/art-decor/decor-project--elmgmt-
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]

Ballotbox DermaKonsilAnfrageBericht

2021-02-24T18:54:27Z

Foemig:

{{BallotboxBegin| Dermatologisches Konsil|Dermatologische Konsilanfrage und -bericht auf Basis der HL7 Clinical Document Architecture Release 2 für das deutsche Gesundheitswesen}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.01
|date = 04.01.2021
|note = Erweiterung des Dermatologischen Konsils um zusätzliche erforderliche Informationen
|pdf = https://wiki.hl7.de/images/DermatologischesKonsil_v101.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:DermaKonsilAnfrageBericht
|artdecor = http://art-decor.org/art-decor/decor-project--konsab-
}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.0
|date = 11.09.2020
|from = 22.07.2020
|to = 31.08.2020
|positive = 6
|negative = 0
|abstain = 0
|novote = 0
|total = 6
|result = 100%
|comments = [[Kommentierung_20200914|Kommentierung Dermatologisches Konsil]]
|pdf = https://wiki.hl7.de/images/DermatologischesKonsil_v100.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:DermaKonsilAnfrageBericht
|artdecor = http://art-decor.org/art-decor/decor-project--konsab-
}}

{{BallotboxItem
|status = vote
|type = STU
|version = 0.2
|date = 22.06.2020
|ballotannouncement = Abstimmungsankündigung_20200624
|ballotstart = Abstimmungsankündigung_20200624
|pdf = https://download.hl7.de/documents/cdar2-konsil/5f16a4c4ba121.pdf
|wiki = http://wiki.hl7.de/index.php?title=IG:DermaKonsilAnfrageBericht
|artdecor = http://art-decor.org/art-decor/decor-project--konsab-
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]

Ballotbox Einweisungsbrief

2021-02-24T18:53:34Z

Foemig:

{{BallotboxBegin| Einweisungsbrief | auf Basis der HL7 Clinical Document Architecture Release 2 für das deutsche Gesundheitswesen}}

{{BallotboxItem
|status = final
|type = STU
|version = 1.0
|date = 11.09.2020
|from = 22.07.2020
|to = 31.08.2020
|positive = 7
|negative = 0
|abstain = 0
|novote = 0
|total = 7
|result = 100%
|comments = [[Abstimmungsankündigung_20200624]]

|ballotannouncement = Abstimmungsankündigung_20200624
|ballotstart = Abstimmungsankündigung_20200624
|pdf = https://wiki.hl7.de/images/Einweisung100.pdf
|wiki = https://wiki.hl7.de/index.php?title=IG:EEinweisungsbrief
|artdecor = https://art-decor.org/art-decor/decor-project--einwde-
}}

{{BallotboxItem
|status = reconc
|type = STU
|version = 0.85
|date = 01.09.2020
|from = 22.07.2020
|to = 31.08.2020
|positive = 7
|negative = 0
|abstain = 0
|novote = 0
|total = 7
|result = 100%
|comments = [[Abstimmungsankündigung_20200624]]

|ballotannouncement = Abstimmungsankündigung_20200624
|ballotstart = Abstimmungsankündigung_20200624
|pdf = download.hl7.de/documents/cdar2-einweisung/Einweisung085.pdf
|wiki = https://wiki.hl7.de/index.php?title=IG:EEinweisungsbrief
|artdecor = https://art-decor.org/art-decor/decor-project--einwde-
}}

{{BallotboxItem
|status = vote
|type = STU
|version = 0.85
|date = 22.06.2020
|from = 22.07.2020
|to = 31.08.2020

|ballotannouncement = Abstimmungsankündigung_20200624
|ballotstart = Abstimmungsankündigung_20200624
|pdf = download.hl7.de/documents/cdar2-einweisung/Einweisung085.pdf
|wiki = https://wiki.hl7.de/index.php?title=IG:EEinweisungsbrief
|artdecor = https://art-decor.org/art-decor/decor-project--einwde-
}}

{{BallotboxEnd}}

Ballotbox_Einweisungsbrief

Kategorie:Ballotbox

2021-02-24T18:52:14Z

Foemig: Die Seite wurde neu angelegt: „Folgende Ballotboxen sind vorhanden:“

Folgende Ballotboxen sind vorhanden:

Ballotbox eMDAF

2021-02-24T18:50:04Z

Foemig:

{{BallotboxBegin| eMDAF| Elektronisches Medikations-Datenaustauschformat}}

{{BallotboxItem
|status = reconc
|type = STU
|version =
|date =
|from = 30.11.2020
|to = 11.01.2021
|positive = 2
|negative = 0
|abstain = 0
|novote = 0
|total = 2
|result = 100%
|comments = kein Quorum
|ballotannouncement =
|ballotstart =
|pdf =
|wiki =
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]

Ballotbox PatTeilnVerz

2021-02-24T18:44:17Z

Foemig: Die Seite wurde neu angelegt: „{{BallotboxBegin| Patiententeilnehmerverzeichnis| Patiententeilnehmerverzeichnis}} {{BallotboxItem |status = reconc |type = Normativ |version = 1 |date = 21.1…“

{{BallotboxBegin| Patiententeilnehmerverzeichnis| Patiententeilnehmerverzeichnis}}

{{BallotboxItem
|status = reconc
|type = Normativ
|version = 1
|date = 21.12.2015
|from = 26.1.2016
|to = 4.3.2016
|positive = 6
|negative = 0
|abstain = 1
|novote = 0
|total = 7
|result = 100%
|comments = [[Abstimmungsankündigung_20151221]], [[Abstimmungsankündigung_20160126a]], [[Kommentierung_20160308]]
|ballotannouncement =
|ballotstart =
|pdf =
|wiki =
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]

Ballotbox Überleitungsmanagement

2021-02-24T18:43:23Z

Foemig: Die Seite wurde neu angelegt: „{{BallotboxBegin| Überleitungsmanagement | Überleitungsmanagement }} {{BallotboxItem |status = reconc |type = Normativ |version = 1 |date = |from = 26.01.2…“

{{BallotboxBegin| Überleitungsmanagement | Überleitungsmanagement }}

{{BallotboxItem
|status = reconc
|type = Normativ
|version = 1
|date =
|from = 26.01.2016
|to = 4.03.2016
|positive = 6
|negative = 0
|abstain = 1
|novote = 0
|total = 7
|result = 100%
|comments = [[Abstimmungsankündigung_20151221]], [[Abstimmungsankündigung_20160126a]], [[Kommentierung_20160307]]
|ballotannouncement =
|ballotstart =
|pdf =
|wiki =
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]

Ballotbox IHE-ValueSet

2021-02-24T18:42:21Z

Foemig: Die Seite wurde neu angelegt: „{{BallotboxBegin| IHE XDS XDS Value Set | Implementierungsleitfaden Value Sets für XDS }} {{BallotboxItem |status = reconc |type = Normativ |version = 1 |dat…“

{{BallotboxBegin| IHE XDS XDS Value Set | Implementierungsleitfaden Value Sets für XDS }}

{{BallotboxItem
|status = reconc
|type = Normativ
|version = 1
|date =
|from = 23.05.2015
|to = 26.06.2016
|positive =
|negative =
|abstain =
|novote =
|total =
|result =
|comments = [[Abstimmungsankündigung_20160531]], [[Kommentierung_20161203|(Start 3. Dezember 2016)]]

|ballotannouncement =
|ballotstart =
|pdf =
|wiki =
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]

Ballotbox Krankenhausbehandlung

2021-02-24T18:41:33Z

Foemig: Die Seite wurde neu angelegt: „{{BallotboxBegin| Krankenhausbehandlung| Krankenhausbehandlung}} {{BallotboxItem |status = reconc |type = STU |version = |date = |from = 30.11.2020 |to = 11…“

{{BallotboxBegin| Krankenhausbehandlung| Krankenhausbehandlung}}

{{BallotboxItem
|status = reconc
|type = STU
|version =
|date =
|from = 30.11.2020
|to = 11.01.2021
|positive = 2
|negative = 0
|abstain = 0
|novote = 0
|total = 2
|quorum = no
|result = 100%
|comments =
|ballotannouncement =
|ballotstart =
|pdf =
|wiki =
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]

Ballotbox FHIR-Basisprofile

2021-02-24T18:40:31Z

Foemig:

{{BallotboxBegin| FHIR Basisprofile | Profile, Extensions und Value Sets für FHIR }}

{{BallotboxItem
|status = vote
|type = STU
|version = 1.0.0
|date = 19.01.2021
|from = 18.02.2021
|to = 31.03.2021
|ballotannouncement = Abstimmungsankündigung_20181119
|ballotstart =
|pdf = https://ig.fhir.de/basisprofile-de/1.0.0-alpha1/
|wiki =
|artdecor = https://github.com/hl7germany/basisprofil-de
}}

{{BallotboxItem
|status = reconc
|type = Informativ
|version = 0.2
|date = 30.01.2019
|from = 17.11.2018
|to = 17.12.2018
|ballotannouncement = Abstimmungsankündigung_20181119
|ballotstart =
|pdf = http://ig.fhir.de/basisprofile-de/0.2
|wiki =
|artdecor = https://github.com/hl7germany/basisprofil-de
}}

{{BallotboxItem
|status = reconc
|type = Informativ
|version = 0.1
|date = 08.07.2017
|from = 07.08.2017
|to = 25.09.2017
|positive = -
|negative = -
|abstain = -
|novote = -
|total = -
|result = -
|comments =
|ballotannouncement = Abstimmungsankündigung_20170708
|pdf = http://ig.fhir.de/basisprofile-de/0.1
|wiki =
|artdecor = https://github.com/hl7germany/basisprofil-de
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]

Ballotbox AnschlussReha

2021-02-24T18:38:15Z

Foemig: Die Seite wurde neu angelegt: „{{BallotboxBegin| Anschlussreha| Anschlussreha}} {{BallotboxItem |status = reconc |type = STU |version = |date = |from = 30.11.2020 |to = 11.01.2021 |positi…“

{{BallotboxBegin| Anschlussreha| Anschlussreha}}

{{BallotboxItem
|status = reconc
|type = STU
|version =
|date =
|from = 30.11.2020
|to = 11.01.2021
|positive = 2
|negative = 0
|abstain = 0
|novote = 0
|total = 2
|quorum = no
|result = 100%
|comments =
|ballotannouncement =
|ballotstart =
|pdf =
|wiki =
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]

Ballotbox eMDAF

2021-02-24T18:37:21Z

Foemig: Die Seite wurde neu angelegt: „{{BallotboxBegin| eMDAF| Elektronisches Medikations-Datenaustauschformat}} {{BallotboxItem |status = reconc |type = STU |version = |date = |from = 30.11.202…“

{{BallotboxBegin| eMDAF| Elektronisches Medikations-Datenaustauschformat}}

{{BallotboxItem
|status = reconc
|type = STU
|version =
|date =
|from = 30.11.2020
|to = 11.01.2021
|positive = 2
|negative = 0
|abstain = 0
|novote = 0
|total = 2
|quorum = no
|result = 100%
|comments =
|ballotannouncement =
|ballotstart =
|pdf =
|wiki =
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]