In der letzten Sitzung des CDISC-SEND-Kernteams diskutierten wir über Anti-Drug-Antikörper-Daten (ADA) und deren Darstellung in SEND. Wir diskutierten darüber, was wir empfehlen würden, und das ist der Grund für meinen Konflikt.
Der Purist in mir möchte "Custom Domain!" schreien. Der Pragmatiker weiß, dass die Branche dafür noch nicht bereit ist. Ich möchte die Tatsache herausschreien, dass wir bei Instem die Werkzeuge und Dienstleistungen haben, um benutzerdefinierte Domains zu unterstützen; aber ich darf CDISC nicht für solche Werbung benutzen. Ich möchte jedem, der mir zuhört, sagen, dass wir die Produkte und Dienstleistungen zur Verfügung haben, die der Industrie helfen, diese benutzerdefinierten Domains zu erstellen, aber das würde über das Ziel hinausschießen. Als Mitglied des CDISC SEND Core Teams muss ich mir also eingestehen, dass die Industrie einfach noch nicht so weit ist.
Ich bin also hin- und hergerissen.
Dies ergab sich aus der Arbeit der FDA CBER und ihrem jüngsten Pilotprojekt des SEND-Standards. Sie haben ein echtes Bedürfnis, ADA in SEND zu sehen. In der aktuellen Version von SEND gibt es keinen Bereich für diese Ergebnisse, aber SDTMIG (der Implementierungsleitfaden für das klinische Äquivalent von SEND) hat einen solchen Bereich. Sie heißt IS - Immunogenicity Specimen Assessment; sie ist jedoch nicht im SENDIG enthalten.
PHUSE hat sich bereits mit dieser Situation befasst und zwei Lösungen gefunden, die sich so zusammenfassen lassen, dass sie zeigen, wie man entweder ADA-Daten in die bestehende LB-Domäne zwangsweise einpasst oder IS aus SDTMIG entleiht und als benutzerdefinierte Domäne in ein SEND-Paket einfügt. (Wahrscheinlich erweise ich den Autoren einen Bärendienst, wenn ich ein ganzes White Paper auf einen einzigen Satz reduziere).
An dieser Stelle werde ich die Frage, ob dies tatsächlich in den Anwendungsbereich fällt oder nicht, zwar zur Kenntnis nehmen, aber völlig ausklammern; und ich weiche den Fragen rund um die Kompatibilität der SDTM-Versionen und die Tatsache, dass CDISC eine IS-Domäne zu SEND 3.2 hinzufügt, völlig aus. Wenn Sie sich damit befassen wollen, dann schreiben Sie mir eine E-Mail an instem denn ich würde die Diskussion gerne in diese Richtung lenken!
Ich bin also hin- und hergerissen; und ein großer Teil dieses Konflikts ist darauf zurückzuführen, dass ich es genieße, an der Spitze von SEND zu stehen. Die "richtige" Antwort lautet: Da diese Daten für die Sicherheitsbewertung wichtig sind, sollten sie in SEND dargestellt werden. Da dies der Fall ist, ist die IS-Domäne besser geeignet als eine missbrauchte LB-Domäne. Im Großen und Ganzen ist die Industrie jedoch nicht auf dem neuesten Stand der Technik, und daher verfügen viele wahrscheinlich nicht über die erforderlichen Instrumente oder Fachkenntnisse. Das ist nicht überraschend, denn ich denke, dass wir bei CDISC bessere Arbeit bei der Bereitstellung der Informationen hätten leisten können. Wir haben einen Implementierungsleitfaden, der zwar benutzerdefinierte Domänen enthält, aber an keiner Stelle als Anleitung für die Implementierung einer benutzerdefinierten Domäne dient. Da dies der Fall ist, werde ich als CDISC-Freiwilliger meine Hand heben und meinen Teil der Verantwortung dafür übernehmen.
An der Spitze zu stehen bedeutet, dass wir die Werkzeuge und Dienste bereits entwickelt haben. Unsere Submit™-Software erstellt und nutzt nicht nur solche Domains, sondern unsere SEND Explorer-Software kann sie auch visualisieren, und unser Serviceteam kann sie erstellen und überprüfen. Wir haben jetzt also alles im Griff. Aber ich weiß, dass das auf viele andere nicht zutrifft.
Ich bin also immer noch hin- und hergerissen.
Das soll nicht nach schamloser Eigenwerbung klingen, nach "schaut, was wir können"; es geht um die persönliche Herausforderung, meine CDISC-Verantwortung ernst zu nehmen und sicherzustellen, dass ich meine privilegierte Position, einen Sitz am SEND-Leadership-Tisch zu haben, nicht überschreite.
Bis zum nächsten Mal
