...
| 1 | P3 - klinische Daten: Folgeereignisse - erste Auswertungserfahrungen | Erledigt | |
| 2 | Therapieangaben liegen im ZfKD in unterschiedlicher Qualität vor (Reduzierung auf J/N notwendig?). | Vorschlag: epi Therapieangaben nicht mehr übermitteln Übermittlung der epi Daten zum RKI Erledigt | |
| 3 | initialer PSA | Erledigt | |
| 4 | https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2818349/JNU+Typ?focusedCommentId=10616888 | Wir haben JNU, bislang aber nicht als Typ verbunden. Kommt auf die Liste für v7 | Erledigt |
| 5 | DCN / DCI / DCO | Erledigt | |
| 6 | Lost-to-follow-up | ist wieder entfernt Erledigt | |
| 7 | Variante 2: Lieferung nach neuem ZfKD-XML-Schema | Erledigt, wird im Kontext diskutiert | |
| 8 | Vorschlag ICD10 Diagnosen | Erledigt | |
| 9 | HH IL: Sex D=Divers wegen Seltenheit/Datenschutz besser in X überführen | Erledigt, in oBDS 3.0.1 ist X und U deklariert, daher auch hier vorgesehen | |
| 10 | Das Modell “choice” ist ein Artefakt der Vorversion und muss korrigiert werden. | Erledigt, wird in v8 gefixt | |
| 11 | Vitalstatus = complexType / Das müßte m.E eine SEQUENCE und keine CHOICE sein | Erledigt, s.o | |
| 12 | Voller Informationsgehalt wäre gegeben über die Stellung in der Kausalkette, also zusätzliche Angabe ob 1a/1b/1c/2a/2b/Unfall …. | ||
| 13 | Hier noch angeben, wie das Datum zu bilden ist (generell 01 für den Tag, da ja sowieso maximal monatsgenau?) Was bei jahrgenau und vollständig geschätzt? Alternativ <xs:restriction base="xs:gYearMonth"> | ||
| 14 | Das Diagnosedatum der Metastase wäre vielleicht doch wichtig. Gerade im Rahmen des primärdiagnostischen Prozesses kann aus dem Diagnosedatum des Tumors nicht unbedingt auf das der Metastase geschlossen werden. Bei Folgeereignissen mag das anders sein - da bestimmen die Metastasen ggf das Ereignis. | ||
| 15 | https://plattform65c.atlassian.net/wiki/spaces/P6/pages/820093/Tumor?focusedCommentId=34537474 | Genetische Varianten sind bewußt weggelassen worden? (Betrifft Diagnose und Verlauf). Die Moduldaten tauchen nur einfach auf. Rein formal wäre es dann noch gut zu beschreiben, daß die Sichtweise zum Zeitpunkt der Diagnose gemeint ist. Wobei das LDH beim Malignen Melanom hier eine Sonderrolle einnimmt, weil es ein Parameter für eine Metastasierung zu einem Zeitpunkt irgendwann im gesamten Verlauf der Erkrankung ist. Vielleicht um das Datum ergänzen? | |
| 16 | Beginn nennen? |
...
| 1 | Therapieangaben für Altfälle | Erledigt, wird im Kontext diskutiert | |
| 2 | Applikationsart | Erledigt | |
| 3 | https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2064400/XML-Schema?focusedCommentId=8617986 | oBDS Schema als Grundlage: Kann oBDS_RKI auf definierte Module von oBDS_RD zurückgreifen? | Teilweise - soweit möglich wurden die oBDS Elemente übernommen, diese können als Module inkludiert werden Erledigt |
| 4 | Mit Udo Altmann klären (Mißverständnis?) | Erledigt | |
| 5 | ICD-Versionen sind optional | Erledigt | |
| 6 | DCI - warum Pflichtfeld | Erledigt, wird im Kontext diskutiert | |
| 7 | Lost to follow up - sinnvoll? | Erledigt, Element ist entfallen | |
| 8 | https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2654511/SYST_Typ?focusedCommentId=20283393 | Eine sprechendere Bezeichnung der Variablen hätte ich besser gefunden, z.B. SYDatumTyp. Datum ist je normalerweise das Datum selber. Warum nicht gleich Beginn? Im Kontext SYST ist das dann klar… . Ich wäre dafür, das Beginn zu nennen, so wie es auch beschrieben ist. |
...
| 1 | Umgestaltung OP-Typ - Probleme in der Implementierung? | Erledigt | |
| 2 | Gibt es einen dedizierten Kanal für den Dateiaustausch? | Erledigt; ist in Vorschlag behandelt | |
| 3 | Ist es grundsätzlich vorstellbar, die bestehende Systematik auch auf diesen use case anzuwenden? | Erledigt; ist in Vorschlag behandelt | |
| 4 | Ist die Dokumentation der derzeit angewandten Methodik zur Stückelung verfügbar? | Erledigt; ist in Vorschlag behandelt | |
| 5 | Ist das ein praktikabler Vorschlag für die Kodierung? | ||
| 6 | Vorschlagsliste für weitere Klassifikationen? | Erledigt. Schematyp ist in v7 entfallen | |
| 7 | Auch bei DCO-Fällen kann anhand der Angaben auf der TB die Diagnosesicherung bekannt sein. Erfassen? | Erledigt | |
| 8 | Sollen tatsächlich die aufgeführten Zeichen erlaubt sein? | Erledigt. Diese Schematypen regeln den automatisierten Austausch von Meldungen und sind ungeeignet für oBDS-RKI, entfallen in v7 | |
| 9 | Die Plattform hat eine Vorschlagsliste für Weitere Klassifikationen veröffentlicht. Ist die auch Grundlage für die Weitergabe der Daten an das ZfKD, oder gibt es Ergänzungen bzw. Informationen die nicht gewollt sind? Was ist mit Angaben die außerhalb der Vorschlagsliste liegen? | ||
| 10 | Warum wird beim UICC davon abgewichen, einen Best-of Datensatz zu übermitteln? Zudem gehört das UICC zum TNM_Typ und für das TNM wird ein Best-of Datensatz erwartet. In der Praxis werden ggf. von verschiedenen Meldern auch verschiedene UICC-Stadien gemeldet, wie ist damit umzugehen? | Wir waren wohl davon ausgegangen, dass die Register dazu noch keinen Best-of habe, die Stand hierzu ist wohl noch sehr unterschiedlich. Wir werden das nochmal anpassen (Best-of, wenn vorhanden). Hier wird man wahrscheinlich erstmal Erfahrung sammeln müssen.. | |
| 11 | https://plattform65c.atlassian.net/wiki/spaces/P6/pages/30965761?focusedCommentId=32735234 | Gibt es hierzu schon eine Abschätzung, wann ? | Stephanie Titze, KBV: der Umstieg auf FHIR als internationalen Standard sollte zeitnah erfolgen; die KBV setzt bei den MIOs und bei neuen Schnittstellen (z.B. eVerordnungen und Interop-Schnittstellen) ebenfalls auf diesen Standard. |
| 12 | Wenn pTNM vorliegt, cTNM zusätzlich nur angeben, wenn das Präfix „c“ für das T-Stadium gesichert ist. Simone Wesselmann: Aber wenn ein sicheres pTNM (mit dazugehöriger Histo/OP-Datum uä) vorliegt, kann ein weiterer TNM nur ein “c” sein, oder? | In dem Fall können die Register dann das “c” ja auch vergeben. Es ist gut möglich, dass das in den Registern noch nicht einheitlich gehandhabt wird, damit müsste man dann erstmal leben. | |
| 13 | Ein fehlendes Präfix wird entsprechend oBDS wie ein Präfix „c“ gewertet. Simone Wesselmann: nur dann, wenn keine Informationen über eine OP vorliegen, oder? | Auch hier würde ich sagen, dass die Register im Rahmen des Best-of entscheiden, ob sie das “p” vergeben können. | |
| 14 | Simone Wesselmann: wie werden Metastasen in paarigen Organen gezählt? 1. FM pro Lunge oder 1. FM pro re Lunge? | Gedacht war die 1. Lungen-, 1. Kochenmetastase usw. | |
| 15 | Simone Wesselmann: LDH wird ja zur Feststellung/Ausschluss von Fernmetastasen genutzt, so dass uU das erste LDH (= bei zB 1.Diagnose) weniger relevant ist als das LDH zur Diagnose Stad IV im Verlauf… Vielleicht verstehe ich es auch nicht richtig u Sie meinen : es liegen mehrere LDH für 1 Meldeanlass vor | Ähnlich wie beim PSA wollten wir hier auch das LDH hier zunächst einmal nur im Rahmen der Primärdiagnose aufnehmen, noch nicht als Verlaufsparameter, um es nicht zu kompliziert zu machen und Fehlinterpretationen vorzubeugen. (auch wenn LDH eine etwas andere Bedeutung hat). Kann man später auch nochmal ändern, wenn die Verläufe wichtiger werden. Vielleicht wäre es dann aber auch hier sinnvoll, eine Datumsangabe (monatsgenau) einzufügen. | |
| 16 | Simone Wesselmann: Warum wurde bei KRK nicht auch KR1, KR2, KR3 u KR5übernommen, wenn es um “tumorspezifische prognostisch und therapeutisch relevante Charakteristika” geht? Aus den Angaben ergeben sich ja therapeutische Implikationen in Abhängigkeit von der Lage des Tumors | ||
| 17 | Was ist die Motivation für die Stückelung in dieser Datenlieferung? Gibt es Limitierungen in der Plattform, oder bei der Verarbeitung der Daten nach Empfang? Im Registerübergreifenden Datenaustausch haben wir eine ähnliche Stückelung vereinbart. Der Hintergrund ist hier, dass große Meldungspakete bei der Verarbeitung in den Softwaresystemen Probleme machen, da diese dort zahlreiche Prüf- und Verarbeitungsprozesse durchlaufen. | Die emfpangenen Daten werden im RKI Prozess ebenfalls geprüft und in andere Systeme überführt, daher sind ähnliche techn. Limitationen wie im RD zu erwarten. | |
| 18 | https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2064400/XML-Schema?focusedCommentId=34406402 | Vielleicht so eine generelle Frage: wenn eine Ausprägung in einem Register nicht in das Format konvertierbar ist - dann das betreffende Element weglassen (sofern optional)? Mir scheint das auch nach Lektüre der Vereinbarungen nicht durchgängig konsistent zu sein. | Wenn die Information nicht (bzw. nicht im geforderten Format) vorliegt soll entweder das Element weggelassen werden (wenn optional), oder in eine bestehende Unbekannt Kodierung überführt werden. Das ist nicht konsistent, dafür aber möglichst kompatibel zu den oBDS Elementen. Bei einigen Elementen wird bewusst eine inhaltliche Angabe erzwungen (z.B. DCN) |
| 19 | Warum fehlen die Sentinel Lk? | ||
| 20 | Es kann sein, daß in einem Register auch zum Zeitpunkt der Primärdiagnose mehrere TNM zu unterschiedlichen Zeitpunkten in unterschiedlicher Qualität vorliegen, weil sich darin ein fortschreitenden diagnostischer Prozeß wiederspiegelt oder ggf. auch ein primäres früheres Fortschreiten der Erkrankung. Welcher wäre ggf. der bevorzugte? | ||
| 21 | “Dies gilt ausdrücklich auch, wenn nach diesem Abgleich zu dieser Person noch eine Meldung im Register eingegangen ist, …” Dann kann es vorkommen, dass übermittelte Folgeereignisse (Therapie, usw.) nach dem letzten “Lebend”-Datum liegen, da der Abgleich mit Mortalitätsdaten der Behörden i.d.R. weniger häufig erfolgt. Kommt es dann nicht zu Problemen bei der Auswertung? |
...
| 1 | Datum_Tag_oder_Monat_oder_Jahr_oder_nicht_genau_Typ - nicht vorhanden | Erledigt | |
| 2 | Unbekannt gibt es so nicht im aktuellen oBDS, aber historisch mag das vorhanden sein. | Zustimmung, das Element “Unbekannt” wurde auf Wunsch der AG ZfKD-Lieferdatensatz deklariert. Erledigt | |
| 3 | DKKR MR: Hier bitte noch das DKKR ergänzen! |