Kommentare und Auflösungen zum Abstimmungsverfahren ‘’IHE XDS Value Sets’’
Stand: 3. Dezember 2016
| Auszählung (Tally) | |
|---|---|
| Anzahl Kommentare | 77 |
| Angenommen | 18 |
| Angenommen mit Modifikationen | 20 |
| Nicht angenommen | 32 |
| Nicht relevant | 3 |
| Zur zukünftigen Verwendung | 3 |
| Weitergeleitet | 0 |
| Warten auf Information vom Antragsteller | 1 |
| Warten auf Information von anderer Arbeitsgruppe | 0 |
| Unbearbeitet | 0 |
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
|---|---|---|---|---|---|
| 1 | 2.1 |  Negativ, schwerwiegend | Angela Merzweiler | IHE/ Uni Heidelberg | |
Kommentar  | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Hinzunahmne von “57016-8” “Privacy Policy Acknowledgement Document” | BPPC hat fest vorgegebenen ClassCode | ||||
Reconcile  | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | vorübergehend im Value Set mit aufnehmen, nicht im Codesystem;zusätzlich eigener TypeCode notwendig im Valueset nicht im Codesystem | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 2 | 2.1 | Negativ, schwerwiegend | Angela Merzweiler | IHE/ Uni Heidelberg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Hinzunahmne von “57016-8” “Privacy Policy Acknowledgement Document” | Hinzunahme von ClassCode für APPC | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | APPC geändert | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 3 | 2.5 |  Kommentar allgemeiner Art | Angela Merzweiler | IHE/ Uni Heidelberg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Neuer Vorschlag für Gliederung: 1. Vergabe von FormatCodes 2. Umfang des IHE Deutschland formatCode ValueSets 3. Aufbau der Format Codes 3.1 Aufbau der durch IHE – International vergebenen FormatCodes 3.2. Aufbau der durch IHE – Deutschland vergebenen FormatCodes 3.2.1 CDA-Dokumente 3.2.2 Nicht CDA-Dokumente 3.3 Empfehlung von IHE Deutschland für den Aufbau für andere Organisationen 4. Veröffentlichung der formatCodes | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 4 | 2.2 | Negativ, schwerwiegend | Angela Merzweiler | IHE/ Uni Heidelberg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Immunologiebefund sollte Subtyp von Befund sein | Erleichtert das Auffinden | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Die AG hat sich gegen eine Hierarchie im typeCode entschieden, Begründung zum TypeCode Einleitungstext hinzufügen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 5 | 2.2 | Negativ, schwerwiegend | Angela Merzweiler | IHE/ Uni Heidelberg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| LAB als ClassCode streichen | ersetzen durch Rohdaten oder BEF | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Labor vs Anforderung im ClassCode genauer beschreiben; keinen neuen TypeCode Labor, die Alternative wurde diskutiert aber bringt nicht genug Vorteile | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 6 | 2.2 | Negativ, schwerwiegend | Angela Merzweiler | IHE/ Uni Heidelberg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| ClassCode Rohdaten, in dem Bilder und Messwerte zusammengefasst werden | EKGs als Bilder wo einsortieren | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Unterscheidung zwischen Rohdaten (z.B. EKG Kurven) und EKG Scans kann über den FormatCode getroffen werden; Konzept Bilddaten unabhängig davon schärfen; Beispiele Bestrahlungsprotokoll und Dosiswerte hinzufügen; formatCode Liste auf XDS-I Werte prüfen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 7 | 1.3 |  Tippfehler | Arnold Roesner | Uniklinik Freiburg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| p0004/32-33: XDSDocumentEntry.typeCode = „Ergebnisse Bildgebende Diagnostik“ | XDSDocumentEntry.typeCode = „Ergebnisse Bildgebender Diagnostik“ | Tippfehler (ref. Bezeichnung im Value Set) | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 8 | 1.5 | Tippfehler | Arnold Roesner | Uniklinik Freiburg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| p0006/05-07: Die Argbeitsgruppe | Die Arbeitsgruppe | Tippfehler | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 9 | 1.7 |  Vorschlag | Arnold Roesner | Uniklinik Freiburg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Änderung und Pflege der hier vorgestellten Value Sets erfolgt durch die IHE Deutschland Arbeitsgruppe "Value Sets". | Hier sollte noch die konkrete Vorgehensweise beschrieben werden, wie Affinity Domains / Einrichtungen / Projekte verfahren sollen, wenn sie den Bedarf an einer Erweiterung der Value Sets sehen; oder auch, wenn ihnen mit den bestehenden Value Sets keine oder keine eindeutige Zuordnung zu z.B. Dokumentenklasse/-typ-Kombinationen oder Einrichtungsarten gelingt. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Governance allgemein klären und Beispiel zur Vorgehensweise hinzufügen;; zusätzlich neues Kapitel, wie sind diese ValueSets zu verwenden (Kapitel Vokabularmanagement) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 10 | 2 |  Negativ, kleineres Problem | Arnold Roesner | Uniklinik Freiburg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| p0007/16-17: Für kodierte Elemente gibt es zwei weitere Arten von Bindungen an Value Sets. | Für kodierte Elemente gibt es zwei weitere Eigenschaften von Bindungen an Value Sets. | Verwechslungsgefahr beim Begriff "Arten" | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 11 | 2 | Negativ, kleineres Problem | Arnold Roesner | Uniklinik Freiburg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| p0007/21-22: Tabellenspaltenüberschrift "Version" | "Versionsbindung" | um deutlicheren Bezug zum Text herzustellen | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 12 | 2.1 (3.1) | Tippfehler | Arnold Roesner | Uniklinik Freiburg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| p0009/10-11: "Briefe" | "Brief / Bericht" | einheitlich Singular; "Bericht" ergänzen, um auch die anderen Formen im Bezeichner zu adressieren, die schon in der Bechreibung genannt werden oder auch nicht explizit adressiert sind (z.B. Physiotherapie-Abschlussbericht in Abgrenzung zum Protokoll einer einzelnen Behandlung) | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | nur Änderung in Brief | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 13 | 2.1 (3.1) | Tippfehler | Arnold Roesner | Uniklinik Freiburg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| p0009: Tabellenspalte "Beschreibung" | einheitlich mit Großbuchstaben beginnen | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 14 | 2.2 (3.2) | Tippfehler | Arnold Roesner | Uniklinik Freiburg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| p0011/16-18: Bei "Anästhesiedokumente" sind die Beispiele nicht sichtbar | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Beispiel hinzufügen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 15 | 2.2 (3.2) | Negativ, kleineres Problem | Arnold Roesner | Uniklinik Freiburg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| p0013/08-09: "ERFU" | "FUNK" oder "FNKT" | Fokus auf "Funktionsdiagnostik", nachgeordnet "Ergebnisse" (siehe "BILD" - nicht "ERBI") | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 16 | 2.2 (3.2) | Negativ, kleineres Problem | Arnold Roesner | Uniklinik Freiburg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| p0013/09-10: CTG-Befund | löschen | als Beispiel entfernen, da explizit im Konzept "GEBU" aufgeführt und beschrieben | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 17 | 2.2 (3.2) | Tippfehler | Arnold Roesner | Uniklinik Freiburg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| p0016/07-12: Konzept "GEBU" | für GEBU stimmt die alphabetische Einsortierung nicht | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Konzepte müssen in ArtDecor richtig sortiert werden, solange es dort einfach geändert werden kann, wenn sortieren dann nach Displayname | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 18 | 2.1-2.2 (3.1-3.2) | Negativ, kleineres Problem | Arnold Roesner | Uniklinik Freiburg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die Bildung der beiden Value Sets classCode und typeCode mit dem Prinzip, dass typeCode keine Spezialisierung von classCode ist (bzw. sein muss), und mit den vorgeschlagenen Codes führt in Einzelfällen zu etwas verwirrenden Zuordungen: z.B. ist "Befund" mal im classCode, mal im typeCode zu setzen (manchmal sogar in beiden gemeinsam). Vielleicht lassen sich solche "problematische" Kombinationskonzepte noch auflösen. | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Die Komplexität in bestimmten Fällen wird in Kauf genommen, da nur dies eine eindeutige Zuordnung über beide Konzepte ermöglicht. Der Beschreibungstext sollte jedoch immer zu einer eindeutigen Zuordnung führen. Gerade beim Befund ist eine feingranularere Einteilung aufgrund der schwierigen Thematik kaum möglich. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 19 | 2.2 (3.2) | Kommentar allgemeiner Art | Arnold Roesner | Uniklinik Freiburg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Wenn nichts dagegen spricht, könnten die typeCodes z.T. durch noch spezifischere Codes erweitert bzw. ersetzt werden; z.B. für radiologische Befunde genauere Typen (CR, CT, MRT,…) vorsehen, ebenso für "Ergebnisse bildgebender Diagnostik" (Sonographie, Herzecho, Koloskopie,...) und auch für "Befunde" oder "Funktionsdiagnostik" insgesamt (EKG, EEG,...), ggf. auch bei anderen Typen überlegen, welche Dokumente besonderen Stellenwert haben und explizit/ausschließend über das Konzept gefunden werden sollen (z.B. OP-Bericht? Narkoseprotokoll?...) | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Zur zukünftigen Verwendung | Der eventCode kann zur Kennzeichnung der Modalitäten oder der Untersuchung verwendet werden, wird bisher von der AG noch nicht festgelegt (kann aber in Zukunft adressiert werden). Über den Titel kann durch Menschen noch eine Unterscheidung getroffen werden. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 20 | 2.4 (3.4) | Tippfehler | Arnold Roesner | Uniklinik Freiburg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| p0022/15-18: Chirurgie Operationstechnische Assistentin / Operationstechnischer Assistent ||Chirurgie Klinische Kodierfachkraft ||Üblicherweise in ärztlich geführter Einrichtung tätig, daher sollte die entsprechende ärztliche Fachrichtung verwendet werden. | das sind 3 separate Tabellenzeilen, die in ein Feld gerutscht sind | Layoutfehler | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 21 | 2.4 (3.4) | Kommentar allgemeiner Art | Arnold Roesner | Uniklinik Freiburg | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| In der Tabelle für das Value Set practiceSettingCode kommen Codes mit Level/Typ 0-S und 1-L vor. Woraus wird der Zusammenhang deutlich, in welcher Beziehung dann einzelne Codes stehen (z.B. HZCH ist Spezialisierung von CHIR und nicht von INNE)? Allein an der Zeilensortierung der Tabelle? Im Art-Decor habe ich auch keinen Hinweis darauf gefunden. Dann Bildungsprinzip evtl. in Erläuterungstext aufnehmen? | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Frage beantwortet; allein ander Zeilensortierung; evtl. erläuternden Text aufnehmen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 22 | Auflistung TypeCode und ClassCode | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Vorschla zur Problemlösung: es sollte geprüft werden ob für die vorhandenen Dokumente weitere Klasse ergänzt werden. Wir können ggfs. einen lösungsvorschlag erstellen. | Wir haben den AG-Vorshclag nochmal durch eine Mitarbeiterin mit der verfügbaren Kernliste an Dokumentation gegengeprüft und haben festgestellt, dass folgende in der Realität existierende Dokumente sich nicht in eine Klasse einsortieren lassen | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | siehe einzelne Antworten unten | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 23 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Anamnesebogen | Einweisungs- und Aufnahmedokumente | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Beispiel Anamnesebogen bei classcode=Durchführungsprotokoll | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 24 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Anmeldung Aufnahme | Einweisungs- und Aufnahmedokumente | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | administratives Dokument | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 25 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Aufnahmebogen | Einweisungs- und Aufnahmedokumente | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | ent. dem Anamnesebogen, daher auch Durchführungsprotokoll als classCode | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 26 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Checkliste Aufnahme | Einweisungs- und Aufnahmedokumente | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | type code: bei ADCH hinzufügen Hinweis auf AUFN; class code: administratives Dokument | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 27 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Stammblatt | Einweisungs- und Aufnahmedokumente | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | administratives Dokument | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 28 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Sonstige Aufnahmedokumentation | Einweisungs- und Aufnahmedokumente | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | kein Dokument | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 29 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Einsatzprotokoll | Rettungsdienstliche Dokumente | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | classcode: Durchführungsprotokoll | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 30 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Notaufnahmebericht | Rettungsdienstliche Dokumente | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | classcode: Brief Richtiger TypeCode: Arztberichte | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 31 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Notaufnahmebogen | Rettungsdienstliche Dokumente | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | classcode: Durchführungsprotokoll; typecode: Aufn | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 32 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Notfalldatensatz | Rettungsdienstliche Dokumente | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | type code: PATD; neuer ClassCode notwendig "medizinischeAusweise" für Notfalldatensatz und Allergiepass, bei classcode: administratives Dokumente Hinweis auf Ausschluss von Notfalldatensatz und Allergiepass hinzufügen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 33 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Sonstige Dokumentation Rettungsstelle | Rettungsdienstliche Dokumente | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | kein Dokument | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 34 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Verordnung von Krankenhausbehandlung | Einweisungs- und Aufnahmedokumente | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Konzept Verordnung erweitern für Überweisungen, Verordnung von Krankenhausbehandlung, Reha | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 35 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Sonstiges Einweisungsdokument | Einweisungs- und Aufnahmedokumente | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | kein Dokument | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 36 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Konsilanmeldung | Fallbesprechungen | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Anforderung für classCode, typeCode "Fallbesprechungen" anpassen (Dokumente bzgl. Einer …) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 37 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Konsilbericht intern | Fallbesprechungen | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Durchführungsprotokoll; Handlungsanweisung/empfehlung in Beschreibung mit aufnehmen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 38 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Konsilbericht extern | Fallbesprechungen | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Durchführungsprotokoll, siehe Konsilbericht intern | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 39 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Visitenprotokoll | Fallbesprechungen | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Durchführungsprotokoll, siehe Konsilbericht intern | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 40 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Tumorkonferenzprotokoll | Fallbesprechungen | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | classCode: Durchführungsprotokoll; typeCode: onkologische Dokumente | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 41 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Teambesprechungsprotokoll | Fallbesprechungen | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | classCode: Durchführungsprotokoll; typeCode: Fallbesprechungen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 42 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Anordnung | kein passenden IHE Code | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | typeCode: Befund (oder spezifischer); classCode: Anforderung (in Definition erwähnen, dass dies auch bei Laboranordnung gilt) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 43 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Verordnung | Verordnungen | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | classCode: Medikation (bei Medikamentösen Verordnungen) oder Verordnung, typeCode: Medikamentöse Therapien (bei Medikationsverordnung); oder Verordnungen (bei Heil und Hilfsmittel) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 44 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Sonstige Fallbesprechung | Fallbesprechungen | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | kein Dokument | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 45 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Follow up-Bogen | Onkologische Dokumente | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | classCode: Durchführungsprotokoll | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 46 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Meldebogen Krebsregister | Onkologische Dokumente | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | classCode: Forschung | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 47 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Tumorkonferenzprotokoll | Onkologische Dokumente | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | classCode: Durchführungsprotokoll; typeCode: onkologische Dokumente | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 48 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Tumorlokalisationsbogen | Onkologische Dokumente | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | classCode: Befund | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 49 | 2.1 | ? ? | Müller-Mielitz | DMI | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Sonstiger onkologische Dokumentationsbogen | Onkologische Dokumente | kein passenden IHE Code | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | kein Dokument | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 50 | 2.1 | Negativ, schwerwiegend | Kämmerer | Visus | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Es wird nicht klar welche Beziehung zwischen classeCode und typeCode besteht. Es müsste eine Art Matrix geben, zu welchem classCode welche typeCodes erlaubt sind. | Ohne diese Grundbedingung kann eine vollständig unsinnige Codierung vorgenommen werden. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Es gibt keine Beziehung | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 51 | 2.1 | Negativ, schwerwiegend | Kämmerer | Visus | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Es gibt keinen classCode für Signaldaten. -> Einführung eines Codes für Signaldaten | Derzeit gibt es keine Möglichkeit nur die Signaldaten (z.B. EKG) zu suchen. Es gibt nur die Möglichkeit diese über den typeCode ERFU zusammen mit der übrigen Funktionsdiagnostik zu suchen. Man sollte sich dann auch überlegen, ob es nicht Sinn macht einen zugehörigen typeCode zu definieren, der Signaldaten nochmals auffächert in Monitoring und Diagnostic | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Teilweise über AuthorRole, gegebenenfalls über formatcode erkennbar; DUR=ClassCode für Signaldaten | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 52 | 2.2 | Negativ, schwerwiegend | Kämmerer | Visus | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die Entitäten, welche unter typeCode BEFU subsummiert werden mit eigenen typeCodes ausstatten. | Der typeCode für Befund BEFU ist viel zu wenig granular. Warum werden die Entitäten in diesem Sammelbecken nicht mit einem eigenen typeCode versehen. In der derzeitigen Fassung kann man nicht einmal die klinische Chemie direkt suchen ohne eine sehr breite gestreute Treffermenge zu erhalten. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Teilweise über PracticesettingCode unterscheidbar. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 53 | 2.5 | Negativ, schwerwiegend | Kämmerer | Visus | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Neuer FormatCode mit DICOM OID | Derzeit kann man DICOM Objekte nur generell damit klassifizieren. Das reicht in der Praxis nicht aus. Es wird die Repräsentanz der DICOM OID benötigt, um gezielt nach Objektarten suchen zu können. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Die Granularität der XDS-I formatCodes erscheint nicht ausreichend. Hier bleibt nur der eventCode um, z.B. Kurvendaten zu kennzeichnen. Ob hier andere formatCodes verwendetwerden sollten ist out-of-scope für diese AG. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 54 | 2.5 | Negativ, schwerwiegend | Kämmerer | Visus | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Einführung von FormatCodes zur näheren Beschreibung der EKG Binärformate SCP EGG und MFER | Für die Prozessoptimierung ist es sinnvoll bereits auf dem Archivquerylevel eine Unterscheidung zwischen den Binärformattypen gezielt vornehmen zu können, um die richtigen Daten an eine Applikation weiterereichen zu können. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | hier kein geschlossenes Valueset, daher können die zuständigen Standardisierer entsprechende codes definieren | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 55 | ? ? | Siemens | |||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Für die Gruppierung von Dokumenten empfehlen wir die Verwendung von Reference ID Lists statt Foldern. | Folder stellen einen eigenen Entitätstyp im Document Registry Datenmodell dar, für den unseres Wissens derzeit ohne proprietäre Erweiterungen nicht über XACML-basierte (XUA, XUA++) Policies Zugriffsrechte abgebildet werden können. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | im APPC Profil teilweise gelöst; nicht relevant für die ValueSets sondern nur für Cookbook | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 56 | 2.1 | ? ? | Siemens | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Löschung Klasse Administratives Dokument | Uns stellt sich die Frage, ob Institutions-interne administrative Artefakte (z.B. ADM, ASM, GUT, teilweise auch ANF) häuserübergreifend verfügbar gemacht werden sollten. Im Zweifelsfall ist bekannt, von welcher teilnehmenden Einrichtung ein Dokument stammt und prozessbeschreibenden bzw. qualitätsbelegende Artefakte (z.B. DUR) können aus dem jeweiligen Informationssystem herangezogen werden. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | muss nicht verwendet werden, in manchen Fällen sind sie relevant | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 57 | 2.1 | ? ? | Siemens | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| FOR | Löschung Klasse Forschungsrelevante Dokumente | Vielmehr hängt es von der jeweiligen Fragestellung ab, welche bestehenden Dokumente in einer Affinity Domain forschungsrelevant sind. Diese Dokumente können unterschiedlicher Art sein. Die Einführung eines eigenen FOR-Codes, missachtet diesen Umstand. Vielmehr müsste a priori (d.h. zum Zeitpunkt des Einstellvorgangs jedes Dokumentes) im jeweiligen Quellsystem bekannt sein, ob es sich um ein forschungsrelevantes Dokument handelt – was so nicht möglich ist und auch nicht dem primären Zweck z.B. eines BEF-Dokuments entspricht (und der ClassCode sollte schließlich die Primärbedeutung eines Dokuments darstellen). | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Dieser Code wird nur verwendet, wenn das Dokument ausschließlich für die Forschung verwendet wird. ==Text in Beschreibung ändern | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 58 | 2.2 | ? ? | Siemens | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| TypeCodes sollten ClassCodes hierarchisch untergeordnet sein. | A) der TypeCode den ClassCode genauer spezifizieren soll, was eine Abhängigkeit des TypeCodes vom ClassCode impliziert. B) das anzustrebende Ziel, das durch die Verwendung jeweils geschlossener Wertemengen für die beiden ValueSets erreicht werden soll (nämlich die semantisch-eindeutige Codierung aller Artefakte einer Affinity Domain) deutlich erschwert wird. Durch die freie Kombination beider VaueSets wird es unnötiger Weise zu einer Vielzahl unterschiedlicher Codier-Ansätze innerhalb einer Affinity Domain kommen, die zwangsweise missverständlich sein werden (z.B. ein Speziallaborbefund könnte als Paar classCode/type code sowohl Befund/Immonologiebefund als auch Labor/Immonulogiebefund haben). Ultimativ wird diese beliebige Kombination das Auffinden relevanter Artefakte erschweren bzw. sogar zu falsche Ergebnisse aus Suchanfragen führen. Auch die überschaubare Definition von Zugriffspolicies aber auch die anzustrebende automatische Auswertung der geteilten Artefakte für Forschungsfragen würde auf diese Weise deutlich erschwert werden. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | es werden keine Hierarchien erstellt. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 59 | 2.2 | ? ? | Siemens | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| MKRO | löschen | Vermischung von Dokumenttypen und Fachrichtung | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | bewusst in Kauf genommen, weil practice setting code nicht konsistent angewendet | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 60 | 2.2 | ? ? | Siemens | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| OPDK | löschen | Vermischung von Dokumenttypen und Fachrichtung | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | OP-Dokumente stammen aus unterschiedlichen Fachrichtungen, daher zur Unterscheidung notwendig | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 61 | 2.2 | ? ? | Siemens | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| PATD | kein passender Class Code | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | für die im Dokument aufgelisteten Beispiele immer der gleiche ClassCode=adminstratives Dokument | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 62 | 2.1-2.4 | ? ? | Heydt/AGFA | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Berücksichtigung von Ambulanzdokumenten | Dokumente von ambulanten Besuchen von Patienten mit Schilddrüsenunterfunktion nicht zuordenbar | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | HealthcarefacilityTypecode=Krankenhaus; practicesettingcode=endokrinologie; evtl. in einen Folder oder einen Eventcode; Rest hängt vom jeweiligen Dokument ab; Beispiel:schilddrüsenbefund: classcode=Befund; typecode=Befund; title=Schilddrüsenbefund (Title ist Freitext) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 63 | 2.2 | ? ? | Heydt/AGFA | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| neue Strukturierung im Bereich Ernährung, Diätetetik, Diabetik | Es gibt eine Vielzahl von Dokumenten, die diesen Themenblock aufgreifen. Eine logische (im Sinne der Übersichtlichkeit) Strukturierung erscheint bislang zu diesem Themenkreis nicht möglich. So wurde beispielsweise der Ernährungsplan dem typeCode Pflegedokumentation zugeordnet, die Diabetesschulung hingegen dem typeCode Verordnungen und die Ernährungstherapie bei Mangelernährung dem typeCode Funktionstherapie. Hier stellt sich tatsächlich die Frage nach der Sinnhaftigkeit in Verbindung mit DocumentEntry.classCode, DocumentEntry.typeCode, DocumentEntry.healthcareFacilityTypeCode und DocumentEntry.prac?ceSeJngCode. Natürlich stellen wir auch hier die Möglichkeit anheim, dass unsere Betrachtung einer Unschärfe unterliegt. Dennoch konnten wir in zahlreichen Verprobungen mit den vorhandenen DocumentEntry.typeCodes in Verbindung mit den anderen Metadaten nicht die benötigte Eineindeutigkeit für einen eineindeutigen Aktenplan erzeugen. Also sehen wir an diesem Punkt Handlungsbedarf, den wir z.B. mit einer zusätzlichen Klasse (z.B. DocumentStatus.ClassCode - stationär / ambulant / invasiv / Reha / präventiv) abfangen könnten. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | evtl. alle Ernährungsdokumente in einem Folder ablegen; practice setting code eindeutig zuordenbar | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 64 | 2.2 | ? ? | Heydt/AGFA | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| DocumentStatus.ClassCode - stationär / ambulant / invasiv / Reha / präventiv) | s.o. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Unterscheidung zwischen ambulant und stationär ist auch innerhalb des Krankenhauses ohne Fallbezug nicht immer möglich; Lösungsvorschlag über ReferenceID List Fallbezug herstellen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 65 | 2.2 | ? ? | Heydt/AGFA | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| PCR Befund einem Type Code zuordnen | Überschneidung Virologiebefunde / Mikrobiologiebefunde | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | virolog. PCR- Befund und mikrobiolog. PCR - Befund aus den Beispielen entfernen, da keine eindeutige allgemeningültige Zuordnung bekannt | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 66 | 2.2 | ? ? | Heydt/AGFA | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Abgrenzung Abrechnungsdokument /Schriftwechsel administrativ | Schriftverkehr Krankenkasse nicht eindeutig zuordenbar; Abrechnungsdokumenten“ (als typeCode) und „Schriftverkehr Krankenkasse (als Beispiel zum typeCode „Schriftwechsel administrativ) | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Text beim Typecode Schriftwechsel administrativ genauer spezifizieren; Abrechnungsdokumente und ärztliche Bescheinigungen ausschließen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 67 | 2.2 | ? ? | Heydt/AGFA | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| einheitliche Regeln für die Zusammensetzung der Deskriptoren | Die Filtration von Dopplungen in bestehenden Aktenplänen ist oft nicht einfach, da das gleiche Wort in diversen Schreibweisen existieren kann (z.B.: Protokoll Sturzereignis, Sturzereignisprotokoll). Hier muss eine eindeutige semantische Festlegung getroffen werden. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Sturzprotokoll erwähnt | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 68 | 2.3 | ? ? | Heydt/AGFA | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| neuer Code für nicht eindeutige Einrichtungstypen | beim Einscannen von Altakten nicht immer bekannt | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | limited metadata oder codes für "Altakte" projektspezifisch definieren, Resteklassen nicht Teil der standardisierten Konzepte; weitere Erläuterungen im Kapitel Vokabularmanagement | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 69 | 2.3 | ? ? | Heydt/AGFA | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| neuer Code für MDK | fehlt | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | MDK hinzufügen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 70 | 2.3 | ? ? | Heydt/AGFA | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| neuer Code für Fremdlabor | fehlt | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Arztpraxis benutzen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 71 | 2.3 | ? ? | Heydt/AGFA | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| genaue Definition wer DocumentOwner ist | Auch bleibt unklar wie ein Dokument, dessen Betrachterrolle z.B. im Rahmen eines Prüfprozesses (MDK oder Prüfauftrag) eventuell die Rolle und Zuordnung zu einem klassischen Owner (FacilityTypeCode) wechselt. Beispiel: Das Dokument kommt im Rahmen einer Codierungsprüfung zum MDK. Der MDK benützt dieses Dokument zur Rechtfertigung des gestellten Gutachtens. Wechselt das Dokument nun den Owner (Facility), weil es in einem anderen Kontext zur Rechtfertigung für den Gutachtenkontent herangezogen wird, oder verbleibt das Dokument bei der ursprünglichen Facility. Dieser Prozess muss in einer allgemeingültigen Regel definiert werden. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Wir legen nur den Healthcarefacility Type code fest. Eigentümer gibt es nicht. Evtl. Cookbookthema | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 72 | 2.4 | ? ? | Heydt/AGFA | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| healthcarepracticeSettingCode | neuer Code für nicht eindeutige practiceSetting | beim Einscannen von Altakten nicht immer bekannt | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | s.o. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 73 | 2.2 | ? ? | Heydt/AGFA | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| eindeutige Definition Betreuung | An zweiter Stelle steht die Vermeidung von zu allgemeinen Begrifflichkeiten, die Interpretationsspielräume offenlassen. Beispiel: Belegart „Betreuungsdokumente“. Bei diesen TypeCodes muss zugunsten einer mathematischen Eineindeutigkeit eine semantische Eineindeutigkeit herbeigeführt werden. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Warten auf Information vom Antragsteller | konkretes Beispiel, bei dem das Problem besteht, angeben | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 74 | 2.2 | ? ? | Heydt/AGFA | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Je nach Kunde ist eine Anpassung (Erweiterung/Einkürzung) der Belegarten flexibel erforderlich. Dies wiederum birgt in regionalen Konzepten die Gefahr von Dubletten und erfordert somit eine eindeutige semantische Festlegung/Zuordnung einzelner Dokumentklassen (typeCode). | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Die Unterscheidung zwischen gleichnamigen Konzepten kann über saubere Code System Definitionen erreicht werden. Das Verhindern von kundenspezifischen Belegarten ist kein Ziel der Arbeitsgruppe. Beim Mapping auf die IHE DE ValueSets muss nur eine eindeutige Zuordnung auf die IHE Werte möglich sein. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 75 | 2.2 | ? ? | Heydt/AGFA | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Befund | Aufteilen in mehrere Codes | Befunde mit 96 Belegart-Zuordnungen. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Zur zukünftigen Verwendung | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 76 | 2.2 | ? ? | Heydt/AGFA | ||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Fallbesprechung | Aufteilen in mehrere Codes | Gerade in Universitätskliniken nehmen fallbezogene Videokonferenzen stetig zu (Kosten- und Zeitersparnis). Auch hier muss semantisch eine Eineindeutigkeit für unterschiedliche Besprechungsformen definiert und Zuordnungen zum TypeCode generiert werden. Vermutlich werden hier in den nächsten Jahren zahlreiche weitere „Belegarten“ hinzukommen. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Zur zukünftigen Verwendung | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 77 | ? ? | ||||
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Schulungnachweise nicht geeignet berücksichtigt | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Schulungsunterlagen und Nachweis unter TypeCode=Patienteninformation ; jeweils Text erweitern | ||||
