Kommentare und Auflösungen zum Abstimmungsverfahren Überleitungsmanagement
Version vom 24. Mai 2016, 15:20 Uhr von Wikiadmin (Diskussion | Beiträge)
Stand: 24. Mai 2016
| Auszählung (Tally) | |
|---|---|
| Anzahl Kommentare | 27 |
| Angenommen | 16 |
| Angenommen mit Modifikationen | 0 |
| Nicht angenommen | 4 |
| Nicht relevant | 0 |
| Zur zukünftigen Verwendung | 6 |
| Weitergeleitet | 0 |
| Warten auf Information vom Antragsteller | 0 |
| Warten auf Information von anderer Arbeitsgruppe | 0 |
| Unbearbeitet | 0 |
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
|---|---|---|---|---|---|
| 1 | 3.3.2.1 |  Negativ, kleineres Problem | Christof Gessner | MxDx Medizinische Informatik | |
Kommentar  | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Angabe von OIDs in der Auflistung (z.B. 1.2.276.0.76.10.3059 Durchgeführte Maßnahmen) | 1.) Andere Darstellung, in der die OID nicht mit einem Identifkator der Section verwechselt werden kann (z.B. Durchgeführte Maßnahmen - definiert im Template ID 1.2.276.0.76.10.3059). Akternativ: Darstellung als Tabelle mit geeigneten Spaltenbeschriftungen. 2.) Kurze Erläuterung, als einleitender Satz, ggf. als Fußnote, was die Rolle der Template-ID hier ist. | An dieser Stelle im Dokument sinddie Template-IDs irrelevant. In der gewählten Darstellung besteht überdies die Gefahr, dass die OIDs als "Codes" mit der Bedeutung der Section verstanden werden. In Wahrheit stehen sie aber für einen definierten Satz von Regeln, die den Inhalt und Aufbau der Section beschreiben. Hilfreich wäre ein kurzer Hinweis auf die Bedeutung der OIDs zusätzlich im folgenden Abschnitt 3.4 Verwendung von Templates. | |||
Reconcile  | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Kann man anders machen - Alternative Darstellungsweise (Mathias) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 2 | "3.4" | Negativ, kleineres Problem | Christof Gessner | MxDx Medizinische Informatik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| -- | Jedes Template ist durch eine OID identifizierbar, die im Dokument als Hinweis auf die verwendeten Regeln referenziert werden kann. | Es fehlt eine Erläuterung der Template-OIDs, auch und gerade in Abgrenzung zu anderen "semantischen" Codes. Das könnte zu Fehlinterpretation führen, in dem Sinne dass beim Parsen des Dokuments auf die template-id Bezug genommen wird. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikation | Eine Beschreibung der Zusammenhänge zwischen Template Ids und semantischen Codes oder Strukturen gehört hier nicht hin; Auf eine Beschreibung an allgemeiner Stelle wird verwiesen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 3 | 1.2.276.0.76.10.1017
 |  Tippfehler | Christof Gessner | MxDx Medizinische Informatik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| im PDF: Angabe "Constraint Kassennummer (scopingOrganization.id) und Kassenname (scopingOrganization.name) sind Pflichtangaben" | verschieben, hier weglassen | Diese Angabe erscheint hier wohl im falschen Kontext. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Bezeichnung des Konstraint nicht passend hier, bezieht sich auf ein Template darunter, ist aber ein auf Komentenlevel gezeichnetes Constraint und erscheint daher es genau an der Stelle. Diies ist aber Irreführend. Contraintangabe wurde entsprechend geändert. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 4 | 1.2.276.0.76.10.2037 | Negativ, kleineres Problem | Christof Gessner | MxDx Medizinische Informatik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| recordTarget/patientRole/patient/name "Nur Vor- und Nachname sind anzugeben" | "Vor- und Nachname müssen angegeben werden. Andere Felder dürfen nicht angegeben werden" oder "Vor- und Nachname müssen angegeben werden. Andere Felder dürfen angegeben werden"" | Regel ist sprachlich nicht eindeutig. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | eGK Kann mehr daher "Vor und Nachname muss andere dürfen"; wurde entsprechend geändert | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 5 | 1.2.276.0.76.10.2022 CDA participant Kostentraeger |  Kommentar allgemeiner Art | Christof Gessner | MxDx Medizinische Informatik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| where [hl7:templateId [@root='1.2.276.0.76.10.2022']] | Frage: Ist das legitim, Vorhandensein und Wert einer template-id als Grundlage einer Regel zu nehmen? Besser typeCode und associatedEntity.classCode verwenden? | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Diese Prädikate werden automatisch erzeugt und in erster Linie beziehen diese sich auf Template Ids (da CDA gänzlich darauf baut). typeCode und classCode werden erst in zweiter Instanz zur Prädikatsbildung herangezogen. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 6 | 1.2.276.0.76.10.1016
 | Tippfehler | Christof Gessner | MxDx Medizinische Informatik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| im PDF: Angabe "Constraint Kassennummer (scopingOrganization.id) und Kassenname (scopingOrganization.name) sind Pflichtangaben" | verschieben, hier weglassen | Diese Angabe erscheint hier wohl im falschen Kontext. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | siehe #3 | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 7 | 1.2.276.0.76.10.2038 Autor und hl7:assignedAuthor |  Vorschlag | Christof Gessner | MxDx Medizinische Informatik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Gemäß Kurzbericht-Vorlage ist die Vertragsarztnummer anzugeben | Gemäß Kurzbericht-Vorlage ist die Vertragsarztnummer anzugeben (Nähere Angaben zu II siehe…) | sinnvoll wäre hier eine Erläuterung, wie die Elemente des II zu füllen sind. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Beispiel für LANR wurde eingefügt. Beispiel für Vertragsarztnummer wird nachgeliefert (Stefan) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 8 | 1.2.276.0.76.10.2022 | Vorschlag | Christof Gessner | MxDx Medizinische Informatik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| participant/time: Hier muss immer ein Quartalsende angegeben (MM/JJ) => YYYYMMDD | Satz unvollständig, Erläuterung kryptisch… Bitte besser erklären! | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Es wird ein Beispiel angegeben - erledigt | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 9 | 1.2.276.0.76.10.3061 | Negativ, kleineres Problem | Christof Gessner | MxDx Medizinische Informatik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| 34856-5 | Bitte prüfen. Scheint kein Section-Konzept zu sein, sondern ein Dokument zu bezeichnen. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Code bezeichnet das Geschehen eindeutig, alternativ müsste man einen neuen LOINC Code beantragen der aber inhaltlich nichts anderes beschreiben würde | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 10 | 1.2.276.0.76.10.3066 | Tippfehler | Christof Gessner | MxDx Medizinische Informatik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| section/title CONF: Elementinhalt muss "Medikation bei Entlassung" sein | section/title CONF: Elementinhalt muss "Einweisungsmedikation" sein | fehlerhafter Title | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Tippfehler wurde korrigiert | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 11 | 1.2.276.0.76.10.3064 | Vorschlag | Christof Gessner | MxDx Medizinische Informatik | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| X_NMTAS | Bitte Hinweis aufnehmen auf den Prozess zur Auflösung des vorläufigen LOINC Codes. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Notebox für den vorrübergehenden LOINC Code hier einfügen (Mathias) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 12 | Negativ, kleineres Problem | Mathias Aschhoff | ZTG, Bochum | Stefan Brüne | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Einige Angaben im Header werden gerade im KH oftmals fehlen (speziell Vertragsarztnummer und Rückfragen Angaben, aber auch Triviales wie eGK Daten) | Möglichst kein Einsatz von Mandatory | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Anpassungen wurden wo sinnvoll angepasst. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 13 | Vorschlag | Mathias Aschhoff | ZTG, Bochum | Stefan Brüne | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Diagnosen sollten maschinenlesbar sein und auch so vorliegen. OPS teilweise auch | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Zur zukünftigen Verwendung | Verweise auf Entry Level Sections des Arztbrief einfügen (bei Diagnose; bei OPS vielleicht besser nicht) Diagnosen, Prozeduren und Medikation sind Bestandteil des Arztbrief 2016 bzw des patientenbezogenen Medikationsplans. Sobald diese hier finalisiert werden, können technisch sehr einfach die Entries von dorther auch hier übernommen werden. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 14 | Vorschlag | Mathias Aschhoff | ZTG, Bochum | Stefan Brüne | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Verwendung des Medikationsplans für Einweisungs-/ Entlassmedikation | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Zur zukünftigen Verwendung | Verweis auf entsprechende Section des Medikationsplans einfügen Diagnosen, Prozeduren und Medikation sind Bestandteil des Arztbrief 2016 bzw des patientenbezogenen Medikationsplans. Sobald diese hier finalisiert werden, können technisch sehr einfach die Entries von dorther auch hier übernommen werden. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 15 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG, Bochum | Stefan Brüne | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Es gibt keine Pflichtangaben im Body (aber leer sollte man das Dokument wohl auch nicht schicken) | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Konformitäten sind angegeben Konformitäten sind angegeben, auch leere Dokumente sind zugelassen | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 16 | Negativ, kleineres Problem | Mathias Aschhoff | ZTG, Bochum | Stefan Brüne | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Es sollte wenige Muss- bzw. Pflichtfelder geben | Möglichst kein Einsatz von Mandatory | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | siehe #12 | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 17 | Kommentar allgemeiner Art | Mathias Aschhoff | ZTG, Bochum | Stefan Brüne | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Medikationsdaten sollten maschinenlesbar sein, aber vor allem an Standard angelehnt | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Verweis auf entsprechende Section des Medikationsplans einfügen siehe #14 | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 18 | Vorschlag | Mathias Aschhoff | ZTG, Bochum | Stefan Brüne | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Konflikt zwischen Papier und Digital: Bspw. viel mehr Diagnosen möglich (und sinnvoll) als auf Papier möglich | Vorschlag: eine Hauptdiagnose und beliebig viele Nebendiagnosen; ggf. beim Druck abkürzen -> 90a UAG | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Formular ist immer eine eingeschränkte Sicht. Verlässt den Rahmen eines Formulars. Feld Diagnosen auf dem Formular müsste dann größer dargestellt werden. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 19 | Negativ, kleineres Problem | Mathias Aschhoff | ZTG, Bochum | Stefan Brüne | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Konflikt bei Versichertenart wegen Unklarheit über zulässige Werte: 1/3/5 (eGK) oder 1/3/5/6/9 (KBV Schlüsseltabelle) | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Wird im Interopforum 2. Juni besprochen (Mathias) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 20 | Vorschlag | Mathias Aschhoff | ZTG, Bochum | Stefan Brüne | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Namensbestandteile: eGK kennt Namenszusätze und Vorwort; KIS üblicherweise nicht | ggf. noch ein separates Feld nutzen? | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | siehe #4 | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 21 | Negativ, kleineres Problem | Mathias Aschhoff | ZTG, Bochum | Stefan Brüne | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Mit "Vertragsarztnummer" kann man im KH nichts anfangen, hat man weder als Abensder noch als Adressat | -> 90a UAG: Absender oder Adressat gemeint? Kein Mandatory! | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | siehe #4 | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 22 | Vorschlag | Mathias Aschhoff | ZTG, Bochum | Stefan Brüne | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Papierdokumente sehen als Anrede für Rückfragen "Herr Dr." / "Frau Dr." vor | Sollte nicht über Geschlecht sondern über ein "Anrede" Feld abgebildet werden -> 90a UAG | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Anreden etwas genauer beschreiben (Mathias) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 23 | Vorschlag | Mathias Aschhoff | ZTG, Bochum | Stefan Brüne | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Bei Diagnosen gibt es eine unglückliche Vermischung der Semantik aus Medizin und Abrechnung | Vorschlag Eine Hauptdiagnose, aber mehrere Nebendiagnosen. Hier ggf. auch Sekundärdiagnose unterbringen und idealerweise kennzeichnen (Kreuz/Stern System) | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Zur zukünftigen Verwendung | Es fehlt hier an Begriffsdefinitionen, Haupt/Nebendisgnosen und Kreuz/Stern Zusätze sind verschiedene Dinge (weitere die Diagnose qualifizierede Diagnosen). Hinweise dazu und Umsetzungsvorschriften wird es im kommenden Diagnosentemplate Arztbrief 2016 geben. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 24 | Vorschlag | Mathias Aschhoff | ZTG, Bochum | Stefan Brüne | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Antikoagulation sollte langfristig in Medikationsdaten einfließen | Vorerst nicht ändern -> 90a UAG | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Zur zukünftigen Verwendung | siehe #14 | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 25 | Vorschlag | Mathias Aschhoff | ZTG, Bochum | Stefan Brüne | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Medikationsdaten sollten sich am Medikationsplan 2.0 orientieren | Verweis auf entsprechende Section des Medikationsplans einfügen | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Zur zukünftigen Verwendung | Verweis auf entsprechende Section des Medikationsplans einfügen siehe #14 | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 26 | Vorschlag | Mathias Aschhoff | ZTG, Bochum | Stefan Brüne | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Einige Informationen zur aktuellen Situation schließen sich gegenseitig aus (Pflege-/Hospizformen) | Umsetzungsempfehlung (Auswahlliste erzeugen?) | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Zur zukünftigen Verwendung | Muss im Formular und softwaretechnisch in der Anwendung umgesetzt werden. Zur Zeit Freitext. Wenn diese Sachverhalte auf Level 3 abgebildet werden kann man eine entsprechende Ausfüllungsvorschrift prüfen. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 27 | 9 | Vorschlag | Mathias Aschhoff | ZTG, Bochum | Stefan Brüne |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Verweis auf Anlagen | Mitgegeben Befunde | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Wird im Wikitext (Datensatz) umbenannt S.9 (Mathias) | ||||
