Ein genereller Anspruch von OFFIS bei der Entwicklung von Software-Werkzeugen ist der, Entwurf und Implementierung so "generisch" zu halten, dass die Werkzeuge möglichst breit, d.h. auch über den orginären Anwendungsbezug hinaus einsetzbar sind. So war auch bei der Realisierung der sogenannten CARTools für das Niedersächsische Krebsregister angestrebt, diese auch anderen Krebsregistern zugänglich zu machen. Es gibt inzwischen eine Reihe entsprechender Kooperationen und weiterer Anfragen. Drei konkrete Beispiele werden nachfolgend beschrieben.

 

 

 

 

 

CARESS im Hamburger Krebsregister

Im Rahmen eines Kooperationsvertrages zwischen OFFIS und dem Krebsregister Hamburg wird die epidemiologische Auswertungskomponente CARESS seit 1996 auch im Hamburgischen Krebsregister eingesetzt und anhand des Hamburger Datenbestandes evaluiert. Diese Evaluation erfolgt durch vergleichende Auswertung zwischen CARESS und den bisher im Hamburgischen Krebsregister verwendeten Verfahren und Werkzeugen. Langfristig ist vorgesehen, CARESS sowohl zur Beantwortung von Ad-Hoc-Anfragen im Tagesgeschäft als auch in verschiedenen Projekten (etwa zur vermeidbaren Krebssterblichkeit) einzusetzen. In 1997 erfolgte für Hamburg eine Erweiterung von CARESS um verschiedene Verfahren der raumbezogenen Clusteranalyse. Die Arbeiten basierten weitgehend auf Ergebnissen des Symposiums "Methoden regionalisierter Beschreibung und Analyse von Krebsregisterdaten", das im Frühjahr 1996 unter Beteiligung der deutschen epidemiologischen Krebsregister sowie nationaler und internationaler Experten auf dem Gebiet der Krebsepidemiologie, der räumlichen Statistik und der regionalen Datenanalyse in Hamburg stattgefunden hatte.

 

Laufzeit: 01/1996 - 12/1996

 

 

 

 

 

 

 

CARESS im Krebsregister Schleswig-Holstein

Das Krebsregsiter Schleswig-Holstein ist das zweite epidemiologische Krebsregister in Deutschland, in dem das explorative Datenanalyse-Auswertungssystem CARESS eingesetzt wird. Im Rahmen einer Kooperation wurde im November 1999 das System auf der Plattform Windows NT in der Registerstelle des Krebsregister in Lübeck bereitgestellt. Weiterhin wurde ein Raumbezug für das gesamte Bundesland Schleswig-Holstein geschaffen und Importfunktionen für die vorliegenden Geo-Daten realisiert.

Mitarbeiter: Dipl.-Math. Martin Rohde

 

Laufzeit: 09/1999 - 11/1999

 

 

 

 

 

 

 

Kontrollnummergenerierung mit UNICON

Rahmenbedingungen: Die ArbeitsgemeinschaftLeitender Medizinalbeamter hat zur weiteren Umsetzung des Bundeskrebsregistergesetzes die Einführung eines einheitlichen Verfahrens zur Generierung von Kontrollnummern in allen Landeskrebsregistern beschlossen. Mit der Umsetzung dieses Beschlusses wurde OFFIS beauftragt. Das zugehörige Projekt trägt den Arbeitstitel UNICON (Uniform Control Number Generator) und wird von der Deutschen Krebshilfe e.V. finanziell gefördert. UNICON schafft die Grundlage für einen registerübergreifenden Datenabgleich und beruht auf einem von Arbeitsgruppen in Mainz und Oldenburg evaluierten Konzept, welches die Generierung von 22 Kontrollnummern aus einzelnen Attributen der personenidentifizierenden Daten einer Krebsmeldung vorsieht. Die Generierung besteht aus einer Standardisierungsphase, in der Klartextdaten einheitlich aufbereitet werden, und einer Chiffrierungsphase, in der standardisierte Merkmalsausprägungen mit kryptographischen Algorithmen verschlüsselt werden. Die vorgesehene technische Umsetzung dieses Konzeptes wird vom Bundesamt für Sicherheit in der Informationstechnik (BSI) akzeptiert.

 

