Kommentare im Überblick

Hier erfolgt eine Auflistung von Kommentaren, die noch nicht beantwortet wurden oder zur Diskussion stehen.

Alle in diesem Bereich eingestellten Kommentare sind zu Präsentations- und Archivierungszwecken in dieser Word-Datei zusammengefasst.

Vorschläge

1

Re: Allgemeine Vereinbarungen | Comment

P3 - klinische Daten: Folgeereignisse - erste Auswertungserfahrungen

Erledigt

2

Re: Allgemeine Vereinbarungen | Comment

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

Re: Vereinbarungen zu Elementen des XML-Schemas | Comment

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

Re: Vereinbarungen zu Elementen des XML-Schemas | Comment

Re: Vereinbarungen zu Elementen des XML-Schemas | Comment

DCN / DCI / DCO

Erledigt

6

Re: Vereinbarungen zu Elementen des XML-Schemas | Comment

Re: Vereinbarungen zu Elementen des XML-Schemas | Comment

Lost-to-follow-up

ist wieder entfernt

Erledigt

7

Re: Allgemeine Vereinbarungen | Comment

Variante 2: Lieferung nach neuem ZfKD-XML-Schema

Erledigt, wird im Kontext diskutiert

8

Re: Allgemeine Vereinbarungen | Comment

Vorschlag ICD10 Diagnosen

Erledigt

9

Re: Patienten_Stammdaten_Typ | Comment

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

Re: Vitalstatus | Comment

Das Modell “choice” ist ein Artefakt der Vorversion und muss korrigiert werden.

Erledigt, wird in v8 gefixt

11

Re: Patienten_Stammdaten_Typ | Comment

Vitalstatus = complexType / Das müßte m.E eine SEQUENCE und keine CHOICE sein

Erledigt, s.o

12

Re: Menge_Weitere_Todesursachen | Comment

Voller Informationsgehalt wäre gegeben über die Stellung in der Kausalkette, also zusätzliche Angabe ob 1a/1b/1c/2a/2b/Unfall ….

Auch aus den bisherigen Erfahrungen heraus: erstes Ziel wäre es , dass Grundleiden der TU abbilden zu können. Alles andere ist außerdem in den Registern nicht einheitlich verfügbar

13

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2359331/Datum_Monat_oder_Jahr_oder_Vollschaetzung_Typ?focusedCommentId=34144262

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">

Wie wird denn das Datum im entsprechenden Element im oBDS gebildet? RKI würde bei der Verarbeitung die geschätzten Datumsbestandteile auf einen default setzen. Besteht dennoch ein Regelungsbedarf?

Altmann:

Im oBDS ist der Datumswert nicht mehr abhängig von der Genauigkeit. Es kann also jeder Datumswert mit jeder Genauigkeitsangabe kombiniert werden.

Früher galt ein quasi statistischer Erwartungswert. 15. bei Schätzung des Tages (Monatsgenauigkeit) und 01.07. bei Schätzung des Monats (Jahresgenauigkeit).

Da durch Schätzwerte Datumshierarchien verletzt werden können, gibt es wohl auch die Praxis, alles auf den ersten zu setzen.

14

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2228588/Fernmetastase?focusedCommentId=34504706

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.

Es sollen hier Metastasen zum Zeitpunkt der Diagnose, also nicht im Verlauf erfasst werden. Dabei ist der „Zeitpunkt“ etwas weiter zu interpretieren: alles „im Rahmen des primärdiagnostischen Prozesses“ würde dazugehören. Laut Best-of-Vereinbarung gehören innerhalb von 3 Monaten ab Diagnosedatum diagnostizierte Metastasen (in der Regel) zur Primärdiagnose. Innerhalb dieses Zeitraums wäre dann eine eigene Datumsangabe entbehrlich, danach gehören Metastasen (in der Regel) zum Verlauf, mit entspr. Datum.

Altmann: Danke, vielleicht wäre es gut, daß noch in die Vereinbarungen mit aufzunehmen.

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?

zu genetischen Varianten: Laut Gesetz sollen hier erst Erfahrungen den Registern in der Erfassung dieser Daten ausgewertet werden. Nach § 5 (6) kann das BMG eine Einbeziehung dieser Daten per Rechtsverordnung regeln, „sobald diese Angaben [zu genetischen Varianten] von den Krebsregistern qualitätsgesichert erhoben werden“.

zu Modulitems: Eine Klarstellung, dass für Modulitems grundsätzlich der Status zum Zeitpunkt der Diagnose gemeint, ist sicher sinnvoll, Danke für die Anregung.

Das LDH ist meines Wissens ist nicht nur Parameter für die Metastasierung, sondern auch unabhängiger prognostischer Faktor bei Vorliegen von Fernmetastasen (schlechtere Prognose bei erhöhtem LDH), und ist eher aus diesem Grund mit aufgenommen worden. Die Angabe eines Datums (analog zum PSA-Wert) erscheint jedoch sinnvoll, um Fehlinterpretationen zu vermeiden.

16

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2687035/Bestrahlung?focusedCommentId=34996226

