https://wiki.hl7.de/api.php?action=feedcontributions&user=Tidris&feedformat=atomHl7wiki - Benutzerbeiträge [de]2024-03-29T15:40:18ZBenutzerbeiträgeMediaWiki 1.31.0https://wiki.hl7.de/index.php?title=IHE_DE_ValueSets_Action_Items&diff=80515IHE DE ValueSets Action Items2023-10-13T11:59:13Z<p>Tidris: </p>
<hr />
<div>'''Tabelle Änderungsanfragen'''<br />
<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! align="left" | Anfrage ID<br />
! align="left" | Anfrage eingegangen am<br />
! align="left" | Anfrage<br />
! align="center" | betrifft Codesystem<br />
! align="center" | Autor der Anfrage<br />
! align="center" | Diskussion<br />
! align="center" | Entscheidung<br />
! align="center" | Action Item<br />
! align="center" | Bearbeitungsstand<br />
! align="center" | zuletzt bearbeitet am<br />
<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 4<br />
| Anfrage eingegangen am|<br />
| Anfrage| Arbeitsgruppe „Weiterentwicklung Klinische Dokumentenklassenliste (KDL)“.<br />
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.<br />
Das aktuelle Mapping liegt der Geschäftsstelle vor und ist bisher mit Angela Merzweiler gemeinsam abgestimmt wurden.<br />
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.<br />
Beispiel:<br />
Ich möchte daher anregen bzw. beantragen, dass die KDL im ersten Schritt offiziell als CodeSystem in das Value Set „EventCodeList“ aufgenommen wird.<br />
Damit haben Hersteller von IHE-konformen Archiven, o. ä. die Möglichkeit, wenigstens die Klassifizierung des Dokuments mittels KDL offiziell abzubilden.<br />
· Code System Name: Klinische Dokumentenklassen Liste (KDL)<br />
· Code System ID: 1.2.276.0.76.3.1.191.0.1.1, versionsabhängig<br />
· Kommentar: Klassifizierung von Dokumenten und Daten als Beispiele für die Value Sets classCode und typeCode<br />
Mittelfristig soll die KDL zu einem terminologischen System mit ontologischem Ansatz ausgebaut werden.<br />
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.<br />
Ich freue mich, wenn wir es gemeinsam schaffen, dazu einen persönlichen Termin für ein Arbeitstreffen zu finden.<br />
| betrifft Codesystem | eventCode<br />
| Autor der Anfrage | AMü<br />
| 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<br />
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)<br />
übergeordnetes Valueset KDL in ArtDecor als Codesystem eingetragen, da der Eintrag als Valueset technisch nicht möglich war.<br />
12.11.2021 erneute Diskussion, ob Eintrag als Codesystem sinnvoll war<br />
| Entscheidung | grundsätzlich zugestimmt, neues Valueset<br />
| Action Item | alle=> Mapping prüfen<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 12.11.2021<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 7<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Deutscher Implementation Guide für MHD Profile mit Verweis auf unsere Valuesets<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | SH über Tarik<br />
| 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 <br />
| 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 <br />
| Action Item | Simone um Referenz der Codes in Deutschen Basisprofilguideline bitten <br />
| Bearbeitungsstand | als Issues in Gitlab eingetragen, im Simplifier sichtbar https://simplifier.net/basisprofil-de-r4/~resources?category=ValueSet&sortBy=RankScore_desc ==> (Angela)<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 19<br />
| Anfrage eingegangen am| 10.07.2020<br />
| 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<br />
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:<br />
Bestehenden Code ALLG - „Allgemeinmedizin“ neu bezeichnen als „Facharzt für Allgemeinmedizin<br />
(Hausarzt)“<br />
2. Neuen Code einführen für „Praktischer Arzt/Arzt (Hausarzt)“. Vorschlag: PRAK<br />
3. Neuen Code einführen für „Hausärztlich tätiger Internist (Hausarzt)“. Vorschlag: HINT<br />
4. Bestehenden Codes ORTH neu bezeichnen als „Orthopädie und Unfallchirurgie“.<br />
5. Neuen Code einführen für „Rheumatologie (Orthopädie)“. Vorschlag: ORRH.<br />
6. Neuen Code einführen für „Infektiologie“. Vorschlag: INFK<br />
7. Neuen Code einführen für „Kinder-Pneumologie“. Vorschlag: KIPN<br />
8. Neuen Code einführen für „Nervenheilkunde/Neurologie und Psychiatrie“. Vorschlag: NERV<br />
9. Neuen Code einführen für „Psychotherapeutisch tätiger Arzt“. Vorschlag: PTAR<br />
10. Neuen Code einführen für „Psychologischer Psychotherapeut“. Vorschlag: PPTH<br />
11.Neuen Code einführen für „Kinder- und Jugendlichen-Psychotherapeut“. Vorschlag: KJPP<br />
| betrifft Codesystem | Practice Setting Code<br />
| Autor der Anfrage | SR (KBV)<br />
| 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.<br />
| 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).<br />
| Action Item | Mapping prüfen und in Implementation Guide eintragen.<br />
| 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.<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 29<br />
| Anfrage eingegangen am| 22.01.2021<br />
| Anfrage| Problem mit ArtDecor bei FHIR<br />
| betrifft Codesystem | alle<br />
| Autor der Anfrage | Axel<br />
| Diskussion| <br />
| Entscheidung | <br />
| Action Item | Axel meldet Issues an Kai<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 22.01.2021<br />
<br />
<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 31<br />
| Anfrage eingegangen am| 18.02.2021<br />
| 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.<br />
| betrifft Codesystem | ClassCode<br />
| Autor der Anfrage | CG<br />
| Diskussion| <br />
| Entscheidung | <br />
| Action Item | <br />
| Bearbeitungsstand | offen<br />
| zuletzt bearbeitet am| <br />
<br />
|- valign="top" <br />
| Anfrage ID| 33<br />
| Anfrage eingegangen am| 22.12.2021<br />
| 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.<br />
| betrifft Codesystem | AuthorSpecialty<br />
| Autor der Anfrage | BPtK<br />
| Diskussion| <br />
Potentieller Ansatz:<br />
"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)<br />
* 74<br />
** 189<br />
*** 76<br />
*** 82<br />
*** 183<br />
**** 184<br />
**** 185<br />
** 190<br />
*** 75<br />
*** 77<br />
*** 78<br />
*** 79<br />
*** 80<br />
*** 81<br />
*** 83<br />
*** 84<br />
*** 85<br />
<br />
Betroffenen Systemen und Use Cases<br />
* Suche KIM-Teilnehmer<br />
** Kammer/HBA-Herausgeber<br />
*** z.B. Landesärztekammern und BPtk, prüfen ob der Gruppen-Code 74 verwendet werden, wahrscheinlich werden eher die konkreten Codes verwendet<br />
** Verzeichnisdienst<br />
*** VZD macht keine Umsetzung von Gruppe zu konkreten Codes, d.h. kein Änderungsbedarf<br />
** AIS / KIS / weitere Primärsysteme<br />
*** 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)<br />
* ePA-Dokumentenmetadaten: authorSpeciality<br />
** ePA-Aktensystem<br />
*** 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.<br />
** ePA-FdV<br />
*** 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.<br />
** Primärsystem<br />
*** 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.<br />
<br />
* XDS Affinity Domains (nicht-ePA)<br />
** Document Source<br />
*** wie bei ePA<br />
** Document Registry<br />
*** wie bei ePA, auch wenn Updates einfacher zu realisieren sind<br />
** Document Consumer<br />
*** Suche nach AuthorSpecialty möglich, Mapping Thematik wie bei ePA<br />
<br />
* Auswirkungen auf ISIK<br />
Umsetzung nach Wunsch BPtK<br />
<br />
BPtK müsste eigenes Codessystem auf jeden Fall selbst pflegen<br />
Impact auf andere Systeme müssen noch genau analysiert werden<br />
<br />
<br />
| Entscheidung | Wenn BPtK eigenes Codesystem erstellt pflegen wir es ein<br />
| Action Item | Einpflegung Codesystem in ArtDecor notwendig<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 23.12.2022<br />
<br />
|- valign="top" <br />
<br />
<br />
| Anfrage ID| 37<br />
| Anfrage eingegangen am| 04.03.2022<br />
| Anfrage| Displaynames Gender konform gestalten<br />
| betrifft Codesystem | v.a. author role, authorspecialty<br />
| Autor der Anfrage | Gematik<br />
| 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; <br />
| 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<br />
| Action Item | Änderung wird befürwortet, wie und wann wird noch festgelegt<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 29.04.2022<br />
|- valign="top" <br />
<br />
| Anfrage ID| 38<br />
| Anfrage eingegangen am| 25.3.2022<br />
| Anfrage| KDL Mapping kontrollieren<br />
| betrifft Codesystem | class code, type code, <br />
| Autor der Anfrage | DVMD<br />
| Diskussion| <br />
| Entscheidung | Das Mapping wird bis in vier Wochen von Raik, Tarik, Arnold und eventuell Sven gereviewed. Angela teilt das Mappingdokument auf ihrem onedrive.<br />
| Action Item | Review bis in vier Wochen<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 29.04.2022<br />
|- valign="top" <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 43<br />
| Anfrage eingegangen am| 10.06.2022<br />
| 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.<br />
| betrifft Codesystem | classCode<br />
| Autor der Anfrage | Raik<br />
| Diskussion| <br />
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. <br />
<br />
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.<br />
<br />
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. <br />
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).<br />
| Entscheidung | <br />
| Action Item | <br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 19.08.2022<br />
<br />
|- valign="top" <br />
| Anfrage ID| 44<br />
| Anfrage eingegangen am| 22.07.2022<br />
| Anfrage| Versionen in FormatCode Display names aufnehmen, da einige Hersteller die FormatCodes an Hand von Displaynames suchen<br />
| betrifft Codesystem | formatCode<br />
| Autor der Anfrage | Raik<br />
| Diskussion| <br />
| Entscheidung | Display Names werden geändert<br />
| Action Item | <br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 22.07.2022<br />
<br />
|- valign="top" <br />
| Anfrage ID| 49<br />
| Anfrage eingegangen am| 12.09.2023<br />
| Anfrage| Canonical URLs für selbst-definierte Code Systems werden in ART-DECOR immer als "urn:oid:..." dargestellt, FHIR bevorzugt aber URLs. Dies führt zu unterschiedlichen Ausprägungen.<br />
| betrifft Codesystem | alle von der AG selbst definierten Code Systeme<br />
| Autor der Anfrage | Tarik<br />
| Diskussion| Es wurde schonmal versucht, aber scheiterte bisher immer an technischen Hürden<br />
| Entscheidung | kurzfristig: Tabelle in Fliesstext im Wiki erstellen, die normative URLs vorgibt. mittelfristig: Möglichkeit eigener simplifier Veröffentlichung prüfen, ART-DECOR Synchronisationsmöglichkeiten evaluieren<br />
| Action Item | <br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 15.09.2023<br />
<br />
|- valign="top" <br />
| Anfrage ID| 50<br />
| Anfrage eingegangen am| 29.08.2023<br />
| Anfrage| Code H5 „vom Patienten hochgeladen“ in Code System „Dokumenten-Warnhinweise“, als digitale Entsprechung von Code H1 (der explizit von vom Patienten mitgebrachten und vom KH-gescannten Dokumenten spricht)<br />
| betrifft Codesystem | Dokumenten-Warnhinweise<br />
| Autor der Anfrage | Tarik<br />
| Diskussion| Vorschlag für neuen Code H5 - "vom Patienten eingestellt"; Klare Unterscheidung vom Konzept H1 "vom Patienten mitgebracht" notwendig; Beschreibung für H5: "Dokumente, die der Patient (oder ein Stellvertreter) direkt eingestellt hat, z.B. über ein Patientenportal. Dokumente die physisch vor Ort an den Leistungserbringer übergeben wurden, werden stattdessen mit dem Konzept H1 gekennzeichnet. Die Dokumente können von Medizinern und anderen Leistungserbringern, von anderen Autoren wie z.B. Behörden/Krankenkassen/Schulen oder vom Patienten selbst erstellt worden sein."<br />
Text für H1 anpassen: "Dokumente, die der Patient zu seinem Arzt oder in die Klinik mitgebracht hat und die dort vom Leistungserbringer eingescannt (bei Papierdokumenten) bzw. importiert und in die Akte eingestellt wurden. Bei vom Patienten direkt in die Akte eingestellten Dokumenten wird stattdessen das Konzept H5 verwendet. Die Dokumente können von Medizinern und anderen Leistungserbringern, von anderen Autoren wie z.B. Behörden/Krankenkassen/Schulen oder vom Patienten selbst erstellt worden sein."<br />
| Entscheidung | Konzepte wie diskutiert anpassen<br />
| Action Item | <br />
| Bearbeitungsstand | offen<br />
| zuletzt bearbeitet am| <br />
<br />
|- valign="top" <br />
| Anfrage ID| 51<br />
| Anfrage eingegangen am| 05.09.2023<br />
| Anfrage| Offizielle Deutsche Übersetzung der Dokumentenattribute<br />
| betrifft Codesystem | <br />
| Autor der Anfrage | Frank<br />
| Diskussion| <br />
| Entscheidung | <br />
| Action Item | <br />
| Bearbeitungsstand | offen<br />
| zuletzt bearbeitet am| <br />
|}<br />
<br />
'''Tabelle abgeschlossene Änderungsanfragen'''<br />
<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! align="left" | Anfrage ID<br />
! align="left" | Anfrage eingegangen am<br />
! align="left" | Anfrage<br />
! align="center" | betrifft Codesystem<br />
! align="center" | Autor der Anfrage<br />
! align="center" | Diskussion<br />
! align="center" | Entscheidung<br />
! align="center" | Action Item<br />
! align="center" | Bearbeitungsstand<br />
! align="center" | zuletzt bearbeitet am<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 1<br />
| Anfrage eingegangen am|<br />
| 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:<br />
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<br />
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.<br />
Wir haben somit eine Mischung aus IHE-D-Codes und IHE-PCC/LAB-LOINC-Codes. Inhaltlich/semantisch überschneidet sich das recht munter. Fragen:<br />
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?<br />
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?<br />
Folgende Codes werden vermisst:<br />
im AOK-Projekt haben wir in Ergänzung zu den IHE-D-Codes die folgenden LOINC-Codes als typeCodes verwendet:<br />
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)<br />
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<br />
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<br />
Verschiedene Ausprägungen des Entlassbriefs, um hier anhand der typeCodes eine bessere Sortierung für den Patienten zu ermöglichen:<br />
11490-0: Ärztlicher Entlassbrief<br />
34105-7: Krankenhausentlassbrief (vorläufige/gekürzte Fassung für den Patienten bei der Entlassung)<br />
18842-5: Finales Krankenhausentlassbrief<br />
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.<br />
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.<br />
58410-2: Vollständiges Blutbild<br />
55429-5: Kleines Blutbild<br />
| betrifft Codesystem | class codes, type codes<br />
| Autor der Anfrage | JC <br />
| 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<br />
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.<br />
<br />
| 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.<br />
| 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<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am|21.2.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 2<br />
| Anfrage eingegangen am|<br />
| Anfrage| es scheint in Deutschland Bestrebungen zu geben, Unfallchirurgie mit der Orthopädie zusammenzulegen.<br />
Ab August 2019 wird es im UKD nur noch die „Klinik für Orthopädie und Unfallchirurgie“ geben.<br />
Ist die Einführung einer weiteren Fachabteilung im DocumentEntry.practiseSettingCode geplant?<br />
In DocumentEntry.authorSpecialty findet sie sich:<br />
Code 512 Anzeigename FA Orthopädie und Unfallchirurgie<br />
| betrifft Codesystem | practiceSettingCode <br />
| Autor der Anfrage | SB<br />
| Diskussion| evtl. practiceSettingCode Chirurgie verwenden, deckt beides ab<br />
| Entscheidung |<br />
| Action Item |<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 29.11.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 3<br />
| Anfrage eingegangen am|<br />
| 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.<br />
Dazu möchten wir das Value Set für XDS-Metadatenattribut formatCode um den folgenden Wert erweitern: urn:gematik:ig:DatensatzPersoenlicheErklaerungen:r3.1<br />
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.<br />
| betrifft Codesystem | formatCode<br />
| Autor der Anfrage | RK<br />
| Diskussion| keine Einwände<br />
| Entscheidung | wir fügen Code hinzu<br />
| Action Item | in ArtDecor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am|13.12.2019<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 5<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Freischaltung der FHIR Schnittstelle in ArtDecor<br />
| betrifft Codesystem | alle<br />
| Autor der Anfrage | SH über Tarik Idris<br />
| Diskussion| <br />
| Entscheidung | wird gemacht<br />
| Action Item | Tarik: FHIR Schnittstelle in ArtDecor freischalten<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 15.11.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 6<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Ansatz Canonical URLs diskutieren<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | Tarik Idris<br />
| Diskussion| Ziel: Gute Einfügung in FHIR Umgebung<br />
| Entscheidung | Für V3 alle URNs durch URLs ersetzen <br />
| 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 <br />
| Bearbeitungsstand | für ValueSets erledigt (Angela)<br />
| zuletzt bearbeitet am| 14.11.2021<br />
<br />
|- valign="top" <br />
| Anfrage ID| 8<br />
| Anfrage eingegangen am| 15.11.2019<br />
| Anfrage| Vorgehensweise für V3 auf eigener WikiSeite beschreiben<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | SL<br />
| Diskussion| befürwortet<br />
| Entscheidung | befürwortet<br />
| Action Item | Anlegen neue Seite im HL7 Wiki ==> Angela, Ziele ==> Angela, allgemeine Weiterentwicklung als Ziel hinzufügen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 13.12.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 9<br />
| Anfrage eingegangen am| 13.12.2019<br />
| Anfrage| Bericht Treffen BVITG, Interopforum, Gematik, Vorabstimmung EPA Version 1.2.2022<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | TI<br />
| 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) <br />
| Entscheidung | über konstruktive Zusammenarbeit wird sich gefreut<br />
| Action Item | keine<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 13.12.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 10<br />
| Anfrage eingegangen am| 12.01.2020<br />
| 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.<br />
https://loinc.org/file-access/download-id/8994/<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | ST<br />
| Diskussion| <br />
| Entscheidung | Gemeinsame Strategietelko zur Zusammenführung LOINC, SNOMED CT, XDT, QMS, KDL deutsche XDS Value Sets am 28.5.2020 10-12 Uhr geplant<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 24.04.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 11<br />
| Anfrage eingegangen am| 07.02.2020<br />
| Anfrage| Zusammenarbeit KBV<br />
| betrifft Codesystem | alle, v.a. format Code<br />
| Autor der Anfrage | RK<br />
| Diskussion| Den MIOs müssen XDS Metadaten zugeordnet werden, v.a. formatCodes<br />
| Entscheidung | Arbeitsgruppe bietet proaktiv Hilfe bzgl. der Metadaten bei KBV an<br />
| Action Item | Mail an Vorstand ==> Mail an KBV (H. Tenkow)<br />
| Bearbeitungsstand | Mail an Vorstand gesendet<br />
| zuletzt bearbeitet am| 07.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 12<br />
| Anfrage eingegangen am| 21.02.2020<br />
| 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<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | RK<br />
| Diskussion| keine Einwände<br />
| Entscheidung | werden aufgenommen<br />
| Action Item | Aufnahme in ArtDecor ==> Angela<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 24.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 13<br />
| Anfrage eingegangen am| 06.03.2020<br />
| Anfrage| Übersetzung der Metadatenbezeichnungen ins Englische<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | SL<br />
| Diskussion| ValueSets sind nur für Deutschland, jeder Dokumentierende sollte über ausreichende Deutschkenntisse verfügen<br />
| Entscheidung | abgelehnt<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 06.03.2020<br />
|- valign="top" <br />
<br />
|- valign="top"<br />
| Anfrage ID| 14<br />
| Anfrage eingegangen am| 24.04.2020<br />
| Anfrage| Neuer FormatCode für eRezept (Daten elektronischer Verordnung) der Gematik<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | RK<br />
| 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<br />
| Entscheidung | urn:gematik:ig:VerordnungsdatensatzMedikation:r4.0<br />
| Action Item | in Art Decor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
<br />
<br />
|- valign="top" <br />
<br />
<br />
| Anfrage ID| 15<br />
| Anfrage eingegangen am| 14.05.2020<br />
| Anfrage| Kommentierung EPA XDS Metadaten<br />
| betrifft Codesystem | fast alle<br />
| Autor der Anfrage | TI<br />
| Diskussion| <br />
| 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<br />
| Action Item | Tarik==> Kommentar an gematik<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.05.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 16<br />
| Anfrage eingegangen am| 14.05.2020<br />
| 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. <br />
| betrifft Codesystem | TypeCode<br />
| Autor der Anfrage | VK<br />
| Diskussion| <br />
| Entscheidung | wird als Beispiel in pathologische Befunde aufgenommen<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
|- valign="top" <br />
<br />
| Anfrage ID| 17<br />
| Anfrage eingegangen am| 14.05.2020<br />
| Anfrage| Am UKHD gibt es ein Zentrum für Seltene Erkrankungen. Dort werden Patienten jeglichen Alters behandelt. <br />
| betrifft Codesystem | PracticeSettingCode<br />
| Autor der Anfrage | VK<br />
| Diskussion| <br />
| 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<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 18<br />
| Anfrage eingegangen am| 26.06.2020<br />
| Anfrage| Code für Erfassung Fall- /Bewegungsdaten<br />
| betrifft Codesystem | Class Code, Type Code<br />
| Autor der Anfrage | AM<br />
| 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<br />
| Entscheidung | keine zusätzlichen Codes<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 20<br />
| Anfrage eingegangen am| 10.07.2020<br />
| 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:<br />
<br />
Unterkategorien von 1a - Code<br />
<br />
Hausarzt/ Hausärztin - practitioner<br />
<br />
Krankenhaus - hospital<br />
<br />
Labor und Humangenetik - laboratory<br />
<br />
Physiotherapeuten - physiotherapy<br />
<br />
Psychotherapeuten - psychotherapy<br />
<br />
Dermatologie - dermatology<br />
<br />
Urologie/Gynäkologie - gynaecology_urology<br />
<br />
Zahnheilkunde und Mund-Kiefer-Gesichtschirurgie - dentistry_oms<br />
<br />
Weitere Fachärzte/ Fachärztinnen - other_medical<br />
<br />
Weitere nicht-ärztliche Berufe - other_non_medical<br />
<br />
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.<br />
<br />
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.<br />
<br />
Für diesen Code soll ein Code-System "Sonstige Berechtigungen ePA" genutzt werden.<br />
| betrifft Codesystem | Anfrage neues Codesystem / ValueSet für Folder<br />
| Autor der Anfrage | JG (Gematik)<br />
| 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<br />
| Entscheidung |Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte<br />
| Action Item | Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte<br />
| 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 <br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 21<br />
| Anfrage eingegangen am| 31.07.2020<br />
| 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:<br />
<br />
"urn:gematik:ig:KinderuntersuchungsheftUntersuchungen:r4.0"<br />
"urn:gematik:ig:KinderuntersuchungsheftTeilnahmekarte:r4.0"<br />
"urn:gematik:ig:KinderuntersuchungsheftNotizen:r4.0"<br />
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.<br />
<br />
<br />
<br />
Als Anzeigename schlage ich vor:<br />
<br />
· Untersuchungen Kinderuntersuchungsheft<br />
<br />
· Teilnahmekarte Kinderuntersuchungsheft<br />
<br />
· Notizen Kinderuntersuchungsheft<br />
| betrifft Codesystem | FormatCodes<br />
| Autor der Anfrage | Gematik<br />
| Diskussion| <br />
| Entscheidung | wird aufgenommen<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 22<br />
| Anfrage eingegangen am| 16.09.2020<br />
| Anfrage| Patientenverfügung als Beispiel für administratives Dokument aufnehmen<br />
| betrifft Codesystem | classCode<br />
| Autor der Anfrage | VB (Uniklinik HD)<br />
| Diskussion| entspricht Mapping in KDL<br />
| Entscheidung | wird als Beispiel hinzugefügt<br />
| Action Item | in ArtDecor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 23<br />
| Anfrage eingegangen am| 18.09.2020<br />
| Anfrage| TypeCode für mikroskopische Bilder<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | VB (Uniklinik HD)<br />
| Diskussion| wenn Ergebnis Mikrobiologie oder Pathologie, dann diesen Code verwenden, ansonsten BILD<br />
| Entscheidung | wenn Ergebnis Mikrobiologie (MKRO) oder Pathologie (PATH) dann diesen Code verwenden, ansonsten BILD<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 24<br />
| Anfrage eingegangen am| 5.11.2020<br />
| 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.<br />
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.<br />
HL7 bildet die Berufsgruppen PP (2 L 82) und KJP (2-L 76) falsch ab, nämlich als Spezialisierung, nicht als Grundberufe.<br />
Die Fachgebiete des neuen Berufs ‚Psychotherapeut*in‘ sind im HL7 nicht abgebildet.<br />
| betrifft Codesystem | authorspecialty<br />
| Autor der Anfrage | BPtK<br />
| Diskussion| <br />
| Entscheidung |Neue Berufsgruppen werden in Authorspecialty aufgenommen.<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 25<br />
| Anfrage eingegangen am| 5.11.2020<br />
| Anfrage| Übernahme der Facharzt- und Schwerpunktscodes aus dem Codesystem der BAEK, da relevante Facharzt - und Schwerpunktscodes fehlen.<br />
| betrifft Codesystem | authorspecialty<br />
| Autor der Anfrage | BAEK<br />
| 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.<br />
| 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<br />
| Action Item | Konzept zur Pflege, Mapping BAEK Codes auf practice Setting Codes wird auch bei KBV veröffentlicht (als FHIR concept map)<br />
| Bearbeitungsstand |erledigt<br />
| zuletzt bearbeitet am| 01.02.2021<br />
<br />
|- valign="top" <br />
| Anfrage ID| 26<br />
| Anfrage eingegangen am| 13.11.2020<br />
| Anfrage| Prozeduren zu Fertilitätsbehandlung in Gebu aufnehmen?<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |nein<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 01.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 27<br />
| Anfrage eingegangen am| 13.11.2020<br />
| Anfrage| Typecode für Erfassung der Dauer der Gebärdendolmetscherunterstützung<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |Abrechnungsdokumente<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 01.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 28<br />
| Anfrage eingegangen am| 10.12.2020<br />
| Anfrage| Classcode für Diagnosenübersichtsblatt<br />
| betrifft Codesystem | classCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |hängt vom UseCase ab<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 01.02.2020<br />
|- valign="top" <br />
| Anfrage ID| 30<br />
| Anfrage eingegangen am| 04.02.2021<br />
| Anfrage| Nutzung von XDS Value Sets für den digitalen Austausch medizinischer Unterlagen mit den Medizinischen Diensten.<br />
| betrifft Codesystem | alle<br />
| Autor der Anfrage | AMue<br />
| Diskussion| <br />
| Entscheidung | <br />
| Action Item | Annett lädt Herrn Dr. Eckardt vom MD Westfalen-Lippe zur nächsten Telko ein<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| <br />
<br />
|- valign="top" <br />
| Anfrage ID| 32<br />
| Anfrage eingegangen am| 09.2021<br />
| Anfrage| Aufnahme von Pflegefachmann/-fachfrau, da neuer Ausbildungsberuf<br />
| betrifft Codesystem | Authorspecialty<br />
| Autor der Anfrage | FP<br />
| 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.<br />
| Entscheidung | Konzepte werden wie vorgeschlagen ergänzt, bzw. - bezeichnungen geändert.<br />
| Action Item | Eröffnung version 4 draft des Value Sets ==> Anpassungen in ArtDecor erfolgt<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 15.10.2021<br />
<br />
|- valign="top" <br />
| Anfrage ID| 34<br />
| Anfrage eingegangen am| 22.12.2021<br />
| 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:<br />
• IHE-XDS classCode = AUS<br />
• IHE-XDS typeCode = BESC<br />
Dies widerspricht den Kodiervorgaben von IHE Deutschland Dort ist festgelegt, dass der Notfalldatensatz mit typeCode PATD dokumentiert werden soll.<br />
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.<br />
Beispiele: Ausweise, Vorsorgevollmacht, Patientenverfügung, Wertgegenständeverwaltung, , Patiententagebuch<br />
<br />
| betrifft Codesystem | TypeCode<br />
| Autor der Anfrage | AMue<br />
| Diskussion| <br />
| Entscheidung | Missverständnis konnte geklärt werden<br />
| Action Item | keine<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| <br />
<br />
|- valign="top" <br />
| Anfrage ID| 35<br />
| Anfrage eingegangen am| 14.02.2022<br />
| Anfrage| Die gematik möchte wieder Aktualisierungen für MIO-Versionen zu den Format Codes einbringen. <br />
<br />
neu (die DisplayNames sind dieselben der Vorgänger)<br />
<br />
· urn:gematik:ig:KinderuntersuchungsheftUntersuchungen:v1.0.1<br />
<br />
· urn:gematik:ig:KinderuntersuchungsheftTeilnahmekarte:v1.0.1<br />
<br />
· urn:gematik:ig:KinderuntersuchungsheftNotizen:v1.0.1<br />
<br />
· urn:gematik:ig:Mutterpass:v1.1.0<br />
<br />
· urn:gematik:ig:VerordnungsdatensatzMedikation:v1.0.2<br />
<br />
<br />
<br />
deprecated/obsolet<br />
<br />
· urn:gematik:ig:VerordnungsdatensatzMedikation:r4.0<br />
<br />
· urn:gematik:ig:Kinderuntersuchungsheft:v1.0.0<br />
<br />
| betrifft Codesystem | FormatCode<br />
| Autor der Anfrage | RK<br />
| Diskussion| Versionsänderungen auf 3. Ebene (Patch) sollten in Zukunft keine Änderungen am Formatcode verursachen<br />
| 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.<br />
| Action Item | Art-Decor anpassen, RK Kommunikation des Wunschs der AG an die Gematik<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.03.2022<br />
<br />
|- valign="top" <br />
| Anfrage ID| 36<br />
| Anfrage eingegangen am| 18.02.2022<br />
| Anfrage| Pflege des Mappings der KDL auf ClassCode TypeCode mit Arbeitsgruppe abstimmen<br />
<br />
| betrifft Codesystem | eventCodeList, classCode, typeCode<br />
| Autor der Anfrage | AM<br />
| Diskussion| <br />
| Entscheidung | Review des Mappings können wir machen, aber Verantwortung liegt bei DVMD, sobald neues Mapping vorliegt, erfolgt Review als neue Anfrage<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.02.2022<br />
<br />
|- valign="top" <br />
| Anfrage ID| 39<br />
| Anfrage eingegangen am| 31.03.2022<br />
| Anfrage| neue FormatCodes, neue eventCodes<br />
DiGA<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:diga:v1.0"<br />
<br />
documentEntry.formatCode.displayName: "DiGA (gematik)"<br />
<br />
<br />
<br />
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: <br />
<br />
<br />
<br />
DMP Asthma bronchiale<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-Asthma:v4.45"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Asthma (gematik)"<br />
<br />
<br />
<br />
DMP Brustkrebs<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-BRK:v4.23"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Brustkrebs (gematik)"<br />
<br />
<br />
<br />
DMP Chronische Herzinsuffizienz<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-HI:v1.1" <br />
<br />
documentEntry.formatCode.displayName: "eDMP Herzinsuffizienz (gematik)"<br />
<br />
<br />
<br />
DMP Chronischer Rückenschmerz<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-Rueckenschmerz:v1.0"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Rückenschmerz (gematik)"<br />
<br />
<br />
<br />
DMP COPD<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-COPD:v4.4" <br />
<br />
documentEntry.formatCode.displayName: "eDMP Chronic Obstrusive Pulmonary Disease (gematik)"<br />
<br />
<br />
<br />
DMP Depressionen<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-Depression:v1.1" <br />
<br />
documentEntry.formatCode.displayName: "eDMP Depression (gematik)"<br />
<br />
<br />
<br />
DMP Diabetes mellitus Typ 1<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-DM1:v5.5"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Diabetes mellitus Typ 1 (gematik)"<br />
<br />
<br />
<br />
DMP Diabetes mellitus Typ 2<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-DM2:v6.5"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Diabetes mellitus Typ 2 (gematik)"<br />
<br />
<br />
<br />
DMP Koronare Herzkrankheit<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-KHK:v4"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Koronare Herzkrankheit (gematik)"<br />
<br />
<br />
<br />
DMP Osteoporose<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-OST:v1.0"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Osteoporose (gematik)<br />
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.<br />
<br />
<br />
<br />
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.<br />
| betrifft Codesystem |formatCodes<br />
| Autor der Anfrage | Gematik<br />
| Diskussion| Die Display names des KBV CodeSystems sind ziemlich uneindeutig. Beispiel: HI könnte nicht nur Herzinsuffizienz sondern auch Hinterwandinfarkt oder Harnwegsinfekt bedeuten.<br />
| 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.<br />
| Action Item | Raik gibt entsprechende Rückmeldung an KBV, Angela fügt eventCOdes und formatCodes den entsprechende ValueSets hinzu<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 27.05.2022<br />
|- valign="top" <br />
<br />
| Anfrage ID| 40<br />
| Anfrage eingegangen am| 28.04.2022<br />
| Anfrage| passender eventCode bei stationärer Wiederaufnahme nach Unterbrechung<br />
| betrifft Codesystem | eventCode<br />
| Autor der Anfrage | AM (UKHD)<br />
| Diskussion| <br />
| Entscheidung | E216 Wiederaufnahme vollstationär nach kurzzeitiger Unterbrechung wird hinzugefügt<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 29.04.2022<br />
<br />
<br />
|- valign="top" <br />
<br />
| Anfrage ID| 41<br />
| Anfrage eingegangen am| 28.04.2022<br />
| 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"<br />
displayName: " Pflegeüberleitungsbogen (gematik)"<br />
| betrifft Codesystem | formatCode<br />
| Autor der Anfrage | gematik<br />
| Diskussion| <br />
| Entscheidung | Major Revisions werden als FormatCodes aufgenommen<br />
| Action Item | Feedback an Gematik ==> positiv<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 27.05.2022<br />
|- valign="top" <br />
<br />
<br />
| Anfrage ID| 42<br />
| Anfrage eingegangen am| 27.05.2022<br />
| Anfrage|neue Dokumentenformate für gematik "urn:gematik:ig:DMP-Rheuma:v1<br />
eDMP" displayName: "Rheumatoide Arthritis (gematik)"<br />
| betrifft Codesystem | formatCode<br />
| Autor der Anfrage | gematik<br />
| Diskussion| <br />
| Entscheidung |Major Revisions werden aufgenommen<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 27.05.2022<br />
|- valign="top" <br />
<br />
| Anfrage ID| 45<br />
| Anfrage eingegangen am| 16.09.2022<br />
| Anfrage| Fragen zu XDS Metadaten aus einem Klinikum<br />
| betrifft Codesystem | practicsettingCode<br />
| Autor der Anfrage | SL<br />
| Diskussion| Fachabteilungsschlüssel werden nicht durch IHE vergeben, sondern vom Klinikum zu Abrechnungszwecken für bettenführende Abteilungen; Die Fachabteilungsschlüssel sind keine XDS Metadaten. Das Mapping ist nur als Hilfestellung gedacht. Die Zuordnung des PracticeSetting erfolgt in der Regel für eine Abteilung. In der Abteilung können unterschiedliche Personengruppen beschäftigt sein. Für die Zuodnung des passenden Codes ist, die Aufgabe der Einrichtung entscheidend.<br />
| Entscheidung | --<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 16.09.2022<br />
<br />
|- valign="top" <br />
| Anfrage ID| 46<br />
| Anfrage eingegangen am| 25.11.2022<br />
| Anfrage| XDS Metadaten für Einlagerungsdokumente<br />
| betrifft Codesystem | typeCode, eventCodeList<br />
| Autor der Anfrage | AM<br />
| Diskussion| Neuer typeCode ist sinnvoll,eventCode wird nur vorgeschlagen, wenn man sinnvollen Wert findet. Bei SNOMED CT könnten Hilfsmittel fehlen.<br />
| Entscheidung | <br />
typeCode: EINL Einlagerungsdokumente Definition: Alle Arten von Dokumenten, die die Einlagerung von patientenbezogenen Objekten beschreiben. Dies sind vor allem Biomaterialien wie Spermien, Gewebeproben, Eier, Blutproben, Speichelproben, die in Biobanken eingelagert werden. Dies können aber auch Hilfsmittel wie Prothesen, Rollstühle sein. Eine genauere Unterscheidung des Typs kann über den eventCode erfolgen. Beispiele: Einlagerungsbestätigung, Einlagerungsschein, Einlagerungsurkunde.<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 09.12.2022<br />
<br />
|- valign="top" <br />
<br />
| Anfrage ID| 47<br />
| Anfrage eingegangen am| 19.01.2023<br />
| Anfrage| neue FormatCodes: urn:gematik:ig:Arbeitsunfaehigkeitsbescheinigung:v1.1 mit DisplayName: Arbeitsunfähigkeitsbescheinigung (gematik) v1.1, Code: urn:gematik:ig:VerordnungsdatensatzMedikation:v1.1 mit<br />
DisplayName: Verordnungsdatensatz Medikation (gematik) v1.1<br />
alte FormatCodes auf deprecated setzen: <br />
urn:gematik:ig:VerordnungsdatensatzMedikation:r4.0<br />
urn:gematik:ig:Mutterpass:v1.0.0<br />
urn:gematik:ig:KinderuntersuchungsheftTeilnahmekarte:v1.0.0<br />
urn:gematik:ig:KinderuntersuchungsheftUntersuchungen:v1.0.0<br />
urn:gematik:ig:KinderuntersuchungsheftNotizen:v1.0.0<br />
<br />
| betrifft Codesystem | formatCodes<br />
| Autor der Anfrage | gematik<br />
| Diskussion| <br />
| Entscheidung | wird angenommen<br />
| Action Item | in ArtDecor übernommen<br />
| Bearbeitungsstand |erledigt<br />
| zuletzt bearbeitet am| 03.02.2023<br />
|- valign="top" <br />
<br />
| Anfrage ID| 48<br />
| Anfrage eingegangen am| 02.03.2023<br />
| Anfrage| Änderung bei FormatCodes: Ersetzung urn:gematik:ig:diga:v1.0 durch urn:gematik:ig:diga:v1.1<br />
<br />
| betrifft Codesystem | formatCodes<br />
| Autor der Anfrage | gematik<br />
| Diskussion| <br />
| Entscheidung | wird angenommen<br />
| Action Item | <br />
| Bearbeitungsstand |erledigt<br />
| zuletzt bearbeitet am| 26.05.2023<br />
|- valign="top" <br />
<br />
<br />
<br />
|}<br />
<br />
'''Tabelle Aktueller Stand'''<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! width="25%" align="left" | Codesystem<br />
! align="center" | Stand Konzepte<br />
! align="center" | ArtDecor<br />
! align="center" | WikiText<br />
! align="center" | Review durch<br />
<br />
|- valign="top" <br />
| Codesystem | Einleitung<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Sven, Frank<br />
<br />
|- valign="top" <br />
| Codesystem | Vokabular Management<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Sven, Frank<br />
<br />
|- valign="top" <br />
| Codesystem | Confidentiality Code<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Sven, Frank<br />
<br />
|- valign="top" <br />
| Codesystem | AuthorRole<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Angela, Sven<br />
<br />
|- valign="top" <br />
| Codesystem | AuthorSpeciality<br />
| Stand Konzepte | n/a<br />
| ArtDecor | offen<br />
| WikiText | offen<br />
| Review durch | ''Tarik?''<br />
<br />
|- valign="top" <br />
| Codesystem | EventCodeList<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Angela<br />
<br />
|- valign="top" <br />
| Codesystem | ContentTypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Axel<br />
<br />
|- valign="top" <br />
| Codesystem | ClassCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Arnold, Antje<br />
<br />
|- valign="top" <br />
| Codesystem | TypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Arnold, Antje<br />
<br />
|- valign="top" <br />
| Codesystem | FormatCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | Axel<br />
<br />
|- valign="top" <br />
| Codesystem | HealthcareFacilityTypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | ''Tarik?''<br />
<br />
|- valign="top" <br />
| Codesystem | PracticeSettingCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | Antje, Arnold<br />
<br />
|- valign="top" <br />
| Codesystem | Folder.codeList<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | Angela, Sven<br />
<br />
<br />
|- valign="top" <br />
| Valuesets/ generell| EPA Verwendung<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Erstellung durch | Raik, Christof<br />
<br />
|}<br />
<br />
'''Schritte zur Veröffentlichung v3'''<br />
# Zeitplan (draft) erstellen<br />
#* Anfang Februar Ankündigung<br />
#* Anfang März Kommentierungsstart<br />
#* Anfang April Ende Kommentierung, Anfang Kommentarauflösungs<br />
#* Anfang Juni Veröffentlichung<br />
# 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<br />
# Ankündigung formulieren <br />
# Kapitel zur Verwendung der ValueSets in der EPA schreiben<br />
# Review der Wiki-Texte und AuthorSpecialty Code anpassen<br />
# Change Liste erstellen<br />
# PDF erstellen<br />
# PDF in Wiki und auf IHE-D Seite hochladen/referenzieren<br />
# Kommentare sammeln<br />
# Kommentare auflösen<br />
# Abstimmung zur Veröffentlichung<br />
# Finale Version erstellen und in Wiki und IHE-D Seite hochladen<br />
<br />
Optional:<br />
* Erläuterung zum Zusammenspiel mit FHIR<br />
* Hinweis/kurze Erläuterung der nicht behandelten XDS Metadaten<br />
<br />
'''IG Struktur'''<br />
<br />
# [[ihevs:Einleitung]] (Vorgehen, Ziele, Umgang mit v1, normativ, Delta-Liste?, Änderungen/Pflege)<br />
# [[Ihevs:Vokabular-Management]]<br />
# [[ihevs:DocumentEntry.authorRole]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.authorSpecialty]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.classCode]]<br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.confidentialityCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.eventCodeList]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.formatCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.healthcareFacilityTypeCode]]<br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.languageCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.practiceSettingCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.typeCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:SubmissionSet.contentTypeCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:Folder.codeList]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor<br />
<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:Vokabular-Management&diff=80495Ihevs:Vokabular-Management2023-09-29T11:57:19Z<p>Tidris: /* Identifikation von Kodesystemen in FHIR-basierter Kommunikation */ URLs basierend auf gihub export geändert</p>
<hr />
<div>{{DocumentPart}}<br />
=Vokabular-Management=<br />
<br />
Die Übermittlung von konkreten Daten kann auf zweierlei Art und Weise erfolgen: Die einfachste Variante ist Freitext, bei der beliebige Daten - als Zeichenkette (ggf. noch eingeschränkt auf einen bestimmten Datentyp) - übertragen werden. Dieses Verfahren bietet sich an, wenn die individuelle Ausprägung sehr unterschiedlich sein kann wie bspw. der Name des Patienten oder ein Kommentar. Für immer wiederkehrende und im Prinzip gleiche Information, wie bspw. der Familienstand, werden die zu übertragenden Daten abgekürzt und durch einen "Platzhalter" ersetzt. Bei letzterem muss die Bedeutung aber klar sein. Hierfür werden Kodesysteme definiert, die sowohl die Abkürzungen - Kodes - als auch deren Bedeutung auflisten. Die Zuordnung von einzelnen Feldern in einer Datenaustauschspezifikation zu konkreten Wertelisten erfolgt mehrstufig: Die Festlegung der erlaubten Werte für ein kodiertes Attribut erfolgt über die Angabe von sog. Konzept- oder Vokabeldomänen (''Concept / Vocabulary Domains''), Kodiersystemen (''Code Systems'') und Wertemengen (''Value Sets''). <br />
<br />
Eine '''Konzeptdomäne''' dient dazu, den Wertebereich eines Attributs einzugrenzen ohne dabei direkt schon feste Kodiersysteme oder Value Sets vorzugeben. Eine Konzeptdomäne wird durch einen Namen, eine textuelle Beschreibung sowie eine Reihe von Beispielkonzepten definiert. Zum Beispiel soll die Konzeptdomäne DocumentEntry.typeCode den Typ eines Dokuments aus Benutzersicht kodieren. <br />
<br />
Ein '''Value Set''' ist eine eindeutige identifizierbare Sammlung von Konzeptrepräsentationen und es ist einer oder mehreren Konzeptdomänen zugeordnet. Ein Value Set kann Codes aus einem oder mehreren Kodiersystemen enthalten. Ein '''Kodiersystem''' wird dabei durch eine Liste von Codes mit zugehörigen Anzeigenamen und Beschreibungen definiert. Innerhalb eines Kodiersystems muss ein Code eine eindeutig definierte Bedeutung haben. <br />
<br />
Value Sets können in unterschiedlicher Art und Weise definiert werden: ''extensional'' als Sammlungen von Codes (Konzepten) oder ''intensional'' über einen berechenbaren Ausdruck, aus dem sich eine Codeliste exakt ermitteln lässt. Die Value Sets für DocumentEntry.typeCode und DocumentEntry.classCode in diesem Leitfaden sind beispielsweise extensional als Listen definiert, während das Value Set für DocumentEntry.formatCode intensional über Konstruktionsvorschriften für URNs definiert wurde.<br />
<br />
Wenn ein Value Set neben den genannten oder beschriebenen Codes zusätzliche Werte erlaubt, wird es als offen (''open'') bezeichnet, andernfalls als geschlossen (''closed''). Das Value Set für DocumentEntry.languageCode ist beispielsweise offen, da neue Sprachcodes gebildet und wenn notwendig auch verwendet werden können. Die Value Sets für DocumentEntry.classCode und DocumentEntry.healthcareFacilityTypeCode sind hingegen geschlossen. Das heißt, dass eine Erweiterung nur über eine neue Version der Value Sets erfolgen sollte.<br />
<br />
Die Identifikation eines Value Sets erfolgt bei CDA und IHE XDS über eine OID, bei FHIR über eine URL. Die Version eines Value Sets wird über einen Zeitstempel charakterisiert. Die Bindung eines kodierten Elementes an ein Value Set (Binding) kann nun dynamisch (''dynamic'') oder statisch (''static'') erfolgen. Ein dynamisches Binding bezieht sich auf die jeweils aktuellste Version eines Value Sets, während bei einem statischen Binding eine feste Version angegeben wird. Bei einem statischen Binding müssen OID bzw. ein eindeutiger Bezeichner sowie ein Zeitstempel angegeben werden. Beim dynamischen Binding fehlt der Zeitstempel. <br />
<br />
Unabhängig davon gibt es für das Binding von ValueSets noch weitere Unterscheidungsmöglichkeiten. Beim ''Design-Time Binding'' wird das zu verwendende Value Set explizit angegeben. Beim ''Runtime Binding'' werden nur die Konzeptdomäne und die sogenannte Realm (z.B. „Deutschland“) festgelegt. Das effektive Value Set wird dann dynamisch über einen Terminologieserver an Hand von Konzeptdomäne und Realm ermittelt. <br />
<br />
Bindings können verpflichtend sein (''required''), empfohlen werden (''suggested'' oder ''preferred'') oder dienen nur als Beispiel (''example''). Einzelne Werte eines Value Sets können als verpflichtend (''required''), erlaubt (''permitted'') oder ausgeschlossen (''excluded'') gekennzeichnet werden. Die in diesem Leitfaden definierten Codes besitzen alle den Status permitted.<br />
<br />
Die folgende Tabelle gibt eine Übersicht über die Eigenschaften der bereits definierten Value Sets:<br />
<div class="landscape"><br />
{| class="hl7table"<br />
|-<br />
!XDS-Metadatum!!Beschreibung!!Definitionsart!!Erweiterbarkeit!!Bindungsstärke!!Bindungsart!!Versionsbindung<br />
|-<br />
|[[Ihevs:DocumentEntry.authorRole|authorRole]] ||Rolle des Autors||extensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.authorSpecialty|authorSpecialty]] ||Fachrichtung des Autors||extensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.classCode|classCode]] ||Dokumentenklasse||extensional||closed||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.confidentialityCode|confidentialityCode]] ||Dokumenten-Vertraulichkeitsstufe||extensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.eventCodeList|eventCodeList]] ||Tätigkeitskennzeichen/Zusätzliche Kennzeichnung||intensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.formatCode|formatCode]] ||Dokumentenformat||intensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.healthcareFacilityTypeCode|healthcareFacilityTypeCode]] ||Einrichtungsart||extensional||closed||suggested|| design-time||dynamic<br />
|-<br />
|[[LanguageCode|languageCode]] ||Dokumentensprache||intensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.PracticeSettingCode|practiceSettingCode]] ||Erstellende Fachrichtung||extensional||closed||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.typeCode|typeCode]] ||Dokumententyp||extensional||closed||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:SubmissionSet.contentTypeCode|SubmissionSet.contentTypeCode]] ||Inhaltskennzeichen des SubmissionSets||extensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:Folder.codeList|Folder.codeList]] ||Ordnerklassifizierung||extensional||open||suggested||design-time||dynamic<br />
|}<br />
</div><br />
<br />
== Identifikation von Kodesystemen in FHIR-basierter Kommunikation ==<br />
<br />
FHIR empfiehlt die Verwendung einer URL als primäre Identifikation eines Kodesystems. Es ist zwar grundsätzlich zulässig eine OID in ihrer URN-form, d.h. beginnend mit "urn:oid:", als Identifikation zu verwenden, aber es gilt als nicht-idiomatisch. Aus technischen Gründen können die von dieser Arbeitsgruppe erstellten Kodesysteme in ART-DECOR nicht konsistent mit einer URL versehen werden. Daher werden die in FHIR zu verwendenen Canonical URLs in der folgenden Tabelle für alle in diesem Leitfaden eingeführten Kodesysteme aufgeführt. Die OID-URNs, die in den in diesem Leitfaden inkludierten ART-DECOR Auszügen verwendet werden, sind als zusätzliche, sekundäre Identifikatoren zu verstehen.<br />
{| class="hl7table"<br />
|-<br />
!Kodesystem!!Canonical URL!!sekundärer Identifier||aus Value Set<br />
|-<br />
|Prozessrollen für Autoren||http://ihe-d.de/CodeSystems/ProzessrollenFuerAutoren||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.13||[[Ihevs:DocumentEntry.authorRole|authorRole]]<br />
|-<br />
|Patientenbeziehungsrollen für Autoren||http://ihe-d.de/CodeSystems/PatientenbeziehungsrollenFuerAutoren||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.14||[[Ihevs:DocumentEntry.authorRole|authorRole]]<br />
|-<br />
|Qualifikationen nicht ärztlicher Autoren||http://ihe-d.de/CodeSystems/QualifikationenNichtAerztlicherAutoren||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.11||[[Ihevs:DocumentEntry.authorSpecialty|authorSpecialty]]<br />
|-<br />
|Facharzttitel der Ärztekammern||http://ihe-d.de/CodeSystems/FacharzttitelDerAerztekammern||urn:oid:1.2.276.0.76.5.514||[[Ihevs:DocumentEntry.authorSpecialty|authorSpecialty]]<br />
|-<br />
|Qualifikatoren zahnärztlicher Autoren||http://ihe-d.de/CodeSystems/QualifikatorenZahnaerztlicherAutoren||urn:oid:1.2.276.0.76.5.492||[[Ihevs:DocumentEntry.authorSpecialty|authorSpecialty]]<br />
|-<br />
|Ärztliche Berufsvarianten||http://ihe-d.de/CodeSystems/AerztlicheBerufsvarianten||urn:oid:1.2.276.0.76.5.493||[[Ihevs:DocumentEntry.authorSpecialty|authorSpecialty]]<br />
|-<br />
|Dokumentenklassen||http://ihe-d.de/CodeSystems/IHEXDSclassCode||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.8||[[Ihevs:DocumentEntry.classCode|classCode]] <br />
|-<br />
|Betroffeneneinschätzung der Vertraulichkeitsstufe||http://ihe-d.de/CodeSystems/BetroffeneneinschaetzungVertraulichkeitsstufe||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.10||[[Ihevs:DocumentEntry.confidentialityCode|confidentialityCode]]<br />
|-<br />
|Dokumenten-Warnhinweise||http://ihe-d.de/CodeSystems/DokumentenWarnhinweise||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.15||[[Ihevs:DocumentEntry.eventCodeList|eventCodeList]]<br />
|-<br />
|Fallkontext bei Dokumentenerstellung||http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.16||[[Ihevs:DocumentEntry.eventCodeList|eventCodeList]]<br />
|-<br />
|Deutsche Dokumentenformate||http://ihe-d.de/CodeSystems/DeutscheDokumentenformate||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.6||[[Ihevs:DocumentEntry.formatCode|formatCode]] <br />
|-<br />
|Einrichtungsarten der patientenbezogenen Gesundheitsversorgung||http://ihe-d.de/CodeSystems/EinrichtungsartenPatientenbezogen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.2||[[Ihevs:DocumentEntry.healthcareFacilityTypeCode|healthcareFacilityTypeCode]] <br />
|-<br />
|Einrichtungsarten ausserhalb der patientenbezogenen Gesundheitsversorgung||http://ihe-d.de/CodeSystems/EinrichtungsartenNichtPatientenbezogen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.3||[[Ihevs:DocumentEntry.healthcareFacilityTypeCode|healthcareFacilityTypeCode]] <br />
|-<br />
|Ärztliche Fachrichtungen||http://ihe-d.de/CodeSystems/AerztlicheFachrichtungen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.4||[[Ihevs:DocumentEntry.PracticeSettingCode|practiceSettingCode]]<br />
|-<br />
|Nicht-ärztliche Fachrichtungen||http://ihe-d.de/CodeSystems/NichtaerztlicheFachrichtungen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.5||[[Ihevs:DocumentEntry.PracticeSettingCode|practiceSettingCode]]<br />
|-<br />
|Dokumententypen||http://ihe-d.de/CodeSystems/IHEXDStypeCode||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.9||[[Ihevs:DocumentEntry.typeCode|typeCode]]<br />
|-<br />
|Grund der Übermittlung||http://ihe-d.de/CodeSystems/GrundDerUebermittlung||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.12||[[Ihevs:SubmissionSet.contentTypeCode|SubmissionSet.contentTypeCode]]<br />
|-<br />
|Ordnertypen||http://ihe-d.de/CodeSystems/Ordnertypen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.7||[[Ihevs:Folder.codeList|Folder.codeList]]<br />
|}<br />
<br />
{{FAQBox|<br />
'''Wie geht man mit Anforderungen nach Kodes um, die in den Value Sets nicht vorkommen?'''<br />
<br />
Das hängt primär von der Erweiterbarkeit und der Bindungsstärke ab!<br />
<br />
Value Set Vorgaben mit der Bindungsstärke "required" müssen verwendet werden. Bei "suggested" kann eine Alternative definiert werden, die dann genutzt werden kann. Allerdings ist hierbei zu beachten, dass man von einer Empfehlung abweicht und damit in zukünftigen Anbindungen Probleme bekommen kann.<br />
<br />
Die Erweiterbarkeit zeigt an, ob das Value Set durch eigene Festlegungen ergänzt werden kann ("open") oder nicht ("closed"). Wenn Ergänzungen zugelassen sind, so ist ein eigenes Kodesystem zu definieren, das in das Value Set mit eingebunden wird. Auf diese Weise werden die bekannten Kodes aus dem bereits vorhandenen Kodesystem eingesetzt und nur für fehlende, aber notwendige Konzepte eigene Kodes definiert.<br />
<br />
Eine elegantere Methode ist die Kontaktaufnahme mit dem Interoperabilitätsforum, um neue Kodes für eine Aufnahme in das offizielle Value Set vorzuschlagen. Dort werden die Vorschläge diskutiert und über einen Änderungs-/Erweiterungsvorschlag in einem Abstimmungsverfahren (Ballot) abgestimmt.<br />
}}<br />
<br />
{{BestPracticeBox|<br />
Wie soll verfahren werden, wenn das hier beschriebene Vorgehen nicht ganz klar ist?<br />
<br />
Das einfachste ist eine eMail an tcs@hl7.de, in der die Frage übermittelt wird. Das Interoperabilitätsforum wird versuchen, darauf schnellstmöglich eine Antwort allgemein verfügbar bereitzustellen.<br />
}}<br />
<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=IHE_DE_ValueSets_Action_Items&diff=80494IHE DE ValueSets Action Items2023-09-28T19:59:22Z<p>Tidris: </p>
<hr />
<div>'''Tabelle Änderungsanfragen'''<br />
<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! align="left" | Anfrage ID<br />
! align="left" | Anfrage eingegangen am<br />
! align="left" | Anfrage<br />
! align="center" | betrifft Codesystem<br />
! align="center" | Autor der Anfrage<br />
! align="center" | Diskussion<br />
! align="center" | Entscheidung<br />
! align="center" | Action Item<br />
! align="center" | Bearbeitungsstand<br />
! align="center" | zuletzt bearbeitet am<br />
<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 4<br />
| Anfrage eingegangen am|<br />
| Anfrage| Arbeitsgruppe „Weiterentwicklung Klinische Dokumentenklassenliste (KDL)“.<br />
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.<br />
Das aktuelle Mapping liegt der Geschäftsstelle vor und ist bisher mit Angela Merzweiler gemeinsam abgestimmt wurden.<br />
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.<br />
Beispiel:<br />
Ich möchte daher anregen bzw. beantragen, dass die KDL im ersten Schritt offiziell als CodeSystem in das Value Set „EventCodeList“ aufgenommen wird.<br />
Damit haben Hersteller von IHE-konformen Archiven, o. ä. die Möglichkeit, wenigstens die Klassifizierung des Dokuments mittels KDL offiziell abzubilden.<br />
· Code System Name: Klinische Dokumentenklassen Liste (KDL)<br />
· Code System ID: 1.2.276.0.76.3.1.191.0.1.1, versionsabhängig<br />
· Kommentar: Klassifizierung von Dokumenten und Daten als Beispiele für die Value Sets classCode und typeCode<br />
Mittelfristig soll die KDL zu einem terminologischen System mit ontologischem Ansatz ausgebaut werden.<br />
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.<br />
Ich freue mich, wenn wir es gemeinsam schaffen, dazu einen persönlichen Termin für ein Arbeitstreffen zu finden.<br />
| betrifft Codesystem | eventCode<br />
| Autor der Anfrage | AMü<br />
| 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<br />
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)<br />
übergeordnetes Valueset KDL in ArtDecor als Codesystem eingetragen, da der Eintrag als Valueset technisch nicht möglich war.<br />
12.11.2021 erneute Diskussion, ob Eintrag als Codesystem sinnvoll war<br />
| Entscheidung | grundsätzlich zugestimmt, neues Valueset<br />
| Action Item | alle=> Mapping prüfen<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 12.11.2021<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 7<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Deutscher Implementation Guide für MHD Profile mit Verweis auf unsere Valuesets<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | SH über Tarik<br />
| 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 <br />
| 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 <br />
| Action Item | Simone um Referenz der Codes in Deutschen Basisprofilguideline bitten <br />
| Bearbeitungsstand | als Issues in Gitlab eingetragen, im Simplifier sichtbar https://simplifier.net/basisprofil-de-r4/~resources?category=ValueSet&sortBy=RankScore_desc ==> (Angela)<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 19<br />
| Anfrage eingegangen am| 10.07.2020<br />
| 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<br />
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:<br />
Bestehenden Code ALLG - „Allgemeinmedizin“ neu bezeichnen als „Facharzt für Allgemeinmedizin<br />
(Hausarzt)“<br />
2. Neuen Code einführen für „Praktischer Arzt/Arzt (Hausarzt)“. Vorschlag: PRAK<br />
3. Neuen Code einführen für „Hausärztlich tätiger Internist (Hausarzt)“. Vorschlag: HINT<br />
4. Bestehenden Codes ORTH neu bezeichnen als „Orthopädie und Unfallchirurgie“.<br />
5. Neuen Code einführen für „Rheumatologie (Orthopädie)“. Vorschlag: ORRH.<br />
6. Neuen Code einführen für „Infektiologie“. Vorschlag: INFK<br />
7. Neuen Code einführen für „Kinder-Pneumologie“. Vorschlag: KIPN<br />
8. Neuen Code einführen für „Nervenheilkunde/Neurologie und Psychiatrie“. Vorschlag: NERV<br />
9. Neuen Code einführen für „Psychotherapeutisch tätiger Arzt“. Vorschlag: PTAR<br />
10. Neuen Code einführen für „Psychologischer Psychotherapeut“. Vorschlag: PPTH<br />
11.Neuen Code einführen für „Kinder- und Jugendlichen-Psychotherapeut“. Vorschlag: KJPP<br />
| betrifft Codesystem | Practice Setting Code<br />
| Autor der Anfrage | SR (KBV)<br />
| 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.<br />
| 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).<br />
| Action Item | Mapping prüfen und in Implementation Guide eintragen.<br />
| 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.<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 29<br />
| Anfrage eingegangen am| 22.01.2021<br />
| Anfrage| Problem mit ArtDecor bei FHIR<br />
| betrifft Codesystem | alle<br />
| Autor der Anfrage | Axel<br />
| Diskussion| <br />
| Entscheidung | <br />
| Action Item | Axel meldet Issues an Kai<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 22.01.2021<br />
<br />
<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 31<br />
| Anfrage eingegangen am| 18.02.2021<br />
| 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.<br />
| betrifft Codesystem | ClassCode<br />
| Autor der Anfrage | CG<br />
| Diskussion| <br />
| Entscheidung | <br />
| Action Item | <br />
| Bearbeitungsstand | offen<br />
| zuletzt bearbeitet am| <br />
<br />
|- valign="top" <br />
| Anfrage ID| 33<br />
| Anfrage eingegangen am| 22.12.2021<br />
| 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.<br />
| betrifft Codesystem | AuthorSpecialty<br />
| Autor der Anfrage | BPtK<br />
| Diskussion| <br />
Potentieller Ansatz:<br />
"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)<br />
* 74<br />
** 189<br />
*** 76<br />
*** 82<br />
*** 183<br />
**** 184<br />
**** 185<br />
** 190<br />
*** 75<br />
*** 77<br />
*** 78<br />
*** 79<br />
*** 80<br />
*** 81<br />
*** 83<br />
*** 84<br />
*** 85<br />
<br />
Betroffenen Systemen und Use Cases<br />
* Suche KIM-Teilnehmer<br />
** Kammer/HBA-Herausgeber<br />
*** z.B. Landesärztekammern und BPtk, prüfen ob der Gruppen-Code 74 verwendet werden, wahrscheinlich werden eher die konkreten Codes verwendet<br />
** Verzeichnisdienst<br />
*** VZD macht keine Umsetzung von Gruppe zu konkreten Codes, d.h. kein Änderungsbedarf<br />
** AIS / KIS / weitere Primärsysteme<br />
*** 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)<br />
* ePA-Dokumentenmetadaten: authorSpeciality<br />
** ePA-Aktensystem<br />
*** 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.<br />
** ePA-FdV<br />
*** 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.<br />
** Primärsystem<br />
*** 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.<br />
<br />
* XDS Affinity Domains (nicht-ePA)<br />
** Document Source<br />
*** wie bei ePA<br />
** Document Registry<br />
*** wie bei ePA, auch wenn Updates einfacher zu realisieren sind<br />
** Document Consumer<br />
*** Suche nach AuthorSpecialty möglich, Mapping Thematik wie bei ePA<br />
<br />
* Auswirkungen auf ISIK<br />
Umsetzung nach Wunsch BPtK<br />
<br />
BPtK müsste eigenes Codessystem auf jeden Fall selbst pflegen<br />
Impact auf andere Systeme müssen noch genau analysiert werden<br />
<br />
<br />
| Entscheidung | Wenn BPtK eigenes Codesystem erstellt pflegen wir es ein<br />
| Action Item | Einpflegung Codesystem in ArtDecor notwendig<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 23.12.2022<br />
<br />
|- valign="top" <br />
<br />
<br />
| Anfrage ID| 37<br />
| Anfrage eingegangen am| 04.03.2022<br />
| Anfrage| Displaynames Gender konform gestalten<br />
| betrifft Codesystem | v.a. author role, authorspecialty<br />
| Autor der Anfrage | Gematik<br />
| 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; <br />
| 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<br />
| Action Item | Änderung wird befürwortet, wie und wann wird noch festgelegt<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 29.04.2022<br />
|- valign="top" <br />
<br />
| Anfrage ID| 38<br />
| Anfrage eingegangen am| 25.3.2022<br />
| Anfrage| KDL Mapping kontrollieren<br />
| betrifft Codesystem | class code, type code, <br />
| Autor der Anfrage | DVMD<br />
| Diskussion| <br />
| Entscheidung | Das Mapping wird bis in vier Wochen von Raik, Tarik, Arnold und eventuell Sven gereviewed. Angela teilt das Mappingdokument auf ihrem onedrive.<br />
| Action Item | Review bis in vier Wochen<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 29.04.2022<br />
|- valign="top" <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 43<br />
| Anfrage eingegangen am| 10.06.2022<br />
| 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.<br />
| betrifft Codesystem | classCode<br />
| Autor der Anfrage | Raik<br />
| Diskussion| <br />
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. <br />
<br />
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.<br />
<br />
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. <br />
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).<br />
| Entscheidung | <br />
| Action Item | <br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 19.08.2022<br />
<br />
|- valign="top" <br />
| Anfrage ID| 44<br />
| Anfrage eingegangen am| 22.07.2022<br />
| Anfrage| Versionen in FormatCode Display names aufnehmen, da einige Hersteller die FormatCodes an Hand von Displaynames suchen<br />
| betrifft Codesystem | formatCode<br />
| Autor der Anfrage | Raik<br />
| Diskussion| <br />
| Entscheidung | Display Names werden geändert<br />
| Action Item | <br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 22.07.2022<br />
<br />
|- valign="top" <br />
| Anfrage ID| 49<br />
| Anfrage eingegangen am| 12.09.2023<br />
| Anfrage| Canonical URLs für selbst-definierte Code Systems werden in ART-DECOR immer als "urn:oid:..." dargestellt, FHIR bevorzugt aber URLs. Dies führt zu unterschiedlichen Ausprägungen.<br />
| betrifft Codesystem | alle von der AG selbst definierten Code Systeme<br />
| Autor der Anfrage | Tarik<br />
| Diskussion| Es wurde schonmal versucht, aber scheiterte bisher immer an technischen Hürden<br />
| Entscheidung | kurzfristig: Tabelle in Fliesstext im Wiki erstellen, die normative URLs vorgibt. mittelfristig: Möglichkeit eigener simplifier Veröffentlichung prüfen, ART-DECOR Synchronisationsmöglichkeiten evaluieren<br />
| Action Item | <br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 15.09.2023<br />
<br />
|- valign="top" <br />
| Anfrage ID| 50<br />
| Anfrage eingegangen am| 29.08.2023<br />
| Anfrage| Code H5 „vom Patienten hochgeladen“ in Code System „Dokumenten-Warnhinweise“, als digitale Entsprechung von Code H1 (der explizit von vom Patienten mitgebrachten und vom KH-gescannten Dokumenten spricht)<br />
| betrifft Codesystem | Dokumenten-Warnhinweise<br />
| Autor der Anfrage | Tarik<br />
| Diskussion| <br />
| Entscheidung | <br />
| Action Item | <br />
| Bearbeitungsstand | offen<br />
| zuletzt bearbeitet am| <br />
<br />
|- valign="top" <br />
| Anfrage ID| 51<br />
| Anfrage eingegangen am| 05.09.2023<br />
| Anfrage| Offizielle Deutsche Übersetzung der Dokumentenattribute<br />
| betrifft Codesystem | <br />
| Autor der Anfrage | Frank<br />
| Diskussion| <br />
| Entscheidung | <br />
| Action Item | <br />
| Bearbeitungsstand | offen<br />
| zuletzt bearbeitet am| <br />
|}<br />
<br />
'''Tabelle abgeschlossene Änderungsanfragen'''<br />
<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! align="left" | Anfrage ID<br />
! align="left" | Anfrage eingegangen am<br />
! align="left" | Anfrage<br />
! align="center" | betrifft Codesystem<br />
! align="center" | Autor der Anfrage<br />
! align="center" | Diskussion<br />
! align="center" | Entscheidung<br />
! align="center" | Action Item<br />
! align="center" | Bearbeitungsstand<br />
! align="center" | zuletzt bearbeitet am<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 1<br />
| Anfrage eingegangen am|<br />
| 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:<br />
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<br />
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.<br />
Wir haben somit eine Mischung aus IHE-D-Codes und IHE-PCC/LAB-LOINC-Codes. Inhaltlich/semantisch überschneidet sich das recht munter. Fragen:<br />
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?<br />
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?<br />
Folgende Codes werden vermisst:<br />
im AOK-Projekt haben wir in Ergänzung zu den IHE-D-Codes die folgenden LOINC-Codes als typeCodes verwendet:<br />
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)<br />
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<br />
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<br />
Verschiedene Ausprägungen des Entlassbriefs, um hier anhand der typeCodes eine bessere Sortierung für den Patienten zu ermöglichen:<br />
11490-0: Ärztlicher Entlassbrief<br />
34105-7: Krankenhausentlassbrief (vorläufige/gekürzte Fassung für den Patienten bei der Entlassung)<br />
18842-5: Finales Krankenhausentlassbrief<br />
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.<br />
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.<br />
58410-2: Vollständiges Blutbild<br />
55429-5: Kleines Blutbild<br />
| betrifft Codesystem | class codes, type codes<br />
| Autor der Anfrage | JC <br />
| 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<br />
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.<br />
<br />
| 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.<br />
| 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<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am|21.2.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 2<br />
| Anfrage eingegangen am|<br />
| Anfrage| es scheint in Deutschland Bestrebungen zu geben, Unfallchirurgie mit der Orthopädie zusammenzulegen.<br />
Ab August 2019 wird es im UKD nur noch die „Klinik für Orthopädie und Unfallchirurgie“ geben.<br />
Ist die Einführung einer weiteren Fachabteilung im DocumentEntry.practiseSettingCode geplant?<br />
In DocumentEntry.authorSpecialty findet sie sich:<br />
Code 512 Anzeigename FA Orthopädie und Unfallchirurgie<br />
| betrifft Codesystem | practiceSettingCode <br />
| Autor der Anfrage | SB<br />
| Diskussion| evtl. practiceSettingCode Chirurgie verwenden, deckt beides ab<br />
| Entscheidung |<br />
| Action Item |<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 29.11.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 3<br />
| Anfrage eingegangen am|<br />
| 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.<br />
Dazu möchten wir das Value Set für XDS-Metadatenattribut formatCode um den folgenden Wert erweitern: urn:gematik:ig:DatensatzPersoenlicheErklaerungen:r3.1<br />
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.<br />
| betrifft Codesystem | formatCode<br />
| Autor der Anfrage | RK<br />
| Diskussion| keine Einwände<br />
| Entscheidung | wir fügen Code hinzu<br />
| Action Item | in ArtDecor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am|13.12.2019<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 5<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Freischaltung der FHIR Schnittstelle in ArtDecor<br />
| betrifft Codesystem | alle<br />
| Autor der Anfrage | SH über Tarik Idris<br />
| Diskussion| <br />
| Entscheidung | wird gemacht<br />
| Action Item | Tarik: FHIR Schnittstelle in ArtDecor freischalten<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 15.11.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 6<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Ansatz Canonical URLs diskutieren<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | Tarik Idris<br />
| Diskussion| Ziel: Gute Einfügung in FHIR Umgebung<br />
| Entscheidung | Für V3 alle URNs durch URLs ersetzen <br />
| 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 <br />
| Bearbeitungsstand | für ValueSets erledigt (Angela)<br />
| zuletzt bearbeitet am| 14.11.2021<br />
<br />
|- valign="top" <br />
| Anfrage ID| 8<br />
| Anfrage eingegangen am| 15.11.2019<br />
| Anfrage| Vorgehensweise für V3 auf eigener WikiSeite beschreiben<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | SL<br />
| Diskussion| befürwortet<br />
| Entscheidung | befürwortet<br />
| Action Item | Anlegen neue Seite im HL7 Wiki ==> Angela, Ziele ==> Angela, allgemeine Weiterentwicklung als Ziel hinzufügen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 13.12.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 9<br />
| Anfrage eingegangen am| 13.12.2019<br />
| Anfrage| Bericht Treffen BVITG, Interopforum, Gematik, Vorabstimmung EPA Version 1.2.2022<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | TI<br />
| 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) <br />
| Entscheidung | über konstruktive Zusammenarbeit wird sich gefreut<br />
| Action Item | keine<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 13.12.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 10<br />
| Anfrage eingegangen am| 12.01.2020<br />
| 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.<br />
https://loinc.org/file-access/download-id/8994/<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | ST<br />
| Diskussion| <br />
| Entscheidung | Gemeinsame Strategietelko zur Zusammenführung LOINC, SNOMED CT, XDT, QMS, KDL deutsche XDS Value Sets am 28.5.2020 10-12 Uhr geplant<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 24.04.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 11<br />
| Anfrage eingegangen am| 07.02.2020<br />
| Anfrage| Zusammenarbeit KBV<br />
| betrifft Codesystem | alle, v.a. format Code<br />
| Autor der Anfrage | RK<br />
| Diskussion| Den MIOs müssen XDS Metadaten zugeordnet werden, v.a. formatCodes<br />
| Entscheidung | Arbeitsgruppe bietet proaktiv Hilfe bzgl. der Metadaten bei KBV an<br />
| Action Item | Mail an Vorstand ==> Mail an KBV (H. Tenkow)<br />
| Bearbeitungsstand | Mail an Vorstand gesendet<br />
| zuletzt bearbeitet am| 07.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 12<br />
| Anfrage eingegangen am| 21.02.2020<br />
| 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<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | RK<br />
| Diskussion| keine Einwände<br />
| Entscheidung | werden aufgenommen<br />
| Action Item | Aufnahme in ArtDecor ==> Angela<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 24.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 13<br />
| Anfrage eingegangen am| 06.03.2020<br />
| Anfrage| Übersetzung der Metadatenbezeichnungen ins Englische<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | SL<br />
| Diskussion| ValueSets sind nur für Deutschland, jeder Dokumentierende sollte über ausreichende Deutschkenntisse verfügen<br />
| Entscheidung | abgelehnt<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 06.03.2020<br />
|- valign="top" <br />
<br />
|- valign="top"<br />
| Anfrage ID| 14<br />
| Anfrage eingegangen am| 24.04.2020<br />
| Anfrage| Neuer FormatCode für eRezept (Daten elektronischer Verordnung) der Gematik<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | RK<br />
| 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<br />
| Entscheidung | urn:gematik:ig:VerordnungsdatensatzMedikation:r4.0<br />
| Action Item | in Art Decor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
<br />
<br />
|- valign="top" <br />
<br />
<br />
| Anfrage ID| 15<br />
| Anfrage eingegangen am| 14.05.2020<br />
| Anfrage| Kommentierung EPA XDS Metadaten<br />
| betrifft Codesystem | fast alle<br />
| Autor der Anfrage | TI<br />
| Diskussion| <br />
| 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<br />
| Action Item | Tarik==> Kommentar an gematik<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.05.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 16<br />
| Anfrage eingegangen am| 14.05.2020<br />
| 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. <br />
| betrifft Codesystem | TypeCode<br />
| Autor der Anfrage | VK<br />
| Diskussion| <br />
| Entscheidung | wird als Beispiel in pathologische Befunde aufgenommen<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
|- valign="top" <br />
<br />
| Anfrage ID| 17<br />
| Anfrage eingegangen am| 14.05.2020<br />
| Anfrage| Am UKHD gibt es ein Zentrum für Seltene Erkrankungen. Dort werden Patienten jeglichen Alters behandelt. <br />
| betrifft Codesystem | PracticeSettingCode<br />
| Autor der Anfrage | VK<br />
| Diskussion| <br />
| 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<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 18<br />
| Anfrage eingegangen am| 26.06.2020<br />
| Anfrage| Code für Erfassung Fall- /Bewegungsdaten<br />
| betrifft Codesystem | Class Code, Type Code<br />
| Autor der Anfrage | AM<br />
| 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<br />
| Entscheidung | keine zusätzlichen Codes<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 20<br />
| Anfrage eingegangen am| 10.07.2020<br />
| 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:<br />
<br />
Unterkategorien von 1a - Code<br />
<br />
Hausarzt/ Hausärztin - practitioner<br />
<br />
Krankenhaus - hospital<br />
<br />
Labor und Humangenetik - laboratory<br />
<br />
Physiotherapeuten - physiotherapy<br />
<br />
Psychotherapeuten - psychotherapy<br />
<br />
Dermatologie - dermatology<br />
<br />
Urologie/Gynäkologie - gynaecology_urology<br />
<br />
Zahnheilkunde und Mund-Kiefer-Gesichtschirurgie - dentistry_oms<br />
<br />
Weitere Fachärzte/ Fachärztinnen - other_medical<br />
<br />
Weitere nicht-ärztliche Berufe - other_non_medical<br />
<br />
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.<br />
<br />
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.<br />
<br />
Für diesen Code soll ein Code-System "Sonstige Berechtigungen ePA" genutzt werden.<br />
| betrifft Codesystem | Anfrage neues Codesystem / ValueSet für Folder<br />
| Autor der Anfrage | JG (Gematik)<br />
| 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<br />
| Entscheidung |Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte<br />
| Action Item | Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte<br />
| 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 <br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 21<br />
| Anfrage eingegangen am| 31.07.2020<br />
| 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:<br />
<br />
"urn:gematik:ig:KinderuntersuchungsheftUntersuchungen:r4.0"<br />
"urn:gematik:ig:KinderuntersuchungsheftTeilnahmekarte:r4.0"<br />
"urn:gematik:ig:KinderuntersuchungsheftNotizen:r4.0"<br />
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.<br />
<br />
<br />
<br />
Als Anzeigename schlage ich vor:<br />
<br />
· Untersuchungen Kinderuntersuchungsheft<br />
<br />
· Teilnahmekarte Kinderuntersuchungsheft<br />
<br />
· Notizen Kinderuntersuchungsheft<br />
| betrifft Codesystem | FormatCodes<br />
| Autor der Anfrage | Gematik<br />
| Diskussion| <br />
| Entscheidung | wird aufgenommen<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 22<br />
| Anfrage eingegangen am| 16.09.2020<br />
| Anfrage| Patientenverfügung als Beispiel für administratives Dokument aufnehmen<br />
| betrifft Codesystem | classCode<br />
| Autor der Anfrage | VB (Uniklinik HD)<br />
| Diskussion| entspricht Mapping in KDL<br />
| Entscheidung | wird als Beispiel hinzugefügt<br />
| Action Item | in ArtDecor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 23<br />
| Anfrage eingegangen am| 18.09.2020<br />
| Anfrage| TypeCode für mikroskopische Bilder<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | VB (Uniklinik HD)<br />
| Diskussion| wenn Ergebnis Mikrobiologie oder Pathologie, dann diesen Code verwenden, ansonsten BILD<br />
| Entscheidung | wenn Ergebnis Mikrobiologie (MKRO) oder Pathologie (PATH) dann diesen Code verwenden, ansonsten BILD<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 24<br />
| Anfrage eingegangen am| 5.11.2020<br />
| 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.<br />
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.<br />
HL7 bildet die Berufsgruppen PP (2 L 82) und KJP (2-L 76) falsch ab, nämlich als Spezialisierung, nicht als Grundberufe.<br />
Die Fachgebiete des neuen Berufs ‚Psychotherapeut*in‘ sind im HL7 nicht abgebildet.<br />
| betrifft Codesystem | authorspecialty<br />
| Autor der Anfrage | BPtK<br />
| Diskussion| <br />
| Entscheidung |Neue Berufsgruppen werden in Authorspecialty aufgenommen.<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 25<br />
| Anfrage eingegangen am| 5.11.2020<br />
| Anfrage| Übernahme der Facharzt- und Schwerpunktscodes aus dem Codesystem der BAEK, da relevante Facharzt - und Schwerpunktscodes fehlen.<br />
| betrifft Codesystem | authorspecialty<br />
| Autor der Anfrage | BAEK<br />
| 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.<br />
| 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<br />
| Action Item | Konzept zur Pflege, Mapping BAEK Codes auf practice Setting Codes wird auch bei KBV veröffentlicht (als FHIR concept map)<br />
| Bearbeitungsstand |erledigt<br />
| zuletzt bearbeitet am| 01.02.2021<br />
<br />
|- valign="top" <br />
| Anfrage ID| 26<br />
| Anfrage eingegangen am| 13.11.2020<br />
| Anfrage| Prozeduren zu Fertilitätsbehandlung in Gebu aufnehmen?<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |nein<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 01.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 27<br />
| Anfrage eingegangen am| 13.11.2020<br />
| Anfrage| Typecode für Erfassung der Dauer der Gebärdendolmetscherunterstützung<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |Abrechnungsdokumente<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 01.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 28<br />
| Anfrage eingegangen am| 10.12.2020<br />
| Anfrage| Classcode für Diagnosenübersichtsblatt<br />
| betrifft Codesystem | classCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |hängt vom UseCase ab<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 01.02.2020<br />
|- valign="top" <br />
| Anfrage ID| 30<br />
| Anfrage eingegangen am| 04.02.2021<br />
| Anfrage| Nutzung von XDS Value Sets für den digitalen Austausch medizinischer Unterlagen mit den Medizinischen Diensten.<br />
| betrifft Codesystem | alle<br />
| Autor der Anfrage | AMue<br />
| Diskussion| <br />
| Entscheidung | <br />
| Action Item | Annett lädt Herrn Dr. Eckardt vom MD Westfalen-Lippe zur nächsten Telko ein<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| <br />
<br />
|- valign="top" <br />
| Anfrage ID| 32<br />
| Anfrage eingegangen am| 09.2021<br />
| Anfrage| Aufnahme von Pflegefachmann/-fachfrau, da neuer Ausbildungsberuf<br />
| betrifft Codesystem | Authorspecialty<br />
| Autor der Anfrage | FP<br />
| 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.<br />
| Entscheidung | Konzepte werden wie vorgeschlagen ergänzt, bzw. - bezeichnungen geändert.<br />
| Action Item | Eröffnung version 4 draft des Value Sets ==> Anpassungen in ArtDecor erfolgt<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 15.10.2021<br />
<br />
|- valign="top" <br />
| Anfrage ID| 34<br />
| Anfrage eingegangen am| 22.12.2021<br />
| 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:<br />
• IHE-XDS classCode = AUS<br />
• IHE-XDS typeCode = BESC<br />
Dies widerspricht den Kodiervorgaben von IHE Deutschland Dort ist festgelegt, dass der Notfalldatensatz mit typeCode PATD dokumentiert werden soll.<br />
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.<br />
Beispiele: Ausweise, Vorsorgevollmacht, Patientenverfügung, Wertgegenständeverwaltung, , Patiententagebuch<br />
<br />
| betrifft Codesystem | TypeCode<br />
| Autor der Anfrage | AMue<br />
| Diskussion| <br />
| Entscheidung | Missverständnis konnte geklärt werden<br />
| Action Item | keine<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| <br />
<br />
|- valign="top" <br />
| Anfrage ID| 35<br />
| Anfrage eingegangen am| 14.02.2022<br />
| Anfrage| Die gematik möchte wieder Aktualisierungen für MIO-Versionen zu den Format Codes einbringen. <br />
<br />
neu (die DisplayNames sind dieselben der Vorgänger)<br />
<br />
· urn:gematik:ig:KinderuntersuchungsheftUntersuchungen:v1.0.1<br />
<br />
· urn:gematik:ig:KinderuntersuchungsheftTeilnahmekarte:v1.0.1<br />
<br />
· urn:gematik:ig:KinderuntersuchungsheftNotizen:v1.0.1<br />
<br />
· urn:gematik:ig:Mutterpass:v1.1.0<br />
<br />
· urn:gematik:ig:VerordnungsdatensatzMedikation:v1.0.2<br />
<br />
<br />
<br />
deprecated/obsolet<br />
<br />
· urn:gematik:ig:VerordnungsdatensatzMedikation:r4.0<br />
<br />
· urn:gematik:ig:Kinderuntersuchungsheft:v1.0.0<br />
<br />
| betrifft Codesystem | FormatCode<br />
| Autor der Anfrage | RK<br />
| Diskussion| Versionsänderungen auf 3. Ebene (Patch) sollten in Zukunft keine Änderungen am Formatcode verursachen<br />
| 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.<br />
| Action Item | Art-Decor anpassen, RK Kommunikation des Wunschs der AG an die Gematik<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.03.2022<br />
<br />
|- valign="top" <br />
| Anfrage ID| 36<br />
| Anfrage eingegangen am| 18.02.2022<br />
| Anfrage| Pflege des Mappings der KDL auf ClassCode TypeCode mit Arbeitsgruppe abstimmen<br />
<br />
| betrifft Codesystem | eventCodeList, classCode, typeCode<br />
| Autor der Anfrage | AM<br />
| Diskussion| <br />
| Entscheidung | Review des Mappings können wir machen, aber Verantwortung liegt bei DVMD, sobald neues Mapping vorliegt, erfolgt Review als neue Anfrage<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.02.2022<br />
<br />
|- valign="top" <br />
| Anfrage ID| 39<br />
| Anfrage eingegangen am| 31.03.2022<br />
| Anfrage| neue FormatCodes, neue eventCodes<br />
DiGA<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:diga:v1.0"<br />
<br />
documentEntry.formatCode.displayName: "DiGA (gematik)"<br />
<br />
<br />
<br />
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: <br />
<br />
<br />
<br />
DMP Asthma bronchiale<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-Asthma:v4.45"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Asthma (gematik)"<br />
<br />
<br />
<br />
DMP Brustkrebs<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-BRK:v4.23"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Brustkrebs (gematik)"<br />
<br />
<br />
<br />
DMP Chronische Herzinsuffizienz<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-HI:v1.1" <br />
<br />
documentEntry.formatCode.displayName: "eDMP Herzinsuffizienz (gematik)"<br />
<br />
<br />
<br />
DMP Chronischer Rückenschmerz<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-Rueckenschmerz:v1.0"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Rückenschmerz (gematik)"<br />
<br />
<br />
<br />
DMP COPD<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-COPD:v4.4" <br />
<br />
documentEntry.formatCode.displayName: "eDMP Chronic Obstrusive Pulmonary Disease (gematik)"<br />
<br />
<br />
<br />
DMP Depressionen<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-Depression:v1.1" <br />
<br />
documentEntry.formatCode.displayName: "eDMP Depression (gematik)"<br />
<br />
<br />
<br />
DMP Diabetes mellitus Typ 1<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-DM1:v5.5"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Diabetes mellitus Typ 1 (gematik)"<br />
<br />
<br />
<br />
DMP Diabetes mellitus Typ 2<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-DM2:v6.5"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Diabetes mellitus Typ 2 (gematik)"<br />
<br />
<br />
<br />
DMP Koronare Herzkrankheit<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-KHK:v4"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Koronare Herzkrankheit (gematik)"<br />
<br />
<br />
<br />
DMP Osteoporose<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-OST:v1.0"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Osteoporose (gematik)<br />
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.<br />
<br />
<br />
<br />
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.<br />
| betrifft Codesystem |formatCodes<br />
| Autor der Anfrage | Gematik<br />
| Diskussion| Die Display names des KBV CodeSystems sind ziemlich uneindeutig. Beispiel: HI könnte nicht nur Herzinsuffizienz sondern auch Hinterwandinfarkt oder Harnwegsinfekt bedeuten.<br />
| 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.<br />
| Action Item | Raik gibt entsprechende Rückmeldung an KBV, Angela fügt eventCOdes und formatCodes den entsprechende ValueSets hinzu<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 27.05.2022<br />
|- valign="top" <br />
<br />
| Anfrage ID| 40<br />
| Anfrage eingegangen am| 28.04.2022<br />
| Anfrage| passender eventCode bei stationärer Wiederaufnahme nach Unterbrechung<br />
| betrifft Codesystem | eventCode<br />
| Autor der Anfrage | AM (UKHD)<br />
| Diskussion| <br />
| Entscheidung | E216 Wiederaufnahme vollstationär nach kurzzeitiger Unterbrechung wird hinzugefügt<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 29.04.2022<br />
<br />
<br />
|- valign="top" <br />
<br />
| Anfrage ID| 41<br />
| Anfrage eingegangen am| 28.04.2022<br />
| 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"<br />
displayName: " Pflegeüberleitungsbogen (gematik)"<br />
| betrifft Codesystem | formatCode<br />
| Autor der Anfrage | gematik<br />
| Diskussion| <br />
| Entscheidung | Major Revisions werden als FormatCodes aufgenommen<br />
| Action Item | Feedback an Gematik ==> positiv<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 27.05.2022<br />
|- valign="top" <br />
<br />
<br />
| Anfrage ID| 42<br />
| Anfrage eingegangen am| 27.05.2022<br />
| Anfrage|neue Dokumentenformate für gematik "urn:gematik:ig:DMP-Rheuma:v1<br />
eDMP" displayName: "Rheumatoide Arthritis (gematik)"<br />
| betrifft Codesystem | formatCode<br />
| Autor der Anfrage | gematik<br />
| Diskussion| <br />
| Entscheidung |Major Revisions werden aufgenommen<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 27.05.2022<br />
|- valign="top" <br />
<br />
| Anfrage ID| 45<br />
| Anfrage eingegangen am| 16.09.2022<br />
| Anfrage| Fragen zu XDS Metadaten aus einem Klinikum<br />
| betrifft Codesystem | practicsettingCode<br />
| Autor der Anfrage | SL<br />
| Diskussion| Fachabteilungsschlüssel werden nicht durch IHE vergeben, sondern vom Klinikum zu Abrechnungszwecken für bettenführende Abteilungen; Die Fachabteilungsschlüssel sind keine XDS Metadaten. Das Mapping ist nur als Hilfestellung gedacht. Die Zuordnung des PracticeSetting erfolgt in der Regel für eine Abteilung. In der Abteilung können unterschiedliche Personengruppen beschäftigt sein. Für die Zuodnung des passenden Codes ist, die Aufgabe der Einrichtung entscheidend.<br />
| Entscheidung | --<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 16.09.2022<br />
<br />
|- valign="top" <br />
| Anfrage ID| 46<br />
| Anfrage eingegangen am| 25.11.2022<br />
| Anfrage| XDS Metadaten für Einlagerungsdokumente<br />
| betrifft Codesystem | typeCode, eventCodeList<br />
| Autor der Anfrage | AM<br />
| Diskussion| Neuer typeCode ist sinnvoll,eventCode wird nur vorgeschlagen, wenn man sinnvollen Wert findet. Bei SNOMED CT könnten Hilfsmittel fehlen.<br />
| Entscheidung | <br />
typeCode: EINL Einlagerungsdokumente Definition: Alle Arten von Dokumenten, die die Einlagerung von patientenbezogenen Objekten beschreiben. Dies sind vor allem Biomaterialien wie Spermien, Gewebeproben, Eier, Blutproben, Speichelproben, die in Biobanken eingelagert werden. Dies können aber auch Hilfsmittel wie Prothesen, Rollstühle sein. Eine genauere Unterscheidung des Typs kann über den eventCode erfolgen. Beispiele: Einlagerungsbestätigung, Einlagerungsschein, Einlagerungsurkunde.<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 09.12.2022<br />
<br />
|- valign="top" <br />
<br />
| Anfrage ID| 47<br />
| Anfrage eingegangen am| 19.01.2023<br />
| Anfrage| neue FormatCodes: urn:gematik:ig:Arbeitsunfaehigkeitsbescheinigung:v1.1 mit DisplayName: Arbeitsunfähigkeitsbescheinigung (gematik) v1.1, Code: urn:gematik:ig:VerordnungsdatensatzMedikation:v1.1 mit<br />
DisplayName: Verordnungsdatensatz Medikation (gematik) v1.1<br />
alte FormatCodes auf deprecated setzen: <br />
urn:gematik:ig:VerordnungsdatensatzMedikation:r4.0<br />
urn:gematik:ig:Mutterpass:v1.0.0<br />
urn:gematik:ig:KinderuntersuchungsheftTeilnahmekarte:v1.0.0<br />
urn:gematik:ig:KinderuntersuchungsheftUntersuchungen:v1.0.0<br />
urn:gematik:ig:KinderuntersuchungsheftNotizen:v1.0.0<br />
<br />
| betrifft Codesystem | formatCodes<br />
| Autor der Anfrage | gematik<br />
| Diskussion| <br />
| Entscheidung | wird angenommen<br />
| Action Item | in ArtDecor übernommen<br />
| Bearbeitungsstand |erledigt<br />
| zuletzt bearbeitet am| 03.02.2023<br />
|- valign="top" <br />
<br />
| Anfrage ID| 48<br />
| Anfrage eingegangen am| 02.03.2023<br />
| Anfrage| Änderung bei FormatCodes: Ersetzung urn:gematik:ig:diga:v1.0 durch urn:gematik:ig:diga:v1.1<br />
<br />
| betrifft Codesystem | formatCodes<br />
| Autor der Anfrage | gematik<br />
| Diskussion| <br />
| Entscheidung | wird angenommen<br />
| Action Item | <br />
| Bearbeitungsstand |erledigt<br />
| zuletzt bearbeitet am| 26.05.2023<br />
|- valign="top" <br />
<br />
<br />
<br />
|}<br />
<br />
'''Tabelle Aktueller Stand'''<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! width="25%" align="left" | Codesystem<br />
! align="center" | Stand Konzepte<br />
! align="center" | ArtDecor<br />
! align="center" | WikiText<br />
! align="center" | Review durch<br />
<br />
|- valign="top" <br />
| Codesystem | Einleitung<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Sven, Frank<br />
<br />
|- valign="top" <br />
| Codesystem | Vokabular Management<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Sven, Frank<br />
<br />
|- valign="top" <br />
| Codesystem | Confidentiality Code<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Sven, Frank<br />
<br />
|- valign="top" <br />
| Codesystem | AuthorRole<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Angela, Sven<br />
<br />
|- valign="top" <br />
| Codesystem | AuthorSpeciality<br />
| Stand Konzepte | n/a<br />
| ArtDecor | offen<br />
| WikiText | offen<br />
| Review durch | ''Tarik?''<br />
<br />
|- valign="top" <br />
| Codesystem | EventCodeList<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Angela<br />
<br />
|- valign="top" <br />
| Codesystem | ContentTypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Axel<br />
<br />
|- valign="top" <br />
| Codesystem | ClassCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Arnold, Antje<br />
<br />
|- valign="top" <br />
| Codesystem | TypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Arnold, Antje<br />
<br />
|- valign="top" <br />
| Codesystem | FormatCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | Axel<br />
<br />
|- valign="top" <br />
| Codesystem | HealthcareFacilityTypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | ''Tarik?''<br />
<br />
|- valign="top" <br />
| Codesystem | PracticeSettingCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | Antje, Arnold<br />
<br />
|- valign="top" <br />
| Codesystem | Folder.codeList<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | Angela, Sven<br />
<br />
<br />
|- valign="top" <br />
| Valuesets/ generell| EPA Verwendung<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Erstellung durch | Raik, Christof<br />
<br />
|}<br />
<br />
'''Schritte zur Veröffentlichung v3'''<br />
# Zeitplan (draft) erstellen<br />
#* Anfang Februar Ankündigung<br />
#* Anfang März Kommentierungsstart<br />
#* Anfang April Ende Kommentierung, Anfang Kommentarauflösungs<br />
#* Anfang Juni Veröffentlichung<br />
# 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<br />
# Ankündigung formulieren <br />
# Kapitel zur Verwendung der ValueSets in der EPA schreiben<br />
# Review der Wiki-Texte und AuthorSpecialty Code anpassen<br />
# Change Liste erstellen<br />
# PDF erstellen<br />
# PDF in Wiki und auf IHE-D Seite hochladen/referenzieren<br />
# Kommentare sammeln<br />
# Kommentare auflösen<br />
# Abstimmung zur Veröffentlichung<br />
# Finale Version erstellen und in Wiki und IHE-D Seite hochladen<br />
<br />
Optional:<br />
* Erläuterung zum Zusammenspiel mit FHIR<br />
* Hinweis/kurze Erläuterung der nicht behandelten XDS Metadaten<br />
<br />
'''IG Struktur'''<br />
<br />
# [[ihevs:Einleitung]] (Vorgehen, Ziele, Umgang mit v1, normativ, Delta-Liste?, Änderungen/Pflege)<br />
# [[Ihevs:Vokabular-Management]]<br />
# [[ihevs:DocumentEntry.authorRole]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.authorSpecialty]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.classCode]]<br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.confidentialityCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.eventCodeList]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.formatCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.healthcareFacilityTypeCode]]<br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.languageCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.practiceSettingCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.typeCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:SubmissionSet.contentTypeCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:Folder.codeList]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor<br />
<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:Vokabular-Management&diff=80493Ihevs:Vokabular-Management2023-09-28T19:43:25Z<p>Tidris: </p>
<hr />
<div>{{DocumentPart}}<br />
=Vokabular-Management=<br />
<br />
Die Übermittlung von konkreten Daten kann auf zweierlei Art und Weise erfolgen: Die einfachste Variante ist Freitext, bei der beliebige Daten - als Zeichenkette (ggf. noch eingeschränkt auf einen bestimmten Datentyp) - übertragen werden. Dieses Verfahren bietet sich an, wenn die individuelle Ausprägung sehr unterschiedlich sein kann wie bspw. der Name des Patienten oder ein Kommentar. Für immer wiederkehrende und im Prinzip gleiche Information, wie bspw. der Familienstand, werden die zu übertragenden Daten abgekürzt und durch einen "Platzhalter" ersetzt. Bei letzterem muss die Bedeutung aber klar sein. Hierfür werden Kodesysteme definiert, die sowohl die Abkürzungen - Kodes - als auch deren Bedeutung auflisten. Die Zuordnung von einzelnen Feldern in einer Datenaustauschspezifikation zu konkreten Wertelisten erfolgt mehrstufig: Die Festlegung der erlaubten Werte für ein kodiertes Attribut erfolgt über die Angabe von sog. Konzept- oder Vokabeldomänen (''Concept / Vocabulary Domains''), Kodiersystemen (''Code Systems'') und Wertemengen (''Value Sets''). <br />
<br />
Eine '''Konzeptdomäne''' dient dazu, den Wertebereich eines Attributs einzugrenzen ohne dabei direkt schon feste Kodiersysteme oder Value Sets vorzugeben. Eine Konzeptdomäne wird durch einen Namen, eine textuelle Beschreibung sowie eine Reihe von Beispielkonzepten definiert. Zum Beispiel soll die Konzeptdomäne DocumentEntry.typeCode den Typ eines Dokuments aus Benutzersicht kodieren. <br />
<br />
Ein '''Value Set''' ist eine eindeutige identifizierbare Sammlung von Konzeptrepräsentationen und es ist einer oder mehreren Konzeptdomänen zugeordnet. Ein Value Set kann Codes aus einem oder mehreren Kodiersystemen enthalten. Ein '''Kodiersystem''' wird dabei durch eine Liste von Codes mit zugehörigen Anzeigenamen und Beschreibungen definiert. Innerhalb eines Kodiersystems muss ein Code eine eindeutig definierte Bedeutung haben. <br />
<br />
Value Sets können in unterschiedlicher Art und Weise definiert werden: ''extensional'' als Sammlungen von Codes (Konzepten) oder ''intensional'' über einen berechenbaren Ausdruck, aus dem sich eine Codeliste exakt ermitteln lässt. Die Value Sets für DocumentEntry.typeCode und DocumentEntry.classCode in diesem Leitfaden sind beispielsweise extensional als Listen definiert, während das Value Set für DocumentEntry.formatCode intensional über Konstruktionsvorschriften für URNs definiert wurde.<br />
<br />
Wenn ein Value Set neben den genannten oder beschriebenen Codes zusätzliche Werte erlaubt, wird es als offen (''open'') bezeichnet, andernfalls als geschlossen (''closed''). Das Value Set für DocumentEntry.languageCode ist beispielsweise offen, da neue Sprachcodes gebildet und wenn notwendig auch verwendet werden können. Die Value Sets für DocumentEntry.classCode und DocumentEntry.healthcareFacilityTypeCode sind hingegen geschlossen. Das heißt, dass eine Erweiterung nur über eine neue Version der Value Sets erfolgen sollte.<br />
<br />
Die Identifikation eines Value Sets erfolgt bei CDA und IHE XDS über eine OID, bei FHIR über eine URL. Die Version eines Value Sets wird über einen Zeitstempel charakterisiert. Die Bindung eines kodierten Elementes an ein Value Set (Binding) kann nun dynamisch (''dynamic'') oder statisch (''static'') erfolgen. Ein dynamisches Binding bezieht sich auf die jeweils aktuellste Version eines Value Sets, während bei einem statischen Binding eine feste Version angegeben wird. Bei einem statischen Binding müssen OID bzw. ein eindeutiger Bezeichner sowie ein Zeitstempel angegeben werden. Beim dynamischen Binding fehlt der Zeitstempel. <br />
<br />
Unabhängig davon gibt es für das Binding von ValueSets noch weitere Unterscheidungsmöglichkeiten. Beim ''Design-Time Binding'' wird das zu verwendende Value Set explizit angegeben. Beim ''Runtime Binding'' werden nur die Konzeptdomäne und die sogenannte Realm (z.B. „Deutschland“) festgelegt. Das effektive Value Set wird dann dynamisch über einen Terminologieserver an Hand von Konzeptdomäne und Realm ermittelt. <br />
<br />
Bindings können verpflichtend sein (''required''), empfohlen werden (''suggested'' oder ''preferred'') oder dienen nur als Beispiel (''example''). Einzelne Werte eines Value Sets können als verpflichtend (''required''), erlaubt (''permitted'') oder ausgeschlossen (''excluded'') gekennzeichnet werden. Die in diesem Leitfaden definierten Codes besitzen alle den Status permitted.<br />
<br />
Die folgende Tabelle gibt eine Übersicht über die Eigenschaften der bereits definierten Value Sets:<br />
<div class="landscape"><br />
{| class="hl7table"<br />
|-<br />
!XDS-Metadatum!!Beschreibung!!Definitionsart!!Erweiterbarkeit!!Bindungsstärke!!Bindungsart!!Versionsbindung<br />
|-<br />
|[[Ihevs:DocumentEntry.authorRole|authorRole]] ||Rolle des Autors||extensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.authorSpecialty|authorSpecialty]] ||Fachrichtung des Autors||extensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.classCode|classCode]] ||Dokumentenklasse||extensional||closed||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.confidentialityCode|confidentialityCode]] ||Dokumenten-Vertraulichkeitsstufe||extensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.eventCodeList|eventCodeList]] ||Tätigkeitskennzeichen/Zusätzliche Kennzeichnung||intensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.formatCode|formatCode]] ||Dokumentenformat||intensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.healthcareFacilityTypeCode|healthcareFacilityTypeCode]] ||Einrichtungsart||extensional||closed||suggested|| design-time||dynamic<br />
|-<br />
|[[LanguageCode|languageCode]] ||Dokumentensprache||intensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.PracticeSettingCode|practiceSettingCode]] ||Erstellende Fachrichtung||extensional||closed||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.typeCode|typeCode]] ||Dokumententyp||extensional||closed||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:SubmissionSet.contentTypeCode|SubmissionSet.contentTypeCode]] ||Inhaltskennzeichen des SubmissionSets||extensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:Folder.codeList|Folder.codeList]] ||Ordnerklassifizierung||extensional||open||suggested||design-time||dynamic<br />
|}<br />
</div><br />
<br />
== Identifikation von Kodesystemen in FHIR-basierter Kommunikation ==<br />
<br />
FHIR empfiehlt die Verwendung einer URL als primäre Identifikation eines Kodesystems. Es ist zwar grundsätzlich zulässig eine OID in ihrer URN-form, d.h. beginnend mit "urn:oid:", als Identifikation zu verwenden, aber es gilt als nicht-idiomatisch. Aus technischen Gründen können die von dieser Arbeitsgruppe erstellten Kodesysteme in ART-DECOR nicht konsistent mit einer URL versehen werden. Daher werden die in FHIR zu verwendenen Canonical URLs in der folgenden Tabelle für alle in diesem Leitfaden eingeführten Kodesysteme aufgeführt. Die OID-URNs, die in den in diesem Leitfaden inkludierten ART-DECOR Auszügen verwendet werden, sind als zusätzliche, sekundäre Identifikatoren zu verstehen.<br />
{| class="hl7table"<br />
|-<br />
!Kodesystem!!Canonical URL!!sekundärer Identifier||aus Value Set<br />
|-<br />
|Prozessrollen für Autoren||http://ihe-d.de/CodeSystems/AutorenProzessRollen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.13||[[Ihevs:DocumentEntry.authorRole|authorRole]]<br />
|-<br />
|Patientenbeziehungsrollen für Autoren||http://ihe-d.de/CodeSystems/AutorenPatientenbeziehungsRollen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.14||[[Ihevs:DocumentEntry.authorRole|authorRole]]<br />
|-<br />
|Qualifikationen nicht ärztlicher Autoren||http://ihe-d.de/CodeSystems/qualifikationen-nichtaerztlicher-autoren||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.11||[[Ihevs:DocumentEntry.authorSpecialty|authorSpecialty]]<br />
|-<br />
|Dokumentenklassen||http://ihe-d.de/CodeSystems/dokumentenklassen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.8||[[Ihevs:DocumentEntry.classCode|classCode]] <br />
|-<br />
|Betroffeneneinschätzung der Vertraulichkeitsstufe||http://ihe-d.de/CodeSystems/betroffenen-vertraulichkeitsstufe||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.10||[[Ihevs:DocumentEntry.confidentialityCode|confidentialityCode]]<br />
|-<br />
|Dokumenten-Warnhinweise||http://ihe-d.de/CodeSystems/dokumenten-warnhinweise||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.15||[[Ihevs:DocumentEntry.eventCodeList|eventCodeList]]<br />
|-<br />
|Fallkontext bei Dokumentenerstellung||http://ihe-d.de/CodeSystems/fallkontext-dokumentenerstellung||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.16||[[Ihevs:DocumentEntry.eventCodeList|eventCodeList]]<br />
|-<br />
|Deutsche Dokumentenformate||http://ihe-d.de/CodeSystems/dokumentenformate||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.6||[[Ihevs:DocumentEntry.formatCode|formatCode]] <br />
|-<br />
|Einrichtungsarten der patientenbezogenen Gesundheitsversorgung||http://ihe-d.de/CodeSystems/einrichtungsarten-patientenbezogen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.2||[[Ihevs:DocumentEntry.healthcareFacilityTypeCode|healthcareFacilityTypeCode]] <br />
|-<br />
|Einrichtungsarten ausserhalb der patientenbezogenen Gesundheitsversorgung||http://ihe-d.de/CodeSystems/einrichtungsarten-nicht-patientenbezogen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.3||[[Ihevs:DocumentEntry.healthcareFacilityTypeCode|healthcareFacilityTypeCode]] <br />
|-<br />
|Ärztliche Fachrichtungen||http://ihe-d.de/CodeSystems/aerztliche-fachrichtungen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.4||[[Ihevs:DocumentEntry.PracticeSettingCode|practiceSettingCode]]<br />
|-<br />
|Nicht-ärztliche Fachrichtungen||http://ihe-d.de/CodeSystems/nicht-aerztliche-fachrichtungen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.5||[[Ihevs:DocumentEntry.PracticeSettingCode|practiceSettingCode]]<br />
|-<br />
|Dokumententypen||http://ihe-d.de/CodeSystems/dokumententypen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.9||[[Ihevs:DocumentEntry.typeCode|typeCode]]<br />
|-<br />
|Grund der Übermittlung||http://ihe-d.de/CodeSystems/uebermittlungsgrund||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.12||[[Ihevs:SubmissionSet.contentTypeCode|SubmissionSet.contentTypeCode]]<br />
|-<br />
|Ordnertypen||http://ihe-d.de/CodeSystems/ordnertypen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.7||[[Ihevs:Folder.codeList|Folder.codeList]]<br />
|}<br />
<br />
{{FAQBox|<br />
'''Wie geht man mit Anforderungen nach Kodes um, die in den Value Sets nicht vorkommen?'''<br />
<br />
Das hängt primär von der Erweiterbarkeit und der Bindungsstärke ab!<br />
<br />
Value Set Vorgaben mit der Bindungsstärke "required" müssen verwendet werden. Bei "suggested" kann eine Alternative definiert werden, die dann genutzt werden kann. Allerdings ist hierbei zu beachten, dass man von einer Empfehlung abweicht und damit in zukünftigen Anbindungen Probleme bekommen kann.<br />
<br />
Die Erweiterbarkeit zeigt an, ob das Value Set durch eigene Festlegungen ergänzt werden kann ("open") oder nicht ("closed"). Wenn Ergänzungen zugelassen sind, so ist ein eigenes Kodesystem zu definieren, das in das Value Set mit eingebunden wird. Auf diese Weise werden die bekannten Kodes aus dem bereits vorhandenen Kodesystem eingesetzt und nur für fehlende, aber notwendige Konzepte eigene Kodes definiert.<br />
<br />
Eine elegantere Methode ist die Kontaktaufnahme mit dem Interoperabilitätsforum, um neue Kodes für eine Aufnahme in das offizielle Value Set vorzuschlagen. Dort werden die Vorschläge diskutiert und über einen Änderungs-/Erweiterungsvorschlag in einem Abstimmungsverfahren (Ballot) abgestimmt.<br />
}}<br />
<br />
{{BestPracticeBox|<br />
Wie soll verfahren werden, wenn das hier beschriebene Vorgehen nicht ganz klar ist?<br />
<br />
Das einfachste ist eine eMail an tcs@hl7.de, in der die Frage übermittelt wird. Das Interoperabilitätsforum wird versuchen, darauf schnellstmöglich eine Antwort allgemein verfügbar bereitzustellen.<br />
}}<br />
<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:Vokabular-Management&diff=80492Ihevs:Vokabular-Management2023-09-28T19:41:59Z<p>Tidris: /* Vokabular-Management */</p>
<hr />
<div>{{DocumentPart}}<br />
=Vokabular-Management=<br />
<br />
Die Übermittlung von konkreten Daten kann auf zweierlei Art und Weise erfolgen: Die einfachste Variante ist Freitext, bei der beliebige Daten - als Zeichenkette (ggf. noch eingeschränkt auf einen bestimmten Datentyp) - übertragen werden. Dieses Verfahren bietet sich an, wenn die individuelle Ausprägung sehr unterschiedlich sein kann wie bspw. der Name des Patienten oder ein Kommentar. Für immer wiederkehrende und im Prinzip gleiche Information, wie bspw. der Familienstand, werden die zu übertragenden Daten abgekürzt und durch einen "Platzhalter" ersetzt. Bei letzterem muss die Bedeutung aber klar sein. Hierfür werden Kodesysteme definiert, die sowohl die Abkürzungen - Kodes - als auch deren Bedeutung auflisten. Die Zuordnung von einzelnen Feldern in einer Datenaustauschspezifikation zu konkreten Wertelisten erfolgt mehrstufig: Die Festlegung der erlaubten Werte für ein kodiertes Attribut erfolgt über die Angabe von sog. Konzept- oder Vokabeldomänen (''Concept / Vocabulary Domains''), Kodiersystemen (''Code Systems'') und Wertemengen (''Value Sets''). <br />
<br />
Eine '''Konzeptdomäne''' dient dazu, den Wertebereich eines Attributs einzugrenzen ohne dabei direkt schon feste Kodiersysteme oder Value Sets vorzugeben. Eine Konzeptdomäne wird durch einen Namen, eine textuelle Beschreibung sowie eine Reihe von Beispielkonzepten definiert. Zum Beispiel soll die Konzeptdomäne DocumentEntry.typeCode den Typ eines Dokuments aus Benutzersicht kodieren. <br />
<br />
Ein '''Value Set''' ist eine eindeutige identifizierbare Sammlung von Konzeptrepräsentationen und es ist einer oder mehreren Konzeptdomänen zugeordnet. Ein Value Set kann Codes aus einem oder mehreren Kodiersystemen enthalten. Ein '''Kodiersystem''' wird dabei durch eine Liste von Codes mit zugehörigen Anzeigenamen und Beschreibungen definiert. Innerhalb eines Kodiersystems muss ein Code eine eindeutig definierte Bedeutung haben. <br />
<br />
Value Sets können in unterschiedlicher Art und Weise definiert werden: ''extensional'' als Sammlungen von Codes (Konzepten) oder ''intensional'' über einen berechenbaren Ausdruck, aus dem sich eine Codeliste exakt ermitteln lässt. Die Value Sets für DocumentEntry.typeCode und DocumentEntry.classCode in diesem Leitfaden sind beispielsweise extensional als Listen definiert, während das Value Set für DocumentEntry.formatCode intensional über Konstruktionsvorschriften für URNs definiert wurde.<br />
<br />
Wenn ein Value Set neben den genannten oder beschriebenen Codes zusätzliche Werte erlaubt, wird es als offen (''open'') bezeichnet, andernfalls als geschlossen (''closed''). Das Value Set für DocumentEntry.languageCode ist beispielsweise offen, da neue Sprachcodes gebildet und wenn notwendig auch verwendet werden können. Die Value Sets für DocumentEntry.classCode und DocumentEntry.healthcareFacilityTypeCode sind hingegen geschlossen. Das heißt, dass eine Erweiterung nur über eine neue Version der Value Sets erfolgen sollte.<br />
<br />
Die Identifikation eines Value Sets erfolgt bei CDA und IHE XDS über eine OID, bei FHIR über eine URL. Die Version eines Value Sets wird über einen Zeitstempel charakterisiert. Die Bindung eines kodierten Elementes an ein Value Set (Binding) kann nun dynamisch (''dynamic'') oder statisch (''static'') erfolgen. Ein dynamisches Binding bezieht sich auf die jeweils aktuellste Version eines Value Sets, während bei einem statischen Binding eine feste Version angegeben wird. Bei einem statischen Binding müssen OID bzw. ein eindeutiger Bezeichner sowie ein Zeitstempel angegeben werden. Beim dynamischen Binding fehlt der Zeitstempel. <br />
<br />
Unabhängig davon gibt es für das Binding von ValueSets noch weitere Unterscheidungsmöglichkeiten. Beim ''Design-Time Binding'' wird das zu verwendende Value Set explizit angegeben. Beim ''Runtime Binding'' werden nur die Konzeptdomäne und die sogenannte Realm (z.B. „Deutschland“) festgelegt. Das effektive Value Set wird dann dynamisch über einen Terminologieserver an Hand von Konzeptdomäne und Realm ermittelt. <br />
<br />
Bindings können verpflichtend sein (''required''), empfohlen werden (''suggested'' oder ''preferred'') oder dienen nur als Beispiel (''example''). Einzelne Werte eines Value Sets können als verpflichtend (''required''), erlaubt (''permitted'') oder ausgeschlossen (''excluded'') gekennzeichnet werden. Die in diesem Leitfaden definierten Codes besitzen alle den Status permitted.<br />
<br />
Die folgende Tabelle gibt eine Übersicht über die Eigenschaften der bereits definierten Value Sets:<br />
<div class="landscape"><br />
{| class="hl7table"<br />
|-<br />
!XDS-Metadatum!!Beschreibung!!Definitionsart!!Erweiterbarkeit!!Bindungsstärke!!Bindungsart!!Versionsbindung<br />
|-<br />
|[[Ihevs:DocumentEntry.authorRole|authorRole]] ||Rolle des Autors||extensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.authorSpecialty|authorSpecialty]] ||Fachrichtung des Autors||extensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.classCode|classCode]] ||Dokumentenklasse||extensional||closed||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.confidentialityCode|confidentialityCode]] ||Dokumenten-Vertraulichkeitsstufe||extensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.eventCodeList|eventCodeList]] ||Tätigkeitskennzeichen/Zusätzliche Kennzeichnung||intensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.formatCode|formatCode]] ||Dokumentenformat||intensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.healthcareFacilityTypeCode|healthcareFacilityTypeCode]] ||Einrichtungsart||extensional||closed||suggested|| design-time||dynamic<br />
|-<br />
|[[LanguageCode|languageCode]] ||Dokumentensprache||intensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.PracticeSettingCode|practiceSettingCode]] ||Erstellende Fachrichtung||extensional||closed||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:DocumentEntry.typeCode|typeCode]] ||Dokumententyp||extensional||closed||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:SubmissionSet.contentTypeCode|SubmissionSet.contentTypeCode]] ||Inhaltskennzeichen des SubmissionSets||extensional||open||suggested||design-time||dynamic<br />
|-<br />
|[[Ihevs:Folder.codeList|Folder.codeList]] ||Ordnerklassifizierung||extensional||open||suggested||design-time||dynamic<br />
|}<br />
</div><br />
<br />
== Identifikation von Kodesystemen in FHIR-basierter Kommunikation ==<br />
<br />
FHIR empfiehlt die Verwendung einer URL als primäre Identifikation eines Kodesystems. Es ist zwar grundsätzlich zulässig eine OID in ihrer URN-form, d.h. beginnend mit "urn:oid:", als Identifikation zu verwenden, aber es gilt als nicht-idiomatisch. Aus technischen Gründen können die von dieser Arbeitsgruppe erstellten Kodesysteme in ART-DECOR nicht konsistent mit einer URL versehen werden. Daher werden die in FHIR zu verwendenen Canonical URLs in der folgenden Tabelle für alle in diesem Leitfaden eingeführten Kodesysteme aufgeführt. Die OID-URNs, die in den in diesem Leitfaden inkludierten ART-DECOR Auszügen verwendet werden, sind als zusätzliche, sekundäre Identifikatoren zu verstehen.<br />
{| class="hl7table"<br />
|-<br />
!Kodesystem!!Canonical URL!!sekundärer Identifier||XDS-Metadatum<br />
|-<br />
|Prozessrollen für Autoren||http://ihe-d.de/CodeSystems/AutorenProzessRollen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.13||[[Ihevs:DocumentEntry.authorRole|authorRole]]<br />
|-<br />
|Patientenbeziehungsrollen für Autoren||http://ihe-d.de/CodeSystems/AutorenPatientenbeziehungsRollen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.14||[[Ihevs:DocumentEntry.authorRole|authorRole]]<br />
|-<br />
|Qualifikationen nicht ärztlicher Autoren||http://ihe-d.de/CodeSystems/qualifikationen-nichtaerztlicher-autoren||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.11||[[Ihevs:DocumentEntry.authorSpecialty|authorSpecialty]]<br />
|-<br />
|Dokumentenklassen||http://ihe-d.de/CodeSystems/dokumentenklassen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.8||[[Ihevs:DocumentEntry.classCode|classCode]] <br />
|-<br />
|Betroffeneneinschätzung der Vertraulichkeitsstufe||http://ihe-d.de/CodeSystems/betroffenen-vertraulichkeitsstufe||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.10||[[Ihevs:DocumentEntry.confidentialityCode|confidentialityCode]]<br />
|-<br />
|Dokumenten-Warnhinweise||http://ihe-d.de/CodeSystems/dokumenten-warnhinweise||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.15||[[Ihevs:DocumentEntry.eventCodeList|eventCodeList]]<br />
|-<br />
|Fallkontext bei Dokumentenerstellung||http://ihe-d.de/CodeSystems/fallkontext-dokumentenerstellung||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.16||[[Ihevs:DocumentEntry.eventCodeList|eventCodeList]]<br />
|-<br />
|Deutsche Dokumentenformate||http://ihe-d.de/CodeSystems/dokumentenformate||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.6||[[Ihevs:DocumentEntry.formatCode|formatCode]] <br />
|-<br />
|Einrichtungsarten der patientenbezogenen Gesundheitsversorgung||http://ihe-d.de/CodeSystems/einrichtungsarten-patientenbezogen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.2||[[Ihevs:DocumentEntry.healthcareFacilityTypeCode|healthcareFacilityTypeCode]] <br />
|-<br />
|Einrichtungsarten ausserhalb der patientenbezogenen Gesundheitsversorgung||http://ihe-d.de/CodeSystems/einrichtungsarten-nicht-patientenbezogen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.3||[[Ihevs:DocumentEntry.healthcareFacilityTypeCode|healthcareFacilityTypeCode]] <br />
|-<br />
|Ärztliche Fachrichtungen||http://ihe-d.de/CodeSystems/aerztliche-fachrichtungen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.4||[[Ihevs:DocumentEntry.PracticeSettingCode|practiceSettingCode]]<br />
|-<br />
|Nicht-ärztliche Fachrichtungen||http://ihe-d.de/CodeSystems/nicht-aerztliche-fachrichtungen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.5||[[Ihevs:DocumentEntry.PracticeSettingCode|practiceSettingCode]]<br />
|-<br />
|Dokumententypen||http://ihe-d.de/CodeSystems/dokumententypen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.9||[[Ihevs:DocumentEntry.typeCode|typeCode]]<br />
|-<br />
|Grund der Übermittlung||http://ihe-d.de/CodeSystems/uebermittlungsgrund||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.12||[[Ihevs:SubmissionSet.contentTypeCode|SubmissionSet.contentTypeCode]]<br />
|-<br />
|Ordnertypen||http://ihe-d.de/CodeSystems/ordnertypen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.7||[[Ihevs:Folder.codeList|Folder.codeList]]<br />
|}<br />
<br />
{{FAQBox|<br />
'''Wie geht man mit Anforderungen nach Kodes um, die in den Value Sets nicht vorkommen?'''<br />
<br />
Das hängt primär von der Erweiterbarkeit und der Bindungsstärke ab!<br />
<br />
Value Set Vorgaben mit der Bindungsstärke "required" müssen verwendet werden. Bei "suggested" kann eine Alternative definiert werden, die dann genutzt werden kann. Allerdings ist hierbei zu beachten, dass man von einer Empfehlung abweicht und damit in zukünftigen Anbindungen Probleme bekommen kann.<br />
<br />
Die Erweiterbarkeit zeigt an, ob das Value Set durch eigene Festlegungen ergänzt werden kann ("open") oder nicht ("closed"). Wenn Ergänzungen zugelassen sind, so ist ein eigenes Kodesystem zu definieren, das in das Value Set mit eingebunden wird. Auf diese Weise werden die bekannten Kodes aus dem bereits vorhandenen Kodesystem eingesetzt und nur für fehlende, aber notwendige Konzepte eigene Kodes definiert.<br />
<br />
Eine elegantere Methode ist die Kontaktaufnahme mit dem Interoperabilitätsforum, um neue Kodes für eine Aufnahme in das offizielle Value Set vorzuschlagen. Dort werden die Vorschläge diskutiert und über einen Änderungs-/Erweiterungsvorschlag in einem Abstimmungsverfahren (Ballot) abgestimmt.<br />
}}<br />
<br />
{{BestPracticeBox|<br />
Wie soll verfahren werden, wenn das hier beschriebene Vorgehen nicht ganz klar ist?<br />
<br />
Das einfachste ist eine eMail an tcs@hl7.de, in der die Frage übermittelt wird. Das Interoperabilitätsforum wird versuchen, darauf schnellstmöglich eine Antwort allgemein verfügbar bereitzustellen.<br />
}}<br />
<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=IHE_DE_ValueSets_Action_Items&diff=78144IHE DE ValueSets Action Items2022-06-10T11:33:01Z<p>Tidris: </p>
<hr />
<div>'''Tabelle Änderungsanfragen'''<br />
<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! align="left" | Anfrage ID<br />
! align="left" | Anfrage eingegangen am<br />
! align="left" | Anfrage<br />
! align="center" | betrifft Codesystem<br />
! align="center" | Autor der Anfrage<br />
! align="center" | Diskussion<br />
! align="center" | Entscheidung<br />
! align="center" | Action Item<br />
! align="center" | Bearbeitungsstand<br />
! align="center" | zuletzt bearbeitet am<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 43<br />
| Anfrage eingegangen am| 10.06.2022<br />
| Anfrage| Im Zuge des KDL-Mapping-Reviews waren sich die Reviewer einig, das eine Klarstellung der Beschreibung des Befundberichts sinnvoll wäre, um Befundberichte besser von Durchführungsprotokollen abzugrenzen.<br />
| betrifft Codesystem | classCode<br />
| Autor der Anfrage | Raik<br />
| Diskussion| <br />
| Entscheidung | <br />
| Action Item | <br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 10.06.2022<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 4<br />
| Anfrage eingegangen am|<br />
| Anfrage| Arbeitsgruppe „Weiterentwicklung Klinische Dokumentenklassenliste (KDL)“.<br />
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.<br />
Das aktuelle Mapping liegt der Geschäftsstelle vor und ist bisher mit Angela Merzweiler gemeinsam abgestimmt wurden.<br />
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.<br />
Beispiel:<br />
Ich möchte daher anregen bzw. beantragen, dass die KDL im ersten Schritt offiziell als CodeSystem in das Value Set „EventCodeList“ aufgenommen wird.<br />
Damit haben Hersteller von IHE-konformen Archiven, o. ä. die Möglichkeit, wenigstens die Klassifizierung des Dokuments mittels KDL offiziell abzubilden.<br />
· Code System Name: Klinische Dokumentenklassen Liste (KDL)<br />
· Code System ID: 1.2.276.0.76.3.1.191.0.1.1, versionsabhängig<br />
· Kommentar: Klassifizierung von Dokumenten und Daten als Beispiele für die Value Sets classCode und typeCode<br />
Mittelfristig soll die KDL zu einem terminologischen System mit ontologischem Ansatz ausgebaut werden.<br />
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.<br />
Ich freue mich, wenn wir es gemeinsam schaffen, dazu einen persönlichen Termin für ein Arbeitstreffen zu finden.<br />
| betrifft Codesystem | eventCode<br />
| Autor der Anfrage | AMü<br />
| 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<br />
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)<br />
übergeordnetes Valueset KDL in ArtDecor als Codesystem eingetragen, da der Eintrag als Valueset technisch nicht möglich war.<br />
12.11.2021 erneute Diskussion, ob Eintrag als Codesystem sinnvoll war<br />
| Entscheidung | grundsätzlich zugestimmt, neues Valueset<br />
| Action Item | alle=> Mapping prüfen<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 12.11.2021<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 6<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Ansatz Canonical URLs diskutieren<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | Tarik Idris<br />
| Diskussion| Ziel: Gute Einfügung in FHIR Umgebung<br />
| Entscheidung | Für V3 alle URNs durch URLs ersetzen <br />
| 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 <br />
| Bearbeitungsstand | für ValueSets erledigt (Angela)<br />
| zuletzt bearbeitet am| 14.11.2021<br />
<br />
|- valign="top" <br />
| Anfrage ID| 7<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Deutscher Implementation Guide für MHD Profile mit Verweis auf unsere Valuesets<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | SH über Tarik<br />
| 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 <br />
| 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 <br />
| Action Item | Simone um Referenz der Codes in Deutschen Basisprofilguideline bitten <br />
| Bearbeitungsstand | als Issues in Gitlab eingetragen, im Simplifier sichtbar https://simplifier.net/basisprofil-de-r4/~resources?category=ValueSet&sortBy=RankScore_desc ==> (Angela)<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 19<br />
| Anfrage eingegangen am| 10.07.2020<br />
| 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<br />
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:<br />
Bestehenden Code ALLG - „Allgemeinmedizin“ neu bezeichnen als „Facharzt für Allgemeinmedizin<br />
(Hausarzt)“<br />
2. Neuen Code einführen für „Praktischer Arzt/Arzt (Hausarzt)“. Vorschlag: PRAK<br />
3. Neuen Code einführen für „Hausärztlich tätiger Internist (Hausarzt)“. Vorschlag: HINT<br />
4. Bestehenden Codes ORTH neu bezeichnen als „Orthopädie und Unfallchirurgie“.<br />
5. Neuen Code einführen für „Rheumatologie (Orthopädie)“. Vorschlag: ORRH.<br />
6. Neuen Code einführen für „Infektiologie“. Vorschlag: INFK<br />
7. Neuen Code einführen für „Kinder-Pneumologie“. Vorschlag: KIPN<br />
8. Neuen Code einführen für „Nervenheilkunde/Neurologie und Psychiatrie“. Vorschlag: NERV<br />
9. Neuen Code einführen für „Psychotherapeutisch tätiger Arzt“. Vorschlag: PTAR<br />
10. Neuen Code einführen für „Psychologischer Psychotherapeut“. Vorschlag: PPTH<br />
11.Neuen Code einführen für „Kinder- und Jugendlichen-Psychotherapeut“. Vorschlag: KJPP<br />
| betrifft Codesystem | Practice Setting Code<br />
| Autor der Anfrage | SR (KBV)<br />
| 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.<br />
| 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).<br />
| Action Item | Mapping prüfen und in Implementation Guide eintragen.<br />
| 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.<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 29<br />
| Anfrage eingegangen am| 22.01.2021<br />
| Anfrage| Problem mit ArtDecor bei FHIR<br />
| betrifft Codesystem | alle<br />
| Autor der Anfrage | Axel<br />
| Diskussion| <br />
| Entscheidung | <br />
| Action Item | Axel meldet Issues an Kai<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 22.01.2021<br />
<br />
<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 31<br />
| Anfrage eingegangen am| 18.02.2021<br />
| 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.<br />
| betrifft Codesystem | ClassCode<br />
| Autor der Anfrage | CG<br />
| Diskussion| <br />
| Entscheidung | <br />
| Action Item | <br />
| Bearbeitungsstand | offen<br />
| zuletzt bearbeitet am| <br />
<br />
|- valign="top" <br />
| Anfrage ID| 33<br />
| Anfrage eingegangen am| 22.12.2021<br />
| 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.<br />
| betrifft Codesystem | AuthorSpecialty<br />
| Autor der Anfrage | BPtK<br />
| Diskussion| <br />
Potentieller Ansatz:<br />
"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)<br />
* 74<br />
** 189<br />
*** 76<br />
*** 82<br />
*** 183<br />
**** 184<br />
**** 185<br />
** 190<br />
*** 75<br />
*** 77<br />
*** 78<br />
*** 79<br />
*** 80<br />
*** 81<br />
*** 83<br />
*** 84<br />
*** 85<br />
<br />
Betroffenen Systemen und Use Cases<br />
* Suche KIM-Teilnehmer<br />
** Kammer/HBA-Herausgeber<br />
*** z.B. Landesärztekammern und BPtk, prüfen ob der Gruppen-Code 74 verwendet werden, wahrscheinlich werden eher die konkreten Codes verwendet<br />
** Verzeichnisdienst<br />
*** VZD macht keine Umsetzung von Gruppe zu konkreten Codes, d.h. kein Änderungsbedarf<br />
** AIS / KIS / weitere Primärsysteme<br />
*** 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)<br />
* ePA-Dokumentenmetadaten: authorSpeciality<br />
** ePA-Aktensystem<br />
*** 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.<br />
** ePA-FdV<br />
*** 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.<br />
** Primärsystem<br />
*** 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.<br />
<br />
* XDS Affinity Domains (nicht-ePA)<br />
** Document Source<br />
*** wie bei ePA<br />
** Document Registry<br />
*** wie bei ePA, auch wenn Updates einfacher zu realisieren sind<br />
** Document Consumer<br />
*** Suche nach AuthorSpecialty möglich, Mapping Thematik wie bei ePA<br />
<br />
* Auswirkungen auf ISIK<br />
Umsetzung nach Wunsch BPtK<br />
<br />
BPtK müsste eigenes Codessystem auf jeden Fall selbst pflegen<br />
Impact auf andere Systeme müssen noch genau analysiert werden<br />
<br />
<br />
| Entscheidung | Wenn BPtK eigenes Codesystem erstellt pflegen wir es ein<br />
| Action Item | BPtK beantragt OID<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 18.03.2022<br />
<br />
|- valign="top" <br />
<br />
<br />
| Anfrage ID| 37<br />
| Anfrage eingegangen am| 04.03.2022<br />
| Anfrage| Displaynames Gender konform gestalten<br />
| betrifft Codesystem | v.a. author role, authorspecialty<br />
| Autor der Anfrage | Gematik<br />
| 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; <br />
| 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<br />
| Action Item | Änderung wird befürwortet, wie und wann wird noch festgelegt<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 29.04.2022<br />
|- valign="top" <br />
<br />
| Anfrage ID| 38<br />
| Anfrage eingegangen am| 25.3.2022<br />
| Anfrage| KDL Mapping kontrollieren<br />
| betrifft Codesystem | class code, type code, <br />
| Autor der Anfrage | DVMD<br />
| Diskussion| <br />
| Entscheidung | Das Mapping wird bis in vier Wochen von Raik, Tarik, Arnold und eventuell Sven gereviewed. Angela teilt das Mappingdokument auf ihrem onedrive.<br />
| Action Item | Review bis in vier Wochen<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 29.04.2022<br />
|- valign="top" <br />
<br />
| Anfrage ID| 39<br />
| Anfrage eingegangen am| 31.03.2022<br />
| Anfrage| neue FormatCodes, neue eventCodes<br />
DiGA<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:diga:v1.0"<br />
<br />
documentEntry.formatCode.displayName: "DiGA (gematik)"<br />
<br />
<br />
<br />
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: <br />
<br />
<br />
<br />
DMP Asthma bronchiale<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-Asthma:v4.45"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Asthma (gematik)"<br />
<br />
<br />
<br />
DMP Brustkrebs<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-BRK:v4.23"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Brustkrebs (gematik)"<br />
<br />
<br />
<br />
DMP Chronische Herzinsuffizienz<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-HI:v1.1" <br />
<br />
documentEntry.formatCode.displayName: "eDMP Herzinsuffizienz (gematik)"<br />
<br />
<br />
<br />
DMP Chronischer Rückenschmerz<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-Rueckenschmerz:v1.0"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Rückenschmerz (gematik)"<br />
<br />
<br />
<br />
DMP COPD<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-COPD:v4.4" <br />
<br />
documentEntry.formatCode.displayName: "eDMP Chronic Obstrusive Pulmonary Disease (gematik)"<br />
<br />
<br />
<br />
DMP Depressionen<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-Depression:v1.1" <br />
<br />
documentEntry.formatCode.displayName: "eDMP Depression (gematik)"<br />
<br />
<br />
<br />
DMP Diabetes mellitus Typ 1<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-DM1:v5.5"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Diabetes mellitus Typ 1 (gematik)"<br />
<br />
<br />
<br />
DMP Diabetes mellitus Typ 2<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-DM2:v6.5"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Diabetes mellitus Typ 2 (gematik)"<br />
<br />
<br />
<br />
DMP Koronare Herzkrankheit<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-KHK:v4"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Koronare Herzkrankheit (gematik)"<br />
<br />
<br />
<br />
DMP Osteoporose<br />
<br />
documentEntry.formatCode.code: "urn:gematik:ig:DMP-OST:v1.0"<br />
<br />
documentEntry.formatCode.displayName: "eDMP Osteoporose (gematik)<br />
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.<br />
<br />
<br />
<br />
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.<br />
| betrifft Codesystem |formatCodes<br />
| Autor der Anfrage | Gematik<br />
| Diskussion| Die Display names des KBV CodeSystems sind ziemlich uneindeutig. Beispiel: HI könnte nicht nur Herzinsuffizienz sondern auch Hinterwandinfarkt oder Harnwegsinfekt bedeuten.<br />
| 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.<br />
| Action Item | Raik gibt entsprechende Rückmeldung an KBV, Angela fügt eventCOdes und formatCodes den entsprechende ValueSets hinzu<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 27.05.2022<br />
|- valign="top" <br />
<br />
| Anfrage ID| 40<br />
| Anfrage eingegangen am| 28.04.2022<br />
| Anfrage| passender eventCode bei stationärer Wiederaufnahme nach Unterbrechung<br />
| betrifft Codesystem | eventCode<br />
| Autor der Anfrage | AM (UKHD)<br />
| Diskussion| <br />
| Entscheidung | E216 Wiederaufnahme vollstationär nach kurzzeitiger Unterbrechung wird hinzugefügt<br />
| Action Item | <br />
| Bearbeitungsstand | in ArtDecor eingetragen<br />
| zuletzt bearbeitet am| 29.04.2022<br />
|- valign="top" <br />
<br />
| Anfrage ID| 41<br />
| Anfrage eingegangen am| 28.04.2022<br />
| 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"<br />
displayName: " Pflegeüberleitungsbogen (gematik)"<br />
| betrifft Codesystem | formatCode<br />
| Autor der Anfrage | gematik<br />
| Diskussion| <br />
| Entscheidung | Major Revisions werden als FormatCodes aufgenommen<br />
| Action Item | Feedback an Gematik ==> positiv<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 27.05.2022<br />
|- valign="top" <br />
<br />
| Anfrage ID| 42<br />
| Anfrage eingegangen am| 27.05.2022<br />
| Anfrage|neue Dokumentenformate für gematik "urn:gematik:ig:DMP-Rheuma:v1<br />
eDMP" displayName: "Rheumatoide Arthritis (gematik)"<br />
| betrifft Codesystem | formatCode<br />
| Autor der Anfrage | gematik<br />
| Diskussion| <br />
| Entscheidung |Major Revisions werden aufgenommen<br />
| Action Item | <br />
| Bearbeitungsstand | in Art Decor eingetragen<br />
| zuletzt bearbeitet am| 27.05.2022<br />
|- valign="top" <br />
|}<br />
<br />
'''Tabelle abgeschlossene Änderungsanfragen'''<br />
<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! align="left" | Anfrage ID<br />
! align="left" | Anfrage eingegangen am<br />
! align="left" | Anfrage<br />
! align="center" | betrifft Codesystem<br />
! align="center" | Autor der Anfrage<br />
! align="center" | Diskussion<br />
! align="center" | Entscheidung<br />
! align="center" | Action Item<br />
! align="center" | Bearbeitungsstand<br />
! align="center" | zuletzt bearbeitet am<br />
<br />
|- valign="top" <br />
| Anfrage ID| 1<br />
| Anfrage eingegangen am|<br />
| 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:<br />
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<br />
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.<br />
Wir haben somit eine Mischung aus IHE-D-Codes und IHE-PCC/LAB-LOINC-Codes. Inhaltlich/semantisch überschneidet sich das recht munter. Fragen:<br />
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?<br />
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?<br />
Folgende Codes werden vermisst:<br />
im AOK-Projekt haben wir in Ergänzung zu den IHE-D-Codes die folgenden LOINC-Codes als typeCodes verwendet:<br />
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)<br />
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<br />
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<br />
Verschiedene Ausprägungen des Entlassbriefs, um hier anhand der typeCodes eine bessere Sortierung für den Patienten zu ermöglichen:<br />
11490-0: Ärztlicher Entlassbrief<br />
34105-7: Krankenhausentlassbrief (vorläufige/gekürzte Fassung für den Patienten bei der Entlassung)<br />
18842-5: Finales Krankenhausentlassbrief<br />
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.<br />
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.<br />
58410-2: Vollständiges Blutbild<br />
55429-5: Kleines Blutbild<br />
| betrifft Codesystem | class codes, type codes<br />
| Autor der Anfrage | JC <br />
| 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<br />
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.<br />
<br />
| 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.<br />
| 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<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am|21.2.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 2<br />
| Anfrage eingegangen am|<br />
| Anfrage| es scheint in Deutschland Bestrebungen zu geben, Unfallchirurgie mit der Orthopädie zusammenzulegen.<br />
Ab August 2019 wird es im UKD nur noch die „Klinik für Orthopädie und Unfallchirurgie“ geben.<br />
Ist die Einführung einer weiteren Fachabteilung im DocumentEntry.practiseSettingCode geplant?<br />
In DocumentEntry.authorSpecialty findet sie sich:<br />
Code 512 Anzeigename FA Orthopädie und Unfallchirurgie<br />
| betrifft Codesystem | practiceSettingCode <br />
| Autor der Anfrage | SB<br />
| Diskussion| evtl. practiceSettingCode Chirurgie verwenden, deckt beides ab<br />
| Entscheidung |<br />
| Action Item |<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 29.11.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 3<br />
| Anfrage eingegangen am|<br />
| 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.<br />
Dazu möchten wir das Value Set für XDS-Metadatenattribut formatCode um den folgenden Wert erweitern: urn:gematik:ig:DatensatzPersoenlicheErklaerungen:r3.1<br />
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.<br />
| betrifft Codesystem | formatCode<br />
| Autor der Anfrage | RK<br />
| Diskussion| keine Einwände<br />
| Entscheidung | wir fügen Code hinzu<br />
| Action Item | in ArtDecor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am|13.12.2019<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 5<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Freischaltung der FHIR Schnittstelle in ArtDecor<br />
| betrifft Codesystem | alle<br />
| Autor der Anfrage | SH über Tarik Idris<br />
| Diskussion| <br />
| Entscheidung | wird gemacht<br />
| Action Item | Tarik: FHIR Schnittstelle in ArtDecor freischalten<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 15.11.2019<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 8<br />
| Anfrage eingegangen am| 15.11.2019<br />
| Anfrage| Vorgehensweise für V3 auf eigener WikiSeite beschreiben<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | SL<br />
| Diskussion| befürwortet<br />
| Entscheidung | befürwortet<br />
| Action Item | Anlegen neue Seite im HL7 Wiki ==> Angela, Ziele ==> Angela, allgemeine Weiterentwicklung als Ziel hinzufügen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 13.12.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 9<br />
| Anfrage eingegangen am| 13.12.2019<br />
| Anfrage| Bericht Treffen BVITG, Interopforum, Gematik, Vorabstimmung EPA Version 1.2.2022<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | TI<br />
| 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) <br />
| Entscheidung | über konstruktive Zusammenarbeit wird sich gefreut<br />
| Action Item | keine<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 13.12.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 10<br />
| Anfrage eingegangen am| 12.01.2020<br />
| 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.<br />
https://loinc.org/file-access/download-id/8994/<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | ST<br />
| Diskussion| <br />
| Entscheidung | Gemeinsame Strategietelko zur Zusammenführung LOINC, SNOMED CT, XDT, QMS, KDL deutsche XDS Value Sets am 28.5.2020 10-12 Uhr geplant<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 24.04.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 11<br />
| Anfrage eingegangen am| 07.02.2020<br />
| Anfrage| Zusammenarbeit KBV<br />
| betrifft Codesystem | alle, v.a. format Code<br />
| Autor der Anfrage | RK<br />
| Diskussion| Den MIOs müssen XDS Metadaten zugeordnet werden, v.a. formatCodes<br />
| Entscheidung | Arbeitsgruppe bietet proaktiv Hilfe bzgl. der Metadaten bei KBV an<br />
| Action Item | Mail an Vorstand ==> Mail an KBV (H. Tenkow)<br />
| Bearbeitungsstand | Mail an Vorstand gesendet<br />
| zuletzt bearbeitet am| 07.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 12<br />
| Anfrage eingegangen am| 21.02.2020<br />
| 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<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | RK<br />
| Diskussion| keine Einwände<br />
| Entscheidung | werden aufgenommen<br />
| Action Item | Aufnahme in ArtDecor ==> Angela<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 24.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 13<br />
| Anfrage eingegangen am| 06.03.2020<br />
| Anfrage| Übersetzung der Metadatenbezeichnungen ins Englische<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | SL<br />
| Diskussion| ValueSets sind nur für Deutschland, jeder Dokumentierende sollte über ausreichende Deutschkenntisse verfügen<br />
| Entscheidung | abgelehnt<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 06.03.2020<br />
|- valign="top" <br />
<br />
|- valign="top"<br />
| Anfrage ID| 14<br />
| Anfrage eingegangen am| 24.04.2020<br />
| Anfrage| Neuer FormatCode für eRezept (Daten elektronischer Verordnung) der Gematik<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | RK<br />
| 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<br />
| Entscheidung | urn:gematik:ig:VerordnungsdatensatzMedikation:r4.0<br />
| Action Item | in Art Decor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
<br />
<br />
|- valign="top" <br />
<br />
<br />
| Anfrage ID| 15<br />
| Anfrage eingegangen am| 14.05.2020<br />
| Anfrage| Kommentierung EPA XDS Metadaten<br />
| betrifft Codesystem | fast alle<br />
| Autor der Anfrage | TI<br />
| Diskussion| <br />
| 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<br />
| Action Item | Tarik==> Kommentar an gematik<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.05.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 16<br />
| Anfrage eingegangen am| 14.05.2020<br />
| 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. <br />
| betrifft Codesystem | TypeCode<br />
| Autor der Anfrage | VK<br />
| Diskussion| <br />
| Entscheidung | wird als Beispiel in pathologische Befunde aufgenommen<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
|- valign="top" <br />
<br />
| Anfrage ID| 17<br />
| Anfrage eingegangen am| 14.05.2020<br />
| Anfrage| Am UKHD gibt es ein Zentrum für Seltene Erkrankungen. Dort werden Patienten jeglichen Alters behandelt. <br />
| betrifft Codesystem | PracticeSettingCode<br />
| Autor der Anfrage | VK<br />
| Diskussion| <br />
| 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<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 18<br />
| Anfrage eingegangen am| 26.06.2020<br />
| Anfrage| Code für Erfassung Fall- /Bewegungsdaten<br />
| betrifft Codesystem | Class Code, Type Code<br />
| Autor der Anfrage | AM<br />
| 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<br />
| Entscheidung | keine zusätzlichen Codes<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 20<br />
| Anfrage eingegangen am| 10.07.2020<br />
| 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:<br />
<br />
Unterkategorien von 1a - Code<br />
<br />
Hausarzt/ Hausärztin - practitioner<br />
<br />
Krankenhaus - hospital<br />
<br />
Labor und Humangenetik - laboratory<br />
<br />
Physiotherapeuten - physiotherapy<br />
<br />
Psychotherapeuten - psychotherapy<br />
<br />
Dermatologie - dermatology<br />
<br />
Urologie/Gynäkologie - gynaecology_urology<br />
<br />
Zahnheilkunde und Mund-Kiefer-Gesichtschirurgie - dentistry_oms<br />
<br />
Weitere Fachärzte/ Fachärztinnen - other_medical<br />
<br />
Weitere nicht-ärztliche Berufe - other_non_medical<br />
<br />
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.<br />
<br />
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.<br />
<br />
Für diesen Code soll ein Code-System "Sonstige Berechtigungen ePA" genutzt werden.<br />
| betrifft Codesystem | Anfrage neues Codesystem / ValueSet für Folder<br />
| Autor der Anfrage | JG (Gematik)<br />
| 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<br />
| Entscheidung |Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte<br />
| Action Item | Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte<br />
| 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 <br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 21<br />
| Anfrage eingegangen am| 31.07.2020<br />
| 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:<br />
<br />
"urn:gematik:ig:KinderuntersuchungsheftUntersuchungen:r4.0"<br />
"urn:gematik:ig:KinderuntersuchungsheftTeilnahmekarte:r4.0"<br />
"urn:gematik:ig:KinderuntersuchungsheftNotizen:r4.0"<br />
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.<br />
<br />
<br />
<br />
Als Anzeigename schlage ich vor:<br />
<br />
· Untersuchungen Kinderuntersuchungsheft<br />
<br />
· Teilnahmekarte Kinderuntersuchungsheft<br />
<br />
· Notizen Kinderuntersuchungsheft<br />
| betrifft Codesystem | FormatCodes<br />
| Autor der Anfrage | Gematik<br />
| Diskussion| <br />
| Entscheidung | wird aufgenommen<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 22<br />
| Anfrage eingegangen am| 16.09.2020<br />
| Anfrage| Patientenverfügung als Beispiel für administratives Dokument aufnehmen<br />
| betrifft Codesystem | classCode<br />
| Autor der Anfrage | VB (Uniklinik HD)<br />
| Diskussion| entspricht Mapping in KDL<br />
| Entscheidung | wird als Beispiel hinzugefügt<br />
| Action Item | in ArtDecor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 23<br />
| Anfrage eingegangen am| 18.09.2020<br />
| Anfrage| TypeCode für mikroskopische Bilder<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | VB (Uniklinik HD)<br />
| Diskussion| wenn Ergebnis Mikrobiologie oder Pathologie, dann diesen Code verwenden, ansonsten BILD<br />
| Entscheidung | wenn Ergebnis Mikrobiologie (MKRO) oder Pathologie (PATH) dann diesen Code verwenden, ansonsten BILD<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 24<br />
| Anfrage eingegangen am| 5.11.2020<br />
| 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.<br />
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.<br />
HL7 bildet die Berufsgruppen PP (2 L 82) und KJP (2-L 76) falsch ab, nämlich als Spezialisierung, nicht als Grundberufe.<br />
Die Fachgebiete des neuen Berufs ‚Psychotherapeut*in‘ sind im HL7 nicht abgebildet.<br />
| betrifft Codesystem | authorspecialty<br />
| Autor der Anfrage | BPtK<br />
| Diskussion| <br />
| Entscheidung |Neue Berufsgruppen werden in Authorspecialty aufgenommen.<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 25<br />
| Anfrage eingegangen am| 5.11.2020<br />
| Anfrage| Übernahme der Facharzt- und Schwerpunktscodes aus dem Codesystem der BAEK, da relevante Facharzt - und Schwerpunktscodes fehlen.<br />
| betrifft Codesystem | authorspecialty<br />
| Autor der Anfrage | BAEK<br />
| 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.<br />
| 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<br />
| Action Item | Konzept zur Pflege, Mapping BAEK Codes auf practice Setting Codes wird auch bei KBV veröffentlicht (als FHIR concept map)<br />
| Bearbeitungsstand |erledigt<br />
| zuletzt bearbeitet am| 01.02.2021<br />
<br />
|- valign="top" <br />
| Anfrage ID| 26<br />
| Anfrage eingegangen am| 13.11.2020<br />
| Anfrage| Prozeduren zu Fertilitätsbehandlung in Gebu aufnehmen?<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |nein<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 01.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 27<br />
| Anfrage eingegangen am| 13.11.2020<br />
| Anfrage| Typecode für Erfassung der Dauer der Gebärdendolmetscherunterstützung<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |Abrechnungsdokumente<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 01.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 28<br />
| Anfrage eingegangen am| 10.12.2020<br />
| Anfrage| Classcode für Diagnosenübersichtsblatt<br />
| betrifft Codesystem | classCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |hängt vom UseCase ab<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 01.02.2020<br />
|- valign="top" <br />
| Anfrage ID| 30<br />
| Anfrage eingegangen am| 04.02.2021<br />
| Anfrage| Nutzung von XDS Value Sets für den digitalen Austausch medizinischer Unterlagen mit den Medizinischen Diensten.<br />
| betrifft Codesystem | alle<br />
| Autor der Anfrage | AMue<br />
| Diskussion| <br />
| Entscheidung | <br />
| Action Item | Annett lädt Herrn Dr. Eckardt vom MD Westfalen-Lippe zur nächsten Telko ein<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| <br />
<br />
|- valign="top" <br />
| Anfrage ID| 32<br />
| Anfrage eingegangen am| 09.2021<br />
| Anfrage| Aufnahme von Pflegefachmann/-fachfrau, da neuer Ausbildungsberuf<br />
| betrifft Codesystem | Authorspecialty<br />
| Autor der Anfrage | FP<br />
| 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.<br />
| Entscheidung | Konzepte werden wie vorgeschlagen ergänzt, bzw. - bezeichnungen geändert.<br />
| Action Item | Eröffnung version 4 draft des Value Sets ==> Anpassungen in ArtDecor erfolgt<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 15.10.2021<br />
<br />
|- valign="top" <br />
| Anfrage ID| 34<br />
| Anfrage eingegangen am| 22.12.2021<br />
| 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:<br />
• IHE-XDS classCode = AUS<br />
• IHE-XDS typeCode = BESC<br />
Dies widerspricht den Kodiervorgaben von IHE Deutschland Dort ist festgelegt, dass der Notfalldatensatz mit typeCode PATD dokumentiert werden soll.<br />
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.<br />
Beispiele: Ausweise, Vorsorgevollmacht, Patientenverfügung, Wertgegenständeverwaltung, , Patiententagebuch<br />
<br />
| betrifft Codesystem | TypeCode<br />
| Autor der Anfrage | AMue<br />
| Diskussion| <br />
| Entscheidung | Missverständnis konnte geklärt werden<br />
| Action Item | keine<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| <br />
<br />
|- valign="top" <br />
| Anfrage ID| 35<br />
| Anfrage eingegangen am| 14.02.2022<br />
| Anfrage| Die gematik möchte wieder Aktualisierungen für MIO-Versionen zu den Format Codes einbringen. <br />
<br />
neu (die DisplayNames sind dieselben der Vorgänger)<br />
<br />
· urn:gematik:ig:KinderuntersuchungsheftUntersuchungen:v1.0.1<br />
<br />
· urn:gematik:ig:KinderuntersuchungsheftTeilnahmekarte:v1.0.1<br />
<br />
· urn:gematik:ig:KinderuntersuchungsheftNotizen:v1.0.1<br />
<br />
· urn:gematik:ig:Mutterpass:v1.1.0<br />
<br />
· urn:gematik:ig:VerordnungsdatensatzMedikation:v1.0.2<br />
<br />
<br />
<br />
deprecated/obsolet<br />
<br />
· urn:gematik:ig:VerordnungsdatensatzMedikation:r4.0<br />
<br />
· urn:gematik:ig:Kinderuntersuchungsheft:v1.0.0<br />
<br />
| betrifft Codesystem | FormatCode<br />
| Autor der Anfrage | RK<br />
| Diskussion| Versionsänderungen auf 3. Ebene (Patch) sollten in Zukunft keine Änderungen am Formatcode verursachen<br />
| 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.<br />
| Action Item | Art-Decor anpassen, RK Kommunikation des Wunschs der AG an die Gematik<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.03.2022<br />
<br />
|- valign="top" <br />
| Anfrage ID| 36<br />
| Anfrage eingegangen am| 18.02.2022<br />
| Anfrage| Pflege des Mappings der KDL auf ClassCode TypeCode mit Arbeitsgruppe abstimmen<br />
<br />
| betrifft Codesystem | eventCodeList, classCode, typeCode<br />
| Autor der Anfrage | AM<br />
| Diskussion| <br />
| Entscheidung | Review des Mappings können wir machen, aber Verantwortung liegt bei DVMD, sobald neues Mapping vorliegt, erfolgt Review als neue Anfrage<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.02.2022<br />
<br />
<br />
|}<br />
<br />
'''Tabelle Aktueller Stand'''<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! width="25%" align="left" | Codesystem<br />
! align="center" | Stand Konzepte<br />
! align="center" | ArtDecor<br />
! align="center" | WikiText<br />
! align="center" | Review durch<br />
<br />
|- valign="top" <br />
| Codesystem | Einleitung<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Sven, Frank<br />
<br />
|- valign="top" <br />
| Codesystem | Vokabular Management<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Sven, Frank<br />
<br />
|- valign="top" <br />
| Codesystem | Confidentiality Code<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Sven, Frank<br />
<br />
|- valign="top" <br />
| Codesystem | AuthorRole<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Angela, Sven<br />
<br />
|- valign="top" <br />
| Codesystem | AuthorSpeciality<br />
| Stand Konzepte | n/a<br />
| ArtDecor | offen<br />
| WikiText | offen<br />
| Review durch | ''Tarik?''<br />
<br />
|- valign="top" <br />
| Codesystem | EventCodeList<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Angela<br />
<br />
|- valign="top" <br />
| Codesystem | ContentTypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Axel<br />
<br />
|- valign="top" <br />
| Codesystem | ClassCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Arnold, Antje<br />
<br />
|- valign="top" <br />
| Codesystem | TypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Arnold, Antje<br />
<br />
|- valign="top" <br />
| Codesystem | FormatCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | Axel<br />
<br />
|- valign="top" <br />
| Codesystem | HealthcareFacilityTypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | ''Tarik?''<br />
<br />
|- valign="top" <br />
| Codesystem | PracticeSettingCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | Antje, Arnold<br />
<br />
|- valign="top" <br />
| Codesystem | Folder.codeList<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | Angela, Sven<br />
<br />
<br />
|- valign="top" <br />
| Valuesets/ generell| EPA Verwendung<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Erstellung durch | Raik, Christof<br />
<br />
|}<br />
<br />
'''Schritte zur Veröffentlichung v3'''<br />
# Zeitplan (draft) erstellen<br />
#* Anfang Februar Ankündigung<br />
#* Anfang März Kommentierungsstart<br />
#* Anfang April Ende Kommentierung, Anfang Kommentarauflösungs<br />
#* Anfang Juni Veröffentlichung<br />
# 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<br />
# Ankündigung formulieren <br />
# Kapitel zur Verwendung der ValueSets in der EPA schreiben<br />
# Review der Wiki-Texte und AuthorSpecialty Code anpassen<br />
# Change Liste erstellen<br />
# PDF erstellen<br />
# PDF in Wiki und auf IHE-D Seite hochladen/referenzieren<br />
# Kommentare sammeln<br />
# Kommentare auflösen<br />
# Abstimmung zur Veröffentlichung<br />
# Finale Version erstellen und in Wiki und IHE-D Seite hochladen<br />
<br />
Optional:<br />
* Erläuterung zum Zusammenspiel mit FHIR<br />
* Hinweis/kurze Erläuterung der nicht behandelten XDS Metadaten<br />
<br />
'''IG Struktur'''<br />
<br />
# [[ihevs:Einleitung]] (Vorgehen, Ziele, Umgang mit v1, normativ, Delta-Liste?, Änderungen/Pflege)<br />
# [[Ihevs:Vokabular-Management]]<br />
# [[ihevs:DocumentEntry.authorRole]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.authorSpecialty]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.classCode]]<br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.confidentialityCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.eventCodeList]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.formatCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.healthcareFacilityTypeCode]]<br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.languageCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.practiceSettingCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.typeCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:SubmissionSet.contentTypeCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:Folder.codeList]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor<br />
<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=IHE_DE_ValueSets_Action_Items&diff=77845IHE DE ValueSets Action Items2022-01-27T14:03:27Z<p>Tidris: </p>
<hr />
<div>'''Tabelle Änderungsanfragen'''<br />
<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! align="left" | Anfrage ID<br />
! align="left" | Anfrage eingegangen am<br />
! align="left" | Anfrage<br />
! align="center" | betrifft Codesystem<br />
! align="center" | Autor der Anfrage<br />
! align="center" | Diskussion<br />
! align="center" | Entscheidung<br />
! align="center" | Action Item<br />
! align="center" | Bearbeitungsstand<br />
! align="center" | zuletzt bearbeitet am<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 4<br />
| Anfrage eingegangen am|<br />
| Anfrage| Arbeitsgruppe „Weiterentwicklung Klinische Dokumentenklassenliste (KDL)“.<br />
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.<br />
Das aktuelle Mapping liegt der Geschäftsstelle vor und ist bisher mit Angela Merzweiler gemeinsam abgestimmt wurden.<br />
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.<br />
Beispiel:<br />
Ich möchte daher anregen bzw. beantragen, dass die KDL im ersten Schritt offiziell als CodeSystem in das Value Set „EventCodeList“ aufgenommen wird.<br />
Damit haben Hersteller von IHE-konformen Archiven, o. ä. die Möglichkeit, wenigstens die Klassifizierung des Dokuments mittels KDL offiziell abzubilden.<br />
· Code System Name: Klinische Dokumentenklassen Liste (KDL)<br />
· Code System ID: 1.2.276.0.76.3.1.191.0.1.1, versionsabhängig<br />
· Kommentar: Klassifizierung von Dokumenten und Daten als Beispiele für die Value Sets classCode und typeCode<br />
Mittelfristig soll die KDL zu einem terminologischen System mit ontologischem Ansatz ausgebaut werden.<br />
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.<br />
Ich freue mich, wenn wir es gemeinsam schaffen, dazu einen persönlichen Termin für ein Arbeitstreffen zu finden.<br />
| betrifft Codesystem | eventCode<br />
| Autor der Anfrage | AMü<br />
| 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<br />
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)<br />
übergeordnetes Valueset KDL in ArtDecor als Codesystem eingetragen, da der Eintrag als Valueset technisch nicht möglich war.<br />
12.11.2021 erneute Diskussion, ob Eintrag als Codesystem sinnvoll war<br />
| Entscheidung | grundsätzlich zugestimmt, neues Valueset<br />
| Action Item | alle=> Mapping prüfen<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 12.11.2021<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 6<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Ansatz Canonical URLs diskutieren<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | Tarik Idris<br />
| Diskussion| Ziel: Gute Einfügung in FHIR Umgebung<br />
| Entscheidung | Für V3 alle URNs durch URLs ersetzen <br />
| 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 <br />
| Bearbeitungsstand | für ValueSets erledigt (Angela)<br />
| zuletzt bearbeitet am| 14.11.2021<br />
<br />
|- valign="top" <br />
| Anfrage ID| 7<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Deutscher Implementation Guide für MHD Profile mit Verweis auf unsere Valuesets<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | SH über Tarik<br />
| 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 <br />
| 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 <br />
| Action Item | Simone um Referenz der Codes in Deutschen Basisprofilguideline bitten <br />
| Bearbeitungsstand | als Issues in Gitlab eingetragen, im Simplifier sichtbar https://simplifier.net/basisprofil-de-r4/~resources?category=ValueSet&sortBy=RankScore_desc ==> (Angela)<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 19<br />
| Anfrage eingegangen am| 10.07.2020<br />
| 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<br />
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:<br />
Bestehenden Code ALLG - „Allgemeinmedizin“ neu bezeichnen als „Facharzt für Allgemeinmedizin<br />
(Hausarzt)“<br />
2. Neuen Code einführen für „Praktischer Arzt/Arzt (Hausarzt)“. Vorschlag: PRAK<br />
3. Neuen Code einführen für „Hausärztlich tätiger Internist (Hausarzt)“. Vorschlag: HINT<br />
4. Bestehenden Codes ORTH neu bezeichnen als „Orthopädie und Unfallchirurgie“.<br />
5. Neuen Code einführen für „Rheumatologie (Orthopädie)“. Vorschlag: ORRH.<br />
6. Neuen Code einführen für „Infektiologie“. Vorschlag: INFK<br />
7. Neuen Code einführen für „Kinder-Pneumologie“. Vorschlag: KIPN<br />
8. Neuen Code einführen für „Nervenheilkunde/Neurologie und Psychiatrie“. Vorschlag: NERV<br />
9. Neuen Code einführen für „Psychotherapeutisch tätiger Arzt“. Vorschlag: PTAR<br />
10. Neuen Code einführen für „Psychologischer Psychotherapeut“. Vorschlag: PPTH<br />
11.Neuen Code einführen für „Kinder- und Jugendlichen-Psychotherapeut“. Vorschlag: KJPP<br />
| betrifft Codesystem | Practice Setting Code<br />
| Autor der Anfrage | SR (KBV)<br />
| 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.<br />
| 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).<br />
| Action Item | Mapping prüfen und in Implementation Guide eintragen.<br />
| 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.<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 29<br />
| Anfrage eingegangen am| 22.01.2021<br />
| Anfrage| Problem mit ArtDecor bei FHIR<br />
| betrifft Codesystem | alle<br />
| Autor der Anfrage | Axel<br />
| Diskussion| <br />
| Entscheidung | <br />
| Action Item | Axel meldet Issues an Kai<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 22.01.2021<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 30<br />
| Anfrage eingegangen am| 04.02.2021<br />
| Anfrage| Nutzung von XDS Value Sets für den digitalen Austausch medizinischer Unterlagen mit den Medizinischen Diensten.<br />
| betrifft Codesystem | alle<br />
| Autor der Anfrage | AMue<br />
| Diskussion| <br />
| Entscheidung | <br />
| Action Item | Annett lädt Herrn Dr. Eckardt vom MD Westfalen-Lippe zur nächsten Telko ein<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| <br />
<br />
|- valign="top" <br />
| Anfrage ID| 31<br />
| Anfrage eingegangen am| 18.02.2021<br />
| 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.<br />
| betrifft Codesystem | ClassCode<br />
| Autor der Anfrage | CG<br />
| Diskussion| <br />
| Entscheidung | <br />
| Action Item | <br />
| Bearbeitungsstand | offen<br />
| zuletzt bearbeitet am| <br />
<br />
|- valign="top" <br />
| Anfrage ID| 33<br />
| Anfrage eingegangen am| 22.12.2021<br />
| 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.<br />
| betrifft Codesystem | AuthorSpecialty<br />
| Autor der Anfrage | BPtK<br />
| Diskussion| <br />
Potentieller Ansatz:<br />
"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)<br />
* 74<br />
** 189<br />
*** 76<br />
*** 82<br />
*** 183<br />
**** 184<br />
**** 185<br />
** 190<br />
*** 75<br />
*** 77<br />
*** 78<br />
*** 79<br />
*** 80<br />
*** 81<br />
*** 83<br />
*** 84<br />
*** 85<br />
<br />
Betroffenen Systemen und Use Cases<br />
* Suche KIM-Teilnehmer<br />
** Kammer/HBA-Herausgeber<br />
*** z.B. Landesärztekammern und BPtk, prüfen ob der Gruppen-Code 74 verwendet werden, wahrscheinlich werden eher die konkreten Codes verwendet<br />
** Verzeichnisdienst<br />
*** VZD macht keine Umsetzung von Gruppe zu konkreten Codes, d.h. kein Änderungsbedarf<br />
** AIS / KIS / weitere Primärsysteme<br />
*** 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)<br />
* ePA-Dokumentenmetadaten: authorSpeciality<br />
** ePA-Aktensystem<br />
*** 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.<br />
** ePA-FdV<br />
*** 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.<br />
** Primärsystem<br />
*** 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.<br />
<br />
* XDS Affinity Domains (nicht-ePA)<br />
** Document Source<br />
*** wie bei ePA<br />
** Document Registry<br />
*** wie bei ePA, auch wenn Updates einfacher zu realisieren sind<br />
** Document Consumer<br />
*** Suche nach AuthorSpecialty möglich, Mapping Thematik wie bei ePA<br />
<br />
| Entscheidung | <br />
| Action Item | <br />
| Bearbeitungsstand | offen<br />
| zuletzt bearbeitet am| <br />
<br />
|- valign="top" <br />
| Anfrage ID| 34<br />
| Anfrage eingegangen am| 22.12.2021<br />
| 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:<br />
• IHE-XDS classCode = AUS<br />
• IHE-XDS typeCode = BESC<br />
Dies widerspricht den Kodiervorgaben von IHE Deutschland Dort ist festgelegt, dass der Notfalldatensatz mit typeCode PATD dokumentiert werden soll.<br />
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.<br />
Beispiele: Ausweise, Vorsorgevollmacht, Patientenverfügung, Wertgegenständeverwaltung, , Patiententagebuch<br />
<br />
| betrifft Codesystem | TypeCode<br />
| Autor der Anfrage | AMue<br />
| Diskussion| <br />
| Entscheidung | <br />
| Action Item | <br />
| Bearbeitungsstand | offen<br />
| zuletzt bearbeitet am| <br />
<br />
<br />
|}<br />
<br />
'''Tabelle abgeschlossene Änderungsanfragen'''<br />
<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! align="left" | Anfrage ID<br />
! align="left" | Anfrage eingegangen am<br />
! align="left" | Anfrage<br />
! align="center" | betrifft Codesystem<br />
! align="center" | Autor der Anfrage<br />
! align="center" | Diskussion<br />
! align="center" | Entscheidung<br />
! align="center" | Action Item<br />
! align="center" | Bearbeitungsstand<br />
! align="center" | zuletzt bearbeitet am<br />
<br />
|- valign="top" <br />
| Anfrage ID| 1<br />
| Anfrage eingegangen am|<br />
| 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:<br />
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<br />
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.<br />
Wir haben somit eine Mischung aus IHE-D-Codes und IHE-PCC/LAB-LOINC-Codes. Inhaltlich/semantisch überschneidet sich das recht munter. Fragen:<br />
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?<br />
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?<br />
Folgende Codes werden vermisst:<br />
im AOK-Projekt haben wir in Ergänzung zu den IHE-D-Codes die folgenden LOINC-Codes als typeCodes verwendet:<br />
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)<br />
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<br />
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<br />
Verschiedene Ausprägungen des Entlassbriefs, um hier anhand der typeCodes eine bessere Sortierung für den Patienten zu ermöglichen:<br />
11490-0: Ärztlicher Entlassbrief<br />
34105-7: Krankenhausentlassbrief (vorläufige/gekürzte Fassung für den Patienten bei der Entlassung)<br />
18842-5: Finales Krankenhausentlassbrief<br />
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.<br />
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.<br />
58410-2: Vollständiges Blutbild<br />
55429-5: Kleines Blutbild<br />
| betrifft Codesystem | class codes, type codes<br />
| Autor der Anfrage | JC <br />
| 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<br />
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.<br />
<br />
| 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.<br />
| 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<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am|21.2.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 2<br />
| Anfrage eingegangen am|<br />
| Anfrage| es scheint in Deutschland Bestrebungen zu geben, Unfallchirurgie mit der Orthopädie zusammenzulegen.<br />
Ab August 2019 wird es im UKD nur noch die „Klinik für Orthopädie und Unfallchirurgie“ geben.<br />
Ist die Einführung einer weiteren Fachabteilung im DocumentEntry.practiseSettingCode geplant?<br />
In DocumentEntry.authorSpecialty findet sie sich:<br />
Code 512 Anzeigename FA Orthopädie und Unfallchirurgie<br />
| betrifft Codesystem | practiceSettingCode <br />
| Autor der Anfrage | SB<br />
| Diskussion| evtl. practiceSettingCode Chirurgie verwenden, deckt beides ab<br />
| Entscheidung |<br />
| Action Item |<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 29.11.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 3<br />
| Anfrage eingegangen am|<br />
| 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.<br />
Dazu möchten wir das Value Set für XDS-Metadatenattribut formatCode um den folgenden Wert erweitern: urn:gematik:ig:DatensatzPersoenlicheErklaerungen:r3.1<br />
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.<br />
| betrifft Codesystem | formatCode<br />
| Autor der Anfrage | RK<br />
| Diskussion| keine Einwände<br />
| Entscheidung | wir fügen Code hinzu<br />
| Action Item | in ArtDecor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am|13.12.2019<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 5<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Freischaltung der FHIR Schnittstelle in ArtDecor<br />
| betrifft Codesystem | alle<br />
| Autor der Anfrage | SH über Tarik Idris<br />
| Diskussion| <br />
| Entscheidung | wird gemacht<br />
| Action Item | Tarik: FHIR Schnittstelle in ArtDecor freischalten<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 15.11.2019<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 8<br />
| Anfrage eingegangen am| 15.11.2019<br />
| Anfrage| Vorgehensweise für V3 auf eigener WikiSeite beschreiben<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | SL<br />
| Diskussion| befürwortet<br />
| Entscheidung | befürwortet<br />
| Action Item | Anlegen neue Seite im HL7 Wiki ==> Angela, Ziele ==> Angela, allgemeine Weiterentwicklung als Ziel hinzufügen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 13.12.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 9<br />
| Anfrage eingegangen am| 13.12.2019<br />
| Anfrage| Bericht Treffen BVITG, Interopforum, Gematik, Vorabstimmung EPA Version 1.2.2022<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | TI<br />
| 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) <br />
| Entscheidung | über konstruktive Zusammenarbeit wird sich gefreut<br />
| Action Item | keine<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 13.12.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 10<br />
| Anfrage eingegangen am| 12.01.2020<br />
| 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.<br />
https://loinc.org/file-access/download-id/8994/<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | ST<br />
| Diskussion| <br />
| Entscheidung | Gemeinsame Strategietelko zur Zusammenführung LOINC, SNOMED CT, XDT, QMS, KDL deutsche XDS Value Sets am 28.5.2020 10-12 Uhr geplant<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 24.04.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 11<br />
| Anfrage eingegangen am| 07.02.2020<br />
| Anfrage| Zusammenarbeit KBV<br />
| betrifft Codesystem | alle, v.a. format Code<br />
| Autor der Anfrage | RK<br />
| Diskussion| Den MIOs müssen XDS Metadaten zugeordnet werden, v.a. formatCodes<br />
| Entscheidung | Arbeitsgruppe bietet proaktiv Hilfe bzgl. der Metadaten bei KBV an<br />
| Action Item | Mail an Vorstand ==> Mail an KBV (H. Tenkow)<br />
| Bearbeitungsstand | Mail an Vorstand gesendet<br />
| zuletzt bearbeitet am| 07.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 12<br />
| Anfrage eingegangen am| 21.02.2020<br />
| 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<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | RK<br />
| Diskussion| keine Einwände<br />
| Entscheidung | werden aufgenommen<br />
| Action Item | Aufnahme in ArtDecor ==> Angela<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 24.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 13<br />
| Anfrage eingegangen am| 06.03.2020<br />
| Anfrage| Übersetzung der Metadatenbezeichnungen ins Englische<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | SL<br />
| Diskussion| ValueSets sind nur für Deutschland, jeder Dokumentierende sollte über ausreichende Deutschkenntisse verfügen<br />
| Entscheidung | abgelehnt<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 06.03.2020<br />
|- valign="top" <br />
<br />
|- valign="top"<br />
| Anfrage ID| 14<br />
| Anfrage eingegangen am| 24.04.2020<br />
| Anfrage| Neuer FormatCode für eRezept (Daten elektronischer Verordnung) der Gematik<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | RK<br />
| 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<br />
| Entscheidung | urn:gematik:ig:VerordnungsdatensatzMedikation:r4.0<br />
| Action Item | in Art Decor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
<br />
<br />
|- valign="top" <br />
<br />
<br />
| Anfrage ID| 15<br />
| Anfrage eingegangen am| 14.05.2020<br />
| Anfrage| Kommentierung EPA XDS Metadaten<br />
| betrifft Codesystem | fast alle<br />
| Autor der Anfrage | TI<br />
| Diskussion| <br />
| 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<br />
| Action Item | Tarik==> Kommentar an gematik<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.05.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 16<br />
| Anfrage eingegangen am| 14.05.2020<br />
| 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. <br />
| betrifft Codesystem | TypeCode<br />
| Autor der Anfrage | VK<br />
| Diskussion| <br />
| Entscheidung | wird als Beispiel in pathologische Befunde aufgenommen<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
|- valign="top" <br />
<br />
| Anfrage ID| 17<br />
| Anfrage eingegangen am| 14.05.2020<br />
| Anfrage| Am UKHD gibt es ein Zentrum für Seltene Erkrankungen. Dort werden Patienten jeglichen Alters behandelt. <br />
| betrifft Codesystem | PracticeSettingCode<br />
| Autor der Anfrage | VK<br />
| Diskussion| <br />
| 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<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 18<br />
| Anfrage eingegangen am| 26.06.2020<br />
| Anfrage| Code für Erfassung Fall- /Bewegungsdaten<br />
| betrifft Codesystem | Class Code, Type Code<br />
| Autor der Anfrage | AM<br />
| 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<br />
| Entscheidung | keine zusätzlichen Codes<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 20<br />
| Anfrage eingegangen am| 10.07.2020<br />
| 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:<br />
<br />
Unterkategorien von 1a - Code<br />
<br />
Hausarzt/ Hausärztin - practitioner<br />
<br />
Krankenhaus - hospital<br />
<br />
Labor und Humangenetik - laboratory<br />
<br />
Physiotherapeuten - physiotherapy<br />
<br />
Psychotherapeuten - psychotherapy<br />
<br />
Dermatologie - dermatology<br />
<br />
Urologie/Gynäkologie - gynaecology_urology<br />
<br />
Zahnheilkunde und Mund-Kiefer-Gesichtschirurgie - dentistry_oms<br />
<br />
Weitere Fachärzte/ Fachärztinnen - other_medical<br />
<br />
Weitere nicht-ärztliche Berufe - other_non_medical<br />
<br />
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.<br />
<br />
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.<br />
<br />
Für diesen Code soll ein Code-System "Sonstige Berechtigungen ePA" genutzt werden.<br />
| betrifft Codesystem | Anfrage neues Codesystem / ValueSet für Folder<br />
| Autor der Anfrage | JG (Gematik)<br />
| 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<br />
| Entscheidung |Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte<br />
| Action Item | Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte<br />
| 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 <br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 21<br />
| Anfrage eingegangen am| 31.07.2020<br />
| 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:<br />
<br />
"urn:gematik:ig:KinderuntersuchungsheftUntersuchungen:r4.0"<br />
"urn:gematik:ig:KinderuntersuchungsheftTeilnahmekarte:r4.0"<br />
"urn:gematik:ig:KinderuntersuchungsheftNotizen:r4.0"<br />
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.<br />
<br />
<br />
<br />
Als Anzeigename schlage ich vor:<br />
<br />
· Untersuchungen Kinderuntersuchungsheft<br />
<br />
· Teilnahmekarte Kinderuntersuchungsheft<br />
<br />
· Notizen Kinderuntersuchungsheft<br />
| betrifft Codesystem | FormatCodes<br />
| Autor der Anfrage | Gematik<br />
| Diskussion| <br />
| Entscheidung | wird aufgenommen<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 22<br />
| Anfrage eingegangen am| 16.09.2020<br />
| Anfrage| Patientenverfügung als Beispiel für administratives Dokument aufnehmen<br />
| betrifft Codesystem | classCode<br />
| Autor der Anfrage | VB (Uniklinik HD)<br />
| Diskussion| entspricht Mapping in KDL<br />
| Entscheidung | wird als Beispiel hinzugefügt<br />
| Action Item | in ArtDecor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 23<br />
| Anfrage eingegangen am| 18.09.2020<br />
| Anfrage| TypeCode für mikroskopische Bilder<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | VB (Uniklinik HD)<br />
| Diskussion| wenn Ergebnis Mikrobiologie oder Pathologie, dann diesen Code verwenden, ansonsten BILD<br />
| Entscheidung | wenn Ergebnis Mikrobiologie (MKRO) oder Pathologie (PATH) dann diesen Code verwenden, ansonsten BILD<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 24<br />
| Anfrage eingegangen am| 5.11.2020<br />
| 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.<br />
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.<br />
HL7 bildet die Berufsgruppen PP (2 L 82) und KJP (2-L 76) falsch ab, nämlich als Spezialisierung, nicht als Grundberufe.<br />
Die Fachgebiete des neuen Berufs ‚Psychotherapeut*in‘ sind im HL7 nicht abgebildet.<br />
| betrifft Codesystem | authorspecialty<br />
| Autor der Anfrage | BPtK<br />
| Diskussion| <br />
| Entscheidung |Neue Berufsgruppen werden in Authorspecialty aufgenommen.<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 25<br />
| Anfrage eingegangen am| 5.11.2020<br />
| Anfrage| Übernahme der Facharzt- und Schwerpunktscodes aus dem Codesystem der BAEK, da relevante Facharzt - und Schwerpunktscodes fehlen.<br />
| betrifft Codesystem | authorspecialty<br />
| Autor der Anfrage | BAEK<br />
| 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.<br />
| 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<br />
| Action Item | Konzept zur Pflege, Mapping BAEK Codes auf practice Setting Codes wird auch bei KBV veröffentlicht (als FHIR concept map)<br />
| Bearbeitungsstand |erledigt<br />
| zuletzt bearbeitet am| 01.02.2021<br />
<br />
|- valign="top" <br />
| Anfrage ID| 26<br />
| Anfrage eingegangen am| 13.11.2020<br />
| Anfrage| Prozeduren zu Fertilitätsbehandlung in Gebu aufnehmen?<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |nein<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 01.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 27<br />
| Anfrage eingegangen am| 13.11.2020<br />
| Anfrage| Typecode für Erfassung der Dauer der Gebärdendolmetscherunterstützung<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |Abrechnungsdokumente<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 01.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 28<br />
| Anfrage eingegangen am| 10.12.2020<br />
| Anfrage| Classcode für Diagnosenübersichtsblatt<br />
| betrifft Codesystem | classCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |hängt vom UseCase ab<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 01.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 32<br />
| Anfrage eingegangen am| 09.2021<br />
| Anfrage| Aufnahme von Pflegefachmann/-fachfrau, da neuer Ausbildungsberuf<br />
| betrifft Codesystem | Authorspecialty<br />
| Autor der Anfrage | FP<br />
| 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.<br />
| Entscheidung | Konzepte werden wie vorgeschlagen ergänzt, bzw. - bezeichnungen geändert.<br />
| Action Item | Eröffnung version 4 draft des Value Sets ==> Anpassungen in ArtDecor erfolgt<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 15.10.2021<br />
<br />
<br />
|}<br />
<br />
'''Tabelle Aktueller Stand'''<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! width="25%" align="left" | Codesystem<br />
! align="center" | Stand Konzepte<br />
! align="center" | ArtDecor<br />
! align="center" | WikiText<br />
! align="center" | Review durch<br />
<br />
|- valign="top" <br />
| Codesystem | Einleitung<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Sven, Frank<br />
<br />
|- valign="top" <br />
| Codesystem | Vokabular Management<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Sven, Frank<br />
<br />
|- valign="top" <br />
| Codesystem | Confidentiality Code<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Sven, Frank<br />
<br />
|- valign="top" <br />
| Codesystem | AuthorRole<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Angela, Sven<br />
<br />
|- valign="top" <br />
| Codesystem | AuthorSpeciality<br />
| Stand Konzepte | n/a<br />
| ArtDecor | offen<br />
| WikiText | offen<br />
| Review durch | ''Tarik?''<br />
<br />
|- valign="top" <br />
| Codesystem | EventCodeList<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Angela<br />
<br />
|- valign="top" <br />
| Codesystem | ContentTypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Axel<br />
<br />
|- valign="top" <br />
| Codesystem | ClassCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Arnold, Antje<br />
<br />
|- valign="top" <br />
| Codesystem | TypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | Arnold, Antje<br />
<br />
|- valign="top" <br />
| Codesystem | FormatCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | Axel<br />
<br />
|- valign="top" <br />
| Codesystem | HealthcareFacilityTypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | ''Tarik?''<br />
<br />
|- valign="top" <br />
| Codesystem | PracticeSettingCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | Antje, Arnold<br />
<br />
|- valign="top" <br />
| Codesystem | Folder.codeList<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | Angela, Sven<br />
<br />
<br />
|- valign="top" <br />
| Valuesets/ generell| EPA Verwendung<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Erstellung durch | Raik, Christof<br />
<br />
|}<br />
<br />
'''Schritte zur Veröffentlichung v3'''<br />
# Zeitplan (draft) erstellen<br />
#* Anfang Februar Ankündigung<br />
#* Anfang März Kommentierungsstart<br />
#* Anfang April Ende Kommentierung, Anfang Kommentarauflösungs<br />
#* Anfang Juni Veröffentlichung<br />
# 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<br />
# Ankündigung formulieren <br />
# Kapitel zur Verwendung der ValueSets in der EPA schreiben<br />
# Review der Wiki-Texte und AuthorSpecialty Code anpassen<br />
# Change Liste erstellen<br />
# PDF erstellen<br />
# PDF in Wiki und auf IHE-D Seite hochladen/referenzieren<br />
# Kommentare sammeln<br />
# Kommentare auflösen<br />
# Abstimmung zur Veröffentlichung<br />
# Finale Version erstellen und in Wiki und IHE-D Seite hochladen<br />
<br />
Optional:<br />
* Erläuterung zum Zusammenspiel mit FHIR<br />
* Hinweis/kurze Erläuterung der nicht behandelten XDS Metadaten<br />
<br />
'''IG Struktur'''<br />
<br />
# [[ihevs:Einleitung]] (Vorgehen, Ziele, Umgang mit v1, normativ, Delta-Liste?, Änderungen/Pflege)<br />
# [[Ihevs:Vokabular-Management]]<br />
# [[ihevs:DocumentEntry.authorRole]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.authorSpecialty]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.classCode]]<br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.confidentialityCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.eventCodeList]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.formatCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.healthcareFacilityTypeCode]]<br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.languageCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.practiceSettingCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.typeCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:SubmissionSet.contentTypeCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:Folder.codeList]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor<br />
<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.languageCode&diff=75793Ihevs:DocumentEntry.languageCode2021-03-31T15:38:59Z<p>Tidris: /* DocumentEntry.languageCode */ "häufige" Fehler hinzugefügt, Beispiele erweitert</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.languageCode==<br />
<br />
Der languageCode dient der Spezifikation der Sprache, in welcher der wesentliche, menschenlesbare Teil des Dokuments abgefasst ist. <br />
<br />
Der DocumentEntry.languageCode entspricht dem CDA-Element ClinicalDocument/languageCode. Um eine eindeutige Kennzeichnung der Dokumentensprache zu ermöglichen und um die Mappingvorgaben des deutschen Nachrichtenprofils [[XDS-MDM-CDA-Mapping]] zu unterstützen, muss die Sprache im DocumentEntry.languageCode Attribut gemäß IETF (Internet Engineering Task Force) RFC 1766 in Verbindung mit DIN EN ISO 3166-1 ausgedrückt werden. <br />
<br />
DocumentEntry.languageCode besitzt somit ein Format, welches aus zwei Kleinbuchstaben für den Sprachencode ("language") und zwei Großbuchstaben für den Ländercode ("territory") besteht. Die beiden Buchstabengruppen werden dabei durch ein '-' verbunden. Die allgemeine Syntax sieht damit aus wie folgt: „aa-BB“ (laut RFC 1766: <Primary Tag>-<Subtag>).<br />
<br />
Dabei wird zusätzlich die Einschränkung zu RFC 1766 hinzugefügt, dass für das Primary Tag (vor dem Bindestrich) ausschließlich die zweibuchstabigen ISO 639-1 Codes für Sprachen als Kleinbuchstaben verwendet werden dürfen. Das Subtag wird für den languageCode verpflichtend und muss mit DIN EN ISO 3166-1 kodiert werden. Diese zweibuchstabigen Länder-Codes müssen als Großbuchstaben ausgedrückt werden.<br />
<br />
Beispiele für den DocumentEntry.languageCode:<br />
<br />
{| class="hl7table"<br />
|+<br />
!Sprache (Land) !!languageCode<br />
|-<br />
|Deutsch (Deutschland) || de-DE<br />
|-<br />
|Deutsch (Österreich) || de-AT<br />
|-<br />
|Deutsch (Schweiz) || de-CH<br />
|-<br />
|Deutsch (Liechtenstein) || de-LI<br />
|-<br />
|Deutsch (Luxemburg) || de-LU<br />
|-<br />
|Luxemburgisch (Luxemburg) || lb-LU<br />
|-<br />
|Dänisch (Dänemark) || da-DK<br />
|-<br />
|Englisch (Großbritannien)|| en-GB<br />
|-<br />
|Englisch (USA) ||en-US<br />
|-<br />
|Englisch (Kanada) || en-CA<br />
|-<br />
|Englisch (Australien) || en-AU<br />
|-<br />
|Französisch (Frankreich) ||fr-FR<br />
|-<br />
|Französisch (Belgien) ||fr-BE<br />
|-<br />
|Französisch (Schweiz) ||fr-CH<br />
|-<br />
|Französisch (Kanada) || fr-CA<br />
|-<br />
|Französisch (Luxemburg) || fr-LU<br />
|-<br />
|Griechisch (Griechenland) || el-GR<br />
|-<br />
|Italienisch (Schweiz) || it-CH<br />
|}<br />
<br />
Wie man aus obiger Tabelle ersieht, können für ein Land mehrere languageCodes existieren. Der Code dient der Spezifikation der Sprache, in der das Dokument abgefasst ist. D.h., wenn eine Sprache in mehreren Ländern gesprochen wird, so wird durch den Code ausgedrückt, in welcher dieser landes-spezifischen Sprachvarianten das Dokument abgefasst ist. Aus Konsistenzgründen wird aber auch bei Sprachen, die nur in einem Land als amtliche Landessprache genutzt werden, der Landes-Code hinzugefügt.<br />
<br />
Das Value Set für Sprachangaben ist als „open“ definiert. Somit können die Anwender weitere Codes gemäß der festgelegten Regeln hinzuzufügen.<br />
<br />
Nützliche Hinweise für gebräuchliche language/territory Kombinationen und die verwendeten Codes (primary tag/subtag) bietet das entsprechende Chart aus dem Common Locale Data Repository (CLDR). Dadurch können häufig auftretende Fehler vermieden werden, wie zum Beispiel:<br />
* der Landes-Code für Griechenland ist "GR", der Sprach-Code für Griechisch ist aber "el"<br />
* der Landes-Code für Luxemburg ist "LU", der Sprach-Code für Luxemburgisch ist aber "lb" ("lu" ist auch ein valider Sprach-Code, bezeichnet aber Kiluba, eine Bantu-Sprache mit ca. 3 Mio Sprechern)<br />
* der Landes-Code für das Vereinigte Königreich Großbritannien und Nordirland ist "GB", nicht "UK" (auch wenn dieser Code in ISO-3166-1 reserviert ist) - somit ist Britisches Englisch als "en-GB" abzubilden<br />
<br />
===Links===<br />
* HL7 Deutschland: deutsche Nachrichtenprofile: XDS-MDM-CDA-Mapping. Online, verfügbar unter http://wiki.hl7.de/index.php?title=XDS-MDM-CDA-Mapping<br />
* RFC 1766 „Tags for the Identification of Languages“. Online, verfügbar unter https://www.ietf.org/rfc/rfc1766.txt<br />
* DIN EN ISO 3166-1 „Codes für die Namen von Ländern und deren Untereinheiten - Teil 1: Codes für Ländernamen“ . Online, verfügbar unter http://www.beuth.de/de/norm/din-en-iso-3166-1/215472359?SearchID=959804312<br />
* IETF „Tags for Identifying Languages“ . Online, verfügbar unter http://tools.ietf.org/html/bcp47<br />
* CLDR „Language-Territory Information“ . Online, verfügbar unter http://www.unicode.org/cldr/charts/latest/supplemental/language_territory_information.html<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|languageCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.author&diff=75783Ihevs:DocumentEntry.author2021-03-19T12:46:19Z<p>Tidris: authorSpecialty Code System Herkunft hinzugefügt</p>
<hr />
<div>{{DocumentPart}}<br />
<br />
==DocumentEntry.author==<br />
Die IHE Document Sharing Metadaten erlauben die Angabe mehrerer Autoren pro Dokument. Der Begriff Autor umfasst dabei alle aktiv an der Dokumentenerstellung beteiligten Personen und Geräte. Somit kann nicht nur der klassische Primärautor abgebildet werden, der die Sätze des Dokumententexts formuliert hat, sondern auch die Assistenzärztin, die die Messung durchgeführt hat, der Diktierdienst, die Spracherkennungssoftware oder auch ein Verwandter der die Anamneseinformationen beigesteuert hat. Welche dieser Teilnehmer sinnvollerweise als Autor in den Dokumentenmetadaten abgebildet werden sollte, ist vom Anwendungsfall abhängig und muss von der Affinity Domain entschieden werden.<br />
<br />
Der Autor hat folgende (Sub-)Attribute:<br />
* 0 oder 1 '''authorPerson'''<br />
* 0, 1 oder mehrere '''authorInstitution'''<br />
* 0, 1 oder mehrere '''authorRole'''<br />
* 0, 1 oder mehrere '''authorSpecialty'''<br />
* 0, 1 oder mehrere '''authorTelecommunication'''<br />
<br />
Der Autor wird primär über das authorPerson Subattribut bestimmt. Wenn vorhanden, muss zumindest der Nachname/Gerätename oder ein Identifier angegeben werden. Wenn diese Informationen nicht verfügbar sind oder (z.B. aus Datenschutzgründen) nicht strukturiert übertragen und gespeichert werden sollen, kann das authorPerson Subattribut auch vollständig entfallen. Die anderen Subattribute (z.B. authorRole und authorSpecialty) beziehen sich dann trotzdem auf die unbenannte authorPerson. authorRole und authorSpecialty beziehen sich nie auf die authorInstitution.<br />
<br />
===DocumentEntry.authorRole===<br />
<br />
Das optionale Attribut '''authorRole''' kann für jeden Autor separat angegeben werden und darf mehrfach vorhanden sein. Es beschreibt eine spezifische Rolle des Autors (AuthorPerson). Dies kann entweder eine Rolle im durch das Dokument beschriebenen Prozess sein (z.B. der Entlassbrief dreht sich um einen Entlass-Prozess, in dem ein Arzt die Rolle "Entlassender" innehat) oder es kann eine prozess- und behandlungsunabhängige Rolle bezogen auf den Patienten sein (z.B. "Hausarzt"). Auf die Hinzunahme der Rolle "Facharzt" wurde bewusst verzichtet, da dies schon über das Value Set authorSpecialty abgedeckt ist.<br />
<br />
Für die Verwendung im authorRole Subattribut wurden dementsprechend zwei Code Systeme entwickelt, das eine für Prozessrollen, das andere für Patientenbeziehungsrollen. Die Prozessrollen orientieren sich an mehreren HL7v2 und v3 Code Systemen (ParticipationType, ParticipationFunction, Table 443), sind jedoch verallgemeinert um sie auch für nicht-ärztliche Autoren nutzen zu können. Zur Unterscheidung eines durchführenden Arztes von einer durchführenden Pflegekraft kann die authorSpecialty verwendet werden.<br />
<br />
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.30&effectiveDate=2018-07-13T13:12:46&language=de-DE ART-DECOR]] zuzugreifen.<br />
<br />
{{ :1.2.276.0.76.11.30/dynamic }}<br />
<br />
===DocumentEntry.authorSpecialty===<br />
<br />
Das Attribut authorSpecialty gibt die Spezialisierung des Autors an, unter der der Autor das Dokument verfasst hat. Beispiele für Spezialisierung können bestimmte Facharzttitel sein, die der Autor besitzt, wie z.B. Facharzt für Psychiatrie oder Facharzt für Innere Medizin. Das Codesystem für ärztliche Spezialisierungen bildet die möglichen ärztlichen Facharztausbildungen und Schwerpunkte/Teilgebiete ab. Auf die Aufnahme von Zusatzbezeichnungen wurde verzichtet. Die Liste der fachärztlichen Titel wurde von der Bundesärztekammer bereitgestellt und mit der Kassenärztlichen Bundesvereinigung abgestimmt.<br />
<br />
Neben den ärztlichen Spezialisierungen können aber auch Qualifikationen nicht-ärztlicher Autoren angegeben werden. Beispielsweise kann es sinnvoll sein, bei einem Autor anzugeben, dass dieser Lehrer, Psychologe oder Logopäde ist. Hierzu wurde von der Arbeitsgruppe ein eigenes Codesystem entwickelt, das typische Berufe des Gesundheitswesens enthält. Quellen hierfür waren ein Codesystem des ZTGs in Bochum und die Internetseiten des Arbeitsamtes. Alle anderen Berufe wurden in grob granulare Berufsgruppen wie Umwelt, Sprachen oder Reinigung zusammengefasst. Dadurch kann, je nach benötigten Detailgrad und je nach Verfügbarkeit der Informationen die Spezialisierung sehr grob (z.B. "Medizintechnik, Laboranalyse") oder sehr feingranular (z.B. "Medizinisch-Technischer Radiologieassistent") abgebildet werden.<br />
<br />
Die authorSpecialty sollte nicht mit dem practiceSettingCode verwechselt werden. Der practiceSettingCode gibt an, in welcher Art von Abteilung das Dokument verfasst wurde. Die authorSpecialty gibt die Qualifikation, die der Autor in dieser Abteilung hat, an. Beispielsweise könnte ein Dokument, das von einer Pflegekraft in einer Abteilung für Innere Medizin verfasst wurde, den practiceSettingCode "Innere Medizin" und die authorSpecialty "Gesundheits- und Krankenpfleger" erhalten.<br />
<br />
Alle Specialties wurden einheitlich in der männlichen Form stellvertretend für alle Geschlechter benannt.<br />
<br />
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.31&effectiveDate=2018-07-13T13:22:08&language=de-DE ART-DECOR]] zuzugreifen.<br />
<br />
{{ :1.2.276.0.76.11.31/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|authorRole]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.author&diff=75781Ihevs:DocumentEntry.author2021-03-19T12:27:52Z<p>Tidris: /* DocumentEntry.authorSpecialty */</p>
<hr />
<div>{{DocumentPart}}<br />
<br />
==DocumentEntry.author==<br />
Die IHE Document Sharing Metadaten erlauben die Angabe mehrerer Autoren pro Dokument. Der Begriff Autor umfasst dabei alle aktiv an der Dokumentenerstellung beteiligten Personen und Geräte. Somit kann nicht nur der klassische Primärautor abgebildet werden, der die Sätze des Dokumententexts formuliert hat, sondern auch die Assistenzärztin, die die Messung durchgeführt hat, der Diktierdienst, die Spracherkennungssoftware oder auch ein Verwandter der die Anamneseinformationen beigesteuert hat. Welche dieser Teilnehmer sinnvollerweise als Autor in den Dokumentenmetadaten abgebildet werden sollte, ist vom Anwendungsfall abhängig und muss von der Affinity Domain entschieden werden.<br />
<br />
Der Autor hat folgende (Sub-)Attribute:<br />
* 0 oder 1 '''authorPerson'''<br />
* 0, 1 oder mehrere '''authorInstitution'''<br />
* 0, 1 oder mehrere '''authorRole'''<br />
* 0, 1 oder mehrere '''authorSpecialty'''<br />
* 0, 1 oder mehrere '''authorTelecommunication'''<br />
<br />
Der Autor wird primär über das authorPerson Subattribut bestimmt. Wenn vorhanden, muss zumindest der Nachname/Gerätename oder ein Identifier angegeben werden. Wenn diese Informationen nicht verfügbar sind oder (z.B. aus Datenschutzgründen) nicht strukturiert übertragen und gespeichert werden sollen, kann das authorPerson Subattribut auch vollständig entfallen. Die anderen Subattribute (z.B. authorRole und authorSpecialty) beziehen sich dann trotzdem auf die unbenannte authorPerson. authorRole und authorSpecialty beziehen sich nie auf die authorInstitution.<br />
<br />
===DocumentEntry.authorRole===<br />
<br />
Das optionale Attribut '''authorRole''' kann für jeden Autor separat angegeben werden und darf mehrfach vorhanden sein. Es beschreibt eine spezifische Rolle des Autors (AuthorPerson). Dies kann entweder eine Rolle im durch das Dokument beschriebenen Prozess sein (z.B. der Entlassbrief dreht sich um einen Entlass-Prozess, in dem ein Arzt die Rolle "Entlassender" innehat) oder es kann eine prozess- und behandlungsunabhängige Rolle bezogen auf den Patienten sein (z.B. "Hausarzt"). Auf die Hinzunahme der Rolle "Facharzt" wurde bewusst verzichtet, da dies schon über das Value Set authorSpecialty abgedeckt ist.<br />
<br />
Für die Verwendung im authorRole Subattribut wurden dementsprechend zwei Code Systeme entwickelt, das eine für Prozessrollen, das andere für Patientenbeziehungsrollen. Die Prozessrollen orientieren sich an mehreren HL7v2 und v3 Code Systemen (ParticipationType, ParticipationFunction, Table 443), sind jedoch verallgemeinert um sie auch für nicht-ärztliche Autoren nutzen zu können. Zur Unterscheidung eines durchführenden Arztes von einer durchführenden Pflegekraft kann die authorSpecialty verwendet werden.<br />
<br />
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.30&effectiveDate=2018-07-13T13:12:46&language=de-DE ART-DECOR]] zuzugreifen.<br />
<br />
{{ :1.2.276.0.76.11.30/dynamic }}<br />
<br />
===DocumentEntry.authorSpecialty===<br />
<br />
Das Attribut authorSpecialty gibt die Spezialisierung des Autors an, unter der der Autor das Dokument verfasst hat. Beispiele für Spezialisierung können bestimmte Facharzttitel sein, die der Autor besitzt, wie z.B. Facharzt für Psychiatrie oder Facharzt für Innere Medizin. Das Codesystem für ärztliche Spezialisierungen bildet die möglichen ärztlichen Facharztausbildungen, die es derzeit in Deutschland gibt, ab. Auf die Aufnahme von Zusatzbezeichnungen wurde verzichtet.<br />
Neben den ärztlichen Spezialisierungen können aber auch Qualifikationen nicht-ärztlicher Autoren angegeben werden. Beispielsweise kann es sinnvoll sein, bei einem Autor anzugeben, dass dieser Lehrer, Psychologe oder Logopäde ist. Hierzu wurde von der Arbeitsgruppe ein eigenes Codesystem entwickelt, das typische Berufe des Gesundheitswesens enthält. Quellen hierfür waren ein Codesystem des ZTGs in Bochum und die Internetseiten des Arbeitsamtes. Alle anderen Berufe wurden in grob granulare Berufsgruppen wie Umwelt, Sprachen oder Reinigung zusammengefasst. Dadurch kann, je nach benötigten Detailgrad und je nach Verfügbarkeit der Informationen die Spezialisierung sehr grob (z.B. "Medizintechnik, Laboranalyse") oder sehr feingranular (z.B. "Medizinisch-Technischer Radiologieassistent") abgebildet werden.<br />
<br />
Die authorSpecialty sollte nicht mit dem practiceSettingCode verwechselt werden. Der practiceSettingCode gibt an, in welcher Art von Abteilung das Dokument verfasst wurde. Die authorSpecialty gibt die Qualifikation, die der Autor in dieser Abteilung hat, an. Beispielsweise könnte ein Dokument, das von einer Pflegekraft in einer Abteilung für Innere Medizin verfasst wurde, den practiceSettingCode "Innere Medizin" und die authorSpecialty "Gesundheits- und Krankenpfleger" erhalten.<br />
<br />
Alle Specialties wurden einheitlich in der männlichen Form stellvertretend für alle Geschlechter benannt.<br />
<br />
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.31&effectiveDate=2018-07-13T13:22:08&language=de-DE ART-DECOR]] zuzugreifen.<br />
<br />
{{ :1.2.276.0.76.11.31/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|authorRole]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=IHE_DE_ValueSets_Action_Items&diff=75570IHE DE ValueSets Action Items2021-01-08T13:00:57Z<p>Tidris: </p>
<hr />
<div>'''Tabelle Änderungsanfragen'''<br />
<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! align="left" | Anfrage ID<br />
! align="left" | Anfrage eingegangen am<br />
! align="left" | Anfrage<br />
! align="center" | betrifft Codesystem<br />
! align="center" | Autor der Anfrage<br />
! align="center" | Diskussion<br />
! align="center" | Entscheidung<br />
! align="center" | Action Item<br />
! align="center" | Bearbeitungsstand<br />
! align="center" | zuletzt bearbeitet am<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 4<br />
| Anfrage eingegangen am|<br />
| Anfrage| Arbeitsgruppe „Weiterentwicklung Klinische Dokumentenklassenliste (KDL)“.<br />
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.<br />
Das aktuelle Mapping liegt der Geschäftsstelle vor und ist bisher mit Angela Merzweiler gemeinsam abgestimmt wurden.<br />
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.<br />
Beispiel:<br />
Ich möchte daher anregen bzw. beantragen, dass die KDL im ersten Schritt offiziell als CodeSystem in das Value Set „EventCodeList“ aufgenommen wird.<br />
Damit haben Hersteller von IHE-konformen Archiven, o. ä. die Möglichkeit, wenigstens die Klassifizierung des Dokuments mittels KDL offiziell abzubilden.<br />
· Code System Name: Klinische Dokumentenklassen Liste (KDL)<br />
· Code System ID: 1.2.276.0.76.3.1.191.0.1.1, versionsabhängig<br />
· Kommentar: Klassifizierung von Dokumenten und Daten als Beispiele für die Value Sets classCode und typeCode<br />
Mittelfristig soll die KDL zu einem terminologischen System mit ontologischem Ansatz ausgebaut werden.<br />
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.<br />
Ich freue mich, wenn wir es gemeinsam schaffen, dazu einen persönlichen Termin für ein Arbeitstreffen zu finden.<br />
| betrifft Codesystem | eventCode<br />
| Autor der Anfrage | AMü<br />
| 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<br />
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)<br />
| Entscheidung | grundsätzlich zugestimmt, neues Valueset <br />
| Action Item | Annett=> noch OID für übergeordnetes Value Set KDL beantragen, dann kann OID für ValueSet in ArtDecor angepasst werden (im Moment nur ValueSet für KDL 2020, alle=> Mapping prüfen<br />
| Bearbeitungsstand | in Bearbeitung (Annett)<br />
| zuletzt bearbeitet am| 02.10.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 6<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Ansatz Canonical URLs diskutieren<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | Tarik Idris<br />
| Diskussion| Ziel: Gute Einfügung in FHIR Umgebung<br />
| Entscheidung | Für V3 alle URNs durch URLs ersetzen <br />
| 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 <br />
| Bearbeitungsstand | in Bearbeitung (Angela)<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 7<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Deutscher Implementation Guide für MHD Profile mit Verweis auf unsere Valuesets<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | SH über Tarik<br />
| 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 <br />
| 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 <br />
| Action Item | Simone um Referenz der Codes in Deutschen Basisprofilguideline bitten <br />
| Bearbeitungsstand | als Issues in Gitlab eingetragen, im Simplifier sichtbar https://simplifier.net/basisprofil-de-r4/~resources?category=ValueSet&sortBy=RankScore_desc ==> (Angela)<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 19<br />
| Anfrage eingegangen am| 10.07.2020<br />
| 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<br />
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:<br />
Bestehenden Code ALLG - „Allgemeinmedizin“ neu bezeichnen als „Facharzt für Allgemeinmedizin<br />
(Hausarzt)“<br />
2. Neuen Code einführen für „Praktischer Arzt/Arzt (Hausarzt)“. Vorschlag: PRAK<br />
3. Neuen Code einführen für „Hausärztlich tätiger Internist (Hausarzt)“. Vorschlag: HINT<br />
4. Bestehenden Codes ORTH neu bezeichnen als „Orthopädie und Unfallchirurgie“.<br />
5. Neuen Code einführen für „Rheumatologie (Orthopädie)“. Vorschlag: ORRH.<br />
6. Neuen Code einführen für „Infektiologie“. Vorschlag: INFK<br />
7. Neuen Code einführen für „Kinder-Pneumologie“. Vorschlag: KIPN<br />
8. Neuen Code einführen für „Nervenheilkunde/Neurologie und Psychiatrie“. Vorschlag: NERV<br />
9. Neuen Code einführen für „Psychotherapeutisch tätiger Arzt“. Vorschlag: PTAR<br />
10. Neuen Code einführen für „Psychologischer Psychotherapeut“. Vorschlag: PPTH<br />
11.Neuen Code einführen für „Kinder- und Jugendlichen-Psychotherapeut“. Vorschlag: KJPP<br />
| betrifft Codesystem | Practice Setting Code<br />
| Autor der Anfrage | SR (KBV)<br />
| 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.<br />
| 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).<br />
| Action Item | Mapping prüfen und in Implementation Guide eintragen.<br />
| 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.<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 24<br />
| Anfrage eingegangen am| 5.11.2020<br />
| 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.<br />
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.<br />
HL7 bildet die Berufsgruppen PP (2 L 82) und KJP (2-L 76) falsch ab, nämlich als Spezialisierung, nicht als Grundberufe.<br />
Die Fachgebiete des neuen Berufs ‚Psychotherapeut*in‘ sind im HL7 nicht abgebildet.<br />
| betrifft Codesystem | authorspecialty<br />
| Autor der Anfrage | BPtK<br />
| Diskussion| <br />
| Entscheidung |Neue Berufsgruppen werden in Authorspecialty aufgenommen.<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 25<br />
| Anfrage eingegangen am| 5.11.2020<br />
| Anfrage| Übernahme der Facharzt- und Schwerpunktscodes aus dem Codesystem der BKAe, da relevante Facharzeit - und Schwerpunktscodes fehlen.<br />
| betrifft Codesystem | authorspecialty<br />
| Autor der Anfrage | BKAe<br />
| 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.<br />
| Entscheidung |Die BKAe stellt uns die Codes möglichst als CSV oder Excelfile zur Verfügung. Die BKAe übernimmt die Pflege und Bereitstellung der Codes, so dass sie von uns in ArtDecor eingetragen werden können. Auch TG Codes<br />
| Action Item | BKAE==> Bereitstellung der Codeliste, Konzept zur Pflege, Mapping BAEK Codes auf practice Setting Codes wird auch bei KBV veröffentlicht (als FHIR concept map)<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 26<br />
| Anfrage eingegangen am| 13.11.2020<br />
| Anfrage| Prozeduren zu Fertilitätsdiagnostik und Behandlung in Gebu aufnehmen?<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |<br />
| Action Item | <br />
| Bearbeitungsstand | neu<br />
| zuletzt bearbeitet am| 13.11.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 27<br />
| Anfrage eingegangen am| 13.11.2020<br />
| Anfrage| Typecode für Gebärdendolmetscheunterstützung<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |<br />
| Action Item | <br />
| Bearbeitungsstand | neu<br />
| zuletzt bearbeitet am| 13.11.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 28<br />
| Anfrage eingegangen am| 10.12.2020<br />
| Anfrage| Classcode für Diagnosenübersichtsblatt<br />
| betrifft Codesystem | classCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |<br />
| Action Item | <br />
| Bearbeitungsstand | neu<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
|}<br />
<br />
'''Tabelle abgeschlossene Änderungsanfragen'''<br />
<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! align="left" | Anfrage ID<br />
! align="left" | Anfrage eingegangen am<br />
! align="left" | Anfrage<br />
! align="center" | betrifft Codesystem<br />
! align="center" | Autor der Anfrage<br />
! align="center" | Diskussion<br />
! align="center" | Entscheidung<br />
! align="center" | Action Item<br />
! align="center" | Bearbeitungsstand<br />
! align="center" | zuletzt bearbeitet am<br />
<br />
|- valign="top" <br />
| Anfrage ID| 1<br />
| Anfrage eingegangen am|<br />
| 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:<br />
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<br />
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.<br />
Wir haben somit eine Mischung aus IHE-D-Codes und IHE-PCC/LAB-LOINC-Codes. Inhaltlich/semantisch überschneidet sich das recht munter. Fragen:<br />
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?<br />
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?<br />
Folgende Codes werden vermisst:<br />
im AOK-Projekt haben wir in Ergänzung zu den IHE-D-Codes die folgenden LOINC-Codes als typeCodes verwendet:<br />
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)<br />
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<br />
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<br />
Verschiedene Ausprägungen des Entlassbriefs, um hier anhand der typeCodes eine bessere Sortierung für den Patienten zu ermöglichen:<br />
11490-0: Ärztlicher Entlassbrief<br />
34105-7: Krankenhausentlassbrief (vorläufige/gekürzte Fassung für den Patienten bei der Entlassung)<br />
18842-5: Finales Krankenhausentlassbrief<br />
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.<br />
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.<br />
58410-2: Vollständiges Blutbild<br />
55429-5: Kleines Blutbild<br />
| betrifft Codesystem | class codes, type codes<br />
| Autor der Anfrage | JC <br />
| 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<br />
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.<br />
<br />
| 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.<br />
| 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<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am|21.2.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 2<br />
| Anfrage eingegangen am|<br />
| Anfrage| es scheint in Deutschland Bestrebungen zu geben, Unfallchirurgie mit der Orthopädie zusammenzulegen.<br />
Ab August 2019 wird es im UKD nur noch die „Klinik für Orthopädie und Unfallchirurgie“ geben.<br />
Ist die Einführung einer weiteren Fachabteilung im DocumentEntry.practiseSettingCode geplant?<br />
In DocumentEntry.authorSpecialty findet sie sich:<br />
Code 512 Anzeigename FA Orthopädie und Unfallchirurgie<br />
| betrifft Codesystem | practiceSettingCode <br />
| Autor der Anfrage | SB<br />
| Diskussion| evtl. practiceSettingCode Chirurgie verwenden, deckt beides ab<br />
| Entscheidung |<br />
| Action Item |<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 29.11.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 3<br />
| Anfrage eingegangen am|<br />
| 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.<br />
Dazu möchten wir das Value Set für XDS-Metadatenattribut formatCode um den folgenden Wert erweitern: urn:gematik:ig:DatensatzPersoenlicheErklaerungen:r3.1<br />
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.<br />
| betrifft Codesystem | formatCode<br />
| Autor der Anfrage | RK<br />
| Diskussion| keine Einwände<br />
| Entscheidung | wir fügen Code hinzu<br />
| Action Item | in ArtDecor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am|13.12.2019<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 5<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Freischaltung der FHIR Schnittstelle in ArtDecor<br />
| betrifft Codesystem | alle<br />
| Autor der Anfrage | SH über Tarik Idris<br />
| Diskussion| <br />
| Entscheidung | wird gemacht<br />
| Action Item | Tarik: FHIR Schnittstelle in ArtDecor freischalten<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 15.11.2019<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 8<br />
| Anfrage eingegangen am| 15.11.2019<br />
| Anfrage| Vorgehensweise für V3 auf eigener WikiSeite beschreiben<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | SL<br />
| Diskussion| befürwortet<br />
| Entscheidung | befürwortet<br />
| Action Item | Anlegen neue Seite im HL7 Wiki ==> Angela, Ziele ==> Angela, allgemeine Weiterentwicklung als Ziel hinzufügen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 13.12.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 9<br />
| Anfrage eingegangen am| 13.12.2019<br />
| Anfrage| Bericht Treffen BVITG, Interopforum, Gematik, Vorabstimmung EPA Version 1.2.2022<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | TI<br />
| 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) <br />
| Entscheidung | über konstruktive Zusammenarbeit wird sich gefreut<br />
| Action Item | keine<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 13.12.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 10<br />
| Anfrage eingegangen am| 12.01.2020<br />
| 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.<br />
https://loinc.org/file-access/download-id/8994/<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | ST<br />
| Diskussion| <br />
| Entscheidung | Gemeinsame Strategietelko zur Zusammenführung LOINC, SNOMED CT, XDT, QMS, KDL deutsche XDS Value Sets am 28.5.2020 10-12 Uhr geplant<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 24.04.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 11<br />
| Anfrage eingegangen am| 07.02.2020<br />
| Anfrage| Zusammenarbeit KBV<br />
| betrifft Codesystem | alle, v.a. format Code<br />
| Autor der Anfrage | RK<br />
| Diskussion| Den MIOs müssen XDS Metadaten zugeordnet werden, v.a. formatCodes<br />
| Entscheidung | Arbeitsgruppe bietet proaktiv Hilfe bzgl. der Metadaten bei KBV an<br />
| Action Item | Mail an Vorstand ==> Mail an KBV (H. Tenkow)<br />
| Bearbeitungsstand | Mail an Vorstand gesendet<br />
| zuletzt bearbeitet am| 07.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 12<br />
| Anfrage eingegangen am| 21.02.2020<br />
| 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<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | RK<br />
| Diskussion| keine Einwände<br />
| Entscheidung | werden aufgenommen<br />
| Action Item | Aufnahme in ArtDecor ==> Angela<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 24.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 13<br />
| Anfrage eingegangen am| 06.03.2020<br />
| Anfrage| Übersetzung der Metadatenbezeichnungen ins Englische<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | SL<br />
| Diskussion| ValueSets sind nur für Deutschland, jeder Dokumentierende sollte über ausreichende Deutschkenntisse verfügen<br />
| Entscheidung | abgelehnt<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 06.03.2020<br />
|- valign="top" <br />
<br />
|- valign="top"<br />
| Anfrage ID| 14<br />
| Anfrage eingegangen am| 24.04.2020<br />
| Anfrage| Neuer FormatCode für eRezept (Daten elektronischer Verordnung) der Gematik<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | RK<br />
| 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<br />
| Entscheidung | urn:gematik:ig:VerordnungsdatensatzMedikation:r4.0<br />
| Action Item | in Art Decor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
<br />
<br />
|- valign="top" <br />
<br />
<br />
| Anfrage ID| 15<br />
| Anfrage eingegangen am| 14.05.2020<br />
| Anfrage| Kommentierung EPA XDS Metadaten<br />
| betrifft Codesystem | fast alle<br />
| Autor der Anfrage | TI<br />
| Diskussion| <br />
| 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<br />
| Action Item | Tarik==> Kommentar an gematik<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.05.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 16<br />
| Anfrage eingegangen am| 14.05.2020<br />
| 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. <br />
| betrifft Codesystem | TypeCode<br />
| Autor der Anfrage | VK<br />
| Diskussion| <br />
| Entscheidung | wird als Beispiel in pathologische Befunde aufgenommen<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
|- valign="top" <br />
<br />
| Anfrage ID| 17<br />
| Anfrage eingegangen am| 14.05.2020<br />
| Anfrage| Am UKHD gibt es ein Zentrum für Seltene Erkrankungen. Dort werden Patienten jeglichen Alters behandelt. <br />
| betrifft Codesystem | PracticeSettingCode<br />
| Autor der Anfrage | VK<br />
| Diskussion| <br />
| 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<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 18<br />
| Anfrage eingegangen am| 26.06.2020<br />
| Anfrage| Code für Erfassung Fall- /Bewegungsdaten<br />
| betrifft Codesystem | Class Code, Type Code<br />
| Autor der Anfrage | AM<br />
| 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<br />
| Entscheidung | keine zusätzlichen Codes<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 20<br />
| Anfrage eingegangen am| 10.07.2020<br />
| 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:<br />
<br />
Unterkategorien von 1a - Code<br />
<br />
Hausarzt/ Hausärztin - practitioner<br />
<br />
Krankenhaus - hospital<br />
<br />
Labor und Humangenetik - laboratory<br />
<br />
Physiotherapeuten - physiotherapy<br />
<br />
Psychotherapeuten - psychotherapy<br />
<br />
Dermatologie - dermatology<br />
<br />
Urologie/Gynäkologie - gynaecology_urology<br />
<br />
Zahnheilkunde und Mund-Kiefer-Gesichtschirurgie - dentistry_oms<br />
<br />
Weitere Fachärzte/ Fachärztinnen - other_medical<br />
<br />
Weitere nicht-ärztliche Berufe - other_non_medical<br />
<br />
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.<br />
<br />
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.<br />
<br />
Für diesen Code soll ein Code-System "Sonstige Berechtigungen ePA" genutzt werden.<br />
| betrifft Codesystem | Anfrage neues Codesystem / ValueSet für Folder<br />
| Autor der Anfrage | JG (Gematik)<br />
| 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<br />
| Entscheidung |Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte<br />
| Action Item | Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte<br />
| 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 <br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 21<br />
| Anfrage eingegangen am| 31.07.2020<br />
| 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:<br />
<br />
"urn:gematik:ig:KinderuntersuchungsheftUntersuchungen:r4.0"<br />
"urn:gematik:ig:KinderuntersuchungsheftTeilnahmekarte:r4.0"<br />
"urn:gematik:ig:KinderuntersuchungsheftNotizen:r4.0"<br />
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.<br />
<br />
<br />
<br />
Als Anzeigename schlage ich vor:<br />
<br />
· Untersuchungen Kinderuntersuchungsheft<br />
<br />
· Teilnahmekarte Kinderuntersuchungsheft<br />
<br />
· Notizen Kinderuntersuchungsheft<br />
| betrifft Codesystem | FormatCodes<br />
| Autor der Anfrage | Gematik<br />
| Diskussion| <br />
| Entscheidung | wird aufgenommen<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 22<br />
| Anfrage eingegangen am| 16.09.2020<br />
| Anfrage| Patientenverfügung als Beispiel für administratives Dokument aufnehmen<br />
| betrifft Codesystem | classCode<br />
| Autor der Anfrage | VB (Uniklinik HD)<br />
| Diskussion| entspricht Mapping in KDL<br />
| Entscheidung | wird als Beispiel hinzugefügt<br />
| Action Item | in ArtDecor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 23<br />
| Anfrage eingegangen am| 18.09.2020<br />
| Anfrage| TypeCode für mikroskopische Bilder<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | VB (Uniklinik HD)<br />
| Diskussion| wenn Ergebnis Mikrobiologie oder Pathologie, dann diesen Code verwenden, ansonsten BILD<br />
| Entscheidung | wenn Ergebnis Mikrobiologie (MKRO) oder Pathologie (PATH) dann diesen Code verwenden, ansonsten BILD<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
<br />
|}<br />
<br />
'''Tabelle Aktueller Stand'''<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! width="25%" align="left" | Codesystem<br />
! align="center" | Stand Konzepte<br />
! align="center" | ArtDecor<br />
! align="center" | WikiText<br />
! align="center" | Review durch<br />
<br />
|- valign="top" <br />
| Codesystem | Einleitung<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | Vokabular Management<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | Confidentiality Code<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | AuthorRole<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | AuthorSpeciality<br />
| Stand Konzepte | n/a<br />
| ArtDecor | offen<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | EventCodeList<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | ContentTypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | ClassCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | TypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | FormatCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | HealthcareFacilityTypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | PracticeSettingCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | Folder.codeList<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | <br />
<br />
|}<br />
<br />
'''Schritte zur Veröffentlichung v3'''<br />
# Zeitplan (draft) erstellen<br />
#* Anfang Februar Ankündigung<br />
#* Anfang März Kommentierungsstart<br />
#* Anfang April Ende Kommentierung, Anfang Kommentarauflösungs<br />
#* Anfang Juni Veröffentlichung<br />
# 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<br />
# Ankündigung formulieren<br />
# Review der Wiki-Texte und AuthorSpecialty Code anpassen<br />
# Change Liste erstellen<br />
# PDF erstellen<br />
# PDF in Wiki und auf IHE-D Seite hochladen/referenzieren<br />
# Kommentare sammeln<br />
# Kommentare auflösen<br />
# Abstimmung zur Veröffentlichung<br />
# Finale Version erstellen und in Wiki und IHE-D Seite hochladen<br />
<br />
Optional:<br />
* Erläuterung zum Zusammenspiel mit FHIR<br />
* Hinweis/kurze Erläuterung der nicht behandelten XDS Metadaten<br />
<br />
'''IG Struktur'''<br />
<br />
# [[ihevs:Einleitung]] (Vorgehen, Ziele, Umgang mit v1, normativ, Delta-Liste?, Änderungen/Pflege)<br />
# [[Ihevs:Vokabular-Management]]<br />
# [[ihevs:DocumentEntry.authorRole]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.authorSpecialty]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.classCode]]<br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.confidentialityCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.eventCodeList]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.formatCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.healthcareFacilityTypeCode]]<br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.languageCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.practiceSettingCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.typeCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:SubmissionSet.contentTypeCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:Folder.codeList]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor<br />
<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=IHE_DE_ValueSets_Action_Items&diff=75569IHE DE ValueSets Action Items2021-01-08T12:53:53Z<p>Tidris: </p>
<hr />
<div>'''Tabelle Änderungsanfragen'''<br />
<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! align="left" | Anfrage ID<br />
! align="left" | Anfrage eingegangen am<br />
! align="left" | Anfrage<br />
! align="center" | betrifft Codesystem<br />
! align="center" | Autor der Anfrage<br />
! align="center" | Diskussion<br />
! align="center" | Entscheidung<br />
! align="center" | Action Item<br />
! align="center" | Bearbeitungsstand<br />
! align="center" | zuletzt bearbeitet am<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 4<br />
| Anfrage eingegangen am|<br />
| Anfrage| Arbeitsgruppe „Weiterentwicklung Klinische Dokumentenklassenliste (KDL)“.<br />
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.<br />
Das aktuelle Mapping liegt der Geschäftsstelle vor und ist bisher mit Angela Merzweiler gemeinsam abgestimmt wurden.<br />
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.<br />
Beispiel:<br />
Ich möchte daher anregen bzw. beantragen, dass die KDL im ersten Schritt offiziell als CodeSystem in das Value Set „EventCodeList“ aufgenommen wird.<br />
Damit haben Hersteller von IHE-konformen Archiven, o. ä. die Möglichkeit, wenigstens die Klassifizierung des Dokuments mittels KDL offiziell abzubilden.<br />
· Code System Name: Klinische Dokumentenklassen Liste (KDL)<br />
· Code System ID: 1.2.276.0.76.3.1.191.0.1.1, versionsabhängig<br />
· Kommentar: Klassifizierung von Dokumenten und Daten als Beispiele für die Value Sets classCode und typeCode<br />
Mittelfristig soll die KDL zu einem terminologischen System mit ontologischem Ansatz ausgebaut werden.<br />
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.<br />
Ich freue mich, wenn wir es gemeinsam schaffen, dazu einen persönlichen Termin für ein Arbeitstreffen zu finden.<br />
| betrifft Codesystem | eventCode<br />
| Autor der Anfrage | AMü<br />
| 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<br />
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)<br />
| Entscheidung | grundsätzlich zugestimmt, neues Valueset <br />
| Action Item | Annett=> noch OID für übergeordnetes Value Set KDL beantragen, dann kann OID für ValueSet in ArtDecor angepasst werden (im Moment nur ValueSet für KDL 2020, alle=> Mapping prüfen<br />
| Bearbeitungsstand | in Bearbeitung (Annett)<br />
| zuletzt bearbeitet am| 02.10.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 6<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Ansatz Canonical URLs diskutieren<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | Tarik Idris<br />
| Diskussion| Ziel: Gute Einfügung in FHIR Umgebung<br />
| Entscheidung | Für V3 alle URNs durch URLs ersetzen <br />
| 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 <br />
| Bearbeitungsstand | in Bearbeitung (Angela)<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 7<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Deutscher Implementation Guide für MHD Profile mit Verweis auf unsere Valuesets<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | SH über Tarik<br />
| 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 <br />
| 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 <br />
| Action Item | Simone um Referenz der Codes in Deutschen Basisprofilguideline bitten <br />
| Bearbeitungsstand | als Issues in Gitlab eingetragen, im Simplifier sichtbar https://simplifier.net/basisprofil-de-r4/~resources?category=ValueSet&sortBy=RankScore_desc ==> (Angela)<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 19<br />
| Anfrage eingegangen am| 10.07.2020<br />
| 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<br />
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:<br />
Bestehenden Code ALLG - „Allgemeinmedizin“ neu bezeichnen als „Facharzt für Allgemeinmedizin<br />
(Hausarzt)“<br />
2. Neuen Code einführen für „Praktischer Arzt/Arzt (Hausarzt)“. Vorschlag: PRAK<br />
3. Neuen Code einführen für „Hausärztlich tätiger Internist (Hausarzt)“. Vorschlag: HINT<br />
4. Bestehenden Codes ORTH neu bezeichnen als „Orthopädie und Unfallchirurgie“.<br />
5. Neuen Code einführen für „Rheumatologie (Orthopädie)“. Vorschlag: ORRH.<br />
6. Neuen Code einführen für „Infektiologie“. Vorschlag: INFK<br />
7. Neuen Code einführen für „Kinder-Pneumologie“. Vorschlag: KIPN<br />
8. Neuen Code einführen für „Nervenheilkunde/Neurologie und Psychiatrie“. Vorschlag: NERV<br />
9. Neuen Code einführen für „Psychotherapeutisch tätiger Arzt“. Vorschlag: PTAR<br />
10. Neuen Code einführen für „Psychologischer Psychotherapeut“. Vorschlag: PPTH<br />
11.Neuen Code einführen für „Kinder- und Jugendlichen-Psychotherapeut“. Vorschlag: KJPP<br />
| betrifft Codesystem | Practice Setting Code<br />
| Autor der Anfrage | SR (KBV)<br />
| 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.<br />
| 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).<br />
| Action Item | Mapping prüfen und in Implementation Guide eintragen.<br />
| 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.<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 24<br />
| Anfrage eingegangen am| 5.11.2020<br />
| 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.<br />
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.<br />
HL7 bildet die Berufsgruppen PP (2 L 82) und KJP (2-L 76) falsch ab, nämlich als Spezialisierung, nicht als Grundberufe.<br />
Die Fachgebiete des neuen Berufs ‚Psychotherapeut*in‘ sind im HL7 nicht abgebildet.<br />
| betrifft Codesystem | authorspecialty<br />
| Autor der Anfrage | BPtK<br />
| Diskussion| <br />
| Entscheidung |Neue Berufsgruppen werden in Authorspecialty aufgenommen.<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 25<br />
| Anfrage eingegangen am| 5.11.2020<br />
| Anfrage| Übernahme der Facharzt- und Schwerpunktscodes aus dem Codesystem der BKAe, da relevante Facharzeit - und Schwerpunktscodes fehlen.<br />
| betrifft Codesystem | authorspecialty<br />
| Autor der Anfrage | BKAe<br />
| 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.<br />
| Entscheidung |Die BKAe stellt uns die Codes möglichst als CSV oder Excelfile zur Verfügung. Die BKAe übernimmt die Pflege und Bereitstellung der Codes, so dass sie von uns in ArtDecor eingetragen werden können. Auch TG Codes<br />
| Action Item | BKAE==> Bereitstellung der Codeliste, Konzept zur Pflege, Mapping BAEK Codes auf practice Setting Codes wird auch bei KBV veröffentlicht (als FHIR concept map)<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 26<br />
| Anfrage eingegangen am| 13.11.2020<br />
| Anfrage| Prozeduren zu Fertilitätsdiagnostik und Behandlung in Gebu aufnehmen?<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |<br />
| Action Item | <br />
| Bearbeitungsstand | neu<br />
| zuletzt bearbeitet am| 13.11.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 27<br />
| Anfrage eingegangen am| 13.11.2020<br />
| Anfrage| Typecode für Gebärdendolmetscheunterstützung<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |<br />
| Action Item | <br />
| Bearbeitungsstand | neu<br />
| zuletzt bearbeitet am| 13.11.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 28<br />
| Anfrage eingegangen am| 10.12.2020<br />
| Anfrage| Classcode für Diagnosenübersichtsblatt<br />
| betrifft Codesystem | classCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |<br />
| Action Item | <br />
| Bearbeitungsstand | neu<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
|}<br />
<br />
'''Tabelle abgeschlossene Änderungsanfragen'''<br />
<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! align="left" | Anfrage ID<br />
! align="left" | Anfrage eingegangen am<br />
! align="left" | Anfrage<br />
! align="center" | betrifft Codesystem<br />
! align="center" | Autor der Anfrage<br />
! align="center" | Diskussion<br />
! align="center" | Entscheidung<br />
! align="center" | Action Item<br />
! align="center" | Bearbeitungsstand<br />
! align="center" | zuletzt bearbeitet am<br />
<br />
|- valign="top" <br />
| Anfrage ID| 1<br />
| Anfrage eingegangen am|<br />
| 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:<br />
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<br />
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.<br />
Wir haben somit eine Mischung aus IHE-D-Codes und IHE-PCC/LAB-LOINC-Codes. Inhaltlich/semantisch überschneidet sich das recht munter. Fragen:<br />
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?<br />
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?<br />
Folgende Codes werden vermisst:<br />
im AOK-Projekt haben wir in Ergänzung zu den IHE-D-Codes die folgenden LOINC-Codes als typeCodes verwendet:<br />
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)<br />
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<br />
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<br />
Verschiedene Ausprägungen des Entlassbriefs, um hier anhand der typeCodes eine bessere Sortierung für den Patienten zu ermöglichen:<br />
11490-0: Ärztlicher Entlassbrief<br />
34105-7: Krankenhausentlassbrief (vorläufige/gekürzte Fassung für den Patienten bei der Entlassung)<br />
18842-5: Finales Krankenhausentlassbrief<br />
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.<br />
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.<br />
58410-2: Vollständiges Blutbild<br />
55429-5: Kleines Blutbild<br />
| betrifft Codesystem | class codes, type codes<br />
| Autor der Anfrage | JC <br />
| 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<br />
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.<br />
<br />
| 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.<br />
| 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<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am|21.2.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 2<br />
| Anfrage eingegangen am|<br />
| Anfrage| es scheint in Deutschland Bestrebungen zu geben, Unfallchirurgie mit der Orthopädie zusammenzulegen.<br />
Ab August 2019 wird es im UKD nur noch die „Klinik für Orthopädie und Unfallchirurgie“ geben.<br />
Ist die Einführung einer weiteren Fachabteilung im DocumentEntry.practiseSettingCode geplant?<br />
In DocumentEntry.authorSpecialty findet sie sich:<br />
Code 512 Anzeigename FA Orthopädie und Unfallchirurgie<br />
| betrifft Codesystem | practiceSettingCode <br />
| Autor der Anfrage | SB<br />
| Diskussion| evtl. practiceSettingCode Chirurgie verwenden, deckt beides ab<br />
| Entscheidung |<br />
| Action Item |<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 29.11.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 3<br />
| Anfrage eingegangen am|<br />
| 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.<br />
Dazu möchten wir das Value Set für XDS-Metadatenattribut formatCode um den folgenden Wert erweitern: urn:gematik:ig:DatensatzPersoenlicheErklaerungen:r3.1<br />
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.<br />
| betrifft Codesystem | formatCode<br />
| Autor der Anfrage | RK<br />
| Diskussion| keine Einwände<br />
| Entscheidung | wir fügen Code hinzu<br />
| Action Item | in ArtDecor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am|13.12.2019<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 5<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Freischaltung der FHIR Schnittstelle in ArtDecor<br />
| betrifft Codesystem | alle<br />
| Autor der Anfrage | SH über Tarik Idris<br />
| Diskussion| <br />
| Entscheidung | wird gemacht<br />
| Action Item | Tarik: FHIR Schnittstelle in ArtDecor freischalten<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 15.11.2019<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 8<br />
| Anfrage eingegangen am| 15.11.2019<br />
| Anfrage| Vorgehensweise für V3 auf eigener WikiSeite beschreiben<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | SL<br />
| Diskussion| befürwortet<br />
| Entscheidung | befürwortet<br />
| Action Item | Anlegen neue Seite im HL7 Wiki ==> Angela, Ziele ==> Angela, allgemeine Weiterentwicklung als Ziel hinzufügen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 13.12.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 9<br />
| Anfrage eingegangen am| 13.12.2019<br />
| Anfrage| Bericht Treffen BVITG, Interopforum, Gematik, Vorabstimmung EPA Version 1.2.2022<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | TI<br />
| 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) <br />
| Entscheidung | über konstruktive Zusammenarbeit wird sich gefreut<br />
| Action Item | keine<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 13.12.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 10<br />
| Anfrage eingegangen am| 12.01.2020<br />
| 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.<br />
https://loinc.org/file-access/download-id/8994/<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | ST<br />
| Diskussion| <br />
| Entscheidung | Gemeinsame Strategietelko zur Zusammenführung LOINC, SNOMED CT, XDT, QMS, KDL deutsche XDS Value Sets am 28.5.2020 10-12 Uhr geplant<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 24.04.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 11<br />
| Anfrage eingegangen am| 07.02.2020<br />
| Anfrage| Zusammenarbeit KBV<br />
| betrifft Codesystem | alle, v.a. format Code<br />
| Autor der Anfrage | RK<br />
| Diskussion| Den MIOs müssen XDS Metadaten zugeordnet werden, v.a. formatCodes<br />
| Entscheidung | Arbeitsgruppe bietet proaktiv Hilfe bzgl. der Metadaten bei KBV an<br />
| Action Item | Mail an Vorstand ==> Mail an KBV (H. Tenkow)<br />
| Bearbeitungsstand | Mail an Vorstand gesendet<br />
| zuletzt bearbeitet am| 07.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 12<br />
| Anfrage eingegangen am| 21.02.2020<br />
| 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<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | RK<br />
| Diskussion| keine Einwände<br />
| Entscheidung | werden aufgenommen<br />
| Action Item | Aufnahme in ArtDecor ==> Angela<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 24.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 13<br />
| Anfrage eingegangen am| 06.03.2020<br />
| Anfrage| Übersetzung der Metadatenbezeichnungen ins Englische<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | SL<br />
| Diskussion| ValueSets sind nur für Deutschland, jeder Dokumentierende sollte über ausreichende Deutschkenntisse verfügen<br />
| Entscheidung | abgelehnt<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 06.03.2020<br />
|- valign="top" <br />
<br />
|- valign="top"<br />
| Anfrage ID| 14<br />
| Anfrage eingegangen am| 24.04.2020<br />
| Anfrage| Neuer FormatCode für eRezept (Daten elektronischer Verordnung) der Gematik<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | RK<br />
| 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<br />
| Entscheidung | urn:gematik:ig:VerordnungsdatensatzMedikation:r4.0<br />
| Action Item | in Art Decor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
<br />
<br />
|- valign="top" <br />
<br />
<br />
| Anfrage ID| 15<br />
| Anfrage eingegangen am| 14.05.2020<br />
| Anfrage| Kommentierung EPA XDS Metadaten<br />
| betrifft Codesystem | fast alle<br />
| Autor der Anfrage | TI<br />
| Diskussion| <br />
| 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<br />
| Action Item | Tarik==> Kommentar an gematik<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.05.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 16<br />
| Anfrage eingegangen am| 14.05.2020<br />
| 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. <br />
| betrifft Codesystem | TypeCode<br />
| Autor der Anfrage | VK<br />
| Diskussion| <br />
| Entscheidung | wird als Beispiel in pathologische Befunde aufgenommen<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
|- valign="top" <br />
<br />
| Anfrage ID| 17<br />
| Anfrage eingegangen am| 14.05.2020<br />
| Anfrage| Am UKHD gibt es ein Zentrum für Seltene Erkrankungen. Dort werden Patienten jeglichen Alters behandelt. <br />
| betrifft Codesystem | PracticeSettingCode<br />
| Autor der Anfrage | VK<br />
| Diskussion| <br />
| 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<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 18<br />
| Anfrage eingegangen am| 26.06.2020<br />
| Anfrage| Code für Erfassung Fall- /Bewegungsdaten<br />
| betrifft Codesystem | Class Code, Type Code<br />
| Autor der Anfrage | AM<br />
| 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<br />
| Entscheidung | keine zusätzlichen Codes<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 20<br />
| Anfrage eingegangen am| 10.07.2020<br />
| 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:<br />
<br />
Unterkategorien von 1a - Code<br />
<br />
Hausarzt/ Hausärztin - practitioner<br />
<br />
Krankenhaus - hospital<br />
<br />
Labor und Humangenetik - laboratory<br />
<br />
Physiotherapeuten - physiotherapy<br />
<br />
Psychotherapeuten - psychotherapy<br />
<br />
Dermatologie - dermatology<br />
<br />
Urologie/Gynäkologie - gynaecology_urology<br />
<br />
Zahnheilkunde und Mund-Kiefer-Gesichtschirurgie - dentistry_oms<br />
<br />
Weitere Fachärzte/ Fachärztinnen - other_medical<br />
<br />
Weitere nicht-ärztliche Berufe - other_non_medical<br />
<br />
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.<br />
<br />
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.<br />
<br />
Für diesen Code soll ein Code-System "Sonstige Berechtigungen ePA" genutzt werden.<br />
| betrifft Codesystem | Anfrage neues Codesystem / ValueSet für Folder<br />
| Autor der Anfrage | JG (Gematik)<br />
| 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<br />
| Entscheidung |Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte<br />
| Action Item | Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte<br />
| 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 <br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 21<br />
| Anfrage eingegangen am| 31.07.2020<br />
| 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:<br />
<br />
"urn:gematik:ig:KinderuntersuchungsheftUntersuchungen:r4.0"<br />
"urn:gematik:ig:KinderuntersuchungsheftTeilnahmekarte:r4.0"<br />
"urn:gematik:ig:KinderuntersuchungsheftNotizen:r4.0"<br />
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.<br />
<br />
<br />
<br />
Als Anzeigename schlage ich vor:<br />
<br />
· Untersuchungen Kinderuntersuchungsheft<br />
<br />
· Teilnahmekarte Kinderuntersuchungsheft<br />
<br />
· Notizen Kinderuntersuchungsheft<br />
| betrifft Codesystem | FormatCodes<br />
| Autor der Anfrage | Gematik<br />
| Diskussion| <br />
| Entscheidung | wird aufgenommen<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 22<br />
| Anfrage eingegangen am| 16.09.2020<br />
| Anfrage| Patientenverfügung als Beispiel für administratives Dokument aufnehmen<br />
| betrifft Codesystem | classCode<br />
| Autor der Anfrage | VB (Uniklinik HD)<br />
| Diskussion| entspricht Mapping in KDL<br />
| Entscheidung | wird als Beispiel hinzugefügt<br />
| Action Item | in ArtDecor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 23<br />
| Anfrage eingegangen am| 18.09.2020<br />
| Anfrage| TypeCode für mikroskopische Bilder<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | VB (Uniklinik HD)<br />
| Diskussion| wenn Ergebnis Mikrobiologie oder Pathologie, dann diesen Code verwenden, ansonsten BILD<br />
| Entscheidung | wenn Ergebnis Mikrobiologie (MKRO) oder Pathologie (PATH) dann diesen Code verwenden, ansonsten BILD<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
<br />
|}<br />
<br />
'''Tabelle Aktueller Stand'''<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! width="25%" align="left" | Codesystem<br />
! align="center" | Stand Konzepte<br />
! align="center" | ArtDecor<br />
! align="center" | WikiText<br />
! align="center" | Review durch<br />
<br />
|- valign="top" <br />
| Codesystem | Einleitung<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | Vokabular Management<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | Confidentiality Code<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | AuthorRole<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | AuthorSpeciality<br />
| Stand Konzepte | n/a<br />
| ArtDecor | offen<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | EventCodeList<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | ContentTypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | ClassCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | TypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | FormatCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | HealthcareFacilityTypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | PracticeSettingCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | Folder.codeList<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | <br />
<br />
|}<br />
<br />
'''Schritte zur Veröffentlichung v3'''<br />
# Zeitplan (draft) erstellen<br />
# 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<br />
# Ankündigung formulieren<br />
# Review der Wiki-Texte und AuthorSpecialty Code anpassen<br />
# Change Liste erstellen<br />
# PDF erstellen<br />
# PDF in Wiki und auf IHE-D Seite hochladen/referenzieren<br />
# Kommentare sammeln<br />
# Kommentare auflösen<br />
# Abstimmung zur Veröffentlichung<br />
# Finale Version erstellen und in Wiki und IHE-D Seite hochladen<br />
<br />
Optional:<br />
* Erläuterung zum Zusammenspiel mit FHIR<br />
* Hinweis/kurze Erläuterung der nicht behandelten XDS Metadaten<br />
<br />
'''IG Struktur'''<br />
<br />
# [[ihevs:Einleitung]] (Vorgehen, Ziele, Umgang mit v1, normativ, Delta-Liste?, Änderungen/Pflege)<br />
# [[Ihevs:Vokabular-Management]]<br />
# [[ihevs:DocumentEntry.authorRole]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.authorSpecialty]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.classCode]]<br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.confidentialityCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.eventCodeList]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.formatCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.healthcareFacilityTypeCode]]<br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.languageCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.practiceSettingCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.typeCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:SubmissionSet.contentTypeCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:Folder.codeList]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor<br />
<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=IHE_DE_ValueSets_Action_Items&diff=75568IHE DE ValueSets Action Items2021-01-08T12:46:10Z<p>Tidris: alte Todos rausgeschmissen, Plan zur Veröffentlichung umrissen, Review Liste aktualisiert</p>
<hr />
<div>'''Tabelle Änderungsanfragen'''<br />
<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! align="left" | Anfrage ID<br />
! align="left" | Anfrage eingegangen am<br />
! align="left" | Anfrage<br />
! align="center" | betrifft Codesystem<br />
! align="center" | Autor der Anfrage<br />
! align="center" | Diskussion<br />
! align="center" | Entscheidung<br />
! align="center" | Action Item<br />
! align="center" | Bearbeitungsstand<br />
! align="center" | zuletzt bearbeitet am<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 4<br />
| Anfrage eingegangen am|<br />
| Anfrage| Arbeitsgruppe „Weiterentwicklung Klinische Dokumentenklassenliste (KDL)“.<br />
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.<br />
Das aktuelle Mapping liegt der Geschäftsstelle vor und ist bisher mit Angela Merzweiler gemeinsam abgestimmt wurden.<br />
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.<br />
Beispiel:<br />
Ich möchte daher anregen bzw. beantragen, dass die KDL im ersten Schritt offiziell als CodeSystem in das Value Set „EventCodeList“ aufgenommen wird.<br />
Damit haben Hersteller von IHE-konformen Archiven, o. ä. die Möglichkeit, wenigstens die Klassifizierung des Dokuments mittels KDL offiziell abzubilden.<br />
· Code System Name: Klinische Dokumentenklassen Liste (KDL)<br />
· Code System ID: 1.2.276.0.76.3.1.191.0.1.1, versionsabhängig<br />
· Kommentar: Klassifizierung von Dokumenten und Daten als Beispiele für die Value Sets classCode und typeCode<br />
Mittelfristig soll die KDL zu einem terminologischen System mit ontologischem Ansatz ausgebaut werden.<br />
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.<br />
Ich freue mich, wenn wir es gemeinsam schaffen, dazu einen persönlichen Termin für ein Arbeitstreffen zu finden.<br />
| betrifft Codesystem | eventCode<br />
| Autor der Anfrage | AMü<br />
| 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<br />
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)<br />
| Entscheidung | grundsätzlich zugestimmt, neues Valueset <br />
| Action Item | Annett=> noch OID für übergeordnetes Value Set KDL beantragen, dann kann OID für ValueSet in ArtDecor angepasst werden (im Moment nur ValueSet für KDL 2020, alle=> Mapping prüfen<br />
| Bearbeitungsstand | in Bearbeitung (Annett)<br />
| zuletzt bearbeitet am| 02.10.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 6<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Ansatz Canonical URLs diskutieren<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | Tarik Idris<br />
| Diskussion| Ziel: Gute Einfügung in FHIR Umgebung<br />
| Entscheidung | Für V3 alle URNs durch URLs ersetzen <br />
| 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 <br />
| Bearbeitungsstand | in Bearbeitung (Angela)<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 7<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Deutscher Implementation Guide für MHD Profile mit Verweis auf unsere Valuesets<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | SH über Tarik<br />
| 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 <br />
| 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 <br />
| Action Item | Simone um Referenz der Codes in Deutschen Basisprofilguideline bitten <br />
| Bearbeitungsstand | als Issues in Gitlab eingetragen, im Simplifier sichtbar https://simplifier.net/basisprofil-de-r4/~resources?category=ValueSet&sortBy=RankScore_desc ==> (Angela)<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 19<br />
| Anfrage eingegangen am| 10.07.2020<br />
| 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<br />
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:<br />
Bestehenden Code ALLG - „Allgemeinmedizin“ neu bezeichnen als „Facharzt für Allgemeinmedizin<br />
(Hausarzt)“<br />
2. Neuen Code einführen für „Praktischer Arzt/Arzt (Hausarzt)“. Vorschlag: PRAK<br />
3. Neuen Code einführen für „Hausärztlich tätiger Internist (Hausarzt)“. Vorschlag: HINT<br />
4. Bestehenden Codes ORTH neu bezeichnen als „Orthopädie und Unfallchirurgie“.<br />
5. Neuen Code einführen für „Rheumatologie (Orthopädie)“. Vorschlag: ORRH.<br />
6. Neuen Code einführen für „Infektiologie“. Vorschlag: INFK<br />
7. Neuen Code einführen für „Kinder-Pneumologie“. Vorschlag: KIPN<br />
8. Neuen Code einführen für „Nervenheilkunde/Neurologie und Psychiatrie“. Vorschlag: NERV<br />
9. Neuen Code einführen für „Psychotherapeutisch tätiger Arzt“. Vorschlag: PTAR<br />
10. Neuen Code einführen für „Psychologischer Psychotherapeut“. Vorschlag: PPTH<br />
11.Neuen Code einführen für „Kinder- und Jugendlichen-Psychotherapeut“. Vorschlag: KJPP<br />
| betrifft Codesystem | Practice Setting Code<br />
| Autor der Anfrage | SR (KBV)<br />
| 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.<br />
| 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).<br />
| Action Item | Mapping prüfen und in Implementation Guide eintragen.<br />
| 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.<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 24<br />
| Anfrage eingegangen am| 5.11.2020<br />
| 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.<br />
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.<br />
HL7 bildet die Berufsgruppen PP (2 L 82) und KJP (2-L 76) falsch ab, nämlich als Spezialisierung, nicht als Grundberufe.<br />
Die Fachgebiete des neuen Berufs ‚Psychotherapeut*in‘ sind im HL7 nicht abgebildet.<br />
| betrifft Codesystem | authorspecialty<br />
| Autor der Anfrage | BPtK<br />
| Diskussion| <br />
| Entscheidung |Neue Berufsgruppen werden in Authorspecialty aufgenommen.<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 25<br />
| Anfrage eingegangen am| 5.11.2020<br />
| Anfrage| Übernahme der Facharzt- und Schwerpunktscodes aus dem Codesystem der BKAe, da relevante Facharzeit - und Schwerpunktscodes fehlen.<br />
| betrifft Codesystem | authorspecialty<br />
| Autor der Anfrage | BKAe<br />
| 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.<br />
| Entscheidung |Die BKAe stellt uns die Codes möglichst als CSV oder Excelfile zur Verfügung. Die BKAe übernimmt die Pflege und Bereitstellung der Codes, so dass sie von uns in ArtDecor eingetragen werden können. Auch TG Codes<br />
| Action Item | BKAE==> Bereitstellung der Codeliste, Konzept zur Pflege, Mapping BAEK Codes auf practice Setting Codes wird auch bei KBV veröffentlicht (als FHIR concept map)<br />
| Bearbeitungsstand | in Bearbeitung<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 26<br />
| Anfrage eingegangen am| 13.11.2020<br />
| Anfrage| Prozeduren zu Fertilitätsdiagnostik und Behandlung in Gebu aufnehmen?<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |<br />
| Action Item | <br />
| Bearbeitungsstand | neu<br />
| zuletzt bearbeitet am| 13.11.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 27<br />
| Anfrage eingegangen am| 13.11.2020<br />
| Anfrage| Typecode für Gebärdendolmetscheunterstützung<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |<br />
| Action Item | <br />
| Bearbeitungsstand | neu<br />
| zuletzt bearbeitet am| 13.11.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 28<br />
| Anfrage eingegangen am| 10.12.2020<br />
| Anfrage| Classcode für Diagnosenübersichtsblatt<br />
| betrifft Codesystem | classCode<br />
| Autor der Anfrage | UKHD<br />
| Diskussion| <br />
| Entscheidung |<br />
| Action Item | <br />
| Bearbeitungsstand | neu<br />
| zuletzt bearbeitet am| 10.12.2020<br />
<br />
|}<br />
<br />
'''Tabelle abgeschlossene Änderungsanfragen'''<br />
<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! align="left" | Anfrage ID<br />
! align="left" | Anfrage eingegangen am<br />
! align="left" | Anfrage<br />
! align="center" | betrifft Codesystem<br />
! align="center" | Autor der Anfrage<br />
! align="center" | Diskussion<br />
! align="center" | Entscheidung<br />
! align="center" | Action Item<br />
! align="center" | Bearbeitungsstand<br />
! align="center" | zuletzt bearbeitet am<br />
<br />
|- valign="top" <br />
| Anfrage ID| 1<br />
| Anfrage eingegangen am|<br />
| 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:<br />
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<br />
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.<br />
Wir haben somit eine Mischung aus IHE-D-Codes und IHE-PCC/LAB-LOINC-Codes. Inhaltlich/semantisch überschneidet sich das recht munter. Fragen:<br />
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?<br />
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?<br />
Folgende Codes werden vermisst:<br />
im AOK-Projekt haben wir in Ergänzung zu den IHE-D-Codes die folgenden LOINC-Codes als typeCodes verwendet:<br />
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)<br />
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<br />
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<br />
Verschiedene Ausprägungen des Entlassbriefs, um hier anhand der typeCodes eine bessere Sortierung für den Patienten zu ermöglichen:<br />
11490-0: Ärztlicher Entlassbrief<br />
34105-7: Krankenhausentlassbrief (vorläufige/gekürzte Fassung für den Patienten bei der Entlassung)<br />
18842-5: Finales Krankenhausentlassbrief<br />
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.<br />
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.<br />
58410-2: Vollständiges Blutbild<br />
55429-5: Kleines Blutbild<br />
| betrifft Codesystem | class codes, type codes<br />
| Autor der Anfrage | JC <br />
| 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<br />
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.<br />
<br />
| 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.<br />
| 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<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am|21.2.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 2<br />
| Anfrage eingegangen am|<br />
| Anfrage| es scheint in Deutschland Bestrebungen zu geben, Unfallchirurgie mit der Orthopädie zusammenzulegen.<br />
Ab August 2019 wird es im UKD nur noch die „Klinik für Orthopädie und Unfallchirurgie“ geben.<br />
Ist die Einführung einer weiteren Fachabteilung im DocumentEntry.practiseSettingCode geplant?<br />
In DocumentEntry.authorSpecialty findet sie sich:<br />
Code 512 Anzeigename FA Orthopädie und Unfallchirurgie<br />
| betrifft Codesystem | practiceSettingCode <br />
| Autor der Anfrage | SB<br />
| Diskussion| evtl. practiceSettingCode Chirurgie verwenden, deckt beides ab<br />
| Entscheidung |<br />
| Action Item |<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 29.11.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 3<br />
| Anfrage eingegangen am|<br />
| 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.<br />
Dazu möchten wir das Value Set für XDS-Metadatenattribut formatCode um den folgenden Wert erweitern: urn:gematik:ig:DatensatzPersoenlicheErklaerungen:r3.1<br />
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.<br />
| betrifft Codesystem | formatCode<br />
| Autor der Anfrage | RK<br />
| Diskussion| keine Einwände<br />
| Entscheidung | wir fügen Code hinzu<br />
| Action Item | in ArtDecor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am|13.12.2019<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 5<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Freischaltung der FHIR Schnittstelle in ArtDecor<br />
| betrifft Codesystem | alle<br />
| Autor der Anfrage | SH über Tarik Idris<br />
| Diskussion| <br />
| Entscheidung | wird gemacht<br />
| Action Item | Tarik: FHIR Schnittstelle in ArtDecor freischalten<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 15.11.2019<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 8<br />
| Anfrage eingegangen am| 15.11.2019<br />
| Anfrage| Vorgehensweise für V3 auf eigener WikiSeite beschreiben<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | SL<br />
| Diskussion| befürwortet<br />
| Entscheidung | befürwortet<br />
| Action Item | Anlegen neue Seite im HL7 Wiki ==> Angela, Ziele ==> Angela, allgemeine Weiterentwicklung als Ziel hinzufügen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 13.12.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 9<br />
| Anfrage eingegangen am| 13.12.2019<br />
| Anfrage| Bericht Treffen BVITG, Interopforum, Gematik, Vorabstimmung EPA Version 1.2.2022<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | TI<br />
| 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) <br />
| Entscheidung | über konstruktive Zusammenarbeit wird sich gefreut<br />
| Action Item | keine<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 13.12.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 10<br />
| Anfrage eingegangen am| 12.01.2020<br />
| 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.<br />
https://loinc.org/file-access/download-id/8994/<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | ST<br />
| Diskussion| <br />
| Entscheidung | Gemeinsame Strategietelko zur Zusammenführung LOINC, SNOMED CT, XDT, QMS, KDL deutsche XDS Value Sets am 28.5.2020 10-12 Uhr geplant<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 24.04.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 11<br />
| Anfrage eingegangen am| 07.02.2020<br />
| Anfrage| Zusammenarbeit KBV<br />
| betrifft Codesystem | alle, v.a. format Code<br />
| Autor der Anfrage | RK<br />
| Diskussion| Den MIOs müssen XDS Metadaten zugeordnet werden, v.a. formatCodes<br />
| Entscheidung | Arbeitsgruppe bietet proaktiv Hilfe bzgl. der Metadaten bei KBV an<br />
| Action Item | Mail an Vorstand ==> Mail an KBV (H. Tenkow)<br />
| Bearbeitungsstand | Mail an Vorstand gesendet<br />
| zuletzt bearbeitet am| 07.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 12<br />
| Anfrage eingegangen am| 21.02.2020<br />
| 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<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | RK<br />
| Diskussion| keine Einwände<br />
| Entscheidung | werden aufgenommen<br />
| Action Item | Aufnahme in ArtDecor ==> Angela<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 24.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 13<br />
| Anfrage eingegangen am| 06.03.2020<br />
| Anfrage| Übersetzung der Metadatenbezeichnungen ins Englische<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | SL<br />
| Diskussion| ValueSets sind nur für Deutschland, jeder Dokumentierende sollte über ausreichende Deutschkenntisse verfügen<br />
| Entscheidung | abgelehnt<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 06.03.2020<br />
|- valign="top" <br />
<br />
|- valign="top"<br />
| Anfrage ID| 14<br />
| Anfrage eingegangen am| 24.04.2020<br />
| Anfrage| Neuer FormatCode für eRezept (Daten elektronischer Verordnung) der Gematik<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | RK<br />
| 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<br />
| Entscheidung | urn:gematik:ig:VerordnungsdatensatzMedikation:r4.0<br />
| Action Item | in Art Decor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
<br />
<br />
|- valign="top" <br />
<br />
<br />
| Anfrage ID| 15<br />
| Anfrage eingegangen am| 14.05.2020<br />
| Anfrage| Kommentierung EPA XDS Metadaten<br />
| betrifft Codesystem | fast alle<br />
| Autor der Anfrage | TI<br />
| Diskussion| <br />
| 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<br />
| Action Item | Tarik==> Kommentar an gematik<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.05.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 16<br />
| Anfrage eingegangen am| 14.05.2020<br />
| 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. <br />
| betrifft Codesystem | TypeCode<br />
| Autor der Anfrage | VK<br />
| Diskussion| <br />
| Entscheidung | wird als Beispiel in pathologische Befunde aufgenommen<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
|- valign="top" <br />
<br />
| Anfrage ID| 17<br />
| Anfrage eingegangen am| 14.05.2020<br />
| Anfrage| Am UKHD gibt es ein Zentrum für Seltene Erkrankungen. Dort werden Patienten jeglichen Alters behandelt. <br />
| betrifft Codesystem | PracticeSettingCode<br />
| Autor der Anfrage | VK<br />
| Diskussion| <br />
| 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<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 18<br />
| Anfrage eingegangen am| 26.06.2020<br />
| Anfrage| Code für Erfassung Fall- /Bewegungsdaten<br />
| betrifft Codesystem | Class Code, Type Code<br />
| Autor der Anfrage | AM<br />
| 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<br />
| Entscheidung | keine zusätzlichen Codes<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 20<br />
| Anfrage eingegangen am| 10.07.2020<br />
| 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:<br />
<br />
Unterkategorien von 1a - Code<br />
<br />
Hausarzt/ Hausärztin - practitioner<br />
<br />
Krankenhaus - hospital<br />
<br />
Labor und Humangenetik - laboratory<br />
<br />
Physiotherapeuten - physiotherapy<br />
<br />
Psychotherapeuten - psychotherapy<br />
<br />
Dermatologie - dermatology<br />
<br />
Urologie/Gynäkologie - gynaecology_urology<br />
<br />
Zahnheilkunde und Mund-Kiefer-Gesichtschirurgie - dentistry_oms<br />
<br />
Weitere Fachärzte/ Fachärztinnen - other_medical<br />
<br />
Weitere nicht-ärztliche Berufe - other_non_medical<br />
<br />
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.<br />
<br />
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.<br />
<br />
Für diesen Code soll ein Code-System "Sonstige Berechtigungen ePA" genutzt werden.<br />
| betrifft Codesystem | Anfrage neues Codesystem / ValueSet für Folder<br />
| Autor der Anfrage | JG (Gematik)<br />
| 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<br />
| Entscheidung |Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte<br />
| Action Item | Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte<br />
| 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 <br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 21<br />
| Anfrage eingegangen am| 31.07.2020<br />
| 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:<br />
<br />
"urn:gematik:ig:KinderuntersuchungsheftUntersuchungen:r4.0"<br />
"urn:gematik:ig:KinderuntersuchungsheftTeilnahmekarte:r4.0"<br />
"urn:gematik:ig:KinderuntersuchungsheftNotizen:r4.0"<br />
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.<br />
<br />
<br />
<br />
Als Anzeigename schlage ich vor:<br />
<br />
· Untersuchungen Kinderuntersuchungsheft<br />
<br />
· Teilnahmekarte Kinderuntersuchungsheft<br />
<br />
· Notizen Kinderuntersuchungsheft<br />
| betrifft Codesystem | FormatCodes<br />
| Autor der Anfrage | Gematik<br />
| Diskussion| <br />
| Entscheidung | wird aufgenommen<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 22<br />
| Anfrage eingegangen am| 16.09.2020<br />
| Anfrage| Patientenverfügung als Beispiel für administratives Dokument aufnehmen<br />
| betrifft Codesystem | classCode<br />
| Autor der Anfrage | VB (Uniklinik HD)<br />
| Diskussion| entspricht Mapping in KDL<br />
| Entscheidung | wird als Beispiel hinzugefügt<br />
| Action Item | in ArtDecor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 23<br />
| Anfrage eingegangen am| 18.09.2020<br />
| Anfrage| TypeCode für mikroskopische Bilder<br />
| betrifft Codesystem | typeCode<br />
| Autor der Anfrage | VB (Uniklinik HD)<br />
| Diskussion| wenn Ergebnis Mikrobiologie oder Pathologie, dann diesen Code verwenden, ansonsten BILD<br />
| Entscheidung | wenn Ergebnis Mikrobiologie (MKRO) oder Pathologie (PATH) dann diesen Code verwenden, ansonsten BILD<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.09.2020<br />
<br />
<br />
|}<br />
<br />
'''Tabelle Aktueller Stand'''<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! width="25%" align="left" | Codesystem<br />
! align="center" | Stand Konzepte<br />
! align="center" | ArtDecor<br />
! align="center" | WikiText<br />
! align="center" | Review durch<br />
<br />
|- valign="top" <br />
| Codesystem | Einleitung<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | Vokabular Management<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | Confidentiality Code<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | AuthorRole<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | AuthorSpeciality<br />
| Stand Konzepte | n/a<br />
| ArtDecor | offen<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | EventCodeList<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | ContentTypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | ClassCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | TypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | FormatCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | HealthcareFacilityTypeCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | PracticeSettingCode<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | Folder.codeList<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | offen <br />
| Review durch | <br />
<br />
|}<br />
<br />
'''Schritte zur Veröffentlichung v3'''<br />
# Zeitplan (draft) erstellen<br />
# 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<br />
# Ankündigung formulieren<br />
# Review der Wiki-Texte und AuthorSpecialty Code anpassen<br />
# Change Liste erstellen<br />
# PDF erstellen<br />
# PDF in Wiki und auf IHE-D Seite hochladen/referenzieren<br />
# Kommentare sammeln<br />
# Kommentare auflösen<br />
# Abstimmung zur Veröffentlichung<br />
# Finale Version erstellen und in Wiki und IHE-D Seite hochladen<br />
<br />
'''IG Struktur'''<br />
<br />
# [[ihevs:Einleitung]] (Vorgehen, Ziele, Umgang mit v1, normativ, Delta-Liste?, Änderungen/Pflege)<br />
# [[Ihevs:Vokabular-Management]]<br />
# [[ihevs:DocumentEntry.authorRole]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.authorSpecialty]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.classCode]]<br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.confidentialityCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.eventCodeList]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.formatCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.healthcareFacilityTypeCode]]<br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.languageCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.practiceSettingCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.typeCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:SubmissionSet.contentTypeCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:Folder.codeList]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor<br />
<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=OID-Konzept_IHE-D&diff=70051OID-Konzept IHE-D2020-09-18T11:41:37Z<p>Tidris: </p>
<hr />
<div><!--<br />
<br />
OID-Konzept von IHE Deutschland<br />
--><br />
{{Infobox Dokument<br />
|Title OID-Konzept von IHE Deutschland<br />
|Short = OID-Konzept IHE-D<br />
|Namespace = cdaab2<br />
|Type = Konzept<br />
|Version = 0.2<br />
|Submitted = .<br />
|Date = 14. Oktober 2015<br />
|Copyright = 2012<br />
|Status = Entwurf<br />
|Period = Entwurf<br />
|OID = n.n.<br />
|Realm = Deutschland<br />
}}<br />
<br />
<br />
[[file:IHE Deutschland final rgb web.jpg|200px|Logo IHE-D]]<br />
<br />
=OID Konzept von IHE-Deutschland=<br />
<br />
==Root-OID==<br />
Als root-OID für IHE Deutschland wurde 1.3.6.1.4.1.19376.3.276 vergeben:<br /><br />
<br />
<blockquote><br />
1 = International Organization for Standardization (ISO)<br /><br />
3 = Organization identification schemes registered according to ISO/IEC 6523-2<br /><br />
6 = United States Department of Defense (DoD)<br /><br />
1 = internet<br /><br />
4 = Internet Assigned Numbers Authority (IANA)<br /><br />
1 = Private enterprises<br /><br />
19376 = Integrating the Healthcare Enterprise International<br /><br />
3 = Organizations<br /><br />
276 = IHE Deutschland<br /><br />
</blockquote><br />
<br />
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.<br />
<br />
==Aufbau des OID-Baums für IHE-D==<br />
{| class="hl7table"<br />
|-<br />
!Extension (Sub-Branch/Type) !! Beschreibung !! Bemerkung<br />
|-<br />
! *.1 !! OID für das OID Konzept Version 1 !!<br />
|-<br />
|.1.1|| Interne Objekte || interne Artefacts wie Modelle<br />
|-<br />
|.1.1.1 || Ordnertypen || <br />
|-<br />
|.1.1.2 || Auswahllisten || <br />
|-<br />
|.1.1.3 || Mitarbeiter || <br />
|-<br />
! *.1.2 !! interne Organisationsstrukturen !!<br />
|-<br />
! *.1.3 !! Instanzen-Identifikationen !!<br />
|-<br />
|.1.3.1 || Organisationen || <br />
|-<br />
|.1.3.2 || Personen || <br />
|-<br />
|.1.3.2.1 || Identifikation des ID-Pools für Patienten || <br />
|-<br />
|.1.3.2.2 || Identifikation des ID-Pools für Personen allgemein (Ärzte, Betreuer, Kontakte, etc.) || <br />
|-<br />
|.1.3.3 || Identifikation des ID-Pools für Fälle || <br />
|-<br />
! *.1.4 !! Identifikation des ID-Pools für Institutionen (Organisationen, Einheiten, etc.) !! Allgemeine Identifikationsmechanismen wie Personalausweis usw.<br />
|-<br />
|.1.4.1 || Krankenhäuser || Wenn möglich, soll ein Krankenhaus eine eigene OID bei DIMDI beantragen<br />
|-<br />
|.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.<br />
|-<br />
|.1.4.3 || Systeme || Alle angeschlossenen Systeme bekommen eine OID. Unterhalb des Systems werden ggfs. ebenfalls bestimmte Subtypen definiert.<br />
|-<br />
! *.1.5 !! '''Kodierschemas''' !!<br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.1 || derzeit unbenutzt<br />
|-<br />
|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<br />
|-<br />
|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<br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.4 || Practice Setting Code (ärztl. Fachrichtungen) || 1.2.276.0.76.11.69<br />
|-<br />
|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<br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.6 || XDS formatCode (vgl. URN-Konzept) || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.7 || XDS Folder.codeList || 1.2.276.0.76.11.40<br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.8 || XDS classCode || 1.2.276.0.76.11.32<br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.9 || XDS typeCode || 1.2.276.0.76.11.38<br />
|-<br />
|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<br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.11 || Authorspecialty (nicht ärztliche Berufe) || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.12 || SubmissionSet Contenttype Code || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.13 || Authorrole Prozessrollen || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.14 || Authorrole Patientenbeziehungsrollen || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.15 || EventCodeList "Hinweise"/"Informationen" /"Warnungen" || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.16 || EventCodeList "Ereignisse CS#1: Aufnahme - Verlegung - Entlassung" || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.17 || retired / bitte nicht verwendet || <br />
|-<br />
!*.1.6 !! Metadaten !!<br />
|-<br />
|.1.6.1 || Ordner-Metadaten || <br />
|-<br />
!*.1.7 !! '''Dokumente''' !! <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.7.1 || OID-Konzept || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.7.2 || Identifikation des ID-Pools für CDA-Dokumente || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.7.3 || Identifikation des ID-Pools für externe Dokumente (in CDAs verlinkt) || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.7.4 || IHE_D Cookbook || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.7.5 || Value-Set-Leitfaden (Vers. 1.0, Nov.2016) || <br />
|-<br />
! *.1.9 !! Nachrichtenprofile !!<br />
|-<br />
|... || ||<br />
|-<br />
! *.1.10 !! Interne Templates !! <br />
|-<br />
|.1.10.1 || Document Templates || <br />
|-<br />
|.1.10.1.1 || root-OID für Template-Ids || <br />
|-<br />
|.1.10.2 || Section Templates || <br />
|-<br />
|.1.10.2.1 || Identifikation des ID-Pools für CDA-Formularteile || <br />
|-<br />
|.1.10.3 || Entry Templates || <br />
|-<br />
! *.1.11 !! '''Value Sets''' !!<br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.11.1 || ''IHEXDSclassCode: Dokumentenart'' '''deprecated, stattdessen 1.2.276.0.76.11.32 verwenden''' || <br />
|-<br />
|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''' || <br />
|-<br />
|... || ||<br />
|-<br />
! *.1.12 !! Deutsch-spezifische Erweiterungen von seitens der Organisation/Firma verwalteten Kodierschemas !!<br />
|-<br />
|... || ||<br />
|-<br />
! *.1.15 !! Kodierschemas seitens Organisation/Firma verwaltet !!<br />
|-<br />
|... || ||<br />
|-<br />
! *.1.60 !! Projekte !!<br />
|-<br />
|... || ||<br />
|-<br />
! *.1.64 !! Policy !!<br />
|-<br />
|... || ||<br />
|-<br />
! *.1.67 !! Installations-Instanzen von Softwaresystemen !!<br />
|-<br />
|... || ||<br />
|-<br />
!*.1.77 !! ART-DECOR !!<br />
|-<br />
|... || ||<br />
|-<br />
!*.1.99 !! Experimentell / Test !!<br />
|-<br />
|... || ||<br />
|}<br />
<br />
== Fußnoten ==<br />
<references /></div>Tidrishttps://wiki.hl7.de/index.php?title=IHE_DE_ValueSets_Action_Items&diff=70017IHE DE ValueSets Action Items2020-09-15T15:48:45Z<p>Tidris: Tippfehler im Datum korrigiert</p>
<hr />
<div>'''Tabelle Änderungsanfragen'''<br />
<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! align="left" | Anfrage ID<br />
! align="left" | Anfrage eingegangen am<br />
! align="left" | Anfrage<br />
! align="center" | betrifft Codesystem<br />
! align="center" | Autor der Anfrage<br />
! align="center" | Diskussion<br />
! align="center" | Entscheidung<br />
! align="center" | Action Item<br />
! align="center" | Bearbeitungsstand<br />
! align="center" | zuletzt bearbeitet am<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 4<br />
| Anfrage eingegangen am|<br />
| Anfrage| Arbeitsgruppe „Weiterentwicklung Klinische Dokumentenklassenliste (KDL)“.<br />
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.<br />
Das aktuelle Mapping liegt der Geschäftsstelle vor und ist bisher mit Angela Merzweiler gemeinsam abgestimmt wurden.<br />
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.<br />
Beispiel:<br />
Ich möchte daher anregen bzw. beantragen, dass die KDL im ersten Schritt offiziell als CodeSystem in das Value Set „EventCodeList“ aufgenommen wird.<br />
Damit haben Hersteller von IHE-konformen Archiven, o. ä. die Möglichkeit, wenigstens die Klassifizierung des Dokuments mittels KDL offiziell abzubilden.<br />
· Code System Name: Klinische Dokumentenklassen Liste (KDL)<br />
· Code System ID: 1.2.276.0.76.3.1.191.0.1.1, versionsabhängig<br />
· Kommentar: Klassifizierung von Dokumenten und Daten als Beispiele für die Value Sets classCode und typeCode<br />
Mittelfristig soll die KDL zu einem terminologischen System mit ontologischem Ansatz ausgebaut werden.<br />
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.<br />
Ich freue mich, wenn wir es gemeinsam schaffen, dazu einen persönlichen Termin für ein Arbeitstreffen zu finden.<br />
| betrifft Codesystem | eventCode<br />
| Autor der Anfrage | AMü<br />
| 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<br />
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)<br />
| Entscheidung | grundsätzlich zugestimmt, neues Valueset <br />
| Action Item | Annett=> Beschreibung des ValueSets im Codesystem korrigieren lassen, URN des Codesystems anpassen, Frank ==> abschließende Prüfung, anschließend Aufnahme als eventCode, alle=> Mapping prüfen<br />
| Bearbeitungsstand | in Bearbeitung (Annett / alle)<br />
| zuletzt bearbeitet am| 10.07.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 6<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Ansatz Canonical URLs diskutieren<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | Tarik Idris<br />
| Diskussion| Ziel: Gute Einfügung in FHIR Umgebung<br />
| Entscheidung | Für V3 alle URNs durch URLs ersetzen <br />
| 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 <br />
| Bearbeitungsstand | in Bearbeitung (Angela)<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 7<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Deutscher Implementation Guide für MHD Profile mit Verweis auf unsere Valuesets<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | SH über Tarik<br />
| 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 <br />
| 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 <br />
| Action Item | Simone um Referenz der Codes in Deutschen Basisprofilguideline bitten <br />
| Bearbeitungsstand | als Issues in Gitlab eingetragen (Angela)<br />
| zuletzt bearbeitet am| 07.08.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 19<br />
| Anfrage eingegangen am| 10.07.2020<br />
| 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<br />
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:<br />
Bestehenden Code ALLG - „Allgemeinmedizin“ neu bezeichnen als „Facharzt für Allgemeinmedizin<br />
(Hausarzt)“<br />
2. Neuen Code einführen für „Praktischer Arzt/Arzt (Hausarzt)“. Vorschlag: PRAK<br />
3. Neuen Code einführen für „Hausärztlich tätiger Internist (Hausarzt)“. Vorschlag: HINT<br />
4. Bestehenden Codes ORTH neu bezeichnen als „Orthopädie und Unfallchirurgie“.<br />
5. Neuen Code einführen für „Rheumatologie (Orthopädie)“. Vorschlag: ORRH.<br />
6. Neuen Code einführen für „Infektiologie“. Vorschlag: INFK<br />
7. Neuen Code einführen für „Kinder-Pneumologie“. Vorschlag: KIPN<br />
8. Neuen Code einführen für „Nervenheilkunde/Neurologie und Psychiatrie“. Vorschlag: NERV<br />
9. Neuen Code einführen für „Psychotherapeutisch tätiger Arzt“. Vorschlag: PTAR<br />
10. Neuen Code einführen für „Psychologischer Psychotherapeut“. Vorschlag: PPTH<br />
11.Neuen Code einführen für „Kinder- und Jugendlichen-Psychotherapeut“. Vorschlag: KJPP<br />
| betrifft Codesystem | Practice Setting Code<br />
| Autor der Anfrage | SR (KBV)<br />
| 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.<br />
| 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, Psychotherapie wird bei nichtärztlichen PracticeSettingCodes hinzugefügt<br />
| Action Item | Mapping prüfen und in Implementation Guide eintragen.<br />
| Bearbeitungsstand | Mapping zur Überprüfung an alle versandt, Psychotherapie bei nichtärztlichen PracticeSettingCodes hinzugefügt (Angela)<br />
| zuletzt bearbeitet am| 07.08.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 20<br />
| Anfrage eingegangen am| 10.07.2020<br />
| 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:<br />
<br />
Unterkategorien von 1a - Code<br />
<br />
Hausarzt/ Hausärztin - practitioner<br />
<br />
Krankenhaus - hospital<br />
<br />
Labor und Humangenetik - laboratory<br />
<br />
Physiotherapeuten - physiotherapy<br />
<br />
Psychotherapeuten - psychotherapy<br />
<br />
Dermatologie - dermatology<br />
<br />
Urologie/Gynäkologie - gynaecology_urology<br />
<br />
Zahnheilkunde und Mund-Kiefer-Gesichtschirurgie - dentistry_oms<br />
<br />
Weitere Fachärzte/ Fachärztinnen - other_medical<br />
<br />
Weitere nicht-ärztliche Berufe - other_non_medical<br />
<br />
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.<br />
<br />
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.<br />
<br />
Für diesen Code soll ein Code-System "Sonstige Berechtigungen ePA" genutzt werden.<br />
| betrifft Codesystem | Anfrage neues Codesystem / ValueSet für Folder<br />
| Autor der Anfrage | JG (Gematik)<br />
| 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<br />
| Entscheidung |Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte<br />
| Action Item | Gematik beantragt OID für ValueSet bei DIMDI, wir reservieren OID für Codesystem, Gematik ergänzt Definitionen der einzelnen Konzepte<br />
| Bearbeitungsstand | in Diskussion <br />
| zuletzt bearbeitet am| 24.07.2020<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 21<br />
| Anfrage eingegangen am| 31.07.2020<br />
| 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:<br />
<br />
"urn:gematik:ig:KinderuntersuchungsheftUntersuchungen:r4.0"<br />
"urn:gematik:ig:KinderuntersuchungsheftTeilnahmekarte:r4.0"<br />
"urn:gematik:ig:KinderuntersuchungsheftNotizen:r4.0"<br />
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.<br />
<br />
<br />
<br />
Als Anzeigename schlage ich vor:<br />
<br />
· Untersuchungen Kinderuntersuchungsheft<br />
<br />
· Teilnahmekarte Kinderuntersuchungsheft<br />
<br />
· Notizen Kinderuntersuchungsheft<br />
| betrifft Codesystem | FormatCodes<br />
| Autor der Anfrage | Gematik<br />
| Diskussion| <br />
| Entscheidung | <br />
| Action Item | <br />
| Bearbeitungsstand | <br />
| zuletzt bearbeitet am| 07.08.2020<br />
<br />
<br />
<br />
|}<br />
<br />
'''Tabelle abgeschlossene Änderungsanfragen'''<br />
<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! align="left" | Anfrage ID<br />
! align="left" | Anfrage eingegangen am<br />
! align="left" | Anfrage<br />
! align="center" | betrifft Codesystem<br />
! align="center" | Autor der Anfrage<br />
! align="center" | Diskussion<br />
! align="center" | Entscheidung<br />
! align="center" | Action Item<br />
! align="center" | Bearbeitungsstand<br />
! align="center" | zuletzt bearbeitet am<br />
<br />
|- valign="top" <br />
| Anfrage ID| 1<br />
| Anfrage eingegangen am|<br />
| 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:<br />
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<br />
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.<br />
Wir haben somit eine Mischung aus IHE-D-Codes und IHE-PCC/LAB-LOINC-Codes. Inhaltlich/semantisch überschneidet sich das recht munter. Fragen:<br />
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?<br />
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?<br />
Folgende Codes werden vermisst:<br />
im AOK-Projekt haben wir in Ergänzung zu den IHE-D-Codes die folgenden LOINC-Codes als typeCodes verwendet:<br />
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)<br />
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<br />
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<br />
Verschiedene Ausprägungen des Entlassbriefs, um hier anhand der typeCodes eine bessere Sortierung für den Patienten zu ermöglichen:<br />
11490-0: Ärztlicher Entlassbrief<br />
34105-7: Krankenhausentlassbrief (vorläufige/gekürzte Fassung für den Patienten bei der Entlassung)<br />
18842-5: Finales Krankenhausentlassbrief<br />
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.<br />
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.<br />
58410-2: Vollständiges Blutbild<br />
55429-5: Kleines Blutbild<br />
| betrifft Codesystem | class codes, type codes<br />
| Autor der Anfrage | JC <br />
| 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<br />
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.<br />
<br />
| 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.<br />
| 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<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am|21.2.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 2<br />
| Anfrage eingegangen am|<br />
| Anfrage| es scheint in Deutschland Bestrebungen zu geben, Unfallchirurgie mit der Orthopädie zusammenzulegen.<br />
Ab August 2019 wird es im UKD nur noch die „Klinik für Orthopädie und Unfallchirurgie“ geben.<br />
Ist die Einführung einer weiteren Fachabteilung im DocumentEntry.practiseSettingCode geplant?<br />
In DocumentEntry.authorSpecialty findet sie sich:<br />
Code 512 Anzeigename FA Orthopädie und Unfallchirurgie<br />
| betrifft Codesystem | practiceSettingCode <br />
| Autor der Anfrage | SB<br />
| Diskussion| evtl. practiceSettingCode Chirurgie verwenden, deckt beides ab<br />
| Entscheidung |<br />
| Action Item |<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 29.11.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 3<br />
| Anfrage eingegangen am|<br />
| 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.<br />
Dazu möchten wir das Value Set für XDS-Metadatenattribut formatCode um den folgenden Wert erweitern: urn:gematik:ig:DatensatzPersoenlicheErklaerungen:r3.1<br />
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.<br />
| betrifft Codesystem | formatCode<br />
| Autor der Anfrage | RK<br />
| Diskussion| keine Einwände<br />
| Entscheidung | wir fügen Code hinzu<br />
| Action Item | in ArtDecor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am|13.12.2019<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 5<br />
| Anfrage eingegangen am| 31.10.2019<br />
| Anfrage| Freischaltung der FHIR Schnittstelle in ArtDecor<br />
| betrifft Codesystem | alle<br />
| Autor der Anfrage | SH über Tarik Idris<br />
| Diskussion| <br />
| Entscheidung | wird gemacht<br />
| Action Item | Tarik: FHIR Schnittstelle in ArtDecor freischalten<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 15.11.2019<br />
<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 8<br />
| Anfrage eingegangen am| 15.11.2019<br />
| Anfrage| Vorgehensweise für V3 auf eigener WikiSeite beschreiben<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | SL<br />
| Diskussion| befürwortet<br />
| Entscheidung | befürwortet<br />
| Action Item | Anlegen neue Seite im HL7 Wiki ==> Angela, Ziele ==> Angela, allgemeine Weiterentwicklung als Ziel hinzufügen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 13.12.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 9<br />
| Anfrage eingegangen am| 13.12.2019<br />
| Anfrage| Bericht Treffen BVITG, Interopforum, Gematik, Vorabstimmung EPA Version 1.2.2022<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | TI<br />
| 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) <br />
| Entscheidung | über konstruktive Zusammenarbeit wird sich gefreut<br />
| Action Item | keine<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 13.12.2019<br />
<br />
|- valign="top" <br />
| Anfrage ID| 10<br />
| Anfrage eingegangen am| 12.01.2020<br />
| 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.<br />
https://loinc.org/file-access/download-id/8994/<br />
| betrifft Codesystem | alle <br />
| Autor der Anfrage | ST<br />
| Diskussion| <br />
| Entscheidung | Gemeinsame Strategietelko zur Zusammenführung LOINC, SNOMED CT, XDT, QMS, KDL deutsche XDS Value Sets am 28.5.2020 10-12 Uhr geplant<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 24.04.2020<br />
<br />
<br />
|- valign="top" <br />
| Anfrage ID| 11<br />
| Anfrage eingegangen am| 07.02.2020<br />
| Anfrage| Zusammenarbeit KBV<br />
| betrifft Codesystem | alle, v.a. format Code<br />
| Autor der Anfrage | RK<br />
| Diskussion| Den MIOs müssen XDS Metadaten zugeordnet werden, v.a. formatCodes<br />
| Entscheidung | Arbeitsgruppe bietet proaktiv Hilfe bzgl. der Metadaten bei KBV an<br />
| Action Item | Mail an Vorstand ==> Mail an KBV (H. Tenkow)<br />
| Bearbeitungsstand | Mail an Vorstand gesendet<br />
| zuletzt bearbeitet am| 07.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 12<br />
| Anfrage eingegangen am| 21.02.2020<br />
| 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<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | RK<br />
| Diskussion| keine Einwände<br />
| Entscheidung | werden aufgenommen<br />
| Action Item | Aufnahme in ArtDecor ==> Angela<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 24.02.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 13<br />
| Anfrage eingegangen am| 06.03.2020<br />
| Anfrage| Übersetzung der Metadatenbezeichnungen ins Englische<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | SL<br />
| Diskussion| ValueSets sind nur für Deutschland, jeder Dokumentierende sollte über ausreichende Deutschkenntisse verfügen<br />
| Entscheidung | abgelehnt<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 06.03.2020<br />
|- valign="top" <br />
<br />
|- valign="top"<br />
| Anfrage ID| 14<br />
| Anfrage eingegangen am| 24.04.2020<br />
| Anfrage| Neuer FormatCode für eRezept (Daten elektronischer Verordnung) der Gematik<br />
| betrifft Codesystem | format Code<br />
| Autor der Anfrage | RK<br />
| 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<br />
| Entscheidung | urn:gematik:ig:VerordnungsdatensatzMedikation:r4.0<br />
| Action Item | in Art Decor eintragen<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
<br />
<br />
|- valign="top" <br />
<br />
<br />
| Anfrage ID| 15<br />
| Anfrage eingegangen am| 14.05.2020<br />
| Anfrage| Kommentierung EPA XDS Metadaten<br />
| betrifft Codesystem | fast alle<br />
| Autor der Anfrage | TI<br />
| Diskussion| <br />
| 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<br />
| Action Item | Tarik==> Kommentar an gematik<br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 18.05.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 16<br />
| Anfrage eingegangen am| 14.05.2020<br />
| 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. <br />
| betrifft Codesystem | TypeCode<br />
| Autor der Anfrage | VK<br />
| Diskussion| <br />
| Entscheidung | wird als Beispiel in pathologische Befunde aufgenommen<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
|- valign="top" <br />
<br />
| Anfrage ID| 17<br />
| Anfrage eingegangen am| 14.05.2020<br />
| Anfrage| Am UKHD gibt es ein Zentrum für Seltene Erkrankungen. Dort werden Patienten jeglichen Alters behandelt. <br />
| betrifft Codesystem | PracticeSettingCode<br />
| Autor der Anfrage | VK<br />
| Diskussion| <br />
| 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<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
|- valign="top" <br />
| Anfrage ID| 18<br />
| Anfrage eingegangen am| 26.06.2020<br />
| Anfrage| Code für Erfassung Fall- /Bewegungsdaten<br />
| betrifft Codesystem | Class Code, Type Code<br />
| Autor der Anfrage | AM<br />
| 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<br />
| Entscheidung | keine zusätzlichen Codes<br />
| Action Item | <br />
| Bearbeitungsstand | erledigt<br />
| zuletzt bearbeitet am| 26.06.2020<br />
<br />
<br />
<br />
|}<br />
<br />
'''Tabelle Aktueller Stand'''<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! width="25%" align="left" | Codesystem<br />
! align="center" | Stand Konzepte<br />
! align="center" | ArtDecor<br />
! align="center" | WikiText<br />
! align="center" | Review durch<br />
<br />
|- valign="top" <br />
| Codesystem | Vokabular Management & Einführung<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | abgeschlossen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | Confidentiality Code<br />
| Stand Konzepte | abgeschlossen<br />
| ArtDecor | abgeschlossen<br />
| WikiText | abgeschlossen<br />
| Review durch | Antje<br />
<br />
|- valign="top" <br />
| Codesystem | AuthorRole<br />
| Stand Konzepte | Review notwendig<br />
| ArtDecor | abgeschlossen<br />
| WikiText | abgeschlossen<br />
| Review durch | Antje, Angela<br />
<br />
|- valign="top" <br />
| Codesystem | AuthorSpeciality<br />
| Stand Konzepte | vorläufig abgeschlossen<br />
| ArtDecor | abgeschlossen<br />
| WikiText | abgeschlossen<br />
| Review durch | Antje, Angela<br />
<br />
|- valign="top" <br />
| Codesystem | EventCodeList<br />
| Stand Konzepte | aus XDS-I, XDW schon Codes vorgegeben weitere müssen noch gesammelt werden, Ideen stehen bereit, Arnold (Aufenthaltsart) und Antje (Warnungen) erarbeiten finale Version<br />
| ArtDecor | abgeschlossen<br />
| WikiText | offen<br />
| Review durch | Angela<br />
<br />
|- valign="top" <br />
| Codesystem | ContentTypecode<br />
| Stand Konzepte | Vorschlag erstellt, gemeinsames Review nötig<br />
| ArtDecor | abgeschlossen<br />
| WikiText | abgeschlossen<br />
| Review durch | Tarik, Antje, Angela<br />
<br />
|- valign="top" <br />
| Codesystem | ClassCode<br />
| Stand Konzepte | erledigt<br />
| ArtDecor | abgeschlossen<br />
| WikiText | abgeschlossen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | TypeCode<br />
| Stand Konzepte | mehrere offene Kommentare<br />
| ArtDecor | offen<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | FormatCode<br />
| Stand Konzepte | offene Kommentare zu FHIR Formaten / Medikationsplan, Änderungen durch neuen code "mimeTypeSufficient"<br />
| ArtDecor | offen (für Medikationsplan)<br />
| WikiText | offen (für Medikationsplan)<br />
| Review durch | <br />
<br />
|}<br />
<br />
'''To dos'''<br />
:{|class="hl7table sortable" <br />
|- <br />
! width="5%" align="center" |#<br />
! width="10%" align="center" |Pkg<br />
! width="10%" align="center" |Sub-Pkg<br />
! width="25%" align="left" |Task<br />
! width="15%" align="left" |Wer?<br />
! width="5%" align="left" |bis? <br />
! align="left" |Anmerkungen<br />
!| Status<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 16<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | ConfidentialityCode<br />
| Aktion | Confidentiality Code ArtDecor überprüfen<br />
| Wer? | Tarik Idris<br />
| bis wann? | 26.03.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 17<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | ConfidentialityCode<br />
| Aktion | Confidentiality Code Beschreibung verfassen<br />
| Wer? | Tarik Idris<br />
| bis wann? | 26.03.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 18<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | AuthorRole<br />
| Aktion | AuthorRole Definitionen der Prozessrollen verfassen<br />
| Wer? | Frank Oemig<br />
| bis wann? | 26.03.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 19<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | AuthorRole<br />
| Aktion | AuthorRole Definitionen der Beziehungsrollen verfassen<br />
| Wer? | offen<br />
| bis wann? | <br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 20<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | AuthorRole<br />
| Aktion | AuthorRole in ArtDecor eintragen<br />
| Wer? | Angela<br />
| bis wann? | <br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 21<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | AuthorRole<br />
| Aktion | AuthorRole Beschreibungstext verfassen<br />
| Wer? | Tarik<br />
| bis wann? | 15.05.<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 22<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | AuthorSpeciality<br />
| Aktion | AuthorSpeciality Codesystem: im ärztlichen Bereich Qualifikation mit berücksichtigen: Zusatzbezeichungen zur vorläufigen Liste hinzufügen<br />
| Wer? | Antje Brandner<br />
| bis wann? | 06.04.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 23<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | AuthorSpeciality<br />
| Aktion | AuthorSpeciality Codesystem: Berufsgruppe: Arzt, nichtärztlichen Berufsgruppen (ohne Qualifikation) (aus ZTG Liste der Gruppen erarbeiten, für KH interne Beruf granularer als außerhalb), mit einer Hierarchie die Berufsgruppen und Berufe vereint <br />
| Wer? | Angela Merzweiler<br />
| bis wann? | 06.04.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 24<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | AuthorSpeciality<br />
| Aktion | AuthorSpeciality für Facharzttitel in ArtDecor anpassen<br />
| Wer? | Tarik Idris<br />
| bis wann? | 03.05.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 25<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | AuthorSpeciality<br />
| Aktion | AuthorSpeciality Beschreibungstext verfassen<br />
| Wer? | Angela<br />
| bis wann? | 15.05.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 26<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | EventCodes<br />
| Aktion | notwendige EventCodes versenden<br />
| Wer? | Angela Merzweiler<br />
| bis wann? | 12.03.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 27<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | EventCodes<br />
| Aktion | Arnold (Aufenthaltsart) und Antje (Warnungen) erarbeiten finale Version<br />
| Wer? | Arnold, Antje<br />
| bis wann? | 26.04.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 28<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | EventCodes<br />
| Aktion | EventCodes in ArtDecor eintragen<br />
| Wer? | Angela<br />
| bis wann? | <br />
| Anm. | eigene Codes eingetragen<br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 29<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | EventCodes<br />
| Aktion | Beschreibung zu EventCodes verfassen<br />
| Wer? | Tarik<br />
| bis wann? | 17.05.2018<br />
| Anm. | <br />
| Status | offen<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 30<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | ContentTypeCodes<br />
| Aktion | ContentTypeCodes zusammenstellen<br />
| Wer? |Sven Lüttmann<br />
| bis wann? | 26.04.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 31<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | ContentTypeCodes<br />
| Aktion | ContentTypeCodes in ArtDecor eintragen<br />
| Wer? | Angela<br />
| bis wann? | <br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 32<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | ContentTypeCodes<br />
| Aktion | Beschreibungstext zu ContentTypeCodes verfassen<br />
| Wer? | Sven<br />
| bis wann? | <br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 33<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | Vokabular-Management<br />
| Aktion | Übersichtstabelle mit Eigenschaften der definierten ValueSets um die Neuen erweitern<br />
| Wer? | Tarik<br />
| bis wann? | <br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 34<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | Class Codes<br />
| Aktion | Medikationen nicht löschen, sondern als deprecated markieren<br />
| Wer? | Angela<br />
| bis wann? | 06.04.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 35<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | Format Code<br />
| Aktion | mimeTypeSufficient hinzufügen und FHIR Mime Type erläutern<br />
| Wer? | Tarik Idris<br />
| bis wann? | 03.05.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 36<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | AuthorSpeciality<br />
| Aktion | nichtärztlich Berufsgruppen in ArtDecor eintragen<br />
| Wer? | Angela Merzweiler<br />
| bis wann? | 12.04.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 37<br />
| Pkg | Abstimmungsverfahren<br />
| Sub-Pkg | Ankündigung<br />
| Aktion | Ankündigung verfassen, über interopforum und IHE Mitgliederliste verteilen, IHE-D Homepage anpassen<br />
| Wer? | Angela Merzweiler<br />
| bis wann? | 17.04.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 38<br />
| Pkg | Abstimmungsverfahren<br />
| Sub-Pkg | Vorbereitung Abstimmungsverfahren<br />
| Aktion | Kommentierungsdokumente bereitstellen (PDF, Excel)<br />
| Wer? | Angela<br />
| bis wann? | 18.05.2018<br />
| Anm. | <br />
| Status | offen<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 39<br />
| Pkg | Abstimmungsverfahren<br />
| Sub-Pkg | Vorbereitung Abstimmungsverfahren<br />
| Aktion | Ankündigungsschreiben anpassen, über interopforum und IHE Mitgliederliste verteilen<br />
| Wer? | Angela<br />
| bis wann? | 18.05.2018<br />
| Anm. | <br />
| Status | offen<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 40<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | ClassCode<br />
| Aktion | Abstimmung eines Kommentars<br />
| Wer? | Angela Merzweiler<br />
| bis wann? | <br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 41<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | ClassCode<br />
| Aktion | Änderungen in ArtDecor eintragen<br />
| Wer? | Angela Merzweiler<br />
| bis wann? | <br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 42<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | TypeCode<br />
| Aktion | über Änderungen abstimmen lassen <br />
| Wer? | Angela Merzweiler<br />
| bis wann? | <br />
| Anm. | <br />
| Status | offen<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 43<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | TypeCode<br />
| Aktion | Änderungen in ArtDecor eintragen<br />
| Wer? | Angela Merzweiler<br />
| bis wann? | <br />
| Anm. | <br />
| Status | offen<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 44<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | FormatCode<br />
| Aktion | über Änderungen abstimmen lassen <br />
| Wer? | <br />
| bis wann? | <br />
| Anm. | <br />
| Status | offen<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 45<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | FormatCode<br />
| Aktion | Änderungen in ArtDecor eintragen<br />
| Wer? | Angela Merzweiler<br />
| bis wann? | <br />
| Anm. | <br />
| Status | offen<br />
<br />
|} <br />
<br />
'''IG Struktur'''<br />
<br />
# [[ihevs:Einleitung]] (Vorgehen, Ziele, Umgang mit v1, normativ, Delta-Liste?, Änderungen/Pflege)<br />
# [[Ihevs:Vokabular-Management]]<br />
# [[ihevs:DocumentEntry.authorRole]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.authorSpecialty]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.classCode]]<br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.confidentialityCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.eventCodeList]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.formatCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.healthcareFacilityTypeCode]]<br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.languageCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.practiceSettingCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.typeCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:SubmissionSet.contentTypeCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:Folder.codeList]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor<br />
<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=OID-Konzept_IHE-D&diff=68339OID-Konzept IHE-D2020-07-24T12:09:39Z<p>Tidris: </p>
<hr />
<div><!--<br />
<br />
OID-Konzept von IHE Deutschland<br />
--><br />
{{Infobox Dokument<br />
|Title OID-Konzept von IHE Deutschland<br />
|Short = OID-Konzept IHE-D<br />
|Namespace = cdaab2<br />
|Type = Konzept<br />
|Version = 0.2<br />
|Submitted = .<br />
|Date = 14. Oktober 2015<br />
|Copyright = 2012<br />
|Status = Entwurf<br />
|Period = Entwurf<br />
|OID = n.n.<br />
|Realm = Deutschland<br />
}}<br />
<br />
<br />
[[file:IHE Deutschland final rgb web.jpg|200px|Logo IHE-D]]<br />
<br />
=OID Konzept von IHE-Deutschland=<br />
<br />
==Root-OID==<br />
Als root-OID für IHE Deutschland wurde 1.3.6.1.4.1.19376.3.276 vergeben:<br /><br />
<br />
<blockquote><br />
1 = International Organization for Standardization (ISO)<br /><br />
3 = Organization identification schemes registered according to ISO/IEC 6523-2<br /><br />
6 = United States Department of Defense (DoD)<br /><br />
1 = internet<br /><br />
4 = Internet Assigned Numbers Authority (IANA)<br /><br />
1 = Private enterprises<br /><br />
19376 = Integrating the Healthcare Enterprise International<br /><br />
3 = Organizations<br /><br />
276 = IHE Deutschland<br /><br />
</blockquote><br />
<br />
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.<br />
<br />
==Aufbau des OID-Baums für IHE-D==<br />
{| class="hl7table"<br />
|-<br />
!Extension (Sub-Branch/Type) !! Beschreibung !! Bemerkung<br />
|-<br />
! *.1 !! OID für das OID Konzept Version 1 !!<br />
|-<br />
|.1.1|| Interne Objekte || interne Artefacts wie Modelle<br />
|-<br />
|.1.1.1 || Ordnertypen || <br />
|-<br />
|.1.1.2 || Auswahllisten || <br />
|-<br />
|.1.1.3 || Mitarbeiter || <br />
|-<br />
! *.1.2 !! interne Organisationsstrukturen !!<br />
|-<br />
! *.1.3 !! Instanzen-Identifikationen !!<br />
|-<br />
|.1.3.1 || Organisationen || <br />
|-<br />
|.1.3.2 || Personen || <br />
|-<br />
|.1.3.2.1 || Identifikation des ID-Pools für Patienten || <br />
|-<br />
|.1.3.2.2 || Identifikation des ID-Pools für Personen allgemein (Ärzte, Betreuer, Kontakte, etc.) || <br />
|-<br />
|.1.3.3 || Identifikation des ID-Pools für Fälle || <br />
|-<br />
! *.1.4 !! Identifikation des ID-Pools für Institutionen (Organisationen, Einheiten, etc.) !! Allgemeine Identifikationsmechanismen wie Personalausweis usw.<br />
|-<br />
|.1.4.1 || Krankenhäuser || Wenn möglich, soll ein Krankenhaus eine eigene OID bei DIMDI beantragen<br />
|-<br />
|.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.<br />
|-<br />
|.1.4.3 || Systeme || Alle angeschlossenen Systeme bekommen eine OID. Unterhalb des Systems werden ggfs. ebenfalls bestimmte Subtypen definiert.<br />
|-<br />
! *.1.5 !! '''Kodierschemas''' !!<br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.1 || derzeit unbenutzt<br />
|-<br />
|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<br />
|-<br />
|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<br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.4 || Practice Setting Code (ärztl. Fachrichtungen) || 1.2.276.0.76.11.69<br />
|-<br />
|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<br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.6 || XDS formatCode (vgl. URN-Konzept) || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.7 || XDS Folder.codeList || 1.2.276.0.76.11.40<br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.8 || XDS classCode || 1.2.276.0.76.11.32<br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.9 || XDS typeCode || 1.2.276.0.76.11.38<br />
|-<br />
|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<br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.11 || Authorspecialty (nicht ärztliche Berufe) || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.12 || SubmissionSet Contenttype Code || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.13 || Authorrole Prozessrollen || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.14 || Authorrole Patientenbeziehungsrollen || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.15 || EventCodeList "Hinweise"/"Informationen" /"Warnungen" || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.16 || EventCodeList "Ereignisse CS#1: Aufnahme - Verlegung - Entlassung" || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.5.17 || Reserviert für gematik ePA 2.0 Zwecke (am 24.07.2020 durch die AG beschlossen; Entscheidung zur Veröffentlichung als Teil des Leitfades steht noch aus) || <br />
|-<br />
!*.1.6 !! Metadaten !!<br />
|-<br />
|.1.6.1 || Ordner-Metadaten || <br />
|-<br />
!*.1.7 !! '''Dokumente''' !! <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.7.1 || OID-Konzept || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.7.2 || Identifikation des ID-Pools für CDA-Dokumente || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.7.3 || Identifikation des ID-Pools für externe Dokumente (in CDAs verlinkt) || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.7.4 || IHE_D Cookbook || <br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.7.5 || Value-Set-Leitfaden (Vers. 1.0, Nov.2016) || <br />
|-<br />
! *.1.9 !! Nachrichtenprofile !!<br />
|-<br />
|... || ||<br />
|-<br />
! *.1.10 !! Interne Templates !! <br />
|-<br />
|.1.10.1 || Document Templates || <br />
|-<br />
|.1.10.1.1 || root-OID für Template-Ids || <br />
|-<br />
|.1.10.2 || Section Templates || <br />
|-<br />
|.1.10.2.1 || Identifikation des ID-Pools für CDA-Formularteile || <br />
|-<br />
|.1.10.3 || Entry Templates || <br />
|-<br />
! *.1.11 !! '''Value Sets''' !!<br />
|-<br />
|1.3.6.1.4.1.19376.3.276.1.11.1 || ''IHEXDSclassCode: Dokumentenart'' '''deprecated, stattdessen 1.2.276.0.76.11.32 verwenden''' || <br />
|-<br />
|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''' || <br />
|-<br />
|... || ||<br />
|-<br />
! *.1.12 !! Deutsch-spezifische Erweiterungen von seitens der Organisation/Firma verwalteten Kodierschemas !!<br />
|-<br />
|... || ||<br />
|-<br />
! *.1.15 !! Kodierschemas seitens Organisation/Firma verwaltet !!<br />
|-<br />
|... || ||<br />
|-<br />
! *.1.60 !! Projekte !!<br />
|-<br />
|... || ||<br />
|-<br />
! *.1.64 !! Policy !!<br />
|-<br />
|... || ||<br />
|-<br />
! *.1.67 !! Installations-Instanzen von Softwaresystemen !!<br />
|-<br />
|... || ||<br />
|-<br />
!*.1.77 !! ART-DECOR !!<br />
|-<br />
|... || ||<br />
|-<br />
!*.1.99 !! Experimentell / Test !!<br />
|-<br />
|... || ||<br />
|}<br />
<br />
== Fußnoten ==<br />
<references /></div>Tidrishttps://wiki.hl7.de/index.php?title=FHIR-Markt%C3%BCbersicht&diff=63221FHIR-Marktübersicht2020-03-18T20:08:36Z<p>Tidris: </p>
<hr />
<div>{{Underconstruction}}<br />
<br />
Diese Seite dient der Orientierung und soll eine grobe Einschätzung der Verbreitung von FHIR in Deutschland erlauben.<br />
<br />
=FHIR-Produkte auf dem Deutschen Markt=<br />
<br />
{| class="hl7table"<br />
!Hersteller!!Produkt/Modul!!Beschreibung!!Rolle!!Ressourcen (Profile)!!FHIR-Version!!Status!!IHE-Profile!!Capability-Statement<br />
|-<br />
|[http://nursit-institute.de/de/startseite/ NursIT Institute]||CareIT Pro||Pflegedokumentationssystem, Pflegeplanung, Bettenbelegung, Questionnaire-Designer||Smart-App Client + SmileCDR Server||Encounter<br/>Patient<br/>Questionnaire<br />QuestionnaireResponse<br/>Procedure<br/>ProcedureRequest<br/>CarePlan<br/>Observation<br/>||STU3||produktiv||-||<br />
|-<br />
|[https://www.sap.com/industries/healthcare.html SAP SE]||SAP Health for Waiting Time Management||Verwaltung und Vorhersage von individuellen Wartezeiten von Patienten in der Notaufnahme und ambulanten Versorgung (siehe Disclaimer und Product Roadmap [https://www.sap.com/products/roadmaps.industry.html#pdf-asset=9435cfc6-c37c-0010-82c7-eda71af511fa&page=1 hier]) ||Cloud Anwendung für Krankenhäuser und Ambulanzen für den Patienten als Konsumenten||Bundle<br/>MessageHeader<br/>Patient<br/>Encounter<br/>Organization<br/>Observation<br/>Location<br/>||STU3||produktiv||-||<br />
|-<br />
|[https://www.sap.com/industries/healthcare.html SAP SE]||SAP S/4HANA Healthcare for Patient Accounting||Patientenabrechnung für Leistungserbringer im Gesundheitswesen (siehe Disclaimer und Product Roadmap [https://www.sap.com/products/roadmaps.industry.html#pdf-asset=9435cfc6-c37c-0010-82c7-eda71af511fa&page=1 hier]) ||Cloud-Anwendung für Patientenabrechner||Patient<br/>EpisodeOfCare<br/>Encounter<br/>Coverage<br />ChargeItem<br/>Invoice<br/>||STU3 und R4||in Entwicklung||-||<br />
|-<br />
|[https://www.ibm.com/de-de/ IBM]||eGA (elektronische Gesundheitsakte)||Elektronische Gesundheitsakte für Versicherte der Techniker Krankenkasse ||App||Claim<br/>DocumentReference<br/>Encounter<br/>Immunization<br/>Medication<br/>MedicationDispense<br/>MedicationRequest<br/>Organization<br/>Practitioner||STU3||in Entwicklung||-||<br />
|-<br />
|[http://dmi.de DMI]||Archivar 4.0||Dokumentenmanagement in der Langzeitarchivierung||FHIR-Server||Patient<br/> Encounter<br/> DocumentReference<br/> Binary||STU3/R4||produktiv/in (Weiter-)Entwicklung||MHD||<br />
|-<br />
|[https://www.corpuls.world GS Elektromedizinische Geräte G. Stemple GmbH]||corpuls.web<br/>LIVE||Telemedizinsoftware zur Liveübertragung von EKGs, Vitalwerten und Patientendaten in der präklinischen Notfallmedizin. Als eigenständiges Medizinprodukt ist es zur Diagnose und Einholung eines Telekonsils im Rettungsdienst und Klinikumfeld zugelassen.||Webanwendung für Telekonsil, Schnittstelle zwischen corpuls Geräten und Drittsoftware||Bundle<br/>CapabilityStatement<br/>(Device)<br/>Encounter<br/>Patient<br/>(Procedure)<br/>Observation||R4||produktiv||-||<br />
|-<br />
|[http://www.icw.de ICW]||ICW eHealth Suite||Master Patient Index, Provider Directory, Document and Image Exchange, Clinical Data Repository, Integrated Forms, Appointments||FHIR-Server||Patient<br/> Encounter<br/> DocumentReference<br/> Binary<br/> Procedure<br/> ProcedureRequest<br/> Observation<br/> Condition<br/> Medication<br/> MedicationStatement<br/> MedicationDispense<br/> MedicationAdministration<br/> Questionnaire<br/> QuestionnaireResponse<br/> Appointment<br/> Practitioner<br/> PractitionerRole<br/> Organization<br/> Device<br/> ||STU3||produktiv||PIXm, PDQm, MHD, mCSD, QEDm||<br />
|-}<br />
{{fmbox<br />
| image = [[Bild:Attention_icon.svg|50px]]<br />
| text = Die hier aufgeführten Informationen bestehen aus der Selbstauskunft der Hersteller. Diese Liste stellt keine Empfehlung von HL7 Deutschland e.V. dar. Auch wird die tatsächliche Kompatibilität der Produkte zum FHIR-Standard zum jetzigen Zeitpunkt nicht vom [[TC_FHIR|Technischen Komitee für FHIR]] überprüft.<br />
}}<br />
<br />
==Herstellerübergreifende FHIR-Projekte und Leitfäden in Deutschland==<br />
<br />
{| class="hl7table"<br />
!Beteiligte Organisationen!!Projekt!!Beschreibung!!Akteure/Rollen!!Resourcen (Profile)!!FHIR-Version!!Status!!IHE-Profile!!verwendete Produkte/Tools<br />
|-<br />
|Hochschule Niederrhein http://hsnr.de||[http://medikationsplan-plus.de MedikationsplanPlus]||FHIR dient neben CDA als strukturierte Darstellungsform für den Medikationsplan. Zudem erhält der auf dem papiergebundenen Medikationsplan aufgedruckte Barcode ein Ultrakurzformat, aus dem die Inhalte der FHIR-Resourcen wiederhergestellt werden können||Erzeuger des Medikationsplans <br /> Konsumenten des Medikationsplans||Patient<br />Composition<br />List<br />MedicationStatement<br />Medication||STU3||in Entwicklung||-||Simplifier/Forge<br />
|-<br />
|Hochschule Niederrhein http://hsnr.de||[http://www.genealyse.de Genealyse]||FHIR dient neben CDA als strukturierte Darstellungsform für den Genetic Testing Report.||Erzeuger des GTR <br /> Konsumenten des GTR||Patient<br />Composition<br />List<br />MedicationStatement<br />Medication||STU3||in Entwicklung||-||Simplifier/Forge<br />
|-<br />
|[http://dmi.de DMI]<br/>[https://dvmd.de/ DVMD]||[https://www.dmi.de/wissen/kdl/ Konsoliderte Dokumentenliste]||Publikation der KDL (einheitliche Terminologie für die Benennung von Dokumenttypen) sowie der Mappings auf IHE-DE Type- und Classcodes als FHIR-Terminologie-Ressourcen||-||ValueSet<br/>CodeSystem<br/>ConceptMap||STU3/R4||Publikation in Vorbereitung||-||Simplifier<br />
|-<br />
|UKs Aachen, Bonn, Düsseldorf, Essen, Halle, Hamburg-Eppendorf, Jena, Leipzig, Rostock, HL7 Deutschland u.a.||[http://www.smith.care Smart Medical Information Technology for Healthcare (SMITH)]||neben IHE-XDS-Infrastrukturen werden in den [https://www.medizininformatik-initiative.de/de/start Datenintegrationszentren] von SMITH FHIR-Server die zentrale Vorhaltung von / Zugriffsmöglichkeit auf Daten der Krankenversorgung bilden, die für spezifische Forschungsprojekte zur Nutzung bereitgestellt werden||Krankenversorger<br /><br />Forscher||Patient<br />Encounter<br />Condition<br />Procedure<br />Observation<br />Medication<br />DiagnosticReport<br />Specimen<br />Provenance<br />Consent<br />Questionnaire<br />ResearchStudy<br />Group<br />Organization<br />etc.||STU3 (Umstellung auf R4 in Planung)||in Entwicklung||-||ART-DECOR<br />Simplifier<br />
|-<br />
|[https://www.uniklinikum-jena.de/gbit/Projekte.html Universitätsklinikum Jena]||ESSENZ||Beschreibung und Umsetzung essenzieller Bestandteile universitätsmedizinischer Dokumentation am UK Jena inkl. notwendiger Mappings, die perspektivisch von allen IT-Subsystemen auf Basis von FHIR kommuniziert und synchronisiert werden sollen (Anbindung von FHIR an ein VNA als Plattformstrategie)||Erzeuger klinischer Dokumentation<br /><br />Konsumenten klinischer Dokumentation||Patient<br />Encounter<br />Condition<br />Procedure<br />Observation<br />Practitioner<br />Organization<br />etc.||STU3 (Umstellung auf R4 in Planung)||in Entwicklung||-||Simplifier (geplant)<br />
|-<br />
|[https://www.hs-osnabrueck.de/forschungsgruppe-informatik-im-gesundheitswesen/ Hochschule Osnabrück]||ePflegebericht||[https://simplifier.net/GermaneNursingSummary/~resources?category=Profile&fhirVersion=R4&sortBy=RankScore_desc Darstellung des ePflegeberichts in HL7-FHIR]||primär Pflegekräfte, als Empfänger auch Ärzte, Patienten und Angehörige möglich||Bundle<br/>Coding<br/>Composition<br/>Condition<br/>Device<br/>DeviceRequest<br/>Goal<br/>Observation<br/>Patient<br/>Procedure<br/>RelatedPerson||R4||in Entwicklung||-||Simplifier, Forge<br />
|-<br />
|[https://www.hs-osnabrueck.de/forschungsgruppe-informatik-im-gesundheitswesen/ Hochschule Osnabrück]||eWundbericht||[https://simplifier.net/PosiThera Darstellung des eWundberichts in HL7-FHIR]||alle an der Wundversorgung beteiligten Professionen (z.B. Pflegekräfte, Ärzte, Wundmanager), als Empfänger auch Patienten und Angehörige möglich||AllergyIntolerance<br/>BodyStructure<br/>Bundle<br/>Composition<br/>Condition<br/>DeviceDefinition<br/>DocumentReference<br/>Goal<br/>Observation<br/>Procedure<br/>RiskAssessment||R4||in Entwicklung||-||Simplifier, Forge<br />
|}<br />
{{fmbox<br />
| image = [[Bild:Attention_icon.svg|50px]]<br />
| text = Die hier aufgeführten Informationen bestehen aus der Selbstauskunft der Organisationen. Die Nennung der Projekte impliziert keine Beteiligung von HL7 Deutschland e.V., es sei denn in der Spalte "Beteiligte Organisationen" explizit genannt.<br />
}}<br />
<br />
==FHIR-Projekte International==<br />
siehe http://wiki.hl7.org/index.php?title=National_FHIR_Projects</div>Tidrishttps://wiki.hl7.de/index.php?title=IG:Value_Sets_f%C3%BCr_XDS&diff=63167IG:Value Sets für XDS2020-02-07T12:28:41Z<p>Tidris: </p>
<hr />
<div><!--<br />
<br />
Implementierungsleitfaden "Value Set"<br />
<br />
--><br />
{{Infobox Dokument<br />
|Title = Value Sets für Aktenprojekte im deutschen Gesundheitswesen<br />
|Short = Value Sets für XDS<br />
|Namespace = ihevs<br />
|Type = Implementierungsleitfaden<br />
|Version = 2.0<br />
|Submitted = IHE Deutschland<br />
|Date = 09.10.2018<br />
|Copyright = 2018<br />
|Status = Final<br />
|Period = Final<br />
|OID = 1.3.6.1.4.1.19376.3.276.1.7.6<br />
|Realm = Deutschland<br />
|Custodian = IHE<br />
}}<br />
<br />
{{Infobox Ballot Begin}}<br />
{{Ballot | Version = 0.1 | Date = 23.05.2016 | Status = Draft | Realm = Deutschland| Othericon = x<br />
| Otherdocuments = http://download.hl7.de/documents/ihexdsvs/Value_Sets4XDS-v01.pdf<br />
| Comment =<br />
}}<br />
{{Ballot | Version = 1.0 | Date = 10.11.2016 | Status = Final | Realm = Deutschland| Othericon = x<br />
| Otherdocuments = http://www.ihe-d.de/download/value-sets-fuer-xds-metadaten<br />
| Comment =<br />
}}<br />
{{Ballot | Version = 1.1 | Date = 22.05.2018 | Status = Draft | Realm = Deutschland| Othericon = x<br />
| Otherdocuments = http://wiki.hl7.de/images/Value_Sets4XDS-v11.pdf<br />
| Comment =<br />
}}<br />
{{Ballot | Version = 2.0 | Date = 09.10.2018 | Status = active| Realm = Deutschland| Othericon = x<br />
| Otherdocuments = http://wiki.hl7.de/images/Value_Sets4XDS-v20.pdf<br />
| Comment =<br />
}}<br />
<br />
{{Infobox Ballot End}}<br />
<br />
{{Infobox Contributors Begin}}<br />
{{Contributor | Logo = Logo_ihe.png | Name = IHE Deutschland| Location = Berlin}}<br />
{{Contributor | Logo = Logo_bvitg.JPG | Name = bvitg (Bundesverband Gesundheits-IT) | Location = Berlin}}<br />
{{Contributor | Logo = Logo_icw.jpg | Name = ICW | Location = Walldorf }}<br />
{{Contributor | Logo = Logo-t-systems.jpg | Name = Deutsche Telekom Healthcare and Security Solutions GmbH | Location = Bonn }}<br />
{{Contributor | Logo = Logo-uk-heidelberg.png | Name = Uniklinik Heidelberg (ZIM) | Location = Heidelberg }}<br />
{{Contributor | Logo = Logo-uk-freiburg.png | Name = Uniklinik Freiburg | Location = Freiburg }}<br />
{{Contributor | Logo = Logo-cerner.jpeg | Name = Cerner | Location = Berlin }}<br />
{{Contributor | Logo = Logo-visus.jpg | Name = VISUS Health IT GmbH | Location = Bochum }}<br />
{{Contributor | Logo = FALKO LOGO.jpg | Name = FALKO.NRW gefördert durch EFRE und das Land Nordrhein-Westfalen|Location=}}<br />
{{Contributor | Logo = Logo-rzv.jpg | Name = RZV Rechenzentrum Volmarstein GmbH | Location = Wetter (Ruhr) }}<br />
{{Infobox Contributors End}}<br />
<br />
{{HL7transclude| ihevs:Einleitung}}<br />
<div class="landscape"><br />
{{HL7transclude| ihevs:FAQs}}<br />
{{HL7transclude| ihevs:Vokabular-Management}}<br />
{{HL7transclude| ihevs:Value-Set-Tabellen}}<br />
=Value Sets=<br />
{{HL7transclude| ihevs:DocumentEntry.author}}<br />
{{HL7transclude| ihevs:DocumentEntry.classCode}}<br />
{{HL7transclude| ihevs:DocumentEntry.confidentialityCode}}<br />
{{HL7transclude| ihevs:DocumentEntry.eventCodeList}}<br />
{{HL7transclude| ihevs:DocumentEntry.formatCode}}<br />
{{HL7transclude| ihevs:DocumentEntry.healthcareFacilityTypeCode}}<br />
{{HL7transclude| Ihevs:DocumentEntry.languageCode}}<br />
{{HL7transclude| ihevs:DocumentEntry.PracticeSettingCode}}<br />
{{HL7transclude| ihevs:DocumentEntry.typeCode}}<br />
{{HL7transclude| ihevs:SubmissionSet.contentTypeCode}}<br />
{{HL7transclude| ihevs:Folder.codeList}}<br />
</div></div>Tidrishttps://wiki.hl7.de/index.php?title=IHE_DE_ValueSets_Action_Items&diff=62623IHE DE ValueSets Action Items2019-11-29T09:24:27Z<p>Tidris: </p>
<hr />
<div>'''Tabelle Änderungsanfragen'''<br />
<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! align="left" | Anfrage ID<br />
! align="left" | Anfrage<br />
! align="center" | betrifft Codesystem<br />
! align="center" | Autor der Anfrage<br />
! align="center" | Diskussion<br />
! align="center" | Entscheidung<br />
! align="center" | Action Item<br />
! align="center" | Bearbeitungsstand<br />
<br />
|- valign="top" <br />
| Anfrage ID| 1<br />
| 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:<br />
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<br />
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.<br />
Wir haben somit eine Mischung aus IHE-D-Codes und IHE-PCC/LAB-LOINC-Codes. Inhaltlich/semantisch überschneidet sich das recht munter. Fragen:<br />
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?<br />
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?<br />
Sofern es hier noch keine Arbeiten zu gibt, können wir gerne für einen der Lösungsansätze (Mapping, ValueSet) aus dem Projekt heraus einen ersten Aufschlag machen. Ich will hier nur nicht mal wieder Aufwand in etwas stecken, wo vielleicht gerade auch schon andere aktiv sind.<br />
| betrifft Codesystem | class codes, type codes<br />
| Autor der Anfrage | JC<br />
| Diskussion| Rückfrage an Autor gestellt, welche Codes konkret vermisst werden<br />
| Entscheidung |<br />
| Action Item |<br />
| Bearbeitungsstand | warten auf Rückmeldung vom Anfragenden<br />
<br />
|- valign="top" <br />
| Anfrage ID| 2<br />
| Anfrage| es scheint in Deutschland Bestrebungen zu geben, Unfallchirurgie mit der Orthopädie zusammenzulegen.<br />
Ab August 2019 wird es im UKD nur noch die „Klinik für Orthopädie und Unfallchirurgie“ geben.<br />
Ist die Einführung einer weiteren Fachabteilung im DocumentEntry.practiseSettingCode geplant?<br />
In DocumentEntry.authorSpecialty findet sie sich:<br />
Code 512 Anzeigename FA Orthopädie und Unfallchirurgie<br />
| betrifft Codesystem | practiceSettingCode <br />
| Autor der Anfrage | SB<br />
| Diskussion| evtl. practiceSettingCode Chirurgie verwenden, deckt beides ab<br />
| Entscheidung |<br />
| Action Item |<br />
| Bearbeitungsstand | Warten auf Rückmeldung vom Anfragenden<br />
<br />
|- valign="top" <br />
| Anfrage ID| 3<br />
| 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.<br />
Dazu möchten wir das Value Set für XDS-Metadatenattribut formatCode um den folgenden Wert erweitern: urn:gematik:ig:DatensatzPersoenlicheErklaerungen:r3.1<br />
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.<br />
| betrifft Codesystem | formatCode<br />
| Autor der Anfrage | RK<br />
| Diskussion| keine Einwände<br />
| Entscheidung | wir fügen Code hinzu<br />
| Action Item | in ArtDecor eintragen<br />
| Bearbeitungsstand | erledigt<br />
<br />
|- valign="top" <br />
| Anfrage ID| 4<br />
| Anfrage| Arbeitsgruppe „Weiterentwicklung Klinische Dokumentenklassenliste (KDL)“.<br />
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.<br />
Das aktuelle Mapping liegt der Geschäftsstelle vor und ist bisher mit Angela Merzweiler gemeinsam abgestimmt wurden.<br />
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.<br />
Beispiel:<br />
Ich möchte daher anregen bzw. beantragen, dass die KDL im ersten Schritt offiziell als CodeSystem in das Value Set „EventCodeList“ aufgenommen wird.<br />
Damit haben Hersteller von IHE-konformen Archiven, o. ä. die Möglichkeit, wenigstens die Klassifizierung des Dokuments mittels KDL offiziell abzubilden.<br />
· Code System Name: Klinische Dokumentenklassen Liste (KDL)<br />
· Code System ID: 1.2.276.0.76.3.1.191.0.1.1, versionsabhängig<br />
· Kommentar: Klassifizierung von Dokumenten und Daten als Beispiele für die Value Sets classCode und typeCode<br />
Mittelfristig soll die KDL zu einem terminologischen System mit ontologischem Ansatz ausgebaut werden.<br />
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.<br />
Ich freue mich, wenn wir es gemeinsam schaffen, dazu einen persönlichen Termin für ein Arbeitstreffen zu finden.<br />
| betrifft Codesystem | eventCode<br />
| Autor der Anfrage | AMü<br />
| Diskussion| EventCode eigentlich als Kontext der Dokumentenerstellung gedacht, als Interimslösung für KDL geeignet, soll aber unbedingt zur Ontologie weiterentwickelt werden. Gemeinsame Telko zur weiteren Abstimmung mit KDL Arbeitsgruppe. 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. <br />
| Entscheidung | grundsätzlich zugestimmt, neues Valueset <br />
| Action Item | OID und URN für neues ValueSet notwendig (==>Annett), danach Eintragung in ArtDecor, gemeinsame Telko mit KDL Arbeitsgruppe (==> Annett erstellt Doodleumfrage, eingeladen werden alle Mitglieder beider Arbeitsgruppen)<br />
| Bearbeitungsstand | in Bearbeitung<br />
<br />
|}<br />
<br />
'''Tabelle Aktueller Stand'''<br />
<br />
:{|class="hl7table sortable" <br />
|- <br />
! width="25%" align="left" | Codesystem<br />
! align="center" | Stand Konzepte<br />
! align="center" | ArtDecor<br />
! align="center" | WikiText<br />
! align="center" | Review durch<br />
<br />
|- valign="top" <br />
| Codesystem | Vokabular Management & Einführung<br />
| Stand Konzepte | n/a<br />
| ArtDecor | n/a<br />
| WikiText | abgeschlossen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | Confidentiality Code<br />
| Stand Konzepte | abgeschlossen<br />
| ArtDecor | abgeschlossen<br />
| WikiText | abgeschlossen<br />
| Review durch | Antje<br />
<br />
|- valign="top" <br />
| Codesystem | AuthorRole<br />
| Stand Konzepte | Review notwendig<br />
| ArtDecor | abgeschlossen<br />
| WikiText | abgeschlossen<br />
| Review durch | Antje, Angela<br />
<br />
|- valign="top" <br />
| Codesystem | AuthorSpeciality<br />
| Stand Konzepte | vorläufig abgeschlossen<br />
| ArtDecor | abgeschlossen<br />
| WikiText | abgeschlossen<br />
| Review durch | Antje, Angela<br />
<br />
|- valign="top" <br />
| Codesystem | EventCodeList<br />
| Stand Konzepte | aus XDS-I, XDW schon Codes vorgegeben weitere müssen noch gesammelt werden, Ideen stehen bereit, Arnold (Aufenthaltsart) und Antje (Warnungen) erarbeiten finale Version<br />
| ArtDecor | abgeschlossen<br />
| WikiText | offen<br />
| Review durch | Angela<br />
<br />
|- valign="top" <br />
| Codesystem | ContentTypecode<br />
| Stand Konzepte | Vorschlag erstellt, gemeinsames Review nötig<br />
| ArtDecor | abgeschlossen<br />
| WikiText | abgeschlossen<br />
| Review durch | Tarik, Antje, Angela<br />
<br />
|- valign="top" <br />
| Codesystem | ClassCode<br />
| Stand Konzepte | erledigt<br />
| ArtDecor | abgeschlossen<br />
| WikiText | abgeschlossen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | TypeCode<br />
| Stand Konzepte | mehrere offene Kommentare<br />
| ArtDecor | offen<br />
| WikiText | offen<br />
| Review durch | <br />
<br />
|- valign="top" <br />
| Codesystem | FormatCode<br />
| Stand Konzepte | offene Kommentare zu FHIR Formaten / Medikationsplan, Änderungen durch neuen code "mimeTypeSufficient"<br />
| ArtDecor | offen (für Medikationsplan)<br />
| WikiText | offen (für Medikationsplan)<br />
| Review durch | <br />
<br />
|}<br />
<br />
'''To dos'''<br />
:{|class="hl7table sortable" <br />
|- <br />
! width="5%" align="center" |#<br />
! width="10%" align="center" |Pkg<br />
! width="10%" align="center" |Sub-Pkg<br />
! width="25%" align="left" |Task<br />
! width="15%" align="left" |Wer?<br />
! width="5%" align="left" |bis? <br />
! align="left" |Anmerkungen<br />
!| Status<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 16<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | ConfidentialityCode<br />
| Aktion | Confidentiality Code ArtDecor überprüfen<br />
| Wer? | Tarik Idris<br />
| bis wann? | 26.03.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 17<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | ConfidentialityCode<br />
| Aktion | Confidentiality Code Beschreibung verfassen<br />
| Wer? | Tarik Idris<br />
| bis wann? | 26.03.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 18<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | AuthorRole<br />
| Aktion | AuthorRole Definitionen der Prozessrollen verfassen<br />
| Wer? | Frank Oemig<br />
| bis wann? | 26.03.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 19<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | AuthorRole<br />
| Aktion | AuthorRole Definitionen der Beziehungsrollen verfassen<br />
| Wer? | offen<br />
| bis wann? | <br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 20<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | AuthorRole<br />
| Aktion | AuthorRole in ArtDecor eintragen<br />
| Wer? | Angela<br />
| bis wann? | <br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 21<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | AuthorRole<br />
| Aktion | AuthorRole Beschreibungstext verfassen<br />
| Wer? | Tarik<br />
| bis wann? | 15.05.<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 22<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | AuthorSpeciality<br />
| Aktion | AuthorSpeciality Codesystem: im ärztlichen Bereich Qualifikation mit berücksichtigen: Zusatzbezeichungen zur vorläufigen Liste hinzufügen<br />
| Wer? | Antje Brandner<br />
| bis wann? | 06.04.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 23<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | AuthorSpeciality<br />
| Aktion | AuthorSpeciality Codesystem: Berufsgruppe: Arzt, nichtärztlichen Berufsgruppen (ohne Qualifikation) (aus ZTG Liste der Gruppen erarbeiten, für KH interne Beruf granularer als außerhalb), mit einer Hierarchie die Berufsgruppen und Berufe vereint <br />
| Wer? | Angela Merzweiler<br />
| bis wann? | 06.04.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 24<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | AuthorSpeciality<br />
| Aktion | AuthorSpeciality für Facharzttitel in ArtDecor anpassen<br />
| Wer? | Tarik Idris<br />
| bis wann? | 03.05.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 25<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | AuthorSpeciality<br />
| Aktion | AuthorSpeciality Beschreibungstext verfassen<br />
| Wer? | Angela<br />
| bis wann? | 15.05.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 26<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | EventCodes<br />
| Aktion | notwendige EventCodes versenden<br />
| Wer? | Angela Merzweiler<br />
| bis wann? | 12.03.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 27<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | EventCodes<br />
| Aktion | Arnold (Aufenthaltsart) und Antje (Warnungen) erarbeiten finale Version<br />
| Wer? | Arnold, Antje<br />
| bis wann? | 26.04.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 28<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | EventCodes<br />
| Aktion | EventCodes in ArtDecor eintragen<br />
| Wer? | Angela<br />
| bis wann? | <br />
| Anm. | eigene Codes eingetragen<br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 29<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | EventCodes<br />
| Aktion | Beschreibung zu EventCodes verfassen<br />
| Wer? | Tarik<br />
| bis wann? | 17.05.2018<br />
| Anm. | <br />
| Status | offen<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 30<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | ContentTypeCodes<br />
| Aktion | ContentTypeCodes zusammenstellen<br />
| Wer? |Sven Lüttmann<br />
| bis wann? | 26.04.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 31<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | ContentTypeCodes<br />
| Aktion | ContentTypeCodes in ArtDecor eintragen<br />
| Wer? | Angela<br />
| bis wann? | <br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 32<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | ContentTypeCodes<br />
| Aktion | Beschreibungstext zu ContentTypeCodes verfassen<br />
| Wer? | Sven<br />
| bis wann? | <br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 33<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | Vokabular-Management<br />
| Aktion | Übersichtstabelle mit Eigenschaften der definierten ValueSets um die Neuen erweitern<br />
| Wer? | Tarik<br />
| bis wann? | <br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 34<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | Class Codes<br />
| Aktion | Medikationen nicht löschen, sondern als deprecated markieren<br />
| Wer? | Angela<br />
| bis wann? | 06.04.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 35<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | Format Code<br />
| Aktion | mimeTypeSufficient hinzufügen und FHIR Mime Type erläutern<br />
| Wer? | Tarik Idris<br />
| bis wann? | 03.05.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 36<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | AuthorSpeciality<br />
| Aktion | nichtärztlich Berufsgruppen in ArtDecor eintragen<br />
| Wer? | Angela Merzweiler<br />
| bis wann? | 12.04.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 37<br />
| Pkg | Abstimmungsverfahren<br />
| Sub-Pkg | Ankündigung<br />
| Aktion | Ankündigung verfassen, über interopforum und IHE Mitgliederliste verteilen, IHE-D Homepage anpassen<br />
| Wer? | Angela Merzweiler<br />
| bis wann? | 17.04.2018<br />
| Anm. | <br />
| Status | erledigt<br />
<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 38<br />
| Pkg | Abstimmungsverfahren<br />
| Sub-Pkg | Vorbereitung Abstimmungsverfahren<br />
| Aktion | Kommentierungsdokumente bereitstellen (PDF, Excel)<br />
| Wer? | Angela<br />
| bis wann? | 18.05.2018<br />
| Anm. | <br />
| Status | offen<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 39<br />
| Pkg | Abstimmungsverfahren<br />
| Sub-Pkg | Vorbereitung Abstimmungsverfahren<br />
| Aktion | Ankündigungsschreiben anpassen, über interopforum und IHE Mitgliederliste verteilen<br />
| Wer? | Angela<br />
| bis wann? | 18.05.2018<br />
| Anm. | <br />
| Status | offen<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 40<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | ClassCode<br />
| Aktion | Abstimmung eines Kommentars<br />
| Wer? | Angela Merzweiler<br />
| bis wann? | <br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 41<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | ClassCode<br />
| Aktion | Änderungen in ArtDecor eintragen<br />
| Wer? | Angela Merzweiler<br />
| bis wann? | <br />
| Anm. | <br />
| Status | erledigt<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 42<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | TypeCode<br />
| Aktion | über Änderungen abstimmen lassen <br />
| Wer? | Angela Merzweiler<br />
| bis wann? | <br />
| Anm. | <br />
| Status | offen<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 43<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | TypeCode<br />
| Aktion | Änderungen in ArtDecor eintragen<br />
| Wer? | Angela Merzweiler<br />
| bis wann? | <br />
| Anm. | <br />
| Status | offen<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 44<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | FormatCode<br />
| Aktion | über Änderungen abstimmen lassen <br />
| Wer? | <br />
| bis wann? | <br />
| Anm. | <br />
| Status | offen<br />
<br />
|- valign="top" <br />
| align="center" Nr. | 45<br />
| Pkg | IHE D ValueSets<br />
| Sub-Pkg | FormatCode<br />
| Aktion | Änderungen in ArtDecor eintragen<br />
| Wer? | Angela Merzweiler<br />
| bis wann? | <br />
| Anm. | <br />
| Status | offen<br />
<br />
|} <br />
<br />
'''IG Struktur'''<br />
<br />
# [[ihevs:Einleitung]] (Vorgehen, Ziele, Umgang mit v1, normativ, Delta-Liste?, Änderungen/Pflege)<br />
# [[Ihevs:Vokabular-Management]]<br />
# [[ihevs:DocumentEntry.authorRole]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.authorSpecialty]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.classCode]]<br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.confidentialityCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.eventCodeList]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:DocumentEntry.formatCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.healthcareFacilityTypeCode]]<br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.languageCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.practiceSettingCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:DocumentEntry.typeCode]] <br />
#* Erläuterungstext (mit Link auf ART Decor)<br />
#* ValueSet aus ART Decor<br />
# [[ihevs:SubmissionSet.contentTypeCode]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor <br />
# [[ihevs:Folder.codeList]] <br />
#* Erläuterungstext<br />
#* ValueSet aus ART Decor<br />
<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Value_Sets_f%C3%BCr_Deutschland_(Projekt)&diff=60901Value Sets für Deutschland (Projekt)2019-09-16T11:32:25Z<p>Tidris: </p>
<hr />
<div>__NOTOC__<br />
=Zusammenfassung=<br />
Zur erfolgreichen Umsetzung von Aktenprojekten (eEPA, EFA, PEPA, etc.) werden Metadaten benötigt, die die Identifikation, Selektion und Auswertung von in den Aktensystemen gespeicherten Dokumenten ermöglichen. In diesem Projekt werden Value Sets entwickelt, die entsprechende Codesysteme bereitstellen. Diese Value Sets werden in [http://art-decor.org ART-DECOR] hinterlegt und ins Wiki exportiert, so dass sie hier in einem Implementierungsleitfaden zusammen mit ergänzenden Informationen bereitgestellt werden können.<br />
<br />
=Anfangs- und geplantes Enddatum=<br />
* Erste Phase: Ballot - 23. Mai bis 26. Juni 2016 (abgeschlossen)<br />
* Zweite Phase: Ballot - 23. Mai bis 26. Juni 2018 (abgeschlossen)<br />
<br />
=Ergebnis=<br />
* [[IG:ValueSet|Leitfaden für Value Sets (aktuell)]]<br />
* Zwischenergebnis erste Phase: [[Datei:Logo-ihe.svg|30px|link=]] [http://www.ihe-d.de/download/value-sets-fuer-xds-metadaten download (Webseite)]<br />
* Zwischenergebnis zweite Phase: [[Datei:Logo-ihe.svg|30px|link=]] [http://www.ihe-d.de/download/ihe-valuesets-v2-0 download (Webseite)]<br />
<br />
=Status=<br />
* Erste Phase: Abgeschlossen [[Kommentierung_20161203|Abstimmungsverfahren]]<br />
* Zweite Phase: Abgeschlossen <br />
* Dritte Phase: in Bearbeitung<br />
[[Kategorie:Projekte in Bearbeitung]]<br />
<br />
=Fürsorger=<br />
* Angela Merzweiler<br />
<br />
=Kontaktperson im Interoperabilitätsforum=<br />
* Angela Merzweiler<br />
<br />
=Beteiligte Organisationen=<br />
* IHE-D<br />
* ICW<br />
* Deutsche Telekom Healthcare and Security Solutions GmbH<br />
* Cerner<br />
* Unikl. Freiburg<br />
* Unikl. Heidelberg<br />
* DMI<br />
* bvitg<br />
* VISUS<br />
<br />
=Nutznießer=<br />
* Affinity Domains<br />
* alle Personen / Institutionen, die einrichtungsübergreifend Patientendokumente austauschen möchten.<br />
<br />
=Erwartete Produkte=<br />
* [[IG:ValueSet|Leitfaden für Value Sets (aktuell)]]<br />
* Value Set (s.u.)<br />
<br />
=Links=<br />
* interne Links (z. B. zu den Produkten)<br />
** Dokumentenformat:[[ihevs:DocumentEntry.formatCode]]<br />
** Dokumentenklasse [[ihevs:DocumentEntry.classCode]]<br />
** Dokumententyp [[ihevs:DocumentEntry.typeCode]]<br />
** Fachrichtung: [[ihevs:DocumentEntry.PracticeSettingCode]]<br />
** Einrichtungsart [[ihevs:DocumentEntry.healthcareFacilityTypeCode]]<br />
** FolderCodeList [[ihevs:Folder.codeList]]<br />
** Dokumentensprache [[ihevs:LanguageCode]]<br />
** [[Value_Sets]]<br />
* externe Links<br />
** http://www.ihe-d.de/projekte/xds-value-sets-fuer-deutschland/<br />
<br />
[[Kategorie:Projekte]]<br />
[[Kategorie:Terminologie-Projekte]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.formatCode&diff=54940Ihevs:DocumentEntry.formatCode2018-12-14T16:56:53Z<p>Tidris: /* DocumentEntry.formatCode */ Änderung nach Aufnahme der gematik codes</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.formatCode==<br />
<br />
Der Code spezifiziert das Format des Dokumentes. Zusammen mit dem typeCode (und ggf. mit dem mimeType) soll der formatCode für hinreichende Information sorgen, um einem potenziellen XDS-Dokument-Konsumenten die Entscheidung zu ermöglichen, ob und wie er das Dokumentenformat verarbeiten kann.<br />
<br />
Der formatCode muss dabei hinreichend eindeutig formuliert sein, um die Verarbeitung/Anzeige des von der Registry angeforderten Dokumentes durch den Dokumentenkonsumer zu gewährleisten.<br />
<br />
===Vergabe von formatCodes===<br />
<br />
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.<br />
<br />
===Umfang des IHE Deutschland formatCode ValueSets===<br />
<br />
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 und weiteren Organisationen zusammen.<br />
<br />
===Aufbau der formatCodes===<br />
====Aufbau der durch IHE International vergebenen formatCodes====<br />
<br />
formatCodes, welche von IHE ITI definiert werden, haben immer das Präfix<br />
<br />
urn:ihe:iti:<br />
<br />
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<br />
<br />
urn:ihe:’domain initials’:<br />
<br />
benutzen, wobei „domain initials“ die Domäne selbst repräsentiert.<br />
<br />
====Aufbau der durch IHE Deutschland vergebenen formatCodes====<br />
<br />
formatCodes, welche von IHE Deutschland definiert werden, haben immer das Präfix<br />
<br />
urn:ihe-d:<br />
<br />
Von IHE Deutschland festgelegte formatCodes werden wie folgt aufgebaut:<br />
<br />
=====Aufbau für CDA-Dokumente=====<br />
<br />
{| border=1<br />
|-<br />
|CDA-Dokumente ohne binärem Inhalt <br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr'<br />
|-<br />
|CDA-Dokumente mit einem Body, der aus einem binärem Inhalt besteht<br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr':nonXmlBody<br />
|-<br />
|CDA-Dokumente mit einem Body, der aus einer XML-Inhalten und mind. einer eingebettenen binärem Datei besteht <br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr':crossXmlBody<br />
|}<br />
<br />
„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).<br />
<br />
Beispiel: Sollte IHE Deutschland 2016 ein eigenes CDA-Dokument für eine Verordnung veröffentlichen, wird dieses entsprechend der obigen Beschreibung wie folgt abgebildet:<br />
<br />
a) Verordnung: Level 1-3 ohne binärem Inhalt<br />
urn:ihe-d:ig:Verordnung:2016<br />
b) Verordnung: Level 1 CDA mit Body bestehend aus einer PDF-Datei ([[IG:CDA_und_PDF/A3]])<br />
urn:ihe-d:ig:Verordnung:2016:nonXmlBody<br />
c) Verordnung: sowohl mit XML-Inhalt wie auch mindestens einer eingebetteten binären Datei <br />
urn:ihe-d:ig:Verordnung:2016:crossXmlBody<br />
<br />
=====Aufbau für nicht CDA-Dokumente=====<br />
<br />
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. <br />
<br />
{| border=1<br />
|-<br />
|IHE Deutschland <br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr'<br />
urn:ihe-d:spec:'Bezeichner':'Jahr'<br />
|}<br />
<br />
„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).<br />
<br />
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 wird Teil der Revision 15 des IHE ITI Technical Frameworks werden. Der equivalente, von IHE Deutschland eingeführte formatCode "urn:ihe-d:mime" gilt ab sofort als "deprecated" und sollte nicht mehr verwendet werden. <br />
<br />
'''Beispiel'''<br />
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. <br />
<br />
'''Sonderfall'''<br />
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”.<br />
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.<br />
<br />
====Empfehlungen von IHE Deutschland für den Aufbau von formatCodes für andere Organisationen====<br />
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.<br />
<br />
====formatCodes für FHIR Ressourcen====<br />
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 und ähnlichen Konstrukten 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'.<br />
<br />
<br />
<br />
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.35&effectiveDate=2018-07-13T16:16:59&language=de-DE ART-DECOR]] zuzugreifen.<br />
<br />
{{:1.2.276.0.76.11.35/dynamic }}<br />
<br />
===Links===<br />
* 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<br />
* RFC 2288 (1998) Using Existing Bibliographic Identifiers as Uniform Resource Names. Online, verfügbar unter http://tools.ietf.org/html/rfc2288<br />
* RFC 2141 (1997).URN Syntax. Online, verfügbar unter https://www.ietf.org/rfc/rfc2141.txt<br />
* RFC 3151 (2001) A URN Namespace for Public Identifiers. Online, verfügbar unter https://tools.ietf.org/html/rfc3151<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|formatCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.formatCode&diff=54939Ihevs:DocumentEntry.formatCode2018-12-14T16:44:33Z<p>Tidris: Änderung 54938 von Tidris (Diskussion) rückgängig gemacht.</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.formatCode==<br />
<br />
Der Code spezifiziert das Format des Dokumentes. Zusammen mit dem typeCode (und ggf. mit dem mimeType) soll der formatCode für hinreichende Information sorgen, um einem potenziellen XDS-Dokument-Konsumenten die Entscheidung zu ermöglichen, ob und wie er das Dokumentenformat verarbeiten kann.<br />
<br />
Der formatCode muss dabei hinreichend eindeutig formuliert sein, um die Verarbeitung/Anzeige des von der Registry angeforderten Dokumentes durch den Dokumentenkonsumer zu gewährleisten.<br />
<br />
===Vergabe von formatCodes===<br />
<br />
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.<br />
<br />
===Umfang des IHE Deutschland formatCode ValueSets===<br />
<br />
Das ValueSet hat die OID 1.2.276.0.76.11.35 und setzt sich aus Codes von IHE International, IHE Deutschland, HL7 und HL7 Deutschland zusammen.<br />
<br />
===Aufbau der formatCodes===<br />
====Aufbau der durch IHE International vergebenen formatCodes====<br />
<br />
formatCodes, welche von IHE ITI definiert werden, haben immer das Präfix<br />
<br />
urn:ihe:iti:<br />
<br />
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<br />
<br />
urn:ihe:’domain initials’:<br />
<br />
benutzen, wobei „domain initials“ die Domäne selbst repräsentiert.<br />
<br />
====Aufbau der durch IHE Deutschland vergebenen formatCodes====<br />
<br />
formatCodes, welche von IHE Deutschland definiert werden, haben immer das Präfix<br />
<br />
urn:ihe-d:<br />
<br />
Von IHE Deutschland festgelegte formatCodes werden wie folgt aufgebaut:<br />
<br />
=====Aufbau für CDA-Dokumente=====<br />
<br />
{| border=1<br />
|-<br />
|CDA-Dokumente ohne binärem Inhalt <br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr'<br />
|-<br />
|CDA-Dokumente mit einem Body, der aus einem binärem Inhalt besteht<br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr':nonXmlBody<br />
|-<br />
|CDA-Dokumente mit einem Body, der aus einer XML-Inhalten und mind. einer eingebettenen binärem Datei besteht <br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr':crossXmlBody<br />
|}<br />
<br />
„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).<br />
<br />
Beispiel: Sollte IHE Deutschland 2016 ein eigenes CDA-Dokument für eine Verordnung veröffentlichen, wird dieses entsprechend der obigen Beschreibung wie folgt abgebildet:<br />
<br />
a) Verordnung: Level 1-3 ohne binärem Inhalt<br />
urn:ihe-d:ig:Verordnung:2016<br />
b) Verordnung: Level 1 CDA mit Body bestehend aus einer PDF-Datei ([[IG:CDA_und_PDF/A3]])<br />
urn:ihe-d:ig:Verordnung:2016:nonXmlBody<br />
c) Verordnung: sowohl mit XML-Inhalt wie auch mindestens einer eingebetteten binären Datei <br />
urn:ihe-d:ig:Verordnung:2016:crossXmlBody<br />
<br />
=====Aufbau für nicht CDA-Dokumente=====<br />
<br />
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. <br />
<br />
{| border=1<br />
|-<br />
|IHE Deutschland <br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr'<br />
urn:ihe-d:spec:'Bezeichner':'Jahr'<br />
|}<br />
<br />
„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).<br />
<br />
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 wird Teil der Revision 15 des IHE ITI Technical Frameworks werden. Der equivalente, von IHE Deutschland eingeführte formatCode "urn:ihe-d:mime" gilt ab sofort als "deprecated" und sollte nicht mehr verwendet werden. <br />
<br />
'''Beispiel'''<br />
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. <br />
<br />
'''Sonderfall'''<br />
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”.<br />
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.<br />
<br />
====Empfehlungen von IHE Deutschland für den Aufbau von formatCodes für andere Organisationen====<br />
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.<br />
<br />
====formatCodes für FHIR Ressourcen====<br />
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 und ähnlichen Konstrukten 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'.<br />
<br />
<br />
<br />
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.35&effectiveDate=2018-07-13T16:16:59&language=de-DE ART-DECOR]] zuzugreifen.<br />
<br />
{{:1.2.276.0.76.11.35/dynamic }}<br />
<br />
===Links===<br />
* 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<br />
* RFC 2288 (1998) Using Existing Bibliographic Identifiers as Uniform Resource Names. Online, verfügbar unter http://tools.ietf.org/html/rfc2288<br />
* RFC 2141 (1997).URN Syntax. Online, verfügbar unter https://www.ietf.org/rfc/rfc2141.txt<br />
* RFC 3151 (2001) A URN Namespace for Public Identifiers. Online, verfügbar unter https://tools.ietf.org/html/rfc3151<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|formatCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.formatCode&diff=54938Ihevs:DocumentEntry.formatCode2018-12-14T16:42:28Z<p>Tidris: /* Umfang des IHE Deutschland formatCode ValueSets */</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.formatCode==<br />
<br />
Der Code spezifiziert das Format des Dokumentes. Zusammen mit dem typeCode (und ggf. mit dem mimeType) soll der formatCode für hinreichende Information sorgen, um einem potenziellen XDS-Dokument-Konsumenten die Entscheidung zu ermöglichen, ob und wie er das Dokumentenformat verarbeiten kann.<br />
<br />
Der formatCode muss dabei hinreichend eindeutig formuliert sein, um die Verarbeitung/Anzeige des von der Registry angeforderten Dokumentes durch den Dokumentenkonsumer zu gewährleisten.<br />
<br />
===Vergabe von formatCodes===<br />
<br />
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.<br />
<br />
===Umfang des IHE Deutschland formatCode ValueSets===<br />
<br />
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 und weiteren Organisationen zusammen.<br />
<br />
===Aufbau der formatCodes===<br />
====Aufbau der durch IHE International vergebenen formatCodes====<br />
<br />
formatCodes, welche von IHE ITI definiert werden, haben immer das Präfix<br />
<br />
urn:ihe:iti:<br />
<br />
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<br />
<br />
urn:ihe:’domain initials’:<br />
<br />
benutzen, wobei „domain initials“ die Domäne selbst repräsentiert.<br />
<br />
====Aufbau der durch IHE Deutschland vergebenen formatCodes====<br />
<br />
formatCodes, welche von IHE Deutschland definiert werden, haben immer das Präfix<br />
<br />
urn:ihe-d:<br />
<br />
Von IHE Deutschland festgelegte formatCodes werden wie folgt aufgebaut:<br />
<br />
=====Aufbau für CDA-Dokumente=====<br />
<br />
{| border=1<br />
|-<br />
|CDA-Dokumente ohne binärem Inhalt <br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr'<br />
|-<br />
|CDA-Dokumente mit einem Body, der aus einem binärem Inhalt besteht<br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr':nonXmlBody<br />
|-<br />
|CDA-Dokumente mit einem Body, der aus einer XML-Inhalten und mind. einer eingebettenen binärem Datei besteht <br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr':crossXmlBody<br />
|}<br />
<br />
„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).<br />
<br />
Beispiel: Sollte IHE Deutschland 2016 ein eigenes CDA-Dokument für eine Verordnung veröffentlichen, wird dieses entsprechend der obigen Beschreibung wie folgt abgebildet:<br />
<br />
a) Verordnung: Level 1-3 ohne binärem Inhalt<br />
urn:ihe-d:ig:Verordnung:2016<br />
b) Verordnung: Level 1 CDA mit Body bestehend aus einer PDF-Datei ([[IG:CDA_und_PDF/A3]])<br />
urn:ihe-d:ig:Verordnung:2016:nonXmlBody<br />
c) Verordnung: sowohl mit XML-Inhalt wie auch mindestens einer eingebetteten binären Datei <br />
urn:ihe-d:ig:Verordnung:2016:crossXmlBody<br />
<br />
=====Aufbau für nicht CDA-Dokumente=====<br />
<br />
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. <br />
<br />
{| border=1<br />
|-<br />
|IHE Deutschland <br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr'<br />
urn:ihe-d:spec:'Bezeichner':'Jahr'<br />
|}<br />
<br />
„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).<br />
<br />
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 wird Teil der Revision 15 des IHE ITI Technical Frameworks werden. Der equivalente, von IHE Deutschland eingeführte formatCode "urn:ihe-d:mime" gilt ab sofort als "deprecated" und sollte nicht mehr verwendet werden. <br />
<br />
'''Beispiel'''<br />
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. <br />
<br />
'''Sonderfall'''<br />
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”.<br />
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.<br />
<br />
====Empfehlungen von IHE Deutschland für den Aufbau von formatCodes für andere Organisationen====<br />
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.<br />
<br />
====formatCodes für FHIR Ressourcen====<br />
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 und ähnlichen Konstrukten 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'.<br />
<br />
<br />
<br />
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.35&effectiveDate=2018-07-13T16:16:59&language=de-DE ART-DECOR]] zuzugreifen.<br />
<br />
{{:1.2.276.0.76.11.35/dynamic }}<br />
<br />
===Links===<br />
* 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<br />
* RFC 2288 (1998) Using Existing Bibliographic Identifiers as Uniform Resource Names. Online, verfügbar unter http://tools.ietf.org/html/rfc2288<br />
* RFC 2141 (1997).URN Syntax. Online, verfügbar unter https://www.ietf.org/rfc/rfc2141.txt<br />
* RFC 3151 (2001) A URN Namespace for Public Identifiers. Online, verfügbar unter https://tools.ietf.org/html/rfc3151<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|formatCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Datei:Logo-rzv.jpg&diff=54186Datei:Logo-rzv.jpg2018-10-17T14:14:48Z<p>Tidris: Quelle www.rzv.de</p>
<hr />
<div>Quelle www.rzv.de</div>Tidrishttps://wiki.hl7.de/index.php?title=IG:Value_Sets_f%C3%BCr_XDS&diff=54185IG:Value Sets für XDS2018-10-17T14:11:20Z<p>Tidris: RZV zu Kollaboratoren hinzugefügt</p>
<hr />
<div><!--<br />
<br />
Implementierungsleitfaden "Value Set"<br />
<br />
--><br />
{{Infobox Dokument<br />
|Title = Value Sets für Aktenprojekte im deutschen Gesundheitswesen<br />
|Short = Value Sets für XDS<br />
|Namespace = ihevs<br />
|Type = Implementierungsleitfaden<br />
|Version = 2.0<br />
|Submitted = IHE Deutschland<br />
|Date = 09.10.2018<br />
|Copyright = 2018<br />
|Status = Final<br />
|Period = Final<br />
|OID = 1.3.6.1.4.1.19376.3.276.1.7.6<br />
|Realm = Deutschland<br />
|Custodian = IHE<br />
}}<br />
<br />
{{Infobox Ballot Begin}}<br />
{{Ballot | Version = 0.1 | Date = 23.05.2016 | Status = Draft | Realm = Deutschland| Othericon = x<br />
| Otherdocuments = http://download.hl7.de/documents/ihexdsvs/Value_Sets4XDS-v01.pdf<br />
| Comment =<br />
}}<br />
{{Ballot | Version = 1.0 | Date = 10.11.2016 | Status = Final | Realm = Deutschland| Othericon = x<br />
| Otherdocuments = http://www.ihe-d.de/download/value-sets-fuer-xds-metadaten<br />
| Comment =<br />
}}<br />
{{Ballot | Version = 1.1 | Date = 22.05.2018 | Status = Draft | Realm = Deutschland| Othericon = x<br />
| Otherdocuments = http://wiki.hl7.de/images/Value_Sets4XDS-v11.pdf<br />
| Comment =<br />
}}<br />
{{Ballot | Version = 2.0 | Date = 09.10.2018 | Status = active| Realm = Deutschland| Othericon = x<br />
| Otherdocuments = http://wiki.hl7.de/images/Value_Sets4XDS-v20.pdf<br />
| Comment =<br />
}}<br />
<br />
{{Infobox Ballot End}}<br />
<br />
{{Infobox Contributors Begin}}<br />
{{Contributor | Logo = Logo_ihe.png | Name = IHE Deutschland| Location = Berlin}}<br />
{{Contributor | Logo = Logo_bvitg.JPG | Name = bvitg (Bundesverband Gesundheits-IT) | Location = Berlin}}<br />
{{Contributor | Logo = Logo_icw.jpg | Name = ICW | Location = Walldorf }}<br />
{{Contributor | Logo = Logo-t-systems.jpg | Name = Deutsche Telekom Healthcare and Security Solutions GmbH | Location = Bonn }}<br />
{{Contributor | Logo = Logo-uk-heidelberg.png | Name = Uniklinik Heidelberg (ZIM) | Location = Heidelberg }}<br />
{{Contributor | Logo = Logo-uk-freiburg.png | Name = Uniklinik Freiburg | Location = Freiburg }}<br />
{{Contributor | Logo = Logo-cerner.jpeg | Name = Cerner | Location = Berlin }}<br />
{{Contributor | Logo = Logo-visus.jpg | Name = VISUS Health IT GmbH | Location = Bochum }}<br />
{{Contributor | Logo = FALKO LOGO.jpg | Name = FALKO.NRW gefördert durch EFRE und das Land Nordrhein-Westfalen|Location=}}<br />
{{Contributor | Logo = Logo-rzv.jpg | Name = RZV Rechenzentrum Volmarstein GmbH | Location = Wetter (Ruhr) }}<br />
{{Infobox Contributors End}}<br />
<br />
{{HL7transclude| ihevs:Einleitung}}<br />
<div class="landscape"><br />
{{HL7transclude| ihevs:Vokabular-Management}}<br />
{{HL7transclude| ihevs:Value-Set-Tabellen}}<br />
=Value Sets=<br />
{{HL7transclude| ihevs:DocumentEntry.author}}<br />
{{HL7transclude| ihevs:DocumentEntry.classCode}}<br />
{{HL7transclude| ihevs:DocumentEntry.confidentialityCode}}<br />
{{HL7transclude| ihevs:DocumentEntry.eventCodeList}}<br />
{{HL7transclude| ihevs:DocumentEntry.formatCode}}<br />
{{HL7transclude| ihevs:DocumentEntry.healthcareFacilityTypeCode}}<br />
{{HL7transclude| Ihevs:DocumentEntry.languageCode}}<br />
{{HL7transclude| ihevs:DocumentEntry.PracticeSettingCode}}<br />
{{HL7transclude| ihevs:DocumentEntry.typeCode}}<br />
{{HL7transclude| ihevs:SubmissionSet.contentTypeCode}}<br />
{{HL7transclude| ihevs:Folder.codeList}}<br />
</div></div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:Value-Set-Tabellen&diff=54102Ihevs:Value-Set-Tabellen2018-10-08T21:13:36Z<p>Tidris: /* Value-Set-Tabellen */</p>
<hr />
<div>{{DocumentPart}}<br />
=Value-Set-Tabellen=<br />
<br />
Wie sind die Tabellen mit den Value Sets zu interpretieren?<br />
<br />
{| class="hl7table"<br />
|-<br />
!Spalte!!Beschreibung<br />
|-<br />
|Level/Typ||Angabe der Hierarchie, in der sich der Kode befindet. Diese Information wird aus zwei Teilen gebildet:<br />
<br />
Der linke Teil ('''Level''') gibt als numerischen Wert die Hierarchie an, in der sich das Element befindet. Ein höherer Werte bedeutet eine tiefere Ebene. Damit ist der Kode spezifischer als der auf der nächst höheren Ebene.<br />
<br />
Der rechte Teil ('''Typ''') gibt an, wie der Kode zu verwenden ist.<br />
<br />
A - abstrakt, d.h. der Kode darf nicht selbst genutzt werden, sondern nur eine Spezialisierung davon.<br />
L - Leaf, d.h. Blatt ohne weitere Spezialisierungen<br />
S - Specializable, d.h. es gibt noch einen Wert auf einer tieferen Ebene<br />
D - Deprecated, d.h. der Kode darf nicht mehr verwendet werden und wird nur aus Kompatibilitäts- und Verwaltungsgründen noch aufgeführt. Typischerweise gibt es dafür einen oder sogar mehrere andere Kodes.<br />
|-<br />
|Code ||der definierte und zu benutzende Kode<br />
|-<br />
|Anzeigename ||textuelle Beschreibung, die zur Anzeige verwendet werden soll<br />
|-<br />
|Codesystem ||Definiert eine Sammlung von Kodes die in einer logischen Beziehung zueinander stehen, z.B. ein Katalog, eine Ontologie, eine Klassifizierung, etc. Wird über eine OID (ggf. auch mit einem zusätzlichen Klarnamen) identifiziert <br />
|-<br />
|Beschreibung ||zusätzliche Hinweise zur Verwendung<br />
|}<br />
<br />
Die Value Sets werden in ART-DECOR von IHE Deutschland veröffentlicht (http://art-decor.org/art-decor/decor-valuesets--ihede-) und im Folgenden 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- ART-DECOR]] zuzugreifen. Dort sind auch maschinenlesbare Versionen in verschiedenen Formaten verfügbar (z.B. CSV, XML, JSON, IHE SVS, ...).<br />
<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:Folder.codeList&diff=54052Ihevs:Folder.codeList2018-10-02T12:16:50Z<p>Tidris: /* Folder.codeList */ Warnhinweis und ART-DECOR Link</p>
<hr />
<div>{{DocumentPart}}<br />
==Folder.codeList==<br />
<br />
Gerade bei longitudinalen Akten stellt sich die Frage, wie die eingestellten Dokumente geordnet werden können. Die in den IHE Document Sharing Profilen vorhandenen Ordner (Folder) entsprechen Markierungen (oft auch als "Tags" bezeichnet), wobei einem Dokument auch mehrere solche Markierungen problemlos zugewiesen werden können. Dies entspricht dem bei Blogs häufig verwendetem System, bei dem ein Artikel mit einem oder mehreren Tags versehen werden. Dies erlaubt es, die Blog Einträge in mehrere, sich überschneidende Teilmengen aufzuteilen, die unterschiedliche Themengebiete darstellen. Im Gegensatz zu Tags bei Blog Software werden die Folder in den IHE Document Sharing Profilen jedoch nicht nur durch eine frei wählbare Zeichenkette beschrieben, sondern zusätzlich durch einen Identifier und durch eine Liste von Codes.<br />
<br />
Ein Dokument kann in XDS also mehreren Ordnern zugeordnet werden, die wiederum durch mehrere Codes gekennzeichnet sein können. Die Ordner (Folder) in XDS entsprechen somit nicht dem Ordnerprinzip, mit dem die verbreiteten Betriebssysteme (Windows, UNIX, Linux) Dokumente organisieren. Dort werden die Dokumente in hierarchischen Strukturen entsprechenden Ankerpunkten zugeordnet. Diese Strukturen werden dabei über Pfadangaben realisiert, die durch voneinander getrennten Zeichenketten organisiert werden. Somit übernehmen diese zusammengesetzten Zeichenketten die Ablagelogik. (z.B. "C \ Windows \ System" oder "usr \ local"). Ein Dokument kann in einem solchen System typischerweise nur einem Ordner zugeordnet werden. (Manche Betriebssysteme ermöglichen über Verknüpfungseinträge auch eine Mehrfachzuordnung.) Die Ordner in XDS sind nicht hierarchisch, da sich keine Beziehungen zwischen Ordnern (wie Ordner A1 ist ein Unterordner von Ordner A) abbilden lassen.<br />
<br />
Die Einsatzzwecke von Ordnern in den IHE Document Sharing Profilen sind vielfältig und werden hier nicht weiter eingeschränkt. Daher ist das Value Set auch als [[Ihevs:Vokabular-Management|''open'']] deklariert und kann um zusätzliche Codes erweitert werden. Um redundante Kennzeichnungen (und daraus häufig resultierende Widersprüchen) zu vermeiden, wird empfohlen keine Ordner anzulegen, die die schon vorhandenen Metadaten duplizieren. Z.B. ist eine Grobklassifizierung von Dokumenten durch den classCode schon gegeben, daher muss kein XdsFolder für "Befunde" angelegt werden. Ebenso kann eine Verlinkung eines Dokuments mit dem zugehörigen administrativen Fall eines Krankenhauses durch die referenceIdList in den XdsDocumentEntry Metadaten realisiert werden, ohne für jeden Fall einen Folder anlegen zu müssen. Die Nutzung der XdsDocumentEntry Metadaten ist prinzipiell zu bevorzugen, da sich diese in XDS Anfragen weitaus flexibler einsetzen lassen und - im Gegensatz zum XdsFolder - kein explizites Anlegen und Verknüpfen erfordern.<br />
<br />
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.40&effectiveDate=2018-07-13T13:27:21&language=de-DE ART-DECOR]] zuzugreifen.<br />
<br />
{{ :1.2.276.0.76.11.40/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|folderCodeList]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:SubmissionSet.contentTypeCode&diff=54051Ihevs:SubmissionSet.contentTypeCode2018-10-02T12:15:20Z<p>Tidris: /* SubmissionSet.contentTypeCode */ Warnhinweis und ART-DECOR Link</p>
<hr />
<div>{{DocumentPart}}<br />
==SubmissionSet.contentTypeCode==<br />
Das Attribute '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. <br />
<br />
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 aber häufig durch einen einzigen Wert nicht ausreichend beschrieben werden kann, wurde sich innerhalb der 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. <br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Das ValueSet ist als "open" definiert, damit es um weitere, ggf. projektspezifische Übermittlungsgründe erweitert werden kann.<br />
<br />
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.39&effectiveDate=2018-07-13T13:28:16&language=de-DE ART-DECOR]] zuzugreifen.<br />
<br />
{{ :1.2.276.0.76.11.39/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|contentTypeCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.typeCode&diff=54050Ihevs:DocumentEntry.typeCode2018-10-02T12:13:57Z<p>Tidris: /* DocumentEntry.typeCode */ Warnhinweis und ART-DECOR Link</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.typeCode==<br />
<br />
Das Attribut typeCode ist gemäß IHE XDS zwingend gefordert und kann zusätzlich zum classCode zur genaueren Klassifizierung des Dokuments genutzt werden, z.B. kann ein Dokument mit classCode "Befunde" durch den typeCode als "Pathologiebefund" 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."Befunde". 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.<br />
<br />
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.<br />
<br />
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 Befunde ist beispielsweise nicht der Oberbegriff zu Konzepten wie Mikrobiologiebefunde und Pathologiebefunde, sondern umfasst nur die Befunde, die nicht durch andere Konzepte abgedeckt werden.<br />
<br />
Bei Verwendung von IHE APPC Dokumenten muss auch der dort fest vorgegebene LOINC Code unterstützt werden. Bei Verwendung von IHE BPPC Dokumenten ist der Einsatz von LOINC für den typeCode nicht gefordert. Bei IHE BPPC gibt es stattdessen eine Vorgabe für den Einsatz eines LOINC Codes als classCode.<br />
<br />
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.<br />
<br />
{{:1.2.276.0.76.11.38/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|typeCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.PracticeSettingCode&diff=54049Ihevs:DocumentEntry.PracticeSettingCode2018-10-02T12:12:34Z<p>Tidris: /* DocumentEntry.practiceSettingCode */ Warnhinweis und ART-DECOR Link</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.practiceSettingCode==<br />
<br />
DocumentEntry.practiceSettingCode spezifiziert die Fachrichtung der erstellenden Einrichtung. Typische Beispiele hierfür sind ärztliche Fachgebiete wie Allgemeinmedizin oder Radiologie. IHE International empfiehlt, dass die Codeliste zwischen 10 und 100 Codes umfassen sollte, so dass die Fachrichtung hinreichend genau abgebildet werden kann.<br />
<br />
Jedem Dokument muss genau ein practiceSettingCode zugeordnet werden, auch wenn es in vielen Situationen mehrere beteiligte Fachrichtungen gibt. Ein Beispiel hierfür ist ein Röntgen-Befund, der aus der Chirurgie angefordert wird. Um hier eindeutig zu sein, schreibt IHE XDS vor, dass als Fachrichtung jene gewählt werden muss, die die Fachrichtung der medizinischen Versorgungseinrichtung beschreibt, deren Tätigkeit zur Erstellung des Dokuments geführt hat. Im obigen Beispiel hat die Radiologie die Röntgen-Aufnahme durchgeführt und dem daraus resultierenden Dokument (der Röntgen-Befund) sollte somit der practiceSettingCode für „Radiologie“ zugeordnet werden. Dabei ist zu beachten, dass die Charakterisierung der durchführenden Organisation entscheidend ist, nicht der Facharzttitel des Akteurs oder die Typisierung des Dokuments. Wenn histologische Befunde aus der Dermatologie kommen, sollte der practiceSettingCode „Dermatologie“ verwendet werden. Wenn ein als Allgemeinarzt tätiger Internist einen Arztbrief schreibt, muss diesem Brief daher der practiceSettingCode für „Allgemeinmedizin“ zugeordnet werden.<br />
<br />
In den verschiedenen Ländern existieren unterschiedliche Anforderungen an diesen Code. IHE UK definierte ein Value Set (http://wiki.ihe-uk.org/AppendixB), desgleichen die Niederlande (http://decor.nictiz.nl/services/RetrieveValueSet?id=2.16.840.1.113883.2.4.3.11.60.106.11.10&effectiveDate=2013-12-12T10:41:06&prefix=xds-&format=html&language=de-DE), aber auch für Connect-a-thons werden eigene Codes definiert (http://www.hl7.org/FHIR/valueset-xds-practice-codes.html).<br />
<br />
In Deutschland existiert durch die (Muster-) Weiterbildungsordnung der Bundesärztekammer eine sehr gute Auflistung medizinischer Fachgebiete, so dass die Fachrichtung der direkten medizinischen Versorgung durch diese Liste wiedergegeben wird. Daneben existieren aber weitere medizinische Versorgungsangebote wie beispielsweise Ernährungsberatung, welche durch die Weiterbildungsordnung nicht abgedeckt werden.<br />
<br />
IHE Deutschland bildete daher zwei Codesysteme: eines basierend auf der ärztlichen Weiterbildungsordnung sowie ein Codesystem für weitergehende medizinische Versorgungsangebote. Die Abbildung in zwei Codesystemen für die Darstellung der Fachrichtung sorgt auch hier für die bessere Wartbarkeit der Codesysteme: so kann einfacher auf Anpassungen der ärztlichen Weiterbildungsordnung reagiert werden. Das Value Set umfasst beide Codesysteme.<br />
<br />
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.37&effectiveDate=2018-10-01T18:31:24&language=de-DE ART-DECOR]] zuzugreifen.<br />
<br />
{{:1.2.276.0.76.11.37/dynamic }}<br />
<br />
Die Fachrichtung ist generell unabhängig von der Ausbildung der Person, welche die medizinische Leistung erbringt. Daher müssen Leistungen, welche nicht-ärztliche Personen erbringen, trotzdem der aus der ärztlichen Weiterbildungsordnung beruhenden Fachrichtung zugeordnet werden, sofern diese existiert. Um die Zuordnung zu erleichtern, erstellte IHE Deutschland nachfolgende Liste als Orientierungshilfe:<br />
<br />
{| class="hl7table"<br />
|-<br />
!Beruf !!Zuordnung Fachrichtung<br />
|-<br />
|Medizinische Fachangestellte / Medizinischer Fachangestellter<br />
(alte Bezeichnung: Arzthelferin / Arzthelfer)<br />
|Üblicherweise in ärztlich geführter Einrichtung tätig, daher sollte die entsprechende ärztliche Fachrichtung verwendet werden.<br />
|-<br />
|Orientierungs- und Mobilitätslehrer/in und ähnliche, ggf. auch Blindenverbände ||Augenheilkunde<br />
|-<br />
|Anästhesie-technische Assistentin / Anästhesie-technischer Assistent ||Anästhesiologie<br />
|-<br />
|Orthoptistin / Orthoptist ||Augenheilkunde<br />
|-<br />
|Chirurgische Operationsassistentin / Chirurgischer Operationsassistent ||Chirurgie<br />
|-<br />
|Medizinisch-technische Assistentin für den Operationsdienst / Medizinisch-technischer Assistent für den Operationsdienst ||Chirurgie<br />
|-<br />
|Operationstechnische Assistentin / Operationstechnischer Assistent ||Chirurgie<br />
|-<br />
|Klinische Kodierfachkraft ||Üblicherweise in ärztlich geführter Einrichtung tätig, daher sollte die entsprechende ärztliche Fachrichtung verwendet werden.<br />
|-<br />
|Medizinische Dokumentarin / Medizinischer Dokumentar ||Üblicherweise in ärztlich geführter Einrichtung tätig, daher sollte die entsprechende ärztliche Fachrichtung verwendet werden<br />
|-<br />
|Medizinische Dokumentationsassistentin / Medizinischer Dokumentationsassistent ||Üblicherweise in ärztlich geführter Einrichtung tätig, daher sollte die entsprechende ärztliche Fachrichtung verwendet werden<br />
|-<br />
|Hebamme / Entbindungspfleger ||Frauenheilkunde und Geburtshilfe<br />
|-<br />
|Heilpraktikerin / Heilpraktiker ||Naturheilverfahren<br />
|-<br />
|Hygiene-Beauftragte / Hygiene-Beauftragter ||Hygiene und Umweltmedizin<br />
|-<br />
|Hygienekontrolleurin / Hygienekontrolleur/Gesundheitsaufseherin/Gesundheitsaufseher ||Hygiene und Umweltmedizin<br />
|-<br />
|Kardiotechnikerin / Kardiotechniker ||Herzchirurgie oder Kardiologie, je nach Einsatzgebiet<br />
|-<br />
|Medizinisch-technische Assistentin für Funktionsdiagnostik / Medizinisch-technischer Assistent für Funktionsdiagnostik ||Üblicherweise in ärztlich geführter Einrichtung tätig, daher sollte die entsprechende ärztliche Fachrichtung verwendet werden<br />
|-<br />
|Medizinisch-technische Laboratoriumsassistentin / Medizinisch-technischer Laboratoriumsassistent ||Laboratoriumsmedizin<br />
|-<br />
|Zahnmedizinische Fachangestellte / Zahnmedizinischer Fachangestellter (alte Bezeichnung: Zahnarzthelferin / Zahnarzthelfer) ||Zahnmedizin<br />
|-<br />
|Notfallsanitäterin / Notfallsanitäter ||Notfallmedizin<br />
|-<br />
|Rettungsassistenten-Praktikantin / Rettungsassistenten-Praktikant ||Notfallmedizin<br />
|-<br />
|Rettungsassistentin / Rettungsassistent ||Notfallmedizin<br />
|-<br />
|Rettungssanitäterin / Rettungssanitäter ||Notfallmedizin<br />
|-<br />
|Heilpraktikerin / Heilpraktiker (beschränkt auf das Gebiet der Psychotherapie) || Je nach Ausrichtung entweder "Psychiatrie und Psychotherapie" oder "Psychosomatische Medizin und Psychotherapie"<br />
|-<br />
|Psychologische Psychotherapeuten ||Je nach Ausrichtung entweder "Psychiatrie und Psychotherapie" oder "Psychosomatische Medizin und Psychotherapie"<br />
|-<br />
|Kinder- und Jugendlichenpsychotherapeuten ||Kinder- und Jugendpsychiatrie und -psychotherapie<br />
|-<br />
|Medizinisch-technische Radiologieassistentin / Medizinisch-technischer Radiologieassistent ||Radiologie<br />
|-<br />
|Masseurin und medizinische Bademeisterin / Masseur und medizinischer Bademeister ||Physikalische und rehabilitative Medizin<br />
|-<br />
|Physiotherapeutin / Physiotherapeut ||Physikalische und rehabilitative Medizin<br />
|-<br />
|Osteopathin / Osteopath ||Physikalische und rehabilitative Medizin<br />
|-<br />
|Qigong-Lehrende / Qigong-Lehrender ||Physikalische und rehabilitative Medizin<br />
|-<br />
|Shiatsu-Praktikerin / Shiatsu-Praktiker ||Physikalische und rehabilitative Medizin<br />
|-<br />
|Taijiquan-Lehrende / Taijiquan-Lehrender ||Physikalische und rehabilitative Medizin<br />
|-<br />
|Dentalhygienikerin / Dentalhygieniker ||Zahnmedizin<br />
|-<br />
|Diplom-Ingenieur/in des Fachbereichs Augenoptik/Diplom-Augenoptiker (FH) ||Augenheilkunde<br />
|-<br />
|Occularist/in / Glasbläser/in mit Fachrichtung Kunstaugen (Himi) ||Augenheilkunde<br />
|-<br />
|Chirurgiemechanikerin / Chirurgiemechaniker ||Chirurgie<br />
|-<br />
|Hörakustikerin / Hörakustiker ||Hals-Nasen-Ohrenheilkunde<br />
|-<br />
|Hörgeräteakustikerin / Hörgeräteakustiker ||Hals-Nasen-Ohrenheilkunde<br />
|-<br />
|Diplomingenieur/in für Orthopädie und Rehatechnik ||Orthopädie<br />
|-<br />
|Orthopädiemechanikerin und Bandagistin / Orthopädiemechaniker und Bandagist ||Orthopädie<br />
|-<br />
|Orthopädieschuhmacherin / Orthopädieschuhmacher ||Orthopädie<br />
|-<br />
|Orthopädietechnikerin / Orthopädietechniker ||Orthopädie<br />
|-<br />
|Dentalingenieur ||Zahnmedizin<br />
|-<br />
|Zahntechnikerin / Zahntechniker ||Zahnmedizin<br />
|-<br />
|Fitnessberaterin / Fitnessberater ||Sport- und Bewegungsmedizin, Physikalische und rehabilitative Medizin; wenn keines von beiden zutrifft: Prävention<br />
|-<br />
|Fitnessmanagerin / Fitnessmanager ||Sport- und Bewegungsmedizin, Physikalische und Rehabilitative Medizin; wenn keines von beiden zutrifft: Prävention<br />
|-<br />
|Fitnesstrainerin / Fitnesstrainer ||Sport- und Bewegungsmedizin, Physikalische und Rehabilitative Medizin; wenn keines von beiden zutrifft: Prävention<br />
|}<br />
<br />
<br />
Nach §301 SGB V müssen deutsche Krankenhäuser bei der Abrechnung Fachabteilungen nach dem Schlüssel 6 "Fachabteilungen" gemäß Anhang 1 der BPflV kodieren.<br />
Zum leichteren Auffinden des PracticeSettingCodes stellen wir daher hier ein Mapping zwischen dem Fachabteilungsschlüssel für Krankenhäuser und dem PracticeSettingCode bereit. In der Regel ist der PracticeSettingCode inhaltsgleich oder allgemeiner als der Fachabteilungsschlüssel. In wenigen Ausnahmen ist der PracticeSettingCode differenzierter als der Fachabteilungsschlüssel. In diesen Fällen ist ein automatisches Mapping nicht möglich. Daher muss die Fachabteilung in diesem Fall selbst entscheiden, welcher PracticeSettingCode für sie am besten geeignet ist. <br />
<br />
<br />
{| class="hl7table"<br />
|-<br />
!Fachabteilungsschlüssel !! Klartext Fachabteilung !! practiceSettingCode !! Displayname PracticeSettingCode !! Bemerkungen<br />
|-<br />
| 100 || Innere Medizin || INNE || Innere Medizin || gleicher Text<br />
|-<br />
| 200 || Geriatrie || GERI || Geriatrie || gleicher Text<br />
|-<br />
| 300 || Kardiologie || KARD || Kardiologie || gleicher Text<br />
|-<br />
| 400 || Nephrologie || NEPH || Nephrologie || gleicher Text<br />
|-<br />
| 500 || Hämatologie und internistische Onkologie || HAEM || Hämatologie und internistische Onkologie || gleicher Text<br />
|-<br />
| 600 || Endokrinologie || ENDO || Endokrinologie und Diabetologie || Quelle differenzierter<br />
|-<br />
| 700 || Gastroenterologie || GAST || Gastroenterologie || gleicher Text<br />
|-<br />
| 800 || Pneumologie || PNEU || Pneumologie || gleicher Text<br />
|-<br />
| 900 || Rheumatologie || RHEU || Rheumatologie || gleicher Text<br />
|-<br />
| 1000 || Pädiatrie || KIJU || Kinder- und Jugendmedizin || gleiche Bedeutung<br />
|-<br />
| 1100 || Kinderkardiologie || KKAR || Kinder-Kardiologie || gleiche Bedeutung<br />
|-<br />
| 1200 || Neonatologie || NNAT || Neonatologie || gleicher Text<br />
|-<br />
| 1300 || Kinderchirurgie || KDCH || Kinderchirurgie || gleicher Text<br />
|-<br />
| 1400 || Lungen- und Bronchialheilkunde || PNEU || Pneumologie || gleiche Bedeutung<br />
|-<br />
| 1500 || Allgemeine Chirurgie || ALCH || Allgemeinchirurgie || gleiche Bedeutung<br />
|-<br />
| 1600 || Unfallchirurgie || UNFC || Unfallchirurgie || gleicher Text<br />
|-<br />
| 1700 || Neurochirurgie || NRCH || Neurochirurgie || gleicher Text<br />
|-<br />
| 1800 || Gefäßchirurgie || GFCH || Gefäßchirurgie || gleicher Text<br />
|-<br />
| 1900 || Plastische Chirurgie || PLCH || Plastische und Ästhetische Chirurgie || Quelle differenzierter<br />
|-<br />
| 2000 || Thoraxchirurgie || THCH || Thoraxchirurgie || gleicher Text<br />
|-<br />
| 2100 || Herzchirurgie || HZCH || Herzchirurgie || gleicher Text<br />
|-<br />
| 2200 || Urologie || UROL || Urologie || gleicher Text<br />
|-<br />
| 2300 || Orthopädie || ORTH || Orthopädie || gleicher Text<br />
|-<br />
| 2400 || Frauenheilkunde und Geburtshilfe || FRAU || Frauenheilkunde und Geburtshilfe || gleicher Text<br />
|-<br />
| 2500 || davon Geburtshilfe || FRAU || Frauenheilkunde und Geburtshilfe || Quelle differenzierter<br />
|-<br />
| 2600 || Hals-, Nasen-, Ohrenheilkunde || HNOH || Hals-Nasen-Ohrenheilkunde || gleiche Bedeutung<br />
|-<br />
| 2700 || Augenheilkunde || AUGE || Augenheilkunde || gleicher Text<br />
|-<br />
| 2800 || Neurologie || NEUR || Neurologie || gleicher Text<br />
|-<br />
| 2900 || Allgemeine Psychiatrie || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 3000 || Kinder- und Jugendpsychiatrie || KPSY || Kinder- und Jugendpsychiatrie und -psychotherapie || Quelle differenzierter<br />
|-<br />
| 3100 || Psychosomatik/Psychotherapie || PSYM || Psychosomatische Medizin und Psychotherapie || gleiche Bedeutung<br />
|-<br />
| 3200 || Nuklearmedizin || NUKL || Nuklearmedizin || gleicher Text<br />
|-<br />
| 3300 || Strahlenheilkunde || STRA || Strahlentherapie || gleiche Bedeutung<br />
|-<br />
| 3400 || Dermatologie || HAUT || Haut- und Geschlechtskrankheiten || gleiche Bedeutung<br />
|-<br />
| 3500 || Zahn- und Kieferheilkunde, Mund- und Kieferchirurgie || MKGC oder MZKH || || Mapping muss für Abteilung individuell erfolgen<br />
|-<br />
| 3600 || Intensivmedizin || INTM || Intensivmedizin || gleicher Text<br />
|-<br />
| 2316 || Orthopädie und Unfallchirurgie || ORTH oder UNFC || || Mapping muss für Abteilung individuell erfolgen<br />
|-<br />
| 2425 || Frauenheilkunde || FRAU || Frauenheilkunde und Geburtshilfe || Quelle differenzierter<br />
|-<br />
| 3700 || Sonstige Fachabteilung || || || Mapping muss für Abteilung individuell erfolgen<br />
|-<br />
| 0102 || Innere Medizin/Schwerpunkt Geriatrie || GERI || Geriatrie || gleiche Bedeutung<br />
|-<br />
| 0103 || Innere Medizin/Schwerpunkt Kardiologie || KARD || Kardiologie || gleiche Bedeutung<br />
|-<br />
| 0104 || Innere Medizin/Schwerpunkt Nephrologie || NEPH || Nephrologie || gleiche Bedeutung<br />
|-<br />
| 0105 || Innere Medizin/Schwerpunkt Hämatologie und internistische Onkologie || HAEM || Hämatologie und internistische Onkologie || gleiche Bedeutung<br />
|-<br />
| 0106 || Innere Medizin/Schwerpunkt Endokrinologie || ENDO || Endokrinologie und Diabetologie || Quelle differenzierter<br />
|-<br />
| 0107 || Innere Medizin/Schwerpunkt Gastroenterologie || GAST || Gastroenterologie || gleiche Bedeutung<br />
|-<br />
| 0108 || Innere Medizin/Schwerpunkt Pneumologie || PNEU || Pneumologie || gleiche Bedeutung<br />
|-<br />
| 0109 || Innere Medizin/Schwerpunkt Rheumatologie || RHEU || Rheumatologie || gleiche Bedeutung<br />
|-<br />
| 0114 || Innere Medizin/Schwerpunkt Lungen- und Bronchialheilkunde || PNEU || Pneumologie || gleiche Bedeutung<br />
|-<br />
| 0150 || Innere Medizin/Tumorforschung || HAEM || Hämatologie und internistische Onkologie || gleiche Bedeutung<br />
|-<br />
| 0151 || Innere Medizin/Schwerpunkt Coloproktologie || GAST || Gastroenterologie || Quelle differenzierter<br />
|-<br />
| 0152 || Innere Medizin/Schwerpunkt Infektionskrankheiten || INNE || Innere Medizin || Quelle differenzierter<br />
|-<br />
| 0153 || Innere Medizin/Schwerpunkt Diabetes || ENDO || Endokrinologie und Diabetologie || Quelle differenzierter<br />
|-<br />
| 0154 || Innere Medizin/Schwerpunkt Naturheilkunde || NATU || Naturheilverfahren und alternative Heilmethoden || gleiche Bedeutung<br />
|-<br />
| 0156 || Innere Medizin/Schwerpunkt Schlaganfallpatienten (Stroke units, Artikel 7 § 1 Abs. 3 GKV-SolG) || INNE || Innere Medizin || Quelle differenzierter<br />
|-<br />
| 0224 || Geriatrie/Schwerpunkt Frauenheilkunde || GERI || Geriatrie || Quelle differenzierter<br />
|-<br />
| 0260 || Geriatrie/Tagesklinik (für teilstationäre Pflegesätze) || GERI || Geriatrie || Quelle differenzierter<br />
|-<br />
| 0261 || Geriatrie/Nachtklinik (für teilstationäre Pflegesätze) || GERI || Geriatrie || Quelle differenzierter<br />
|-<br />
| 0410 || Nephrologie/Schwerpunkt Pädiatrie || NEPH || Nephrologie || Quelle differenzierter<br />
|-<br />
| 0436 || Nephrologie/Intensivmedizin || NEPH || Nephrologie || Quelle differenzierter<br />
|-<br />
| 0510 || Hämatologie und internistische Onkologie/Schwerpunkt Pädiatrie || KONK || Kinder-Hämatologie und -Onkologie || Quelle differenzierter<br />
|-<br />
| 0524 || Hämatologie und internistische Onkologie/Schwerpunkt Frauenheilkunde || GONK || Gynäkologische Onkologie || gleiche Bedeutung<br />
|-<br />
| 0533 || Hämatologie und internistische Onkologie/Schwerpunkt Strahlenheilkunde || HAEM || Hämatologie und internistische Onkologie || Quelle differenzierter<br />
|-<br />
| 0607 || Endokrinologie/Schwerpunkt Gastroenterologie || ENDO || Endokrinologie und Diabetologie || Quelle differenzierter<br />
|-<br />
| 0610 || Endokrinologie/Schwerpunkt Pädiatrie || ENDO || Endokrinologie und Diabetologie || Quelle differenzierter<br />
|-<br />
| 0706 || Gastroenterologie/Schwerpunkt Endokrinologie || GAST || Gastroenterologie || Quelle differenzierter<br />
|-<br />
| 0710 || Gastroenterologie/Schwerpunkt Pädiatrie || GAST || Gastroenterologie || Quelle differenzierter<br />
|-<br />
| 0910 || Rheumatologie/Schwerpunkt Pädiatrie || RHEU || Rheumatologie || Quelle differenzierter<br />
|-<br />
| 1004 || Pädiatrie/Schwerpunkt Nephrologie || KIJU || Kinder- und Jugendmedizin || Quelle differenzierter<br />
|-<br />
| 1005 || Pädiatrie/Schwerpunkt Hämatologie und internistische Onkologie || KONK || Kinder-Hämatologie und -Onkologie || Quelle differenzierter<br />
|-<br />
| 1006 || Pädiatrie/Schwerpunkt Endokrinologie || KIJU || Kinder- und Jugendmedizin || Quelle differenzierter<br />
|-<br />
| 1007 || Pädiatrie/Schwerpunkt Gastroenterologie || KIJU || Kinder- und Jugendmedizin || Quelle differenzierter<br />
|-<br />
| 1009 || Pädiatrie/Schwerpunkt Rheumatologie || KIJU || Kinder- und Jugendmedizin || Quelle differenzierter<br />
|-<br />
| 1011 || Pädiatrie/Schwerpunkt Kinderkardiologie || KKAR || Kinder-Kardiologie || gleiche Bedeutung<br />
|-<br />
| 1012 || Pädiatrie/Schwerpunkt Neonatologie || NNAT || Neonatologie || gleiche Bedeutung<br />
|-<br />
| 1014 || Pädiatrie/Schwerpunkt Lungen- und Bronchialheilkunde || KIJU || Kinder- und Jugendmedizin || Quelle differenzierter<br />
|-<br />
| 1028 || Pädiatrie/Schwerpunkt Kinderneurologie || NPAE || Neuropädiatrie || gleiche Bedeutung<br />
|-<br />
| 1050 || Pädiatrie/Schwerpunkt Perinatalmedizin || PERI || Perinatalmedizin || gleiche Bedeutung<br />
|-<br />
| 1051 || Langzeitbereich Kinder || KIJU || Kinder- und Jugendmedizin || Quelle differenzierter<br />
|-<br />
| 1136 || Kinderkardiologie/Schwerpunkt Intensivmedizin || KKAR || Kinder-Kardiologie || Quelle differenzierter<br />
|-<br />
| 1410 || Lungen- und Bronchialheilkunde/Schwerpunkt Pädiatrie || PNEU || Pneumologie || Quelle differenzierter<br />
|-<br />
| 1513 || Allgemeine Chirurgie/Schwerpunkt Kinderchirurgie || KDCH || Kinderchirurgie || gleiche Bedeutung<br />
|-<br />
| 1516 || Allgemeine Chirurgie/Schwerpunkt Unfallchirurgie || UNFC || Unfallchirurgie || gleiche Bedeutung<br />
|-<br />
| 1518 || Allgemeine Chirurgie/Schwerpunkt Gefäßchirurgie || GFCH || Gefäßchirurgie || gleiche Bedeutung<br />
|-<br />
| 1519 || Allgemeine Chirurgie/Schwerpunkt Plastische Chirurgie || PLCH || Plastische und Ästhetische Chirurgie || Quelle differenzierter<br />
|-<br />
| 1520 || Allgemeine Chirurgie/Schwerpunkt Thoraxchirurgie || THCH || Thoraxchirurgie || gleiche Bedeutung<br />
|-<br />
| 1523 || Chirurgie/Schwerpunkt Orthopädie || ORTH || Orthopädie || gleiche Bedeutung<br />
|-<br />
| 1536 || Allgemeine Chirurgie/Intensivmedizin (§ 13 Abs. 2 Satz 3 2. Halbsatz BPflV in der am 31.12.2003 geltenden Fassung) || ALCH || Allgemeinchirurgie || Quelle differenzierter<br />
|-<br />
| 1550 || Allgemeine Chirurgie/Schwerpunkt Abdominal- und Gefäßchirurgie || ALCH || Allgemeinchirurgie || Quelle differenzierter<br />
|-<br />
| 1551 || Allgemeine Chirurgie/Schwerpunkt Handchirurgie || ALCH || Allgemeinchirurgie || Quelle differenzierter<br />
|-<br />
| 2021 || Thoraxchirurgie/Schwerpunkt Herzchirurgie || THCH || Thoraxchirurgie || Quelle differenzierter<br />
|-<br />
| 2036 || Thoraxchirurgie/Intensivmedizin || THCH || Thoraxchirurgie || Quelle differenzierter<br />
|-<br />
| 2050 || Thoraxchirurgie/Schwerpunkt Herzchirurgie Intensivmedizin || THCH || Thoraxchirurgie || Quelle differenzierter<br />
|-<br />
| 2120 || Herzchirurgie/Schwerpunkt Thoraxchirurgie || HZCH || Herzchirurgie || Quelle differenzierter<br />
|-<br />
| 2136 || Herzchirurgie/Intensivmedizin (§ 13 Abs. 2 Satz 3 2. Halbsatz BPflV in der am 31.12.2003 geltenden Fassung) || HZCH || Herzchirurgie || Quelle differenzierter<br />
|-<br />
| 2150 || Herzchirurgie/Schwerpunkt Thoraxchirurgie Intensivmedizin || HZCH || Herzchirurgie || Quelle differenzierter<br />
|-<br />
| 2309 || Orthopädie/Schwerpunkt Rheumatologie || ORTH || Orthopädie || Quelle differenzierter<br />
|-<br />
| 2315 || Orthopädie/Schwerpunkt Chirurgie || ORTH || Orthopädie || Quelle differenzierter<br />
|-<br />
| 2402 || Frauenheilkunde/Schwerpunkt Geriatrie || FRAU || Frauenheilkunde und Geburtshilfe || Quelle differenzierter<br />
|-<br />
| 2405 || Frauenheilkunde/Schwerpunkt Hämatologie und internistische Onkologie || GONK || Gynäkologische Onkologie || gleiche Bedeutung<br />
|-<br />
| 2406 || Frauenheilkunde/Schwerpunkt Endokrinologie || GEND || Gynäkologische Endokrinologie und Reproduktionsmedizin || Quelle differenzierter<br />
|-<br />
| 2810 || Neurologie/Schwerpunkt Pädiatrie || NPAE || Neuropädiatrie || gleiche Bedeutung<br />
|-<br />
| 2856 || Neurologie/Schwerpunkt Schlaganfallpatienten (Stroke units, Artikel 7 § 1 Abs. 3 GKV-SolG) || NEUR || Neurologie || Quelle differenzierter<br />
|-<br />
| 2928 || Allgemeine Psychiatrie/Schwerpunkt Neurologie || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2930 || Allgemeine Psychiatrie/Schwerpunkt Kinder- und Jugendpsychiatrie || KPSY || Kinder- und Jugendpsychiatrie und -psychotherapie || gleiche Bedeutung<br />
|-<br />
| 2931 || Allgemeine Psychiatrie/Schwerpunkt Psychosomatik/Psychotherapie || PSYM || Psychosomatische Medizin und Psychotherapie || gleiche Bedeutung<br />
|-<br />
| 2950 || Allgemeine Psychiatrie/Schwerpunkt Suchtbehandlung || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2951 || Allgemeine Psychiatrie/Schwerpunkt Gerontopsychiatrie || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2952 || Allgemeine Psychiatrie/Schwerpunkt Forensische Behandlung || FPSY || Forensische Psychiatrie || gleiche Bedeutung<br />
|-<br />
| 2953 || Allgemeine Psychiatrie/Schwerpunkt Suchtbehandlung, Tagesklinik || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2954 || Allgemeine Psychiatrie/Schwerpunkt Suchtbehandlung, Nachtklinik || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2955 || Allgemeine Psychiatrie/Schwerpunkt Gerontopsychiatrie, Tagesklinik || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2956 || Allgemeine Psychiatrie/Schwerpunkt Gerontopsychiatrie, Nachtklinik || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2960 || Allgemeine Psychiatrie/Tagesklinik (für teilstationäre Pflegesätze) || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2961 || Allgemeine Psychiatrie/Nachtklinik (für teilstationäre Pflegesätze) || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 3060 || Kinder- und Jugendpsychiatrie/Tagesklinik (für teilstationäre Pflegesätze) || KPSY || Kinder- und Jugendpsychiatrie und -psychotherapie || Quelle differenzierter<br />
|-<br />
| 3061 || Kinder- und Jugendpsychiatrie/Nachtklinik (für teilstationäre Pflegesätze) || KPSY || Kinder- und Jugendpsychiatrie und -psychotherapie || Quelle differenzierter<br />
|-<br />
| 3160 || Psychosomatik/Psychotherapie/Tagesklinik (für teilstationäre Pflegesätze) || PSYM || Psychosomatische Medizin und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 3161 || Psychosomatik/Psychotherapie/Nachtklinik (für teilstationäre Pflegesätze) || PSYM || Psychosomatische Medizin und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 3233 || Nuklearmedizin/Schwerpunkt Strahlenheilkunde || NUKL || Nuklearmedizin || Quelle differenzierter<br />
|-<br />
| 3305 || Strahlenheilkunde/Schwerpunkt Hämatologie und internistische Onkologie || STRA || Strahlentherapie || Quelle differenzierter<br />
|-<br />
| 3350 || Strahlenheilkunde/Schwerpunkt Radiologie || STRA || Strahlentherapie || Quelle differenzierter<br />
|-<br />
| 3460 || Dermatologie/Tagesklinik (für teilstationäre Pflegesätze) || HAUT || Haut- und Geschlechtskrankheiten || Quelle differenzierter<br />
|-<br />
| 3601 || Intensivmedizin/Schwerpunkt Innere Medizin || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3603 || Intensivmedizin/Schwerpunkt Kardiologie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3610 || Intensivmedizin/Schwerpunkt Pädiatrie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3617 || Intensivmedizin/Schwerpunkt Neurochirurgie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3618 || Intensivmedizin/Schwerpunkt Chirurgie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3621 || Intensivmedizin/Schwerpunkt Herzchirurgie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3622 || Intensivmedizin/Schwerpunkt Urologie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3624 || Intensivmedizin/Schwerpunkt Frauenheilkunde und Geburtshilfe || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3626 || Intensivmedizin/Schwerpunkt Hals-, Nasen-, Ohrenheilkunde || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3628 || Intensivmedizin/Schwerpunkt Neurologie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3650 || Operative Intensivmedizin/Schwerpunkt Chirurgie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3651 || Intensivmedizin/Thorax-Herzchirurgie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3652 || Intensivmedizin/Herz-Thoraxchirurgie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3750 || Angiologie || ANGI || Angiologie || gleicher Text<br />
|-<br />
| 3751 || Radiologie || RADI || Radiologie || gleicher Text<br />
|-<br />
| 3752 || Palliativmedizin || PALL || Palliativmedizin || gleicher Text<br />
|-<br />
| 3753 || Schmerztherapie || INTM, ANAE || || Mapping muss für Abteilung individuell erfolgen<br />
|-<br />
| 3754 || Heiltherapeutische Abteilung || NATU || Naturheilverfahren und alternative Heilmethoden || Quelle differenzierter<br />
|-<br />
| 3755 || Wirbelsäulenchirurgie || ORTH, NRCH || || Mapping muss für Abteilung individuell erfolgen<br />
|-<br />
| 3756 || Suchtmedizin || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 3757 || Visceralchirurgie || VICH || Viszeralchirurgie || gleiche Bedeutung<br />
|-<br />
| 3758 || Weaningeinheit || INTM || Intensivmedizin || Quelle differenzierter<br />
<br />
|}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|practiceSettingCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.healthcareFacilityTypeCode&diff=54048Ihevs:DocumentEntry.healthcareFacilityTypeCode2018-10-02T12:10:53Z<p>Tidris: /* DocumentEntry.healthcareFacilityTypeCode */ Warnhinweis und ART-DECOR Link</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.healthcareFacilityTypeCode==<br />
<br />
''DocumentEntry.healthcareFacilityTypeCode'' repräsentiert die Art der Einrichtung, in der die Tätigkeit stattfand, die zur Erzeugung des Dokuments führte. Zum Beispiel sollten Dokumente, die während eines ambulanten Falls in einem Krankenhaus entstehen, mit dem healthcareFacilityTypeCode für „Krankenhaus“ gekennzeichnet werden. Dabei ist zu beachten, dass es sich nicht notwendigerweise um die Art der Einrichtung handelt, in der das Dokument erstellt wurde. Beispielsweise ist es bei teleradiologischer Befundung eines Röntgenbildes für den healthcareFacilityTypeCode unerheblich, ob der befundende Radiologe in einem Krankenhaus oder in einer radiologischen Praxis ansässig ist; für den healthcareFacilityTypeCode wird die Einrichtungsart der Untersuchungsstelle (in der das Gerät betrieben wird) herangezogen.<br />
<br />
Ein Großteil der Dokumente, welche im Kontext von Datenaustauschszenarien in eine XDS-Domäne eingestellt werden sollen, entsteht in Einrichtungen der Patientenversorgung, wie beispielsweise Arztpraxen, Krankenhäusern oder auch Apotheken. In Deutschland werden aber nicht nur in Einrichtungen der Patientenversorgung Dokumente erzeugt, die über XDS-basierte Patientenakten ausgetauscht werden sollen. Innerhalb von anderen Institutionen wie beispielsweise Krankenkassen oder Forschungseinrichtungen werden ebenfalls entsprechende Dokumente erzeugt. Weiterhin kann der Patient selbst natürlich auch entsprechende Informationen in eine XDS-Domäne einstellen, z.B. mittels einer Healthcare-Smartphone-App oder Wearables. Der Anteil der Dokumente, die nicht in Einrichtungen der Patientenversorgung entstehen, wird voraussichtlich in Zukunft steigen.<br />
<br />
Daher entschied sich IHE Deutschland zur Erstellung von zwei Codesystemen, eines für Einrichtungen der Patientenversorgung, sowie eines für Einrichtungen außerhalb der Patientenversorgung. Der Einsatz von zwei separaten Codesystemen erleichtert die Pflege der Codes. Im ValueSet für den healthcareFacilityTypeCode werden natürlich Codes aus beiden Code-Systemen verwendet.<br />
<br />
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.36&effectiveDate=2018-10-01T18:33:06&language=de-DE ART-DECOR]] zuzugreifen.<br />
<br />
{{:1.2.276.0.76.11.36/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|HealthcareFacilityTypeCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.eventCodeList&diff=54047Ihevs:DocumentEntry.eventCodeList2018-10-02T12:09:45Z<p>Tidris: /* DocumentEntry.eventCodeList */ Warnhinweis und ART-DECOR Link</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.eventCodeList==<br />
<br />
Die eventCode Liste wurde konzipiert, um den medizinischen Kontext von Dokumenten abzubilden. Jedem Dokument können beliebig viele eventCodes zugeordnet werden. Zum Beispiel kann ein OP-Bericht über die eventCodeList mit je einem kodierten Wert für die durchgeführte Prozedur (z.B. Blinddarmentfernung) und die vorliegende Erkrankung (z.B. Appendizitis) versehen werden. Dies ermöglicht die Suche nach Dokumenten, die mit einer bestimmten Prozedur oder Diagnose zusammenhängen. Über den medizinischen Kontext hinaus kann das Attribut auch allgemein zur Kontextualisierung und zur Inhaltszusammenfassung verwendet werden. Zum Beispiel sieht das IHE BPPC Profil die Nutzung des eventCodes vor, um die Policy ID eines Patienteneinwilligungsdokuments abzubilden. IHE XDW wiederum nutzt den eventCode, um offene von abgeschlossenen Workflow-Aufgaben zu unterscheiden.<br />
<br />
Das von der Arbeitsgruppe definierte ValueSet umfasst sowohl von IHE International vergebene eventCodes (u.a. aus XDS-I, DSG) als auch neue von der AG definierte Code Systeme, sowie Empfehlungen zur Einbindung von größeren Katalogen.<br />
<br />
Der medizinische Kontext lässt sich gemäß obiger einführender Beschreibung zum Beispiel über einen oder mehrere OPS Codes und/oder ICD-10 Codes ausdrücken. Wenn andere Kataloge für ein bestimmtes Anwendungsgebiet sinnvoller sind (z.B. ORPHA-Nummern bei seltenen Erkrankungen oder ICD-O-3 bei Tumorerkrankungen), kann die Affinity Domain natürlich auch diese in der eventCodeList verwenden. Ob allerdings der medizinische Kontext überhaupt in dieser Granularität in den Metadaten abgebildet werden soll, ist abhängig von den Anwendungsfällen und muss projektspezifisch entschieden werden.<br />
<br />
Sowohl der OPS Katalog als auch der ICD-10-GM Katalog werden jedes Jahr mit einer neuen Code System ID veröffentlicht. Um in dieser Spezifikation nicht eine jahresspezifische Version zu referenzieren, wird das Value Set diesbezüglich intensional definiert. Somit empfiehlt die Arbeitsgruppe neben den weiter unten ausdrücklich benannten Codes auch die jeweils aktuelle ICD-10-GM und OPS Versionen als Bestandteil des Value Sets zu implementieren.<br />
<br />
Wie oben bereits erwähnt, hat die Arbeitsgruppe zwei neue Codesysteme erstellt, die auch Bestandteile dieses Value Sets sind:<br />
<br />
Das erste Codesystem (ihede-codesystem-15) umfasst Warnhinweise, die einem Dokument hinzugefügt werden können. Dazu gehört beispielsweise der Hinweis, dass dies ein vorläufiges Dokument ist (z.B. vorläufiger Arztbrief). Der Begriff vorläufig ist dabei unabhängig vom Dokumenten-Status/Lebenszyklus, der in XDS im availabilityStatus abgebildet wird. Ein weiterer Warnhinweis ist, dass das Dokument noch nicht mit dem Patienten besprochen wurde. Letzteres ist vor allem bei Akten sinnvoll, auf die auch der Patient Zugriff hat.<br />
<br />
Das zweite Codesystem (ihede-codesystem-16) umfasst den Fallkontext, in dem das Dokument erstellt wurde. Dazu gehört beispielsweise, ob das Dokument in einem ambulanten, stationären oder telemedizinischen Kontext erstellt wurde. Das Codesystem ist hierarchisch gegliedert, so dass die Abbildung auf einen entsprechenden eventCode je nach vorliegender Information bzw. je nach auslösendem Ereignis der Dokumenterstellung in verschiedenen Detaillierungsgraden erfolgen kann (z.B. "stationärer Aufenthalt" vs. "Verlegung in ein anderes Krankenhaus"). Die Arbeitsgruppe hat sich zur Bildung des Codesystems für den Fallkontext an den bestehenden Schlüsseltabellen zur Abbildung von - im weitesten Sinne - "ADT-Ereignissen" orientiert, die in Anlage 2 zur Vereinbarung nach § 301 Abs. 3 SGB V ("GKV-Datenaustausch") definiert sind (Schlüssel 1 Aufnahmegrund, Schlüssel 5 Entlassungs-/Verlegungsgrund). Hierbei wurden vorhandene Differenzierungen, die allein für spezifische Belange des Entgeltsystems von Bedeutung sind, nicht in das Value Set übertragen; es ist jedoch für jeden relevanten § 301 Schlüssel eine Abbildung auf einen ggf. übergeordneten, weniger detaillierten Code aus dem ihede-codesystem-16 möglich. Zusätzlich wurde ein Abgleich mit HL7 v2.5 Tabelle 0112 (Discharge Disposition) vorgenommen, so dass auch hier die meisten Konzepte abgebildet werden können.<br />
<br />
<br />
=== Vollständige Definition des Value Sets mit ID 1.2.276.0.76.11.34 ===<br />
{| class="hl7table"<br />
|+<br />
!Code System Name!! Code System ID!! Kommentar<br />
|-<br />
|Internationale statistische Klassifikation der Krankheiten und verwandter Gesundheitsprobleme (ICD-10) || versionsabhängig || z.B. ICD-10 GM 2018 mit Code System ID 1.2.276.0.76.5.471<br />
|-<br />
|Operationen- und Prozedurenschlüssel (OPS) || Versionsabhängig || z.B. OPS Version 2018 mit Code System ID 1.2.276.0.76.5.472<br />
|-<br />
|Digital Signature Purposes from ASTM E1762-95(2013) || 1.2.840.10065.1.12 || aus IHE DSG<br />
|-<br />
|IHE Format Codes || 1.3.6.1.4.1.19376.1.2.3 || IHE XDW eventCodes werden von IHE International ausnahmsweise mit der OID für das IHE formatCode Code System geführt; siehe unten für die Liste der Codes die Teil des Value Sets sind<br />
|-<br />
|DICOM Acquisition Modality || 1.2.840.10008.6.1.19 || aus IHE XDS-I<br />
|-<br />
|DICOM Anatomic Region || 1.2.840.10008.6.1.2 || aus IHE XDS-I<br />
|-<br />
|IHE Deutschland Warnhinweise || 1.3.6.1.4.1.19376.3.276.1.5.15 || Das vollständige Code System findet sich weiter unten<br />
|-<br />
|IHE Deutschland Fallkontext || 1.3.6.1.4.1.19376.3.276.1.5.16 || Das vollständige Code System findet sich weiter unten<br />
|}<br />
<br />
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.34&effectiveDate=2018-07-13T13:28:43&language=de-DE ART-DECOR]] zuzugreifen.<br />
<br />
{{ :1.2.276.0.76.11.34/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|eventCodeList]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.confidentialityCode&diff=54046Ihevs:DocumentEntry.confidentialityCode2018-10-02T12:08:34Z<p>Tidris: /* DocumentEntry.confidentialityCode */ Warnhinweis und ART-DECOR Link</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.confidentialityCode==<br />
Der Confidentiality Code drückt die Vertraulichkeitsstufe des Dokuments aus. Die Vertraulichkeitsstufe ist üblicherweise die Einschätzung des Autors oder des Einstellenden wie schützenswert das Dokument ist. Die Einschätzung des Autors oder Erstellers sollte erhalten bleiben, auch wenn die des Betroffenen (d.h. des Patienten) davon abweicht. <br />
Das heißt, dass man dem Dokument mehrere ConfidentialityCodes zuordnen können sollte. Dies unterstützt IHE XDS auch.<br />
Daher enthält das deutsche Value Set neben Codes der Autoreneinschätzung explizite Codes zur Betroffeneneinschätzung, die aus einem separaten, dediziertem Codesystem stammen. Die Einschätzung des Autors wird durch Codes des HL7-Codesystems Confidentiality ausgedrückt. Die Einschätzung des Betroffenen kann über das neue, von der Arbeitsgruppe definierte Codesystem ihede-codesystem-10 ausgedrückt werden. <br />
Jedes Dokument sollte eine Autoreneinschätzung haben. Die Betroffeneneinschätzung sollte zusätzlich verwendet werden, wenn der Patient explizit eine dementsprechende Entscheidung getroffen hat. Für vom Patienten erstellte oder eingestellte Dokumente sollte immer sowohl die Autoreneinschätzung wie auch die Betroffeneneinschätzung verwendet werden. <br />
Der Confidentiality Code ist ein wichtiges - jedoch nicht das einzige - Signal für das Berechtigungssystem um den Zugriff auf das Dokument zu regeln. Die hier vorgeschlagenen Werte implizieren kein spezifisches Berechtigungssystem. Zwei Affinity Domains können beide die hier vorgeschlagenen Codes verwenden, jedoch vollkommen unterschiedliche Berechtigungsentscheidungen treffen. Während zum Beispiel in der ersten Affinity Domain eingeschränkte Dokumente nur für den Hausarzt sichtbar sind, könnte die andere Affinity Domain eingeschränkte Dokumente nur für Fachärzte mit einer zum practiceSettingCode passenden authorSpeciality sichtbar machen. Die Interpretation des Confidentiality Codes ist somit Aufgabe des Berechtigungssystems. <br />
IHE XDS unterstützt die Verwendung von mehreren Confidentiality Codes für ein Dokument. Damit lässt sich zum Beispiel der von HL7 entwickelte Mechanismus für Security und Privacy Tags ("HL7 Healthcare Privacy and Security Classification System - HCS") umsetzen. Das hier vorgestellte Value Set lässt sich vollständig mit HCS kombinieren. <br />
<br />
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.33&effectiveDate=2018-07-13T13:27:59&language=de-DE ART-DECOR]] zuzugreifen.<br />
<br />
{{ :1.2.276.0.76.11.33/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|confidentialityCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.classCode&diff=54045Ihevs:DocumentEntry.classCode2018-10-02T12:07:26Z<p>Tidris: /* DocumentEntry.classCode */ Warnhinweis und ART-DECOR Link</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.classCode==<br />
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, Befunde oder Bilddaten. Die Wertemenge für diese Obermengen sollte nicht zu detailliert sein, da im Attribut ‚typeCode‘ eine weitere, verfeinerte Beschreibung der Dokumente erfolgt, die allerdings keine Spezialisierung des ,classCode' darstellen muss.<br />
<br />
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.<br />
<br />
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 IHE BPPC Dokumenten auch der dort fest vorgegebene LOINC Code unterstützt werden. Bei Verwendung von IHE APPC Dokumenten ist der Einsatz von LOINC für den classCode nicht gefordert. Bei IHE APPC gibt es stattdessen eine Vorgabe für den Einsatz eines LOINC Codes als typeCode.<br />
<br />
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.<br />
<br />
{{:1.2.276.0.76.11.32/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|classCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.author&diff=54044Ihevs:DocumentEntry.author2018-10-02T12:05:28Z<p>Tidris: /* DocumentEntry.authorSpecialty */ Warnhinweis und ART-DECOR Link</p>
<hr />
<div>{{DocumentPart}}<br />
<br />
==DocumentEntry.author==<br />
Die IHE Document Sharing Metadaten erlauben die Angabe mehrerer Autoren pro Dokument. Der Begriff Autor umfasst dabei alle aktiv an der Dokumentenerstellung beteiligten Personen und Geräte. Somit kann nicht nur der klassische Primärautor abgebildet werden, der die Sätze des Dokumententexts formuliert hat, sondern auch die Assistenzärztin, die die Messung durchgeführt hat, der Diktierdienst, die Spracherkennungssoftware oder auch ein Verwandter der die Anamneseinformationen beigesteuert hat. Welche dieser Teilnehmer sinnvollerweise als Autor in den Dokumentenmetadaten abgebildet werden sollte, ist vom Anwendungsfall abhängig und muss von der Affinity Domain entschieden werden.<br />
<br />
Der Autor hat folgende (Sub-)Attribute:<br />
* 0 oder 1 '''authorPerson'''<br />
* 0, 1 oder mehrere '''authorInstitution'''<br />
* 0, 1 oder mehrere '''authorRole'''<br />
* 0, 1 oder mehrere '''authorSpecialty'''<br />
* 0, 1 oder mehrere '''authorTelecommunication'''<br />
<br />
Der Autor wird primär über das authorPerson Subattribut bestimmt. Wenn vorhanden, muss zumindest der Nachname/Gerätename oder ein Identifier angegeben werden. Wenn diese Informationen nicht verfügbar sind oder (z.B. aus Datenschutzgründen) nicht strukturiert übertragen und gespeichert werden sollen, kann das authorPerson Subattribut auch vollständig entfallen. Die anderen Subattribute (z.B. authorRole und authorSpecialty) beziehen sich dann trotzdem auf die unbenannte authorPerson. authorRole und authorSpecialty beziehen sich nie auf die authorInstitution.<br />
<br />
===DocumentEntry.authorRole===<br />
<br />
Das optionale Attribut '''authorRole''' kann für jeden Autor separat angegeben werden und darf mehrfach vorhanden sein. Es beschreibt eine spezifische Rolle des Autors. Dies kann entweder eine Rolle im durch das Dokument beschriebenen Prozess sein (z.B. der Entlassbrief dreht sich um einen Entlass-Prozess, in dem ein Arzt die Rolle "Entlassender" innehat) oder es kann eine prozess- und behandlungsunabhängige Rolle bezogen auf den Patienten sein (z.B. "Hausarzt"). Auf die Hinzunahme der Rolle "Facharzt" wurde bewusst verzichtet, da dies schon über das Value Set authorSpecialty abgedeckt ist.<br />
<br />
Für die Verwendung im authorRole Subattribut wurden dementsprechend zwei Code Systeme entwickelt, das eine für Prozessrollen, das andere für Patientenbeziehungsrollen. Die Prozessrollen orientieren sich an mehreren HL7v2 und v3 Code Systemen (ParticipationType, ParticipationFunction, Table 443), sind jedoch verallgemeinert um sie auch für nicht-ärztliche Autoren nutzen zu können. Zur Unterscheidung eines durchführenden Arztes von einer durchführenden Pflegekraft kann die authorSpecialty verwendet werden.<br />
<br />
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.30&effectiveDate=2018-07-13T13:12:46&language=de-DE ART-DECOR]] zuzugreifen.<br />
<br />
{{ :1.2.276.0.76.11.30/dynamic }}<br />
<br />
===DocumentEntry.authorSpecialty===<br />
<br />
Das Attribut authorSpecialty gibt die Spezialisierung des Autors an, unter der der Autor das Dokument verfasst hat. Beispiele für Spezialisierung können bestimmte Facharzttitel sein, die der Autor besitzt, wie z.B. Facharzt für Psychiatrie oder Facharzt für Innere Medizin. Das Codesystem für ärztliche Spezialisierungen bildet die möglichen ärztlichen Facharztausbildungen, die es derzeit in Deutschland gibt, ab. Auf die Aufnahme von Zusatzbezeichnungen wurde verzichtet.<br />
Neben den ärztlichen Spezialisierungen können aber auch Qualifikationen nicht ärztlicher Autoren angegeben werden. Beispielsweise kann es sinnvoll sein, bei einem Autor anzugeben, dass dieser Lehrer, Psychologe oder Logopäde ist. Hierzu wurde von der Arbeitsgruppe ein eigenes Codesystem entwickelt, das typische Berufe des Gesundheitswesens enthält. Quellen hierfür waren ein Codesystem des ZTGs in Bochum und die Internetseiten des Arbeitsamtes. Alle anderen Berufe wurden in grob granulare Berufsgruppen wie Umwelt, Sprachen oder Reinigung zusammengefasst. Dadurch kann, je nach benötigten Detailgrad und je nach Verfügbarkeit der Informationen die Spezialisierung sehr grob (z.B. "Medizintechnik, Laboranalyse") oder sehr feingranular (z.B. "Medizinisch-Technischer Radiologieassistent") abgebildet werden.<br />
<br />
Die authorSpecialty sollte nicht mit dem practiceSettingCode verwechselt werden. Der practiceSettingCode gibt an, in welcher Art von Abteilung das Dokument verfasst wurde. Die authorSpecialty gibt die Qualifikation, die der Autor in dieser Abteilung hat, an. Beispielsweise könnte ein Dokument, das von einer Pflegekraft in einer Abteilung für Innere Medizin verfasst wurde, den practiceSettingCode "Innere Medizin" und die authorSpecialty "Gesundheits- und Krankenpfleger" erhalten.<br />
<br />
Alle Specialties wurden einheitlich in der männlichen Form stellvertretend für alle Geschlechter benannt.<br />
<br />
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.31&effectiveDate=2018-07-13T13:22:08&language=de-DE ART-DECOR]] zuzugreifen.<br />
<br />
{{ :1.2.276.0.76.11.31/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|authorRole]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.author&diff=54043Ihevs:DocumentEntry.author2018-10-02T12:04:31Z<p>Tidris: /* DocumentEntry.authorRole */ Links korrigiert</p>
<hr />
<div>{{DocumentPart}}<br />
<br />
==DocumentEntry.author==<br />
Die IHE Document Sharing Metadaten erlauben die Angabe mehrerer Autoren pro Dokument. Der Begriff Autor umfasst dabei alle aktiv an der Dokumentenerstellung beteiligten Personen und Geräte. Somit kann nicht nur der klassische Primärautor abgebildet werden, der die Sätze des Dokumententexts formuliert hat, sondern auch die Assistenzärztin, die die Messung durchgeführt hat, der Diktierdienst, die Spracherkennungssoftware oder auch ein Verwandter der die Anamneseinformationen beigesteuert hat. Welche dieser Teilnehmer sinnvollerweise als Autor in den Dokumentenmetadaten abgebildet werden sollte, ist vom Anwendungsfall abhängig und muss von der Affinity Domain entschieden werden.<br />
<br />
Der Autor hat folgende (Sub-)Attribute:<br />
* 0 oder 1 '''authorPerson'''<br />
* 0, 1 oder mehrere '''authorInstitution'''<br />
* 0, 1 oder mehrere '''authorRole'''<br />
* 0, 1 oder mehrere '''authorSpecialty'''<br />
* 0, 1 oder mehrere '''authorTelecommunication'''<br />
<br />
Der Autor wird primär über das authorPerson Subattribut bestimmt. Wenn vorhanden, muss zumindest der Nachname/Gerätename oder ein Identifier angegeben werden. Wenn diese Informationen nicht verfügbar sind oder (z.B. aus Datenschutzgründen) nicht strukturiert übertragen und gespeichert werden sollen, kann das authorPerson Subattribut auch vollständig entfallen. Die anderen Subattribute (z.B. authorRole und authorSpecialty) beziehen sich dann trotzdem auf die unbenannte authorPerson. authorRole und authorSpecialty beziehen sich nie auf die authorInstitution.<br />
<br />
===DocumentEntry.authorRole===<br />
<br />
Das optionale Attribut '''authorRole''' kann für jeden Autor separat angegeben werden und darf mehrfach vorhanden sein. Es beschreibt eine spezifische Rolle des Autors. Dies kann entweder eine Rolle im durch das Dokument beschriebenen Prozess sein (z.B. der Entlassbrief dreht sich um einen Entlass-Prozess, in dem ein Arzt die Rolle "Entlassender" innehat) oder es kann eine prozess- und behandlungsunabhängige Rolle bezogen auf den Patienten sein (z.B. "Hausarzt"). Auf die Hinzunahme der Rolle "Facharzt" wurde bewusst verzichtet, da dies schon über das Value Set authorSpecialty abgedeckt ist.<br />
<br />
Für die Verwendung im authorRole Subattribut wurden dementsprechend zwei Code Systeme entwickelt, das eine für Prozessrollen, das andere für Patientenbeziehungsrollen. Die Prozessrollen orientieren sich an mehreren HL7v2 und v3 Code Systemen (ParticipationType, ParticipationFunction, Table 443), sind jedoch verallgemeinert um sie auch für nicht-ärztliche Autoren nutzen zu können. Zur Unterscheidung eines durchführenden Arztes von einer durchführenden Pflegekraft kann die authorSpecialty verwendet werden.<br />
<br />
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.30&effectiveDate=2018-07-13T13:12:46&language=de-DE ART-DECOR]] zuzugreifen.<br />
<br />
{{ :1.2.276.0.76.11.30/dynamic }}<br />
<br />
===DocumentEntry.authorSpecialty===<br />
<br />
Das Attribut authorSpecialty gibt die Spezialisierung des Autors an, unter der der Autor das Dokument verfasst hat. Beispiele für Spezialisierung können bestimmte Facharzttitel sein, die der Autor besitzt, wie z.B. Facharzt für Psychiatrie oder Facharzt für Innere Medizin. Das Codesystem für ärztliche Spezialisierungen bildet die möglichen ärztlichen Facharztausbildungen, die es derzeit in Deutschland gibt, ab. Auf die Aufnahme von Zusatzbezeichnungen wurde verzichtet.<br />
Neben den ärztlichen Spezialisierungen können aber auch Qualifikationen nicht ärztlicher Autoren angegeben werden. Beispielsweise kann es sinnvoll sein, bei einem Autor anzugeben, dass dieser Lehrer, Psychologe oder Logopäde ist. Hierzu wurde von der Arbeitsgruppe ein eigenes Codesystem entwickelt, das typische Berufe des Gesundheitswesens enthält. Quellen hierfür waren ein Codesystem des ZTGs in Bochum und die Internetseiten des Arbeitsamtes. Alle anderen Berufe wurden in grob granulare Berufsgruppen wie Umwelt, Sprachen oder Reinigung zusammengefasst. Dadurch kann, je nach benötigten Detailgrad und je nach Verfügbarkeit der Informationen die Spezialisierung sehr grob (z.B. "Medizintechnik, Laboranalyse") oder sehr feingranular (z.B. "Medizinisch-Technischer Radiologieassistent") abgebildet werden.<br />
<br />
Die authorSpecialty sollte nicht mit dem practiceSettingCode verwechselt werden. Der practiceSettingCode gibt an, in welcher Art von Abteilung das Dokument verfasst wurde. Die authorSpecialty gibt die Qualifikation, die der Autor in dieser Abteilung hat, an. Beispielsweise könnte ein Dokument, das von einer Pflegekraft in einer Abteilung für Innere Medizin verfasst wurde, den practiceSettingCode "Innere Medizin" und die authorSpecialty "Gesundheits- und Krankenpfleger" erhalten.<br />
<br />
Alle Specialties wurden einheitlich in der männlichen Form stellvertretend für alle Geschlechter benannt.<br />
<br />
{{ :1.2.276.0.76.11.31/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|authorRole]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.author&diff=54042Ihevs:DocumentEntry.author2018-10-02T11:59:53Z<p>Tidris: /* DocumentEntry.authorRole */ Warnhinweis und ART-DECOR Link</p>
<hr />
<div>{{DocumentPart}}<br />
<br />
==DocumentEntry.author==<br />
Die IHE Document Sharing Metadaten erlauben die Angabe mehrerer Autoren pro Dokument. Der Begriff Autor umfasst dabei alle aktiv an der Dokumentenerstellung beteiligten Personen und Geräte. Somit kann nicht nur der klassische Primärautor abgebildet werden, der die Sätze des Dokumententexts formuliert hat, sondern auch die Assistenzärztin, die die Messung durchgeführt hat, der Diktierdienst, die Spracherkennungssoftware oder auch ein Verwandter der die Anamneseinformationen beigesteuert hat. Welche dieser Teilnehmer sinnvollerweise als Autor in den Dokumentenmetadaten abgebildet werden sollte, ist vom Anwendungsfall abhängig und muss von der Affinity Domain entschieden werden.<br />
<br />
Der Autor hat folgende (Sub-)Attribute:<br />
* 0 oder 1 '''authorPerson'''<br />
* 0, 1 oder mehrere '''authorInstitution'''<br />
* 0, 1 oder mehrere '''authorRole'''<br />
* 0, 1 oder mehrere '''authorSpecialty'''<br />
* 0, 1 oder mehrere '''authorTelecommunication'''<br />
<br />
Der Autor wird primär über das authorPerson Subattribut bestimmt. Wenn vorhanden, muss zumindest der Nachname/Gerätename oder ein Identifier angegeben werden. Wenn diese Informationen nicht verfügbar sind oder (z.B. aus Datenschutzgründen) nicht strukturiert übertragen und gespeichert werden sollen, kann das authorPerson Subattribut auch vollständig entfallen. Die anderen Subattribute (z.B. authorRole und authorSpecialty) beziehen sich dann trotzdem auf die unbenannte authorPerson. authorRole und authorSpecialty beziehen sich nie auf die authorInstitution.<br />
<br />
===DocumentEntry.authorRole===<br />
<br />
Das optionale Attribut '''authorRole''' kann für jeden Autor separat angegeben werden und darf mehrfach vorhanden sein. Es beschreibt eine spezifische Rolle des Autors. Dies kann entweder eine Rolle im durch das Dokument beschriebenen Prozess sein (z.B. der Entlassbrief dreht sich um einen Entlass-Prozess, in dem ein Arzt die Rolle "Entlassender" innehat) oder es kann eine prozess- und behandlungsunabhängige Rolle bezogen auf den Patienten sein (z.B. "Hausarzt"). Auf die Hinzunahme der Rolle "Facharzt" wurde bewusst verzichtet, da dies schon über das Value Set authorSpecialty abgedeckt ist.<br />
<br />
Für die Verwendung im authorRole Subattribut wurden dementsprechend zwei Code Systeme entwickelt, das eine für Prozessrollen, das andere für Patientenbeziehungsrollen. Die Prozessrollen orientieren sich an mehreren HL7v2 und v3 Code Systemen (ParticipationType, ParticipationFunction, Table 443), sind jedoch verallgemeinert um sie auch für nicht-ärztliche Autoren nutzen zu können. Zur Unterscheidung eines durchführenden Arztes von einer durchführenden Pflegekraft kann die authorSpecialty verwendet werden.<br />
<br />
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-<br />
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.30&effectiveDate=2018-07-13T13:12:46&language=de-DE]] zuzugreifen.<br />
<br />
{{ :1.2.276.0.76.11.30/dynamic }}<br />
<br />
===DocumentEntry.authorSpecialty===<br />
<br />
Das Attribut authorSpecialty gibt die Spezialisierung des Autors an, unter der der Autor das Dokument verfasst hat. Beispiele für Spezialisierung können bestimmte Facharzttitel sein, die der Autor besitzt, wie z.B. Facharzt für Psychiatrie oder Facharzt für Innere Medizin. Das Codesystem für ärztliche Spezialisierungen bildet die möglichen ärztlichen Facharztausbildungen, die es derzeit in Deutschland gibt, ab. Auf die Aufnahme von Zusatzbezeichnungen wurde verzichtet.<br />
Neben den ärztlichen Spezialisierungen können aber auch Qualifikationen nicht ärztlicher Autoren angegeben werden. Beispielsweise kann es sinnvoll sein, bei einem Autor anzugeben, dass dieser Lehrer, Psychologe oder Logopäde ist. Hierzu wurde von der Arbeitsgruppe ein eigenes Codesystem entwickelt, das typische Berufe des Gesundheitswesens enthält. Quellen hierfür waren ein Codesystem des ZTGs in Bochum und die Internetseiten des Arbeitsamtes. Alle anderen Berufe wurden in grob granulare Berufsgruppen wie Umwelt, Sprachen oder Reinigung zusammengefasst. Dadurch kann, je nach benötigten Detailgrad und je nach Verfügbarkeit der Informationen die Spezialisierung sehr grob (z.B. "Medizintechnik, Laboranalyse") oder sehr feingranular (z.B. "Medizinisch-Technischer Radiologieassistent") abgebildet werden.<br />
<br />
Die authorSpecialty sollte nicht mit dem practiceSettingCode verwechselt werden. Der practiceSettingCode gibt an, in welcher Art von Abteilung das Dokument verfasst wurde. Die authorSpecialty gibt die Qualifikation, die der Autor in dieser Abteilung hat, an. Beispielsweise könnte ein Dokument, das von einer Pflegekraft in einer Abteilung für Innere Medizin verfasst wurde, den practiceSettingCode "Innere Medizin" und die authorSpecialty "Gesundheits- und Krankenpfleger" erhalten.<br />
<br />
Alle Specialties wurden einheitlich in der männlichen Form stellvertretend für alle Geschlechter benannt.<br />
<br />
{{ :1.2.276.0.76.11.31/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|authorRole]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.formatCode&diff=54041Ihevs:DocumentEntry.formatCode2018-10-02T11:58:09Z<p>Tidris: /* Veröffentlichung der formatCodes */ Warnhinweis und Verweis auf ART-DECOR überarbeitet</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.formatCode==<br />
<br />
Der Code spezifiziert das Format des Dokumentes. Zusammen mit dem typeCode (und ggf. mit dem mimeType) soll der formatCode für hinreichende Information sorgen, um einem potenziellen XDS-Dokument-Konsumenten die Entscheidung zu ermöglichen, ob und wie er das Dokumentenformat verarbeiten kann.<br />
<br />
Der formatCode muss dabei hinreichend eindeutig formuliert sein, um die Verarbeitung/Anzeige des von der Registry angeforderten Dokumentes durch den Dokumentenkonsumer zu gewährleisten.<br />
<br />
===Vergabe von formatCodes===<br />
<br />
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.<br />
<br />
===Umfang des IHE Deutschland formatCode ValueSets===<br />
<br />
Das ValueSet hat die OID 1.2.276.0.76.11.35 und setzt sich aus Codes von IHE International, IHE Deutschland, HL7 und HL7 Deutschland zusammen.<br />
<br />
===Aufbau der formatCodes===<br />
====Aufbau der durch IHE International vergebenen formatCodes====<br />
<br />
formatCodes, welche von IHE ITI definiert werden, haben immer das Präfix<br />
<br />
urn:ihe:iti:<br />
<br />
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<br />
<br />
urn:ihe:’domain initials’:<br />
<br />
benutzen, wobei „domain initials“ die Domäne selbst repräsentiert.<br />
<br />
====Aufbau der durch IHE Deutschland vergebenen formatCodes====<br />
<br />
formatCodes, welche von IHE Deutschland definiert werden, haben immer das Präfix<br />
<br />
urn:ihe-d:<br />
<br />
Von IHE Deutschland festgelegte formatCodes werden wie folgt aufgebaut:<br />
<br />
=====Aufbau für CDA-Dokumente=====<br />
<br />
{| border=1<br />
|-<br />
|CDA-Dokumente ohne binärem Inhalt <br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr'<br />
|-<br />
|CDA-Dokumente mit einem Body, der aus einem binärem Inhalt besteht<br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr':nonXmlBody<br />
|-<br />
|CDA-Dokumente mit einem Body, der aus einer XML-Inhalten und mind. einer eingebettenen binärem Datei besteht <br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr':crossXmlBody<br />
|}<br />
<br />
„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).<br />
<br />
Beispiel: Sollte IHE Deutschland 2016 ein eigenes CDA-Dokument für eine Verordnung veröffentlichen, wird dieses entsprechend der obigen Beschreibung wie folgt abgebildet:<br />
<br />
a) Verordnung: Level 1-3 ohne binärem Inhalt<br />
urn:ihe-d:ig:Verordnung:2016<br />
b) Verordnung: Level 1 CDA mit Body bestehend aus einer PDF-Datei ([[IG:CDA_und_PDF/A3]])<br />
urn:ihe-d:ig:Verordnung:2016:nonXmlBody<br />
c) Verordnung: sowohl mit XML-Inhalt wie auch mindestens einer eingebetteten binären Datei <br />
urn:ihe-d:ig:Verordnung:2016:crossXmlBody<br />
<br />
=====Aufbau für nicht CDA-Dokumente=====<br />
<br />
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. <br />
<br />
{| border=1<br />
|-<br />
|IHE Deutschland <br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr'<br />
urn:ihe-d:spec:'Bezeichner':'Jahr'<br />
|}<br />
<br />
„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).<br />
<br />
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 wird Teil der Revision 15 des IHE ITI Technical Frameworks werden. Der equivalente, von IHE Deutschland eingeführte formatCode "urn:ihe-d:mime" gilt ab sofort als "deprecated" und sollte nicht mehr verwendet werden. <br />
<br />
'''Beispiel'''<br />
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. <br />
<br />
'''Sonderfall'''<br />
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”.<br />
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.<br />
<br />
====Empfehlungen von IHE Deutschland für den Aufbau von formatCodes für andere Organisationen====<br />
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.<br />
<br />
====formatCodes für FHIR Ressourcen====<br />
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 und ähnlichen Konstrukten 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'.<br />
<br />
<br />
<br />
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.35&effectiveDate=2018-07-13T16:16:59&language=de-DE ART-DECOR]] zuzugreifen.<br />
<br />
{{:1.2.276.0.76.11.35/dynamic }}<br />
<br />
===Links===<br />
* 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<br />
* RFC 2288 (1998) Using Existing Bibliographic Identifiers as Uniform Resource Names. Online, verfügbar unter http://tools.ietf.org/html/rfc2288<br />
* RFC 2141 (1997).URN Syntax. Online, verfügbar unter https://www.ietf.org/rfc/rfc2141.txt<br />
* RFC 3151 (2001) A URN Namespace for Public Identifiers. Online, verfügbar unter https://tools.ietf.org/html/rfc3151<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|formatCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.classCode&diff=54040Ihevs:DocumentEntry.classCode2018-10-02T11:41:05Z<p>Tidris: /* DocumentEntry.classCode */ redundante Tablle entfernt</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.classCode==<br />
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, Befunde oder Bilddaten. Die Wertemenge für diese Obermengen sollte nicht zu detailliert sein, da im Attribut ‚typeCode‘ eine weitere, verfeinerte Beschreibung der Dokumente erfolgt, die allerdings keine Spezialisierung des ,classCode' darstellen muss.<br />
<br />
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.<br />
<br />
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 IHE BPPC Dokumenten auch der dort fest vorgegebene LOINC Code unterstützt werden. Bei Verwendung von IHE APPC Dokumenten ist der Einsatz von LOINC für den classCode nicht gefordert. Bei IHE APPC gibt es stattdessen eine Vorgabe für den Einsatz eines LOINC Codes als typeCode.<br />
<br />
{{:1.2.276.0.76.11.32/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|classCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:Folder.codeList&diff=54039Ihevs:Folder.codeList2018-10-02T11:40:07Z<p>Tidris: /* Folder.codeList */ redundante Tabelle entfernt</p>
<hr />
<div>{{DocumentPart}}<br />
==Folder.codeList==<br />
<br />
Gerade bei longitudinalen Akten stellt sich die Frage, wie die eingestellten Dokumente geordnet werden können. Die in den IHE Document Sharing Profilen vorhandenen Ordner (Folder) entsprechen Markierungen (oft auch als "Tags" bezeichnet), wobei einem Dokument auch mehrere solche Markierungen problemlos zugewiesen werden können. Dies entspricht dem bei Blogs häufig verwendetem System, bei dem ein Artikel mit einem oder mehreren Tags versehen werden. Dies erlaubt es, die Blog Einträge in mehrere, sich überschneidende Teilmengen aufzuteilen, die unterschiedliche Themengebiete darstellen. Im Gegensatz zu Tags bei Blog Software werden die Folder in den IHE Document Sharing Profilen jedoch nicht nur durch eine frei wählbare Zeichenkette beschrieben, sondern zusätzlich durch einen Identifier und durch eine Liste von Codes.<br />
<br />
Ein Dokument kann in XDS also mehreren Ordnern zugeordnet werden, die wiederum durch mehrere Codes gekennzeichnet sein können. Die Ordner (Folder) in XDS entsprechen somit nicht dem Ordnerprinzip, mit dem die verbreiteten Betriebssysteme (Windows, UNIX, Linux) Dokumente organisieren. Dort werden die Dokumente in hierarchischen Strukturen entsprechenden Ankerpunkten zugeordnet. Diese Strukturen werden dabei über Pfadangaben realisiert, die durch voneinander getrennten Zeichenketten organisiert werden. Somit übernehmen diese zusammengesetzten Zeichenketten die Ablagelogik. (z.B. "C \ Windows \ System" oder "usr \ local"). Ein Dokument kann in einem solchen System typischerweise nur einem Ordner zugeordnet werden. (Manche Betriebssysteme ermöglichen über Verknüpfungseinträge auch eine Mehrfachzuordnung.) Die Ordner in XDS sind nicht hierarchisch, da sich keine Beziehungen zwischen Ordnern (wie Ordner A1 ist ein Unterordner von Ordner A) abbilden lassen.<br />
<br />
Die Einsatzzwecke von Ordnern in den IHE Document Sharing Profilen sind vielfältig und werden hier nicht weiter eingeschränkt. Daher ist das Value Set auch als [[Ihevs:Vokabular-Management|''open'']] deklariert und kann um zusätzliche Codes erweitert werden. Um redundante Kennzeichnungen (und daraus häufig resultierende Widersprüchen) zu vermeiden, wird empfohlen keine Ordner anzulegen, die die schon vorhandenen Metadaten duplizieren. Z.B. ist eine Grobklassifizierung von Dokumenten durch den classCode schon gegeben, daher muss kein XdsFolder für "Befunde" angelegt werden. Ebenso kann eine Verlinkung eines Dokuments mit dem zugehörigen administrativen Fall eines Krankenhauses durch die referenceIdList in den XdsDocumentEntry Metadaten realisiert werden, ohne für jeden Fall einen Folder anlegen zu müssen. Die Nutzung der XdsDocumentEntry Metadaten ist prinzipiell zu bevorzugen, da sich diese in XDS Anfragen weitaus flexibler einsetzen lassen und - im Gegensatz zum XdsFolder - kein explizites Anlegen und Verknüpfen erfordern.<br />
<br />
{{ :1.2.276.0.76.11.40/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|folderCodeList]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.healthcareFacilityTypeCode&diff=54038Ihevs:DocumentEntry.healthcareFacilityTypeCode2018-10-02T11:38:45Z<p>Tidris: /* DocumentEntry.healthcareFacilityTypeCode */ Redundante Tabelle entfernt</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.healthcareFacilityTypeCode==<br />
<br />
''DocumentEntry.healthcareFacilityTypeCode'' repräsentiert die Art der Einrichtung, in der die Tätigkeit stattfand, die zur Erzeugung des Dokuments führte. Zum Beispiel sollten Dokumente, die während eines ambulanten Falls in einem Krankenhaus entstehen, mit dem healthcareFacilityTypeCode für „Krankenhaus“ gekennzeichnet werden. Dabei ist zu beachten, dass es sich nicht notwendigerweise um die Art der Einrichtung handelt, in der das Dokument erstellt wurde. Beispielsweise ist es bei teleradiologischer Befundung eines Röntgenbildes für den healthcareFacilityTypeCode unerheblich, ob der befundende Radiologe in einem Krankenhaus oder in einer radiologischen Praxis ansässig ist; für den healthcareFacilityTypeCode wird die Einrichtungsart der Untersuchungsstelle (in der das Gerät betrieben wird) herangezogen.<br />
<br />
Ein Großteil der Dokumente, welche im Kontext von Datenaustauschszenarien in eine XDS-Domäne eingestellt werden sollen, entsteht in Einrichtungen der Patientenversorgung, wie beispielsweise Arztpraxen, Krankenhäusern oder auch Apotheken. In Deutschland werden aber nicht nur in Einrichtungen der Patientenversorgung Dokumente erzeugt, die über XDS-basierte Patientenakten ausgetauscht werden sollen. Innerhalb von anderen Institutionen wie beispielsweise Krankenkassen oder Forschungseinrichtungen werden ebenfalls entsprechende Dokumente erzeugt. Weiterhin kann der Patient selbst natürlich auch entsprechende Informationen in eine XDS-Domäne einstellen, z.B. mittels einer Healthcare-Smartphone-App oder Wearables. Der Anteil der Dokumente, die nicht in Einrichtungen der Patientenversorgung entstehen, wird voraussichtlich in Zukunft steigen.<br />
<br />
Daher entschied sich IHE Deutschland zur Erstellung von zwei Codesystemen, eines für Einrichtungen der Patientenversorgung, sowie eines für Einrichtungen außerhalb der Patientenversorgung. Der Einsatz von zwei separaten Codesystemen erleichtert die Pflege der Codes. Im ValueSet für den healthcareFacilityTypeCode werden natürlich Codes aus beiden Code-Systemen verwendet.<br />
<br />
{{:1.2.276.0.76.11.36/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|HealthcareFacilityTypeCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.typeCode&diff=54037Ihevs:DocumentEntry.typeCode2018-10-02T11:36:03Z<p>Tidris: /* DocumentEntry.typeCode */ Hinweis auf APPC Vorgaben hinzugefügt</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.typeCode==<br />
<br />
Das Attribut typeCode ist gemäß IHE XDS zwingend gefordert und kann zusätzlich zum classCode zur genaueren Klassifizierung des Dokuments genutzt werden, z.B. kann ein Dokument mit classCode "Befunde" durch den typeCode als "Pathologiebefund" 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."Befunde". 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.<br />
<br />
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.<br />
<br />
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 Befunde ist beispielsweise nicht der Oberbegriff zu Konzepten wie Mikrobiologiebefunde und Pathologiebefunde, sondern umfasst nur die Befunde, die nicht durch andere Konzepte abgedeckt werden.<br />
<br />
Bei Verwendung von IHE APPC Dokumenten muss auch der dort fest vorgegebene LOINC Code unterstützt werden. Bei Verwendung von IHE BPPC Dokumenten ist der Einsatz von LOINC für den typeCode nicht gefordert. Bei IHE BPPC gibt es stattdessen eine Vorgabe für den Einsatz eines LOINC Codes als classCode.<br />
<br />
{{:1.2.276.0.76.11.38/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|typeCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.classCode&diff=54036Ihevs:DocumentEntry.classCode2018-10-02T11:33:46Z<p>Tidris: /* DocumentEntry.classCode */ Hinweis auf LOINC Vorgaben von BPPC</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.classCode==<br />
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, Befunde oder Bilddaten. Die Wertemenge für diese Obermengen sollte nicht zu detailliert sein, da im Attribut ‚typeCode‘ eine weitere, verfeinerte Beschreibung der Dokumente erfolgt, die allerdings keine Spezialisierung des ,classCode' darstellen muss.<br />
<br />
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.<br />
<br />
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 IHE BPPC Dokumenten auch der dort fest vorgegebene LOINC Code unterstützt werden. Bei Verwendung von IHE APPC Dokumenten ist der Einsatz von LOINC für den classCode nicht gefordert. Bei IHE APPC gibt es stattdessen eine Vorgabe für den Einsatz eines LOINC Codes als typeCode.<br />
<br />
{| class="hl7table"<br />
|-<br />
!Codesystem !! Beschreibung !! Bildung<br />
|-<br />
| 1.3.6.1.4.1.19376.3.276.1.5.8 || Dokumentenklassen || alle Codes aus dem Codesystem<br />
|-<br />
| 2.16.840.1.113883.6.1 || LOINC || Codes die in internationalen IHE Profilen festgelegt wurden<br />
|}<br />
<br />
{{:1.2.276.0.76.11.32/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|classCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.typeCode&diff=53998Ihevs:DocumentEntry.typeCode2018-10-01T16:51:18Z<p>Tidris: /* DocumentEntry.typeCode */ Redundante Tabelle entfernt</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.typeCode==<br />
<br />
Das Attribut typeCode ist gemäß IHE XDS zwingend gefordert und kann zusätzlich zum classCode zur genaueren Klassifizierung des Dokuments genutzt werden, z.B. kann ein Dokument mit classCode "Befunde" durch den typeCode als "Pathologiebefund" 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."Befunde". 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.<br />
<br />
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.<br />
<br />
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 Befunde ist beispielsweise nicht der Oberbegriff zu Konzepten wie Mikrobiologiebefunde und Pathologiebefunde, sondern umfasst nur die Befunde, die nicht durch andere Konzepte abgedeckt werden.<br />
<br />
{{:1.2.276.0.76.11.38/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|typeCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.typeCode&diff=53997Ihevs:DocumentEntry.typeCode2018-10-01T16:49:22Z<p>Tidris: /* DocumentEntry.typeCode */</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.typeCode==<br />
<br />
Das Attribut typeCode ist gemäß IHE XDS zwingend gefordert und kann zusätzlich zum classCode zur genaueren Klassifizierung des Dokuments genutzt werden, z.B. kann ein Dokument mit classCode "Befunde" durch den typeCode als "Pathologiebefund" 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."Befunde". 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.<br />
<br />
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.<br />
<br />
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 Befunde ist beispielsweise nicht der Oberbegriff zu Konzepten wie Mikrobiologiebefunde und Pathologiebefunde, sondern umfasst nur die Befunde, die nicht durch andere Konzepte abgedeckt werden.<br />
<br />
<br />
{| class="hl7table"<br />
|-<br />
!Codesystem !! Beschreibung !! Bildung<br />
|-<br />
| 1.3.6.1.4.1.19376.3.276.1.5.9 || Dokumententypen || alle Codes aus dem Codesystem<br />
|}<br />
<br />
{{:1.2.276.0.76.11.38/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|typeCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.PracticeSettingCode&diff=53996Ihevs:DocumentEntry.PracticeSettingCode2018-10-01T16:47:39Z<p>Tidris: /* DocumentEntry.practiceSettingCode */ Kleinere Schreibfehler entfernt, redundante Code System Auflistung entfernt</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.practiceSettingCode==<br />
<br />
DocumentEntry.practiceSettingCode spezifiziert die Fachrichtung der erstellenden Einrichtung. Typische Beispiele hierfür sind ärztliche Fachgebiete wie Allgemeinmedizin oder Radiologie. IHE International empfiehlt, dass die Codeliste zwischen 10 und 100 Codes umfassen sollte, so dass die Fachrichtung hinreichend genau abgebildet werden kann.<br />
<br />
Jedem Dokument muss genau ein practiceSettingCode zugeordnet werden, auch wenn es in vielen Situationen mehrere beteiligte Fachrichtungen gibt. Ein Beispiel hierfür ist ein Röntgen-Befund, der aus der Chirurgie angefordert wird. Um hier eindeutig zu sein, schreibt IHE XDS vor, dass als Fachrichtung jene gewählt werden muss, die die Fachrichtung der medizinischen Versorgungseinrichtung beschreibt, deren Tätigkeit zur Erstellung des Dokuments geführt hat. Im obigen Beispiel hat die Radiologie die Röntgen-Aufnahme durchgeführt und dem daraus resultierenden Dokument (der Röntgen-Befund) sollte somit der practiceSettingCode für „Radiologie“ zugeordnet werden. Dabei ist zu beachten, dass die Charakterisierung der durchführenden Organisation entscheidend ist, nicht der Facharzttitel des Akteurs oder die Typisierung des Dokuments. Wenn histologische Befunde aus der Dermatologie kommen, sollte der practiceSettingCode „Dermatologie“ verwendet werden. Wenn ein als Allgemeinarzt tätiger Internist einen Arztbrief schreibt, muss diesem Brief daher der practiceSettingCode für „Allgemeinmedizin“ zugeordnet werden.<br />
<br />
In den verschiedenen Ländern existieren unterschiedliche Anforderungen an diesen Code. IHE UK definierte ein Value Set (http://wiki.ihe-uk.org/AppendixB), desgleichen die Niederlande (http://decor.nictiz.nl/services/RetrieveValueSet?id=2.16.840.1.113883.2.4.3.11.60.106.11.10&effectiveDate=2013-12-12T10:41:06&prefix=xds-&format=html&language=de-DE), aber auch für Connect-a-thons werden eigene Codes definiert (http://www.hl7.org/FHIR/valueset-xds-practice-codes.html).<br />
<br />
In Deutschland existiert durch die (Muster-) Weiterbildungsordnung der Bundesärztekammer eine sehr gute Auflistung medizinischer Fachgebiete, so dass die Fachrichtung der direkten medizinischen Versorgung durch diese Liste wiedergegeben wird. Daneben existieren aber weitere medizinische Versorgungsangebote wie beispielsweise Ernährungsberatung, welche durch die Weiterbildungsordnung nicht abgedeckt werden.<br />
<br />
IHE Deutschland bildete daher zwei Codesysteme: eines basierend auf der ärztlichen Weiterbildungsordnung sowie ein Codesystem für weitergehende medizinische Versorgungsangebote. Die Abbildung in zwei Codesystemen für die Darstellung der Fachrichtung sorgt auch hier für die bessere Wartbarkeit der Codesysteme: so kann einfacher auf Anpassungen der ärztlichen Weiterbildungsordnung reagiert werden. Das Value Set umfasst beide Codesysteme.<br />
<br />
Das Value Set für DocumentEntry.practiceSettingCode setzt sich aus den beiden Kodesystemen für ärztliche und nicht-ärztliche Fachrichtungen zusammen, die nachfolgend aufgeführt sind:<br />
{{:1.2.276.0.76.11.37/dynamic }}<br />
<br />
Die Fachrichtung ist generell unabhängig von der Ausbildung der Person, welche die medizinische Leistung erbringt. Daher müssen Leistungen, welche nicht-ärztliche Personen erbringen, trotzdem der aus der ärztlichen Weiterbildungsordnung beruhenden Fachrichtung zugeordnet werden, sofern diese existiert. Um die Zuordnung zu erleichtern, erstellte IHE Deutschland nachfolgende Liste als Orientierungshilfe:<br />
<br />
{| class="hl7table"<br />
|-<br />
!Beruf !!Zuordnung Fachrichtung<br />
|-<br />
|Medizinische Fachangestellte / Medizinischer Fachangestellter<br />
(alte Bezeichnung: Arzthelferin / Arzthelfer)<br />
|Üblicherweise in ärztlich geführter Einrichtung tätig, daher sollte die entsprechende ärztliche Fachrichtung verwendet werden.<br />
|-<br />
|Orientierungs- und Mobilitätslehrer/in und ähnliche, ggf. auch Blindenverbände ||Augenheilkunde<br />
|-<br />
|Anästhesie-technische Assistentin / Anästhesie-technischer Assistent ||Anästhesiologie<br />
|-<br />
|Orthoptistin / Orthoptist ||Augenheilkunde<br />
|-<br />
|Chirurgische Operationsassistentin / Chirurgischer Operationsassistent ||Chirurgie<br />
|-<br />
|Medizinisch-technische Assistentin für den Operationsdienst / Medizinisch-technischer Assistent für den Operationsdienst ||Chirurgie<br />
|-<br />
|Operationstechnische Assistentin / Operationstechnischer Assistent ||Chirurgie<br />
|-<br />
|Klinische Kodierfachkraft ||Üblicherweise in ärztlich geführter Einrichtung tätig, daher sollte die entsprechende ärztliche Fachrichtung verwendet werden.<br />
|-<br />
|Medizinische Dokumentarin / Medizinischer Dokumentar ||Üblicherweise in ärztlich geführter Einrichtung tätig, daher sollte die entsprechende ärztliche Fachrichtung verwendet werden<br />
|-<br />
|Medizinische Dokumentationsassistentin / Medizinischer Dokumentationsassistent ||Üblicherweise in ärztlich geführter Einrichtung tätig, daher sollte die entsprechende ärztliche Fachrichtung verwendet werden<br />
|-<br />
|Hebamme / Entbindungspfleger ||Frauenheilkunde und Geburtshilfe<br />
|-<br />
|Heilpraktikerin / Heilpraktiker ||Naturheilverfahren<br />
|-<br />
|Hygiene-Beauftragte / Hygiene-Beauftragter ||Hygiene und Umweltmedizin<br />
|-<br />
|Hygienekontrolleurin / Hygienekontrolleur/Gesundheitsaufseherin/Gesundheitsaufseher ||Hygiene und Umweltmedizin<br />
|-<br />
|Kardiotechnikerin / Kardiotechniker ||Herzchirurgie oder Kardiologie, je nach Einsatzgebiet<br />
|-<br />
|Medizinisch-technische Assistentin für Funktionsdiagnostik / Medizinisch-technischer Assistent für Funktionsdiagnostik ||Üblicherweise in ärztlich geführter Einrichtung tätig, daher sollte die entsprechende ärztliche Fachrichtung verwendet werden<br />
|-<br />
|Medizinisch-technische Laboratoriumsassistentin / Medizinisch-technischer Laboratoriumsassistent ||Laboratoriumsmedizin<br />
|-<br />
|Zahnmedizinische Fachangestellte / Zahnmedizinischer Fachangestellter (alte Bezeichnung: Zahnarzthelferin / Zahnarzthelfer) ||Zahnmedizin<br />
|-<br />
|Notfallsanitäterin / Notfallsanitäter ||Notfallmedizin<br />
|-<br />
|Rettungsassistenten-Praktikantin / Rettungsassistenten-Praktikant ||Notfallmedizin<br />
|-<br />
|Rettungsassistentin / Rettungsassistent ||Notfallmedizin<br />
|-<br />
|Rettungssanitäterin / Rettungssanitäter ||Notfallmedizin<br />
|-<br />
|Heilpraktikerin / Heilpraktiker (beschränkt auf das Gebiet der Psychotherapie) || Je nach Ausrichtung entweder "Psychiatrie und Psychotherapie" oder "Psychosomatische Medizin und Psychotherapie"<br />
|-<br />
|Psychologische Psychotherapeuten ||Je nach Ausrichtung entweder "Psychiatrie und Psychotherapie" oder "Psychosomatische Medizin und Psychotherapie"<br />
|-<br />
|Kinder- und Jugendlichenpsychotherapeuten ||Kinder- und Jugendpsychiatrie und -psychotherapie<br />
|-<br />
|Medizinisch-technische Radiologieassistentin / Medizinisch-technischer Radiologieassistent ||Radiologie<br />
|-<br />
|Masseurin und medizinische Bademeisterin / Masseur und medizinischer Bademeister ||Physikalische und rehabilitative Medizin<br />
|-<br />
|Physiotherapeutin / Physiotherapeut ||Physikalische und rehabilitative Medizin<br />
|-<br />
|Osteopathin / Osteopath ||Physikalische und rehabilitative Medizin<br />
|-<br />
|Qigong-Lehrende / Qigong-Lehrender ||Physikalische und rehabilitative Medizin<br />
|-<br />
|Shiatsu-Praktikerin / Shiatsu-Praktiker ||Physikalische und rehabilitative Medizin<br />
|-<br />
|Taijiquan-Lehrende / Taijiquan-Lehrender ||Physikalische und rehabilitative Medizin<br />
|-<br />
|Dentalhygienikerin / Dentalhygieniker ||Zahnmedizin<br />
|-<br />
|Diplom-Ingenieur/in des Fachbereichs Augenoptik/Diplom-Augenoptiker (FH) ||Augenheilkunde<br />
|-<br />
|Occularist/in / Glasbläser/in mit Fachrichtung Kunstaugen (Himi) ||Augenheilkunde<br />
|-<br />
|Chirurgiemechanikerin / Chirurgiemechaniker ||Chirurgie<br />
|-<br />
|Hörakustikerin / Hörakustiker ||Hals-Nasen-Ohrenheilkunde<br />
|-<br />
|Hörgeräteakustikerin / Hörgeräteakustiker ||Hals-Nasen-Ohrenheilkunde<br />
|-<br />
|Diplomingenieur/in für Orthopädie und Rehatechnik ||Orthopädie<br />
|-<br />
|Orthopädiemechanikerin und Bandagistin / Orthopädiemechaniker und Bandagist ||Orthopädie<br />
|-<br />
|Orthopädieschuhmacherin / Orthopädieschuhmacher ||Orthopädie<br />
|-<br />
|Orthopädietechnikerin / Orthopädietechniker ||Orthopädie<br />
|-<br />
|Dentalingenieur ||Zahnmedizin<br />
|-<br />
|Zahntechnikerin / Zahntechniker ||Zahnmedizin<br />
|-<br />
|Fitnessberaterin / Fitnessberater ||Sport- und Bewegungsmedizin, Physikalische und rehabilitative Medizin; wenn keines von beiden zutrifft: Prävention<br />
|-<br />
|Fitnessmanagerin / Fitnessmanager ||Sport- und Bewegungsmedizin, Physikalische und Rehabilitative Medizin; wenn keines von beiden zutrifft: Prävention<br />
|-<br />
|Fitnesstrainerin / Fitnesstrainer ||Sport- und Bewegungsmedizin, Physikalische und Rehabilitative Medizin; wenn keines von beiden zutrifft: Prävention<br />
|}<br />
<br />
<br />
Nach §301 SGB V müssen deutsche Krankenhäuser bei der Abrechnung Fachabteilungen nach dem Schlüssel 6 "Fachabteilungen" gemäß Anhang 1 der BPflV kodieren.<br />
Zum leichteren Auffinden des PracticeSettingCodes stellen wir daher hier ein Mapping zwischen dem Fachabteilungsschlüssel für Krankenhäuser und dem PracticeSettingCode bereit. In der Regel ist der PracticeSettingCode inhaltsgleich oder allgemeiner als der Fachabteilungsschlüssel. In wenigen Ausnahmen ist der PracticeSettingCode differenzierter als der Fachabteilungsschlüssel. In diesen Fällen ist ein automatisches Mapping nicht möglich. Daher muss die Fachabteilung in diesem Fall selbst entscheiden, welcher PracticeSettingCode für sie am besten geeignet ist. <br />
<br />
<br />
{| class="hl7table"<br />
|-<br />
!Fachabteilungsschlüssel !! Klartext Fachabteilung !! practiceSettingCode !! Displayname PracticeSettingCode !! Bemerkungen<br />
|-<br />
| 100 || Innere Medizin || INNE || Innere Medizin || gleicher Text<br />
|-<br />
| 200 || Geriatrie || GERI || Geriatrie || gleicher Text<br />
|-<br />
| 300 || Kardiologie || KARD || Kardiologie || gleicher Text<br />
|-<br />
| 400 || Nephrologie || NEPH || Nephrologie || gleicher Text<br />
|-<br />
| 500 || Hämatologie und internistische Onkologie || HAEM || Hämatologie und internistische Onkologie || gleicher Text<br />
|-<br />
| 600 || Endokrinologie || ENDO || Endokrinologie und Diabetologie || Quelle differenzierter<br />
|-<br />
| 700 || Gastroenterologie || GAST || Gastroenterologie || gleicher Text<br />
|-<br />
| 800 || Pneumologie || PNEU || Pneumologie || gleicher Text<br />
|-<br />
| 900 || Rheumatologie || RHEU || Rheumatologie || gleicher Text<br />
|-<br />
| 1000 || Pädiatrie || KIJU || Kinder- und Jugendmedizin || gleiche Bedeutung<br />
|-<br />
| 1100 || Kinderkardiologie || KKAR || Kinder-Kardiologie || gleiche Bedeutung<br />
|-<br />
| 1200 || Neonatologie || NNAT || Neonatologie || gleicher Text<br />
|-<br />
| 1300 || Kinderchirurgie || KDCH || Kinderchirurgie || gleicher Text<br />
|-<br />
| 1400 || Lungen- und Bronchialheilkunde || PNEU || Pneumologie || gleiche Bedeutung<br />
|-<br />
| 1500 || Allgemeine Chirurgie || ALCH || Allgemeinchirurgie || gleiche Bedeutung<br />
|-<br />
| 1600 || Unfallchirurgie || UNFC || Unfallchirurgie || gleicher Text<br />
|-<br />
| 1700 || Neurochirurgie || NRCH || Neurochirurgie || gleicher Text<br />
|-<br />
| 1800 || Gefäßchirurgie || GFCH || Gefäßchirurgie || gleicher Text<br />
|-<br />
| 1900 || Plastische Chirurgie || PLCH || Plastische und Ästhetische Chirurgie || Quelle differenzierter<br />
|-<br />
| 2000 || Thoraxchirurgie || THCH || Thoraxchirurgie || gleicher Text<br />
|-<br />
| 2100 || Herzchirurgie || HZCH || Herzchirurgie || gleicher Text<br />
|-<br />
| 2200 || Urologie || UROL || Urologie || gleicher Text<br />
|-<br />
| 2300 || Orthopädie || ORTH || Orthopädie || gleicher Text<br />
|-<br />
| 2400 || Frauenheilkunde und Geburtshilfe || FRAU || Frauenheilkunde und Geburtshilfe || gleicher Text<br />
|-<br />
| 2500 || davon Geburtshilfe || FRAU || Frauenheilkunde und Geburtshilfe || Quelle differenzierter<br />
|-<br />
| 2600 || Hals-, Nasen-, Ohrenheilkunde || HNOH || Hals-Nasen-Ohrenheilkunde || gleiche Bedeutung<br />
|-<br />
| 2700 || Augenheilkunde || AUGE || Augenheilkunde || gleicher Text<br />
|-<br />
| 2800 || Neurologie || NEUR || Neurologie || gleicher Text<br />
|-<br />
| 2900 || Allgemeine Psychiatrie || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 3000 || Kinder- und Jugendpsychiatrie || KPSY || Kinder- und Jugendpsychiatrie und -psychotherapie || Quelle differenzierter<br />
|-<br />
| 3100 || Psychosomatik/Psychotherapie || PSYM || Psychosomatische Medizin und Psychotherapie || gleiche Bedeutung<br />
|-<br />
| 3200 || Nuklearmedizin || NUKL || Nuklearmedizin || gleicher Text<br />
|-<br />
| 3300 || Strahlenheilkunde || STRA || Strahlentherapie || gleiche Bedeutung<br />
|-<br />
| 3400 || Dermatologie || HAUT || Haut- und Geschlechtskrankheiten || gleiche Bedeutung<br />
|-<br />
| 3500 || Zahn- und Kieferheilkunde, Mund- und Kieferchirurgie || MKGC oder MZKH || || Mapping muss für Abteilung individuell erfolgen<br />
|-<br />
| 3600 || Intensivmedizin || INTM || Intensivmedizin || gleicher Text<br />
|-<br />
| 2316 || Orthopädie und Unfallchirurgie || ORTH oder UNFC || || Mapping muss für Abteilung individuell erfolgen<br />
|-<br />
| 2425 || Frauenheilkunde || FRAU || Frauenheilkunde und Geburtshilfe || Quelle differenzierter<br />
|-<br />
| 3700 || Sonstige Fachabteilung || || || Mapping muss für Abteilung individuell erfolgen<br />
|-<br />
| 0102 || Innere Medizin/Schwerpunkt Geriatrie || GERI || Geriatrie || gleiche Bedeutung<br />
|-<br />
| 0103 || Innere Medizin/Schwerpunkt Kardiologie || KARD || Kardiologie || gleiche Bedeutung<br />
|-<br />
| 0104 || Innere Medizin/Schwerpunkt Nephrologie || NEPH || Nephrologie || gleiche Bedeutung<br />
|-<br />
| 0105 || Innere Medizin/Schwerpunkt Hämatologie und internistische Onkologie || HAEM || Hämatologie und internistische Onkologie || gleiche Bedeutung<br />
|-<br />
| 0106 || Innere Medizin/Schwerpunkt Endokrinologie || ENDO || Endokrinologie und Diabetologie || Quelle differenzierter<br />
|-<br />
| 0107 || Innere Medizin/Schwerpunkt Gastroenterologie || GAST || Gastroenterologie || gleiche Bedeutung<br />
|-<br />
| 0108 || Innere Medizin/Schwerpunkt Pneumologie || PNEU || Pneumologie || gleiche Bedeutung<br />
|-<br />
| 0109 || Innere Medizin/Schwerpunkt Rheumatologie || RHEU || Rheumatologie || gleiche Bedeutung<br />
|-<br />
| 0114 || Innere Medizin/Schwerpunkt Lungen- und Bronchialheilkunde || PNEU || Pneumologie || gleiche Bedeutung<br />
|-<br />
| 0150 || Innere Medizin/Tumorforschung || HAEM || Hämatologie und internistische Onkologie || gleiche Bedeutung<br />
|-<br />
| 0151 || Innere Medizin/Schwerpunkt Coloproktologie || GAST || Gastroenterologie || Quelle differenzierter<br />
|-<br />
| 0152 || Innere Medizin/Schwerpunkt Infektionskrankheiten || INNE || Innere Medizin || Quelle differenzierter<br />
|-<br />
| 0153 || Innere Medizin/Schwerpunkt Diabetes || ENDO || Endokrinologie und Diabetologie || Quelle differenzierter<br />
|-<br />
| 0154 || Innere Medizin/Schwerpunkt Naturheilkunde || NATU || Naturheilverfahren und alternative Heilmethoden || gleiche Bedeutung<br />
|-<br />
| 0156 || Innere Medizin/Schwerpunkt Schlaganfallpatienten (Stroke units, Artikel 7 § 1 Abs. 3 GKV-SolG) || INNE || Innere Medizin || Quelle differenzierter<br />
|-<br />
| 0224 || Geriatrie/Schwerpunkt Frauenheilkunde || GERI || Geriatrie || Quelle differenzierter<br />
|-<br />
| 0260 || Geriatrie/Tagesklinik (für teilstationäre Pflegesätze) || GERI || Geriatrie || Quelle differenzierter<br />
|-<br />
| 0261 || Geriatrie/Nachtklinik (für teilstationäre Pflegesätze) || GERI || Geriatrie || Quelle differenzierter<br />
|-<br />
| 0410 || Nephrologie/Schwerpunkt Pädiatrie || NEPH || Nephrologie || Quelle differenzierter<br />
|-<br />
| 0436 || Nephrologie/Intensivmedizin || NEPH || Nephrologie || Quelle differenzierter<br />
|-<br />
| 0510 || Hämatologie und internistische Onkologie/Schwerpunkt Pädiatrie || KONK || Kinder-Hämatologie und -Onkologie || Quelle differenzierter<br />
|-<br />
| 0524 || Hämatologie und internistische Onkologie/Schwerpunkt Frauenheilkunde || GONK || Gynäkologische Onkologie || gleiche Bedeutung<br />
|-<br />
| 0533 || Hämatologie und internistische Onkologie/Schwerpunkt Strahlenheilkunde || HAEM || Hämatologie und internistische Onkologie || Quelle differenzierter<br />
|-<br />
| 0607 || Endokrinologie/Schwerpunkt Gastroenterologie || ENDO || Endokrinologie und Diabetologie || Quelle differenzierter<br />
|-<br />
| 0610 || Endokrinologie/Schwerpunkt Pädiatrie || ENDO || Endokrinologie und Diabetologie || Quelle differenzierter<br />
|-<br />
| 0706 || Gastroenterologie/Schwerpunkt Endokrinologie || GAST || Gastroenterologie || Quelle differenzierter<br />
|-<br />
| 0710 || Gastroenterologie/Schwerpunkt Pädiatrie || GAST || Gastroenterologie || Quelle differenzierter<br />
|-<br />
| 0910 || Rheumatologie/Schwerpunkt Pädiatrie || RHEU || Rheumatologie || Quelle differenzierter<br />
|-<br />
| 1004 || Pädiatrie/Schwerpunkt Nephrologie || KIJU || Kinder- und Jugendmedizin || Quelle differenzierter<br />
|-<br />
| 1005 || Pädiatrie/Schwerpunkt Hämatologie und internistische Onkologie || KONK || Kinder-Hämatologie und -Onkologie || Quelle differenzierter<br />
|-<br />
| 1006 || Pädiatrie/Schwerpunkt Endokrinologie || KIJU || Kinder- und Jugendmedizin || Quelle differenzierter<br />
|-<br />
| 1007 || Pädiatrie/Schwerpunkt Gastroenterologie || KIJU || Kinder- und Jugendmedizin || Quelle differenzierter<br />
|-<br />
| 1009 || Pädiatrie/Schwerpunkt Rheumatologie || KIJU || Kinder- und Jugendmedizin || Quelle differenzierter<br />
|-<br />
| 1011 || Pädiatrie/Schwerpunkt Kinderkardiologie || KKAR || Kinder-Kardiologie || gleiche Bedeutung<br />
|-<br />
| 1012 || Pädiatrie/Schwerpunkt Neonatologie || NNAT || Neonatologie || gleiche Bedeutung<br />
|-<br />
| 1014 || Pädiatrie/Schwerpunkt Lungen- und Bronchialheilkunde || KIJU || Kinder- und Jugendmedizin || Quelle differenzierter<br />
|-<br />
| 1028 || Pädiatrie/Schwerpunkt Kinderneurologie || NPAE || Neuropädiatrie || gleiche Bedeutung<br />
|-<br />
| 1050 || Pädiatrie/Schwerpunkt Perinatalmedizin || PERI || Perinatalmedizin || gleiche Bedeutung<br />
|-<br />
| 1051 || Langzeitbereich Kinder || KIJU || Kinder- und Jugendmedizin || Quelle differenzierter<br />
|-<br />
| 1136 || Kinderkardiologie/Schwerpunkt Intensivmedizin || KKAR || Kinder-Kardiologie || Quelle differenzierter<br />
|-<br />
| 1410 || Lungen- und Bronchialheilkunde/Schwerpunkt Pädiatrie || PNEU || Pneumologie || Quelle differenzierter<br />
|-<br />
| 1513 || Allgemeine Chirurgie/Schwerpunkt Kinderchirurgie || KDCH || Kinderchirurgie || gleiche Bedeutung<br />
|-<br />
| 1516 || Allgemeine Chirurgie/Schwerpunkt Unfallchirurgie || UNFC || Unfallchirurgie || gleiche Bedeutung<br />
|-<br />
| 1518 || Allgemeine Chirurgie/Schwerpunkt Gefäßchirurgie || GFCH || Gefäßchirurgie || gleiche Bedeutung<br />
|-<br />
| 1519 || Allgemeine Chirurgie/Schwerpunkt Plastische Chirurgie || PLCH || Plastische und Ästhetische Chirurgie || Quelle differenzierter<br />
|-<br />
| 1520 || Allgemeine Chirurgie/Schwerpunkt Thoraxchirurgie || THCH || Thoraxchirurgie || gleiche Bedeutung<br />
|-<br />
| 1523 || Chirurgie/Schwerpunkt Orthopädie || ORTH || Orthopädie || gleiche Bedeutung<br />
|-<br />
| 1536 || Allgemeine Chirurgie/Intensivmedizin (§ 13 Abs. 2 Satz 3 2. Halbsatz BPflV in der am 31.12.2003 geltenden Fassung) || ALCH || Allgemeinchirurgie || Quelle differenzierter<br />
|-<br />
| 1550 || Allgemeine Chirurgie/Schwerpunkt Abdominal- und Gefäßchirurgie || ALCH || Allgemeinchirurgie || Quelle differenzierter<br />
|-<br />
| 1551 || Allgemeine Chirurgie/Schwerpunkt Handchirurgie || ALCH || Allgemeinchirurgie || Quelle differenzierter<br />
|-<br />
| 2021 || Thoraxchirurgie/Schwerpunkt Herzchirurgie || THCH || Thoraxchirurgie || Quelle differenzierter<br />
|-<br />
| 2036 || Thoraxchirurgie/Intensivmedizin || THCH || Thoraxchirurgie || Quelle differenzierter<br />
|-<br />
| 2050 || Thoraxchirurgie/Schwerpunkt Herzchirurgie Intensivmedizin || THCH || Thoraxchirurgie || Quelle differenzierter<br />
|-<br />
| 2120 || Herzchirurgie/Schwerpunkt Thoraxchirurgie || HZCH || Herzchirurgie || Quelle differenzierter<br />
|-<br />
| 2136 || Herzchirurgie/Intensivmedizin (§ 13 Abs. 2 Satz 3 2. Halbsatz BPflV in der am 31.12.2003 geltenden Fassung) || HZCH || Herzchirurgie || Quelle differenzierter<br />
|-<br />
| 2150 || Herzchirurgie/Schwerpunkt Thoraxchirurgie Intensivmedizin || HZCH || Herzchirurgie || Quelle differenzierter<br />
|-<br />
| 2309 || Orthopädie/Schwerpunkt Rheumatologie || ORTH || Orthopädie || Quelle differenzierter<br />
|-<br />
| 2315 || Orthopädie/Schwerpunkt Chirurgie || ORTH || Orthopädie || Quelle differenzierter<br />
|-<br />
| 2402 || Frauenheilkunde/Schwerpunkt Geriatrie || FRAU || Frauenheilkunde und Geburtshilfe || Quelle differenzierter<br />
|-<br />
| 2405 || Frauenheilkunde/Schwerpunkt Hämatologie und internistische Onkologie || GONK || Gynäkologische Onkologie || gleiche Bedeutung<br />
|-<br />
| 2406 || Frauenheilkunde/Schwerpunkt Endokrinologie || GEND || Gynäkologische Endokrinologie und Reproduktionsmedizin || Quelle differenzierter<br />
|-<br />
| 2810 || Neurologie/Schwerpunkt Pädiatrie || NPAE || Neuropädiatrie || gleiche Bedeutung<br />
|-<br />
| 2856 || Neurologie/Schwerpunkt Schlaganfallpatienten (Stroke units, Artikel 7 § 1 Abs. 3 GKV-SolG) || NEUR || Neurologie || Quelle differenzierter<br />
|-<br />
| 2928 || Allgemeine Psychiatrie/Schwerpunkt Neurologie || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2930 || Allgemeine Psychiatrie/Schwerpunkt Kinder- und Jugendpsychiatrie || KPSY || Kinder- und Jugendpsychiatrie und -psychotherapie || gleiche Bedeutung<br />
|-<br />
| 2931 || Allgemeine Psychiatrie/Schwerpunkt Psychosomatik/Psychotherapie || PSYM || Psychosomatische Medizin und Psychotherapie || gleiche Bedeutung<br />
|-<br />
| 2950 || Allgemeine Psychiatrie/Schwerpunkt Suchtbehandlung || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2951 || Allgemeine Psychiatrie/Schwerpunkt Gerontopsychiatrie || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2952 || Allgemeine Psychiatrie/Schwerpunkt Forensische Behandlung || FPSY || Forensische Psychiatrie || gleiche Bedeutung<br />
|-<br />
| 2953 || Allgemeine Psychiatrie/Schwerpunkt Suchtbehandlung, Tagesklinik || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2954 || Allgemeine Psychiatrie/Schwerpunkt Suchtbehandlung, Nachtklinik || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2955 || Allgemeine Psychiatrie/Schwerpunkt Gerontopsychiatrie, Tagesklinik || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2956 || Allgemeine Psychiatrie/Schwerpunkt Gerontopsychiatrie, Nachtklinik || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2960 || Allgemeine Psychiatrie/Tagesklinik (für teilstationäre Pflegesätze) || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2961 || Allgemeine Psychiatrie/Nachtklinik (für teilstationäre Pflegesätze) || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 3060 || Kinder- und Jugendpsychiatrie/Tagesklinik (für teilstationäre Pflegesätze) || KPSY || Kinder- und Jugendpsychiatrie und -psychotherapie || Quelle differenzierter<br />
|-<br />
| 3061 || Kinder- und Jugendpsychiatrie/Nachtklinik (für teilstationäre Pflegesätze) || KPSY || Kinder- und Jugendpsychiatrie und -psychotherapie || Quelle differenzierter<br />
|-<br />
| 3160 || Psychosomatik/Psychotherapie/Tagesklinik (für teilstationäre Pflegesätze) || PSYM || Psychosomatische Medizin und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 3161 || Psychosomatik/Psychotherapie/Nachtklinik (für teilstationäre Pflegesätze) || PSYM || Psychosomatische Medizin und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 3233 || Nuklearmedizin/Schwerpunkt Strahlenheilkunde || NUKL || Nuklearmedizin || Quelle differenzierter<br />
|-<br />
| 3305 || Strahlenheilkunde/Schwerpunkt Hämatologie und internistische Onkologie || STRA || Strahlentherapie || Quelle differenzierter<br />
|-<br />
| 3350 || Strahlenheilkunde/Schwerpunkt Radiologie || STRA || Strahlentherapie || Quelle differenzierter<br />
|-<br />
| 3460 || Dermatologie/Tagesklinik (für teilstationäre Pflegesätze) || HAUT || Haut- und Geschlechtskrankheiten || Quelle differenzierter<br />
|-<br />
| 3601 || Intensivmedizin/Schwerpunkt Innere Medizin || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3603 || Intensivmedizin/Schwerpunkt Kardiologie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3610 || Intensivmedizin/Schwerpunkt Pädiatrie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3617 || Intensivmedizin/Schwerpunkt Neurochirurgie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3618 || Intensivmedizin/Schwerpunkt Chirurgie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3621 || Intensivmedizin/Schwerpunkt Herzchirurgie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3622 || Intensivmedizin/Schwerpunkt Urologie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3624 || Intensivmedizin/Schwerpunkt Frauenheilkunde und Geburtshilfe || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3626 || Intensivmedizin/Schwerpunkt Hals-, Nasen-, Ohrenheilkunde || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3628 || Intensivmedizin/Schwerpunkt Neurologie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3650 || Operative Intensivmedizin/Schwerpunkt Chirurgie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3651 || Intensivmedizin/Thorax-Herzchirurgie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3652 || Intensivmedizin/Herz-Thoraxchirurgie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3750 || Angiologie || ANGI || Angiologie || gleicher Text<br />
|-<br />
| 3751 || Radiologie || RADI || Radiologie || gleicher Text<br />
|-<br />
| 3752 || Palliativmedizin || PALL || Palliativmedizin || gleicher Text<br />
|-<br />
| 3753 || Schmerztherapie || INTM, ANAE || || Mapping muss für Abteilung individuell erfolgen<br />
|-<br />
| 3754 || Heiltherapeutische Abteilung || NATU || Naturheilverfahren und alternative Heilmethoden || Quelle differenzierter<br />
|-<br />
| 3755 || Wirbelsäulenchirurgie || ORTH, NRCH || || Mapping muss für Abteilung individuell erfolgen<br />
|-<br />
| 3756 || Suchtmedizin || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 3757 || Visceralchirurgie || VICH || Viszeralchirurgie || gleiche Bedeutung<br />
|-<br />
| 3758 || Weaningeinheit || INTM || Intensivmedizin || Quelle differenzierter<br />
<br />
|}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|practiceSettingCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.classCode&diff=53995Ihevs:DocumentEntry.classCode2018-10-01T15:51:20Z<p>Tidris: /* DocumentEntry.classCode */ kleinere Schreibfehler korrigiert, LOINC zur Liste hinzugefügt</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.classCode==<br />
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, Befunde oder Bilddaten. Die Wertemenge für diese Obermengen sollte nicht zu detailliert sein, da im Attribut ‚typeCode‘ eine weitere, verfeinerte Beschreibung der Dokumente erfolgt, die allerdings keine Spezialisierung des ,classCode' darstellen muss.<br />
<br />
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.<br />
<br />
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.<br />
<br />
{| class="hl7table"<br />
|-<br />
!Codesystem !! Beschreibung !! Bildung<br />
|-<br />
| 1.3.6.1.4.1.19376.3.276.1.5.8 || Dokumentenklassen || alle Codes aus dem Codesystem<br />
|-<br />
| 2.16.840.1.113883.6.1 || LOINC || Codes die in internationalen IHE Profilen festgelegt wurden<br />
|}<br />
<br />
{{:1.2.276.0.76.11.32/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|classCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.classCode&diff=53994Ihevs:DocumentEntry.classCode2018-10-01T15:45:49Z<p>Tidris: /* DocumentEntry.classCode */</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.classCode==<br />
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, Befunde oder Bilddaten. Die Wertemenge für diese Obermengen sollte nicht zu detailliert sein, da im Attribut ‚typeCode‘ eine weitere, verfeinerte Beschreibung der Dokumente erfolgt, die allerdings keine Spezialisierung des ,classCode' darstellen muss.<br />
<br />
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.<br />
<br />
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.<br />
<br />
{| class="hl7table"<br />
|-<br />
!Codesystem !! Beschreibung !! Bildung<br />
|-<br />
| 1.3.6.1.4.1.19376.3.276.1.5.8 || Dokumentenklassen || alle Codes aus dem Codesystem<br />
|}<br />
<br />
{{:1.2.276.0.76.11.32/dynamic }}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|classCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.PracticeSettingCode&diff=53993Ihevs:DocumentEntry.PracticeSettingCode2018-10-01T08:31:58Z<p>Tidris: </p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.practiceSettingCode==<br />
<br />
DocumentEntry.practiceSettingCode spezifiziert die Fachrichtung der erstellenden Einrichtung. Typische Beispiele hierfür sind ärztliche Fachgebiete wie Allgemeinmedizin oder Radiologie. IHE International empfiehlt, dass die Codeliste zwischen 10 und 100 Codes umfassen sollte, so dass die Fachrichtung hinreichend genau abgebildet werden kann.<br />
<br />
Jedem Dokument muss genau ein practiceSettingCode zugeordnet werden, auch wenn es in vielen Situationen mehrere beteiligte Fachrichtungen gibt. Ein Beispiel hierfür ist ein Röntgen-Befund, der aus der Chirurgie angefordert wird. Um hier eindeutig zu sein, schreibt IHE-XDS vor, dass als Fachrichtung jene gewählt werden muss, die die Fachrichtung der medizinischen Versorgungseinrichtung beschreibt, deren Tätigkeit zur Erstellung des Dokuments geführt hat. Im obigen Beispiel hat die Radiologie die Röntgen-Aufnahme durchgeführt und dem daraus resultierenden Dokument (der Röntgen-Befund) sollte somit der practiceSettingCode für „Radiologie“ zugeordnet werden. Dabei ist zu beachten, dass die Charakterisierung der durchführenden Organisation entscheidend ist, nicht der Facharzttitel des Akteurs oder die Typisierung des Dokuments. Wenn histologische Befunde aus der Dermatologie kommen, sollte der practiceSettingCode „Dermatologie“ verwendet werden. Wenn ein als Allgemeinarzt tätiger Internist einen Arztbrief schreibt, muss diesem Brief daher der practiceSettingCode für „Allgemeinmedizin“ zugeordnet werden.<br />
<br />
In den verschiedenen Ländern existieren unterschiedliche Anforderungen an diesen Code. IHE UK definierte ein Value Set (http://wiki.ihe-uk.org/AppendixB), desgleichen Holland (http://decor.nictiz.nl/services/RetrieveValueSet?id=2.16.840.1.113883.2.4.3.11.60.106.11.10&effectiveDate=2013-12-12T10:41:06&prefix=xds-&format=html&language=de-DE), aber auch für Connect-a-thons werden eigene Codes definiert (http://www.hl7.org/FHIR/valueset-xds-practice-codes.html).<br />
<br />
In Deutschland existiert durch die (Muster-) Weiterbildungsordnung der Bundesärztekammer eine sehr gute Auflistung medizinischer Fachgebiete, so dass die Fachrichtung der direkten medizinischen Versorgung durch diese Liste wiedergegeben wird. Daneben existieren aber weitere medizinische Versorgungsangebote wie beispielsweise Ernährungsberatung, welche durch die Weiterbildungsordnung nicht abgedeckt werden.<br />
<br />
IHE Deutschland bildete daher zwei Codesysteme: eines basierend auf der ärztlichen Weiterbildungsordnung sowie ein Codesystem für weitergehende medizinische Versorgungsangebote. Die Abbildung in zwei Codesystemen für die Darstellung der Fachrichtung sorgt auch hier für die bessere Wartbarkeit der Codesysteme: so kann einfacher auf Anpassungen der ärztlichen Weiterbildungsordnung reagiert werden. Das Value Set umfasst beide Codesysteme.<br />
<br />
Das Value Set für DocumentEntry.practiceSettingCode setzt sich aus den beiden Kodesystemen für ärztliche und nicht-ärztliche Fachrichtungen zusammen, die nachfolgend aufgeführt sind:<br />
<br />
{| class="hl7table"<br />
|-<br />
!Codesystem !! Beschreibung !! Bildung<br />
|-<br />
| 1.3.6.1.4.1.19376.3.276.1.5.4 || ärztlich || alle Codes aus dem Codesystem<br />
|-<br />
| 1.3.6.1.4.1.19376.3.276.1.5.5 || nicht-ärztlich || alle Codes aus dem Codesystem<br />
|}<br />
<br />
{{:1.2.276.0.76.11.37/dynamic }}<br />
<br />
Die Fachrichtung ist generell unabhängig von der Ausbildung der Person, welche die medizinische Leistung erbringt. Daher müssen Leistungen, welche nicht-ärztliche Personen erbringen, trotzdem der aus der ärztlichen Weiterbildungsordnung beruhenden Fachrichtung zugeordnet werden, sofern diese existiert. Um die Zuordnung zu erleichtern, erstellte IHE Deutschland nachfolgende Liste als Orientierungshilfe:<br />
<br />
{| class="hl7table"<br />
|-<br />
!Beruf !!Zuordnung Fachrichtung<br />
|-<br />
|Medizinische Fachangestellte / Medizinischer Fachangestellter<br />
(alte Bezeichnung: Arzthelferin / Arzthelfer)<br />
|Üblicherweise in ärztlich geführter Einrichtung tätig, daher sollte die entsprechende ärztliche Fachrichtung verwendet werden.<br />
|-<br />
|Orientierungs- und Mobilitätslehrer/in und ähnliche, ggf. auch Blindenverbände ||Augenheilkunde<br />
|-<br />
|Anästhesie-technische Assistentin / Anästhesie-technischer Assistent ||Anästhesiologie<br />
|-<br />
|Orthoptistin / Orthoptist ||Augenheilkunde<br />
|-<br />
|Chirurgische Operationsassistentin / Chirurgischer Operationsassistent ||Chirurgie<br />
|-<br />
|Medizinisch-technische Assistentin für den Operationsdienst / Medizinisch-technischer Assistent für den Operationsdienst ||Chirurgie<br />
|-<br />
|Operationstechnische Assistentin / Operationstechnischer Assistent ||Chirurgie<br />
|-<br />
|Klinische Kodierfachkraft ||Üblicherweise in ärztlich geführter Einrichtung tätig, daher sollte die entsprechende ärztliche Fachrichtung verwendet werden.<br />
|-<br />
|Medizinische Dokumentarin / Medizinischer Dokumentar ||Üblicherweise in ärztlich geführter Einrichtung tätig, daher sollte die entsprechende ärztliche Fachrichtung verwendet werden<br />
|-<br />
|Medizinische Dokumentationsassistentin / Medizinischer Dokumentationsassistent ||Üblicherweise in ärztlich geführter Einrichtung tätig, daher sollte die entsprechende ärztliche Fachrichtung verwendet werden<br />
|-<br />
|Hebamme / Entbindungspfleger ||Frauenheilkunde und Geburtshilfe<br />
|-<br />
|Heilpraktikerin / Heilpraktiker ||Naturheilverfahren<br />
|-<br />
|Hygiene-Beauftragte / Hygiene-Beauftragter ||Hygiene und Umweltmedizin<br />
|-<br />
|Hygienekontrolleurin / Hygienekontrolleur/Gesundheitsaufseherin/Gesundheitsaufseher ||Hygiene und Umweltmedizin<br />
|-<br />
|Kardiotechnikerin / Kardiotechniker ||Herzchirurgie oder Kardiologie, je nach Einsatzgebiet<br />
|-<br />
|Medizinisch-technische Assistentin für Funktionsdiagnostik / Medizinisch-technischer Assistent für Funktionsdiagnostik ||Üblicherweise in ärztlich geführter Einrichtung tätig, daher sollte die entsprechende ärztliche Fachrichtung verwendet werden<br />
|-<br />
|Medizinisch-technische Laboratoriumsassistentin / Medizinisch-technischer Laboratoriumsassistent ||Laboratoriumsmedizin<br />
|-<br />
|Zahnmedizinische Fachangestellte / Zahnmedizinischer Fachangestellter (alte Bezeichnung: Zahnarzthelferin / Zahnarzthelfer) ||Zahnmedizin<br />
|-<br />
|Notfallsanitäterin / Notfallsanitäter ||Notfallmedizin<br />
|-<br />
|Rettungsassistenten-Praktikantin / Rettungsassistenten-Praktikant ||Notfallmedizin<br />
|-<br />
|Rettungsassistentin / Rettungsassistent ||Notfallmedizin<br />
|-<br />
|Rettungssanitäterin / Rettungssanitäter ||Notfallmedizin<br />
|-<br />
|Heilpraktikerin / Heilpraktiker (beschränkt auf das Gebiet der Psychotherapie) || Je nach Ausrichtung entweder "Psychiatrie und Psychotherapie" oder "Psychosomatische Medizin und Psychotherapie"<br />
|-<br />
|Psychologische Psychotherapeuten ||Je nach Ausrichtung entweder "Psychiatrie und Psychotherapie" oder "Psychosomatische Medizin und Psychotherapie"<br />
|-<br />
|Kinder- und Jugendlichenpsychotherapeuten ||Kinder- und Jugendpsychiatrie und -psychotherapie<br />
|-<br />
|Medizinisch-technische Radiologieassistentin / Medizinisch-technischer Radiologieassistent ||Radiologie<br />
|-<br />
|Masseurin und medizinische Bademeisterin / Masseur und medizinischer Bademeister ||Physikalische und rehabilitative Medizin<br />
|-<br />
|Physiotherapeutin / Physiotherapeut ||Physikalische und rehabilitative Medizin<br />
|-<br />
|Osteopathin / Osteopath ||Physikalische und rehabilitative Medizin<br />
|-<br />
|Qigong-Lehrende / Qigong-Lehrender ||Physikalische und rehabilitative Medizin<br />
|-<br />
|Shiatsu-Praktikerin / Shiatsu-Praktiker ||Physikalische und rehabilitative Medizin<br />
|-<br />
|Taijiquan-Lehrende / Taijiquan-Lehrender ||Physikalische und rehabilitative Medizin<br />
|-<br />
|Dentalhygienikerin / Dentalhygieniker ||Zahnmedizin<br />
|-<br />
|Diplom-Ingenieur/in des Fachbereichs Augenoptik/Diplom-Augenoptiker (FH) ||Augenheilkunde<br />
|-<br />
|Occularist/in / Glasbläser/in mit Fachrichtung Kunstaugen (Himi) ||Augenheilkunde<br />
|-<br />
|Chirurgiemechanikerin / Chirurgiemechaniker ||Chirurgie<br />
|-<br />
|Hörakustikerin / Hörakustiker ||Hals-Nasen-Ohrenheilkunde<br />
|-<br />
|Hörgeräteakustikerin / Hörgeräteakustiker ||Hals-Nasen-Ohrenheilkunde<br />
|-<br />
|Diplomingenieur/in für Orthopädie und Rehatechnik ||Orthopädie<br />
|-<br />
|Orthopädiemechanikerin und Bandagistin / Orthopädiemechaniker und Bandagist ||Orthopädie<br />
|-<br />
|Orthopädieschuhmacherin / Orthopädieschuhmacher ||Orthopädie<br />
|-<br />
|Orthopädietechnikerin / Orthopädietechniker ||Orthopädie<br />
|-<br />
|Dentalingenieur ||Zahnmedizin<br />
|-<br />
|Zahntechnikerin / Zahntechniker ||Zahnmedizin<br />
|-<br />
|Fitnessberaterin / Fitnessberater ||Sport- und Bewegungsmedizin, Physikalische und rehabilitative Medizin; wenn keines von beiden zutrifft: Prävention<br />
|-<br />
|Fitnessmanagerin / Fitnessmanager ||Sport- und Bewegungsmedizin, Physikalische und Rehabilitative Medizin; wenn keines von beiden zutrifft: Prävention<br />
|-<br />
|Fitnesstrainerin / Fitnesstrainer ||Sport- und Bewegungsmedizin, Physikalische und Rehabilitative Medizin; wenn keines von beiden zutrifft: Prävention<br />
|}<br />
<br />
<br />
Nach §301 SGB V müssen deutsche Krankenhäuser bei der Abrechnung Fachabteilungen nach dem Schlüssel 6 "Fachabteilungen" gemäß Anhang 1 der BPflV kodieren.<br />
Zum leichteren Auffinden des PracticeSettingCodes stellen wir daher hier ein Mapping zwischen dem Fachabteilungsschlüssel für Krankenhäuser und dem PracticeSettingCode bereit. In der Regel ist der PracticeSettingCode inhaltsgleich oder allgemeiner als der Fachabteilungsschlüssel. In wenigen Ausnahmen ist der PracticeSettingCode differenzierter als der Fachabteilungsschlüssel. In diesen Fällen ist ein automatisches Mapping nicht möglich. Daher muss die Fachabteilung in diesem Fall selbst entscheiden, welcher PracticeSettingCode für sie am besten geeignet ist. <br />
<br />
<br />
{| class="hl7table"<br />
|-<br />
!Fachabteilungsschlüssel !! Klartext Fachabteilung !! practiceSettingCode !! Displayname PracticeSettingCode !! Bemerkungen<br />
|-<br />
| 100 || Innere Medizin || INNE || Innere Medizin || gleicher Text<br />
|-<br />
| 200 || Geriatrie || GERI || Geriatrie || gleicher Text<br />
|-<br />
| 300 || Kardiologie || KARD || Kardiologie || gleicher Text<br />
|-<br />
| 400 || Nephrologie || NEPH || Nephrologie || gleicher Text<br />
|-<br />
| 500 || Hämatologie und internistische Onkologie || HAEM || Hämatologie und internistische Onkologie || gleicher Text<br />
|-<br />
| 600 || Endokrinologie || ENDO || Endokrinologie und Diabetologie || Quelle differenzierter<br />
|-<br />
| 700 || Gastroenterologie || GAST || Gastroenterologie || gleicher Text<br />
|-<br />
| 800 || Pneumologie || PNEU || Pneumologie || gleicher Text<br />
|-<br />
| 900 || Rheumatologie || RHEU || Rheumatologie || gleicher Text<br />
|-<br />
| 1000 || Pädiatrie || KIJU || Kinder- und Jugendmedizin || gleiche Bedeutung<br />
|-<br />
| 1100 || Kinderkardiologie || KKAR || Kinder-Kardiologie || gleiche Bedeutung<br />
|-<br />
| 1200 || Neonatologie || NNAT || Neonatologie || gleicher Text<br />
|-<br />
| 1300 || Kinderchirurgie || KDCH || Kinderchirurgie || gleicher Text<br />
|-<br />
| 1400 || Lungen- und Bronchialheilkunde || PNEU || Pneumologie || gleiche Bedeutung<br />
|-<br />
| 1500 || Allgemeine Chirurgie || ALCH || Allgemeinchirurgie || gleiche Bedeutung<br />
|-<br />
| 1600 || Unfallchirurgie || UNFC || Unfallchirurgie || gleicher Text<br />
|-<br />
| 1700 || Neurochirurgie || NRCH || Neurochirurgie || gleicher Text<br />
|-<br />
| 1800 || Gefäßchirurgie || GFCH || Gefäßchirurgie || gleicher Text<br />
|-<br />
| 1900 || Plastische Chirurgie || PLCH || Plastische und Ästhetische Chirurgie || Quelle differenzierter<br />
|-<br />
| 2000 || Thoraxchirurgie || THCH || Thoraxchirurgie || gleicher Text<br />
|-<br />
| 2100 || Herzchirurgie || HZCH || Herzchirurgie || gleicher Text<br />
|-<br />
| 2200 || Urologie || UROL || Urologie || gleicher Text<br />
|-<br />
| 2300 || Orthopädie || ORTH || Orthopädie || gleicher Text<br />
|-<br />
| 2400 || Frauenheilkunde und Geburtshilfe || FRAU || Frauenheilkunde und Geburtshilfe || gleicher Text<br />
|-<br />
| 2500 || davon Geburtshilfe || FRAU || Frauenheilkunde und Geburtshilfe || Quelle differenzierter<br />
|-<br />
| 2600 || Hals-, Nasen-, Ohrenheilkunde || HNOH || Hals-Nasen-Ohrenheilkunde || gleiche Bedeutung<br />
|-<br />
| 2700 || Augenheilkunde || AUGE || Augenheilkunde || gleicher Text<br />
|-<br />
| 2800 || Neurologie || NEUR || Neurologie || gleicher Text<br />
|-<br />
| 2900 || Allgemeine Psychiatrie || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 3000 || Kinder- und Jugendpsychiatrie || KPSY || Kinder- und Jugendpsychiatrie und -psychotherapie || Quelle differenzierter<br />
|-<br />
| 3100 || Psychosomatik/Psychotherapie || PSYM || Psychosomatische Medizin und Psychotherapie || gleiche Bedeutung<br />
|-<br />
| 3200 || Nuklearmedizin || NUKL || Nuklearmedizin || gleicher Text<br />
|-<br />
| 3300 || Strahlenheilkunde || STRA || Strahlentherapie || gleiche Bedeutung<br />
|-<br />
| 3400 || Dermatologie || HAUT || Haut- und Geschlechtskrankheiten || gleiche Bedeutung<br />
|-<br />
| 3500 || Zahn- und Kieferheilkunde, Mund- und Kieferchirurgie || MKGC oder MZKH || || Mapping muss für Abteilung individuell erfolgen<br />
|-<br />
| 3600 || Intensivmedizin || INTM || Intensivmedizin || gleicher Text<br />
|-<br />
| 2316 || Orthopädie und Unfallchirurgie || ORTH oder UNFC || || Mapping muss für Abteilung individuell erfolgen<br />
|-<br />
| 2425 || Frauenheilkunde || FRAU || Frauenheilkunde und Geburtshilfe || Quelle differenzierter<br />
|-<br />
| 3700 || Sonstige Fachabteilung || || || Mapping muss für Abteilung individuell erfolgen<br />
|-<br />
| 0102 || Innere Medizin/Schwerpunkt Geriatrie || GERI || Geriatrie || gleiche Bedeutung<br />
|-<br />
| 0103 || Innere Medizin/Schwerpunkt Kardiologie || KARD || Kardiologie || gleiche Bedeutung<br />
|-<br />
| 0104 || Innere Medizin/Schwerpunkt Nephrologie || NEPH || Nephrologie || gleiche Bedeutung<br />
|-<br />
| 0105 || Innere Medizin/Schwerpunkt Hämatologie und internistische Onkologie || HAEM || Hämatologie und internistische Onkologie || gleiche Bedeutung<br />
|-<br />
| 0106 || Innere Medizin/Schwerpunkt Endokrinologie || ENDO || Endokrinologie und Diabetologie || Quelle differenzierter<br />
|-<br />
| 0107 || Innere Medizin/Schwerpunkt Gastroenterologie || GAST || Gastroenterologie || gleiche Bedeutung<br />
|-<br />
| 0108 || Innere Medizin/Schwerpunkt Pneumologie || PNEU || Pneumologie || gleiche Bedeutung<br />
|-<br />
| 0109 || Innere Medizin/Schwerpunkt Rheumatologie || RHEU || Rheumatologie || gleiche Bedeutung<br />
|-<br />
| 0114 || Innere Medizin/Schwerpunkt Lungen- und Bronchialheilkunde || PNEU || Pneumologie || gleiche Bedeutung<br />
|-<br />
| 0150 || Innere Medizin/Tumorforschung || HAEM || Hämatologie und internistische Onkologie || gleiche Bedeutung<br />
|-<br />
| 0151 || Innere Medizin/Schwerpunkt Coloproktologie || GAST || Gastroenterologie || Quelle differenzierter<br />
|-<br />
| 0152 || Innere Medizin/Schwerpunkt Infektionskrankheiten || INNE || Innere Medizin || Quelle differenzierter<br />
|-<br />
| 0153 || Innere Medizin/Schwerpunkt Diabetes || ENDO || Endokrinologie und Diabetologie || Quelle differenzierter<br />
|-<br />
| 0154 || Innere Medizin/Schwerpunkt Naturheilkunde || NATU || Naturheilverfahren und alternative Heilmethoden || gleiche Bedeutung<br />
|-<br />
| 0156 || Innere Medizin/Schwerpunkt Schlaganfallpatienten (Stroke units, Artikel 7 § 1 Abs. 3 GKV-SolG) || INNE || Innere Medizin || Quelle differenzierter<br />
|-<br />
| 0224 || Geriatrie/Schwerpunkt Frauenheilkunde || GERI || Geriatrie || Quelle differenzierter<br />
|-<br />
| 0260 || Geriatrie/Tagesklinik (für teilstationäre Pflegesätze) || GERI || Geriatrie || Quelle differenzierter<br />
|-<br />
| 0261 || Geriatrie/Nachtklinik (für teilstationäre Pflegesätze) || GERI || Geriatrie || Quelle differenzierter<br />
|-<br />
| 0410 || Nephrologie/Schwerpunkt Pädiatrie || NEPH || Nephrologie || Quelle differenzierter<br />
|-<br />
| 0436 || Nephrologie/Intensivmedizin || NEPH || Nephrologie || Quelle differenzierter<br />
|-<br />
| 0510 || Hämatologie und internistische Onkologie/Schwerpunkt Pädiatrie || KONK || Kinder-Hämatologie und -Onkologie || Quelle differenzierter<br />
|-<br />
| 0524 || Hämatologie und internistische Onkologie/Schwerpunkt Frauenheilkunde || GONK || Gynäkologische Onkologie || gleiche Bedeutung<br />
|-<br />
| 0533 || Hämatologie und internistische Onkologie/Schwerpunkt Strahlenheilkunde || HAEM || Hämatologie und internistische Onkologie || Quelle differenzierter<br />
|-<br />
| 0607 || Endokrinologie/Schwerpunkt Gastroenterologie || ENDO || Endokrinologie und Diabetologie || Quelle differenzierter<br />
|-<br />
| 0610 || Endokrinologie/Schwerpunkt Pädiatrie || ENDO || Endokrinologie und Diabetologie || Quelle differenzierter<br />
|-<br />
| 0706 || Gastroenterologie/Schwerpunkt Endokrinologie || GAST || Gastroenterologie || Quelle differenzierter<br />
|-<br />
| 0710 || Gastroenterologie/Schwerpunkt Pädiatrie || GAST || Gastroenterologie || Quelle differenzierter<br />
|-<br />
| 0910 || Rheumatologie/Schwerpunkt Pädiatrie || RHEU || Rheumatologie || Quelle differenzierter<br />
|-<br />
| 1004 || Pädiatrie/Schwerpunkt Nephrologie || KIJU || Kinder- und Jugendmedizin || Quelle differenzierter<br />
|-<br />
| 1005 || Pädiatrie/Schwerpunkt Hämatologie und internistische Onkologie || KONK || Kinder-Hämatologie und -Onkologie || Quelle differenzierter<br />
|-<br />
| 1006 || Pädiatrie/Schwerpunkt Endokrinologie || KIJU || Kinder- und Jugendmedizin || Quelle differenzierter<br />
|-<br />
| 1007 || Pädiatrie/Schwerpunkt Gastroenterologie || KIJU || Kinder- und Jugendmedizin || Quelle differenzierter<br />
|-<br />
| 1009 || Pädiatrie/Schwerpunkt Rheumatologie || KIJU || Kinder- und Jugendmedizin || Quelle differenzierter<br />
|-<br />
| 1011 || Pädiatrie/Schwerpunkt Kinderkardiologie || KKAR || Kinder-Kardiologie || gleiche Bedeutung<br />
|-<br />
| 1012 || Pädiatrie/Schwerpunkt Neonatologie || NNAT || Neonatologie || gleiche Bedeutung<br />
|-<br />
| 1014 || Pädiatrie/Schwerpunkt Lungen- und Bronchialheilkunde || KIJU || Kinder- und Jugendmedizin || Quelle differenzierter<br />
|-<br />
| 1028 || Pädiatrie/Schwerpunkt Kinderneurologie || NPAE || Neuropädiatrie || gleiche Bedeutung<br />
|-<br />
| 1050 || Pädiatrie/Schwerpunkt Perinatalmedizin || PERI || Perinatalmedizin || gleiche Bedeutung<br />
|-<br />
| 1051 || Langzeitbereich Kinder || KIJU || Kinder- und Jugendmedizin || Quelle differenzierter<br />
|-<br />
| 1136 || Kinderkardiologie/Schwerpunkt Intensivmedizin || KKAR || Kinder-Kardiologie || Quelle differenzierter<br />
|-<br />
| 1410 || Lungen- und Bronchialheilkunde/Schwerpunkt Pädiatrie || PNEU || Pneumologie || Quelle differenzierter<br />
|-<br />
| 1513 || Allgemeine Chirurgie/Schwerpunkt Kinderchirurgie || KDCH || Kinderchirurgie || gleiche Bedeutung<br />
|-<br />
| 1516 || Allgemeine Chirurgie/Schwerpunkt Unfallchirurgie || UNFC || Unfallchirurgie || gleiche Bedeutung<br />
|-<br />
| 1518 || Allgemeine Chirurgie/Schwerpunkt Gefäßchirurgie || GFCH || Gefäßchirurgie || gleiche Bedeutung<br />
|-<br />
| 1519 || Allgemeine Chirurgie/Schwerpunkt Plastische Chirurgie || PLCH || Plastische und Ästhetische Chirurgie || Quelle differenzierter<br />
|-<br />
| 1520 || Allgemeine Chirurgie/Schwerpunkt Thoraxchirurgie || THCH || Thoraxchirurgie || gleiche Bedeutung<br />
|-<br />
| 1523 || Chirurgie/Schwerpunkt Orthopädie || ORTH || Orthopädie || gleiche Bedeutung<br />
|-<br />
| 1536 || Allgemeine Chirurgie/Intensivmedizin (§ 13 Abs. 2 Satz 3 2. Halbsatz BPflV in der am 31.12.2003 geltenden Fassung) || ALCH || Allgemeinchirurgie || Quelle differenzierter<br />
|-<br />
| 1550 || Allgemeine Chirurgie/Schwerpunkt Abdominal- und Gefäßchirurgie || ALCH || Allgemeinchirurgie || Quelle differenzierter<br />
|-<br />
| 1551 || Allgemeine Chirurgie/Schwerpunkt Handchirurgie || ALCH || Allgemeinchirurgie || Quelle differenzierter<br />
|-<br />
| 2021 || Thoraxchirurgie/Schwerpunkt Herzchirurgie || THCH || Thoraxchirurgie || Quelle differenzierter<br />
|-<br />
| 2036 || Thoraxchirurgie/Intensivmedizin || THCH || Thoraxchirurgie || Quelle differenzierter<br />
|-<br />
| 2050 || Thoraxchirurgie/Schwerpunkt Herzchirurgie Intensivmedizin || THCH || Thoraxchirurgie || Quelle differenzierter<br />
|-<br />
| 2120 || Herzchirurgie/Schwerpunkt Thoraxchirurgie || HZCH || Herzchirurgie || Quelle differenzierter<br />
|-<br />
| 2136 || Herzchirurgie/Intensivmedizin (§ 13 Abs. 2 Satz 3 2. Halbsatz BPflV in der am 31.12.2003 geltenden Fassung) || HZCH || Herzchirurgie || Quelle differenzierter<br />
|-<br />
| 2150 || Herzchirurgie/Schwerpunkt Thoraxchirurgie Intensivmedizin || HZCH || Herzchirurgie || Quelle differenzierter<br />
|-<br />
| 2309 || Orthopädie/Schwerpunkt Rheumatologie || ORTH || Orthopädie || Quelle differenzierter<br />
|-<br />
| 2315 || Orthopädie/Schwerpunkt Chirurgie || ORTH || Orthopädie || Quelle differenzierter<br />
|-<br />
| 2402 || Frauenheilkunde/Schwerpunkt Geriatrie || FRAU || Frauenheilkunde und Geburtshilfe || Quelle differenzierter<br />
|-<br />
| 2405 || Frauenheilkunde/Schwerpunkt Hämatologie und internistische Onkologie || GONK || Gynäkologische Onkologie || gleiche Bedeutung<br />
|-<br />
| 2406 || Frauenheilkunde/Schwerpunkt Endokrinologie || GEND || Gynäkologische Endokrinologie und Reproduktionsmedizin || Quelle differenzierter<br />
|-<br />
| 2810 || Neurologie/Schwerpunkt Pädiatrie || NPAE || Neuropädiatrie || gleiche Bedeutung<br />
|-<br />
| 2856 || Neurologie/Schwerpunkt Schlaganfallpatienten (Stroke units, Artikel 7 § 1 Abs. 3 GKV-SolG) || NEUR || Neurologie || Quelle differenzierter<br />
|-<br />
| 2928 || Allgemeine Psychiatrie/Schwerpunkt Neurologie || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2930 || Allgemeine Psychiatrie/Schwerpunkt Kinder- und Jugendpsychiatrie || KPSY || Kinder- und Jugendpsychiatrie und -psychotherapie || gleiche Bedeutung<br />
|-<br />
| 2931 || Allgemeine Psychiatrie/Schwerpunkt Psychosomatik/Psychotherapie || PSYM || Psychosomatische Medizin und Psychotherapie || gleiche Bedeutung<br />
|-<br />
| 2950 || Allgemeine Psychiatrie/Schwerpunkt Suchtbehandlung || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2951 || Allgemeine Psychiatrie/Schwerpunkt Gerontopsychiatrie || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2952 || Allgemeine Psychiatrie/Schwerpunkt Forensische Behandlung || FPSY || Forensische Psychiatrie || gleiche Bedeutung<br />
|-<br />
| 2953 || Allgemeine Psychiatrie/Schwerpunkt Suchtbehandlung, Tagesklinik || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2954 || Allgemeine Psychiatrie/Schwerpunkt Suchtbehandlung, Nachtklinik || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2955 || Allgemeine Psychiatrie/Schwerpunkt Gerontopsychiatrie, Tagesklinik || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2956 || Allgemeine Psychiatrie/Schwerpunkt Gerontopsychiatrie, Nachtklinik || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2960 || Allgemeine Psychiatrie/Tagesklinik (für teilstationäre Pflegesätze) || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 2961 || Allgemeine Psychiatrie/Nachtklinik (für teilstationäre Pflegesätze) || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 3060 || Kinder- und Jugendpsychiatrie/Tagesklinik (für teilstationäre Pflegesätze) || KPSY || Kinder- und Jugendpsychiatrie und -psychotherapie || Quelle differenzierter<br />
|-<br />
| 3061 || Kinder- und Jugendpsychiatrie/Nachtklinik (für teilstationäre Pflegesätze) || KPSY || Kinder- und Jugendpsychiatrie und -psychotherapie || Quelle differenzierter<br />
|-<br />
| 3160 || Psychosomatik/Psychotherapie/Tagesklinik (für teilstationäre Pflegesätze) || PSYM || Psychosomatische Medizin und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 3161 || Psychosomatik/Psychotherapie/Nachtklinik (für teilstationäre Pflegesätze) || PSYM || Psychosomatische Medizin und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 3233 || Nuklearmedizin/Schwerpunkt Strahlenheilkunde || NUKL || Nuklearmedizin || Quelle differenzierter<br />
|-<br />
| 3305 || Strahlenheilkunde/Schwerpunkt Hämatologie und internistische Onkologie || STRA || Strahlentherapie || Quelle differenzierter<br />
|-<br />
| 3350 || Strahlenheilkunde/Schwerpunkt Radiologie || STRA || Strahlentherapie || Quelle differenzierter<br />
|-<br />
| 3460 || Dermatologie/Tagesklinik (für teilstationäre Pflegesätze) || HAUT || Haut- und Geschlechtskrankheiten || Quelle differenzierter<br />
|-<br />
| 3601 || Intensivmedizin/Schwerpunkt Innere Medizin || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3603 || Intensivmedizin/Schwerpunkt Kardiologie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3610 || Intensivmedizin/Schwerpunkt Pädiatrie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3617 || Intensivmedizin/Schwerpunkt Neurochirurgie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3618 || Intensivmedizin/Schwerpunkt Chirurgie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3621 || Intensivmedizin/Schwerpunkt Herzchirurgie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3622 || Intensivmedizin/Schwerpunkt Urologie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3624 || Intensivmedizin/Schwerpunkt Frauenheilkunde und Geburtshilfe || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3626 || Intensivmedizin/Schwerpunkt Hals-, Nasen-, Ohrenheilkunde || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3628 || Intensivmedizin/Schwerpunkt Neurologie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3650 || Operative Intensivmedizin/Schwerpunkt Chirurgie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3651 || Intensivmedizin/Thorax-Herzchirurgie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3652 || Intensivmedizin/Herz-Thoraxchirurgie || INTM || Intensivmedizin || Quelle differenzierter<br />
|-<br />
| 3750 || Angiologie || ANGI || Angiologie || gleicher Text<br />
|-<br />
| 3751 || Radiologie || RADI || Radiologie || gleicher Text<br />
|-<br />
| 3752 || Palliativmedizin || PALL || Palliativmedizin || gleicher Text<br />
|-<br />
| 3753 || Schmerztherapie || INTM, ANAE || || Mapping muss für Abteilung individuell erfolgen<br />
|-<br />
| 3754 || Heiltherapeutische Abteilung || NATU || Naturheilverfahren und alternative Heilmethoden || Quelle differenzierter<br />
|-<br />
| 3755 || Wirbelsäulenchirurgie || ORTH, NRCH || || Mapping muss für Abteilung individuell erfolgen<br />
|-<br />
| 3756 || Suchtmedizin || PSYC || Psychiatrie und Psychotherapie || Quelle differenzierter<br />
|-<br />
| 3757 || Visceralchirurgie || VICH || Viszeralchirurgie || gleiche Bedeutung<br />
|-<br />
| 3758 || Weaningeinheit || INTM || Intensivmedizin || Quelle differenzierter<br />
<br />
|}<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|practiceSettingCode]]<br />
[[Kategorie:ihevs]]</div>Tidrishttps://wiki.hl7.de/index.php?title=Ihevs:DocumentEntry.formatCode&diff=51091Ihevs:DocumentEntry.formatCode2018-07-24T08:48:18Z<p>Tidris: Link auf PDF in CDA korrigiert</p>
<hr />
<div>{{DocumentPart}}<br />
==DocumentEntry.formatCode==<br />
<br />
Der Code spezifiziert das Format des Dokumentes. Zusammen mit dem typeCode (und ggf. mit dem mimeType) soll der formatCode für hinreichende Information sorgen, um einem potenziellen XDS-Dokument-Konsumenten die Entscheidung zu ermöglichen, ob und wie er das Dokumentenformat verarbeiten kann.<br />
<br />
Der formatCode muss dabei hinreichend eindeutig formuliert sein, um die Verarbeitung/Anzeige des von der Registry angeforderten Dokumentes durch den Dokumentenkonsumer zu gewährleisten.<br />
<br />
===Vergabe von formatCodes===<br />
<br />
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.<br />
<br />
===Umfang des IHE Deutschland formatCode ValueSets===<br />
<br />
Das ValueSet hat die OID 1.2.276.0.76.11.35 und setzt sich aus Codes von IHE International, IHE Deutschland, HL7 und HL7 Deutschland zusammen.<br />
<br />
===Aufbau der formatCodes===<br />
====Aufbau der durch IHE International vergebenen formatCodes====<br />
<br />
formatCodes, welche von IHE ITI definiert werden, haben immer das Präfix<br />
<br />
urn:ihe:iti:<br />
<br />
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<br />
<br />
urn:ihe:’domain initials’:<br />
<br />
benutzen, wobei „domain initials“ die Domäne selbst repräsentiert.<br />
<br />
====Aufbau der durch IHE Deutschland vergebenen formatCodes====<br />
<br />
formatCodes, welche von IHE Deutschland definiert werden, haben immer das Präfix<br />
<br />
urn:ihe-d:<br />
<br />
Von IHE Deutschland festgelegte formatCodes werden wie folgt aufgebaut:<br />
<br />
=====Aufbau für CDA-Dokumente=====<br />
<br />
{| border=1<br />
|-<br />
|CDA-Dokumente ohne binärem Inhalt <br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr'<br />
|-<br />
|CDA-Dokumente mit einem Body, der aus einem binärem Inhalt besteht<br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr':nonXmlBody<br />
|-<br />
|CDA-Dokumente mit einem Body, der aus einer XML-Inhalten und mind. einer eingebettenen binärem Datei besteht <br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr':crossXmlBody<br />
|}<br />
<br />
„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).<br />
<br />
Beispiel: Sollte IHE Deutschland 2016 ein eigenes CDA-Dokument für eine Verordnung veröffentlichen, wird dieses entsprechend der obigen Beschreibung wie folgt abgebildet:<br />
<br />
a) Verordnung: Level 1-3 ohne binärem Inhalt<br />
urn:ihe-d:ig:Verordnung:2016<br />
b) Verordnung: Level 1 CDA mit Body bestehend aus einer PDF-Datei ([[IG:CDA_und_PDF/A3]])<br />
urn:ihe-d:ig:Verordnung:2016:nonXmlBody<br />
c) Verordnung: sowohl mit XML-Inhalt wie auch mindestens einer eingebetteten binären Datei <br />
urn:ihe-d:ig:Verordnung:2016:crossXmlBody<br />
<br />
=====Aufbau für nicht CDA-Dokumente=====<br />
<br />
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. <br />
<br />
{| border=1<br />
|-<br />
|IHE Deutschland <br />
|<br />
urn:ihe-d:ig:'Bezeichner':'Jahr'<br />
urn:ihe-d:spec:'Bezeichner':'Jahr'<br />
|}<br />
<br />
„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).<br />
<br />
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 wird Teil der Revision 15 des IHE ITI Technical Frameworks werden. Der equivalente, von IHE Deutschland eingeführte formatCode "urn:ihe-d:mime" gilt ab sofort als "deprecated" und sollte nicht mehr verwendet werden. <br />
<br />
'''Beispiel'''<br />
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. <br />
<br />
'''Sonderfall'''<br />
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”.<br />
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.<br />
<br />
====Empfehlungen von IHE Deutschland für den Aufbau von formatCodes für andere Organisationen====<br />
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.<br />
<br />
====formatCodes für FHIR Ressourcen====<br />
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 und ähnlichen Konstrukten 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'.<br />
<br />
<br />
===Veröffentlichung der formatCodes===<br />
Die Codes für das ValueSet „formatCode“ werden in art-decor zusammen mit den anderen von IHE Deutschland erstellten ValueSets veröffentlicht (http://art-decor.org/art-decor/decor-valuesets--ihede-). Sie umfassen sowohl die eigenen nach obigen Schema definierten Codes, wie auch die von IHE International vorgegebenen Codes.<br />
<br />
{{:1.2.276.0.76.11.35/dynamic }}<br />
<br />
===Links===<br />
* 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<br />
* RFC 2288 (1998) Using Existing Bibliographic Identifiers as Uniform Resource Names. Online, verfügbar unter http://tools.ietf.org/html/rfc2288<br />
* RFC 2141 (1997).URN Syntax. Online, verfügbar unter https://www.ietf.org/rfc/rfc2141.txt<br />
* RFC 3151 (2001) A URN Namespace for Public Identifiers. Online, verfügbar unter https://tools.ietf.org/html/rfc3151<br />
<br />
[[Kategorie:Enzyklopädie]]<br />
[[Kategorie:Abkürzungen|formatCode]]<br />
[[Kategorie:ihevs]]</div>Tidris