Voraussetzungen: Notwendige Voraussetzung fürdie Bereitstellung eines Software-Werkzeugs zur einheitlichen Kontrollnummergenerierung ist die Ermittlung der Hard- und Software-Umgebungen der einzelnen Krebsregister. Zu diesem Zweck wurde eine Fragebogenaktion durchgeführt, deren Ergebnis hardwareseitig ein recht homogenes, softwareseitig jedoch ein sehr heterogenes Bild offenbarte. Nach Auswertung der Antworten auf den Fragebogen konnte mit der Entwicklung der Software begonnen werden. Das UNICON-Modul wird für die Betriebssysteme Windows NT, Windows 95, Windows 3.11, MS-DOS, Solaris 2.5 und SCO Unix verfügbar sein. Zur Anbindung an Fremdapplikationen werden sowohl eine Dateischnittstelle als auch eine Funktionsschnittstelle als API angeboten. Das UNICON-Modul soll an verschiedene Applikationen angebunden werden können. Dabei handelt es sich i.a. um Frontends zur Erfassung von Meldungen in der Vertrauensstelle eines epidemiologischen Krebsregisters gemäß Bundesgesetz über Krebsregister. Da in den Landeskrebsregistern vorwiegend Eigenentwicklungen eingesetzt werden, stellt sich die Software-Landschaft hier sehr heterogen dar: Nicht nur die Frontends sind unterschiedlich, auch die verwendeten Entwicklungssysteme differieren. So kommen z.T. die 4GLs von PC-Datenbanken wie Clipper oder Paradox, z.T. C++-Compiler mit Anbindung an RDBMS wie ORACLE zum Einsatz. Daraus ergibt sich für das UNICON-System das Problem, eine Schnittstelle zur Verfügung zu stellen, die von allen relevanten Frontends verwendet werden kann. So erlauben einige Programme einen Aufruf von externen C- oder C++-Routinen, andere jedoch nicht.

 

Systemaufbau: Den kleinsten gemeinsamen Nennerbildet daher eine Dateischnittstelle: Das Frontend schreibt personenidentifizierende Daten in eine Datei, deren Inhalt anschließend vom UNICON-System ausgelesen und verarbeitet wird. Die von UNICON ebenfalls in eine Datei geschriebenen verschlüsselten Kontrollnummern können dann wieder in das Frontend übernommen werden. Würde UNICON lediglich diese (restriktive) Dateischnittstelle anbieten, könnten diejenigen Applikationen mit Fähigkeit zum Aufruf externer Routinen die Low-Level-Funktionalität von UNICON nicht nutzen. Aus diesem Grund wird zusätzlich zur Dateischnittstelle eine Funktionsschnittstelle bereitgestellt. Diese besteht aus mehreren Schichten, die unterschiedlichen Abstraktionsebenen entsprechen, wobei die Routinen der unteren Schichten nach oben durchgereicht werden. Die unterste Schicht kapselt die Funktionalität einer kryptographischen Bibliothek. Diese kann also bei Bedarf ausgetauscht werden, ohne daß die darüberliegenden Schnittstellen davon beeinflußt werden. In der Entwicklungsphase von UNICON wurden verschiedene Kryptobibliotheken evaluiert, insbesondere SecuDE und SSLeay. Letztere wurde aufgrund ihrer weiten Verbreitung, guten Portierbarkeit und freien Verfügbarkeit als am besten geeignet beurteilt. Zusammenfassend sieht die UNICON-Architektur bottom-up wie folgt aus (siehe die Schichtenarchitektur von UNICON ).

 

Das Modul CacrymBase basiert auf dem Dateisystem und enthält Funktionen zum Schlüsselmanagement sowie zur Formatierung von Zeichenketten. Aufsetzend auf einer kryptographischen Bibliothek und CacrymBase, stellt die Low-Level-Kryptographie-Schnittstelle CacrymSimpleCrypt eine Basisfunktionalität zur Verfügung, die u.a. kryptographische Verfahren wie MD5, IDEA oder RSA umfaßt. Auf der nächsthöheren Schicht befindet sich die High-Level-Kryptographie-Schnittstelle CacrymComplexCrypt, die Routinen zur Chiffrierung von Kontrollnummern enthält. Sowohl CacrymSimpleCrypt als auch CacrymComplexCrypt werden von dem Modul UniconGenerator verwendet, das aus personenidentifizierenden Daten Kontrollnummern bildet. UniconGenerator greift dazu auf Funktionen des Moduls UniconBase zurück, welches vorwiegend zur Standardisierung von Eingabedaten dient. UniconGenerator wiederum stellt die Basis für die Dateischnittstelle UniconFile dar. Als Frontend fungiert schließlich die in der Vertrauensstelle des jeweiligen Krebsregisters eingesetzte Applikation, an die das UNICON-System angebunden wurde. Diese Applikation hat aus Gründen der maximalen Flexibilität Zugriff auf alle sechs untergeordneten Schnittstellen. Falls das der Applikation zugrundeliegende Entwicklungssystem eine Verwendung der (komfortablen) Funktionsschnittstellen nicht zuläßt, muß als "Notlösung" auf die Dateischnittstelle zurückgegriffen werden. Die Erzeugung von Kontrollnummern macht langfristig nur Sinn, wenn diese auch zum Record Linkage hinzugezogen werden. Dazu wird heute schon in den Krebsregistern von Rheinland-Pfalz und Niedersachsen das stochastische Abgleichsystem AutoMatch der amerikanischen Firma MatchWare eingesetzt. So greift z.B. das von OFFIS entwickelte Abgleich- und Aufbereitungssystem CARELIS auf AutoMatch zurück. Für den dauerhaften Einsatz von AutoMatch in den Landeskrebsregistern sind allerdings noch rechtliche Fragen zu klären, die Aspekte wie Wartung und Quellcode-Hinterlegung bei einem Treuhänder betreffen.

 

Mitarbeiter: Dipl.-Inform.Holger Hinrichs

 

Laufzeit: 07/1997 - 06/1999