Beginn nennen?

Guter Punkt, es wäre in der Tat klarer, bei ST und SYST von Therapiebeginn zu sprechen.

Wird entsprechend umbenannt. Erledigt.

17

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/30965761?focusedCommentId=41517058

Die KBV bittet darum, in diesem Kontext die schon in der Stellungnahme zur Benehmens-Herstellung Plattform §65c eingebrachten Punkte noch einmal zu prüfen. Dies gilt insbesondere für KIM als Übertragungsweg; KIM zählt zu den sicheren Übermittlungsverfahren im § 311 Absatz 6. Eine TI-Anbindung für die Krebsregister und das RKI ist mittlerweile über die SMC-B-Org der gematik möglich https://fachportal.gematik.de/toolkit/karte-smc-b-org . Perspektivisch könnten dann für alle Beteiligten Lieferungen per Knopfdruck möglich sein.

 

18

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2064400/XML-Schema?focusedCommentId=42205186

IT-Choice (Wronka) - Auffälligkeiten bei Sichtung des Schemas (v3.0.0.7):

  • Einige Typen (z.B. Diagnose_Typ, TNM_Typ) sind derzeit anders als im oBDS-Schema nicht als sequence definiert

  • Beim Typ ST_Typ sind noch keine Pflichtangaben definiert (Element kann leer übermittelt werden)

  • Im Element OPS ist die Angabe einer Version anders als bei den anderen Katalogen mandatorisch.

  • Typ Substanz_Typ: pro Substanz können aktuell beliebig viele ATC-Codes und/oder Bezeichnungen hinterlegt werden (statt ein ATC-Code oder eine Bezeichnung pro Substanz)

 

19

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/16613377/Vorschlag+Technischer+Ablauf+Lieferung+klinischer+Daten+zum+RKI?focusedCommentId=41189383

IT-Choice, Wronka: vermutlich basierend auf KKRTransport v2.0.0 (ggf. kleinere Anpassungen vorsehen, z.B. receiver_ik raus)? Soll eine Signaturbildung erfolgen (Zertifikat auch auf Seiten der KR erforderlich)? PGP-Verschlüsselung gesetzt oder evtl. Anlehnung an Verschlüsselungsverfahren für RÜD-REST?

In KKRTransport ggf. weiteres Item zur Kennzeichnung der “Datenart” (EPI vs. klinisch) vorsehen? (oder wird “gemischt”?)

 

Diskussion

Fragen

1

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/8257538/Technische+Abstimmung?focusedCommentId=10616948

Umgestaltung OP-Typ - Probleme in der Implementierung?

Erledigt

2

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/8257538/Technische+Abstimmung?focusedCommentId=10682487

Gibt es einen dedizierten Kanal für den Dateiaustausch?

Erledigt; ist in Vorschlag behandelt

3

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/8257538/Technische+Abstimmung?focusedCommentId=10682497

Ist es grundsätzlich vorstellbar, die bestehende Systematik auch auf diesen use case anzuwenden?

Erledigt; ist in Vorschlag behandelt

4

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/8257538/Technische+Abstimmung?focusedCommentId=10715214

Ist die Dokumentation der derzeit angewandten Methodik zur Stückelung verfügbar?

Erledigt; ist in Vorschlag behandelt

5

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/7372826/Vereinbarungen+zu+Elementen+des+XML-Schemas?focusedCommentId=11108404

Ist das ein praktikabler Vorschlag für die Kodierung?

Erledigt.

6

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2392323/Weitere+Klassifikation?focusedCommentId=14155783

Vorschlagsliste für weitere Klassifikationen?

Erledigt. Schematyp ist in v7 entfallen

7

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/7372826/Vereinbarungen+zu+Elementen+des+XML-Schemas?focusedCommentId=14778370

Auch bei DCO-Fällen kann anhand der Angaben auf der TB die Diagnosesicherung bekannt sein. Erfassen?

Erledigt

8

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/3145745/datatypeCtrimmed?focusedCommentId=20348929

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

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2392323/Weitere_Klassifikation?focusedCommentId=14155783

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?

Die Einigung auf Wertebereiche kann diese Arbeitsgruppe (leider) nicht leisten, offenbar gibt es dazu diverse Bestrebungen und Vorschläge (ebenso auch eine eigene Arbeitsgruppe?) Daher bleiben auch diese Klassifikationen weiter im Freitext. Die Antwort ist etwas unbefriedigend, wir können das Thema gerne am Freitag aufnehmen.

Kraywinkel: Als Vorschlag kann diese Liste zwar der Orientierung dienen, aber aus unserer Sicht nicht verbindlich vorgeschrieben werden. Insofern können Angaben auch außerhalb der Vorschlagsliste liegen. Ebenso wenig lässt sich bei Freitextangaben definieren, welche Informationen nicht gewollt sind.

Erledigt

10

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/7372826/Vereinbarungen+zu+Elementen+des+XML-Schemas?focusedCommentId=32112642

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

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/7372826/Vereinbarungen+zu+Elementen+des+XML-Schemas?focusedCommentId=32636931

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

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/7372826/Vereinbarungen+zu+Elementen+des+XML-Schemas?focusedCommentId=32407559

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

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/7372826/Vereinbarungen+zu+Elementen+des+XML-Schemas?focusedCommentId=32899074

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

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/7372826/Vereinbarungen+zu+Elementen+des+XML-Schemas?focusedCommentId=32931842

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

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/8781996/Gesetzliche+Grundlage?focusedCommentId=33062914

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

Das Gesetz lässt hier ja ausnahmsweise relativ viel Interpretationsspielraum. Wir wollten uns für den ersten Datensatz auf wesentliche, möglichst klar definierte Items beschränken, die mit einiger Wahrscheinlichkeit auch aussagekräftige Daten erzeugen, und eher zur Diagnose als zur Therapie gehören. Wenn mehr Erfahrungen in den Registern mit diesen Items (und evtl. auch mehr Module) vorliegen, können weitere Items in den Datensatz übernommen werden.

Die Variable „Abstand des Tumorunterrandes zur Anokutanlinie“ nehmen wir noch hinzu. Dann haben wir zumindest eine therapeutisch bzw. prognostisch relevante Information zur Lage des Rektum-Ca.

17

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/16613377/Vorschlag+Technischer+Ablauf+Lieferung+klinischer+Daten+zum+RKI?focusedCommentId=33161218

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

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2424849/Histologie_Typ?focusedCommentId=34275331

Warum fehlen die Sentinel Lk?

Im Gesetz ist nur von der Zahl der untersuchten und Zahl der befallenen LK die Rede, insofern schien uns eine Aufnahme der Sentinel-LK nicht gerechtfertigt.

20

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2097263/Diagnose_Typ?focusedCommentId=34603010

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?

Wir würden hier davon ausgehen, dass für das TNM bei Primärdiagnose in den Registern in der Regel ein Best-of vorliegt (s. auch Krebsregistermanual, Seite 89), dieses sollte übermittelt werden.

21

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/7372826/Vereinbarungen+zu+Elementen+des+XML-Schemas?focusedCommentId=38240258

“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?

Nein, zumindest für die Berechnung von Überlebens- und Rezidivraten gerade nicht. Wenn man diese Angaben berücksichtigen würde, würden Angaben zu Überlebenden (bzw. Pat. mit Rezidiven) selektiv mit höherer Wahrscheinlichkeit mit aufgenommen, als solche von Verstorbenen (oder Pat. ohne Ereignissen). Ein einheitliches bzw. einheitlich ermitteltes „end-of-follow-up“ Datum (abgesehen von Wegzügen und Sterbefällen) schützt also eher vor Verzerrungen. Später liegende Verlaufsereignisse können aber durchaus übermittelt werden, insofern geht so keine Information verloren.

Unerledigt

1

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2359331/Datum+Monat+oder+Jahr+oder+Vollschaetzung+Typ?focusedCommentId=2720121

Datum_Tag_oder_Monat_oder_Jahr_oder_nicht_genau_Typ - nicht vorhanden

Erledigt

2

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2621556/Applikationsart?focusedCommentId=34635778

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

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2228301/Lieferregister_Typ?focusedCommentId=36929537

DKKR MR: Hier bitte noch das DKKR ergänzen!

Das DKKR ist derzeit noch kein Lieferregister im Sinne des BKRG, eine Erwähnung an dieser Stelle würde hier eher verwirren. Wir werden an anderer Stelle darauf hinweisen, dass das DKKR vorerst weiter aggregierte Daten an das ZfKD liefert zur Berechnung der bundesweiten Inzidenz. Eine nachträgliche Aufnahme des DKKR ist jederzeit möglich, auch Anpassungen des Datensatzes, wenn diese notwendig sein sollten.

4

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/7143545/Allgemeine+Vereinbarungen?focusedCommentId=39354370

Volker Arndt: Bitte klarstellen, ob nur Ergänzungen oder der komplette aktualisierte Datensatz (inkl. der akten Bestandsdaten) jedes Mal übermittelt werden soll. Da das Pseudonym jedes Jahr wechselt, braucht es die Übermittlung aller bereits in den Vorjahren übermittelten Daten um jahresübergreifende Zeitreihen abbilden zu können.

Ja stimmt, dass müssen wir auch an dieser Stelle klarer formulieren (Gesamtbestand aller Daten).

5

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/7143545/Allgemeine+Vereinbarungen?focusedCommentId=39387138

Volker Arndt: Gesamtbestand aller Personen-IDs oder Gesamtbestand aller zu übermittelnden Daten (bitte klarstellen)

Gemeint ist der “Gesamtbestand aller zu übermittelnden Daten”.

6

https://plattform65c.atlassian.net/wiki/spaces/P6/pages/7143545/Allgemeine+Vereinbarungen?focusedCommentId=39419906

Volker Arndt: Angabe erforderlich, bis wann der Vitalstatusabgleich im Register vorliegt (Zensurdatum).

Nachtrag: Ich sehe gerade, dass weiter unter “Vitalstatus” vermutlich dieser Punkt aufgegriffen wird.