Laborinformationssysteme - Bereit für die Anwendung?

Validierung des LIMS als Datendrehscheibe im regulierten Labor

  • Dr. Karl Kleine Karl Kleine ist Diplom-Chemiker (Uni Bonn) und heute als selbständiger Qualitätsmanagementberater im Bereich Labor und Pharma tätig. Er betreut Biotech-Firmen als externer Qualitätsmanager und führt als Auftragsauditor Qualifizierungsaudits von Laboren und anderen Organisationen im Bereich der Arzneimittelentwicklung und der Medizinprodukte (In-vitro Diagnostika) durch. Als Trainer gibt er Schulungen zu diversen Themen im Laborumfeld und unterschiedlichsten Regularien als in-Haus oder offene Schulung. Von 1999 bis 2010 war er verschiedenen Positionen bei Epidauros Biotechnologie AG, Bernried, tätig und für IT-Infrastruktur, Bioinformatik und Qualitätsmanagement zuständig. In dieser Zeit und davor bei Novartis Pharma, Wien, war er regelmäßig, verantwortlich für IT- und Softwareentwicklungsprojekten, einschließlich LIMS, tätig.Dr. Karl Kleine Karl Kleine ist Diplom-Chemiker (Uni Bonn) und heute als selbständiger Qualitätsmanagementberater im Bereich Labor und Pharma tätig. Er betreut Biotech-Firmen als externer Qualitätsmanager und führt als Auftragsauditor Qualifizierungsaudits von Laboren und anderen Organisationen im Bereich der Arzneimittelentwicklung und der Medizinprodukte (In-vitro Diagnostika) durch. Als Trainer gibt er Schulungen zu diversen Themen im Laborumfeld und unterschiedlichsten Regularien als in-Haus oder offene Schulung. Von 1999 bis 2010 war er verschiedenen Positionen bei Epidauros Biotechnologie AG, Bernried, tätig und für IT-Infrastruktur, Bioinformatik und Qualitätsmanagement zuständig. In dieser Zeit und davor bei Novartis Pharma, Wien, war er regelmäßig, verantwortlich für IT- und Softwareentwicklungsprojekten, einschließlich LIMS, tätig.
  • Dr. Karl Kleine Karl Kleine ist Diplom-Chemiker (Uni Bonn) und heute als selbständiger Qualitätsmanagementberater im Bereich Labor und Pharma tätig. Er betreut Biotech-Firmen als externer Qualitätsmanager und führt als Auftragsauditor Qualifizierungsaudits von Laboren und anderen Organisationen im Bereich der Arzneimittelentwicklung und der Medizinprodukte (In-vitro Diagnostika) durch. Als Trainer gibt er Schulungen zu diversen Themen im Laborumfeld und unterschiedlichsten Regularien als in-Haus oder offene Schulung. Von 1999 bis 2010 war er verschiedenen Positionen bei Epidauros Biotechnologie AG, Bernried, tätig und für IT-Infrastruktur, Bioinformatik und Qualitätsmanagement zuständig. In dieser Zeit und davor bei Novartis Pharma, Wien, war er regelmäßig, verantwortlich für IT- und Softwareentwicklungsprojekten, einschließlich LIMS, tätig.
  • Abb. 1: V-Model für den Softwarelebenszyklus in Anlehnung an GAMP5 (Abbildung mit freundlicher Genehmigung durch nabios, München)
  • Abb. 2: Das Projektmanagement Scrum ist ein Beispiel für ein agiles Entwicklungsvorgehensmodell (Quelle: www.scrum.org)
  • Abb. 3: Prozessabbildung mit Schnittstellen für einen Elisa-Test (eigene Abbildung)

Aktuelle Entwicklungen zu Datenformaten und Kommunikationsschnittstellen unabhängig von Herstellern von Geräten oder Laborinformationssystemen (LIMS) eröffnen Möglichkeiten, eigene LIMS-Entwicklungen zu wagen oder zusammen mit LIMS-Anbietern Projekte anzugehen, die schneller und valider in den produktiven Einsatz kommen können. Die Mittel dazu stammen aus der Softwarewelt, nutzen aktuelle Entwicklungswerkzeuge und -konzepte und können die flexible und angepasste Strategie zur Validierung von computergestützten Systemen, die in aktuellen Regularien angeboten wird, nutzen.

Laborautomation und LIMS

Automation der Laborprozesse ist heute eine nahezu unverzichtbare Aufgabe in jedem Labor. Herkömmliches, rein manuelles Arbeiten stößt an Kapazitätsgrenzen. Steigende Dokumentationsanforderungen, überwiegend aus regulatorischen Anforderungen (z. B. Gute Laborpraxis, GLP, oder im akkreditierten Labor) sind zu bewältigen und eine sichere, wenig fehleranfällige Durchführung von Laborprozessen ist ein Ziel, welches rein manuell kaum zu erreichen ist. Dazu kommt der Wunsch in vielen Laboren, alle Information in einem einheitlichen System zu speichern und zu verarbeiten und damit ein Laborinformationsmanagementsystem (LIMS) einzuführen.

Die Konzeption eines LIMS kann sehr unterschiedlich sein, z. B. nur Probenverwaltung und Ergebnisspeicher mit Berichtsfunktion oder ein voll integriertes System vom Probeneingang über alle experimentellen Schritte, Gerätesteuerung, Ergebnistransfers, Berichterstellung und periphere Module zu Vorschriftensammlung, Reagenzien-/Verbrauchsmaterialmanagement und auch Abrechnung. Die Verwendung im regulierten Umfeld erfordert dann den durchgehenden Nachweis, dass alle Module im Rahmen der LIMS-Entwicklung auf Eignung geprüft wurden und gewissermaßen der regulatorische Stempel „Bereit für die Anwendung“ erteilt werden kann.

V-Modell: der Klassiker

Klassischerweise würde nun ein Projektteam gebildet und die LIMS-Konzeption entworfen und nach und nach die Anwenderanforderungen (User Requirements Specification, URS) zusammengestellt. Nach ausführlicher Prüfung würde ein Entwicklerteam die Programmierung vornehmen und parallel das Testszenario für alle Funktionalitäten basierend auf einer Risikobetrachtung entwerfen.

Nach ausführlichen Tests durch die Entwickler oder spezielle Tester würden die Anwender eingebunden, die ihre Akzeptanztests zur Abnahme der Software durchführen und somit den Entwicklungszyklus nach dem V-Model [1] abschließen. Kritische Faktoren für solche Projekte sind u. a. die Güte der Spezifikation und die Zeit vom Wunsch der Anwender für so ein LIMS bis zur Inbetriebnahme.

Entwicklung in den Regularien

Was ist auf der regulatorischen Seite neu und hilft uns, das LIMS einfacher und effizienter zu entwickeln? Hier ist mit dem seit 2016 gültigen Dokument zur “Anwendung der Grundsätze der Guten Laborpraxis auf computergestützte Systeme“ [2] ein Regelwerk in Kraft getreten, welches auf allen Ebenen angepasste Strategien und einen Validierungsaufwand auf Basis von risikobasiertem Denken zulässt und erwartet. Bei kritischen Prozessen und Daten wird die Entwicklung und Validierung so gestaltet, dass die erkannten (und dokumentierten) Risiken bestmöglich vermieden werden. Für Bereiche unseres LIMS, die weniger kritisch bewertet werden, kann eine einfache Spezifikation und Testung ausreichend sein. Diese Denkweise der Regulatoren ist allgemein gültig und nicht GLP-spezifisch und kann ohne Einbuße für anderen Bereiche übernommen werden, z. B. in der Guten Klinischen Praxis (GCP), der Guten Herstellpraxis (GMP) und auch im akkreditierten Bereich (z. B. ISO 17025, ISO 15189, ISO 17020, andere), auch wenn die geltenden Regularien jeweils weniger ausführlich formuliert sind [3-8].

Moderne Softwareentwicklung

Mit Beginn des neuen Jahrtausends hat in der Softwareentwicklung ein Umdenken begonnen, in dem die Schwerpunkte und Schwerfälligkeiten von Softwareentwicklung, z. B. nach dem V-Modell (Abb. 1), durch „agile“ Konzepte überwunden werden sollten. Funktionierende Software wurde als wichtigeres Ziel gesehen, gegenüber ausführlicher Dokumentation und auch die Zusammenarbeit mit dem Anwender während der Entwicklung wurde höher bewertet als vertragliche Zusicherungen. Schließlich wurde gesehen, dass Projekte laufenden Anpassungen unterworfen sein können und ein starres Festhalten an einem einmal gefassten Plan eine Entwicklung eher behindert. Scrum oder Extreme Programming sind methodische Ansätze der agilen Entwicklung (Abb. 2), implizieren aber noch keine Festlegungen auf die Auswahl der Programmiersprache oder die Softwarearchitektur.

Aus regulatorischer Sicht erscheint agiles Entwickeln zunächst ungeeignet, da dem grundlegenden Anspruch nach einem „dokumentierten Nachweis“ der Eignung einer Software für ihren Anwendungszweck („Bereit für die Anwendung“), also unseren verschiedenen Einsatzzwecken und Modulen des LIMS, nicht automatisch genügt wird. Dennoch überwiegen die Vorteile einer agilen Entwicklung. Dazu muss es gelingen, die Anwender nicht erst am Ende eines Projektes vor „vollendete Tatsachen“ zu stellen, sprich die fertige Software auszuliefern. Stattdessen werden im Verlauf des Projekts regelmäßig funktionierende Module, die eigenständig lauffähig und einsatzbereit sind, produktiv gesetzt. Damit steigt bei Anwendern der Erwartungsdruck auf das fertige Produkt und „zieht“ das Projekt vorwärts, während Entwickler aus dem unmittelbaren Feedback Motivation und vor allem die Information erhalten, auf dem richtigen Weg zu sein.

Welche „Zutaten“ unterstützen die Entwicklung?

Ein LIMS-Projekt aus dem Boden zu stampfen ist immer ein Kraftakt und beginnt mit einer Anforderungsanalyse. Da die Anwender ihre Prozesse am besten kennen, müssen sie befragt werden und diese Information strukturiert erfasst werden, um daraus z. B. die benötigten Workflows oder Datenstrukturen abzuleiten. Oft haben Anwender dies bereits beschrieben, z. B. in Experiment-Checklisten, Pipettierschemata oder Auswerte-Tools, oft auf Basis von Excel. Diese sind auf ein bestimmtes Analyseverfahren zugeschnitten und haben somit bereits spezifischen (Modul)-Charakter, enthalten aber auch Elemente, die verallgemeinert auf viele Analyseverfahren anwendbar und gültig sind. Dies ist der Input der Anwender.

Die Einbindung von Geräten mit dem Ziel einer Automation, ist mit den „Hausmitteln“ eines Anwenders allerdings nicht mehr zu machen. Hier muss der Entwickler seine Fachkompetenz einbringen und auf etablierte, z. T. vorgefertigte Konzepte zurückgreifen. Was gilt es hier zu lösen? Einmal die Ansprache eines Instruments („Gerät xy tue dies, tue das!“), d.h. die Kommunikation mit dem Gerät und auf der anderen Seite der Austausch von Information und Daten („Gerät xy, was brauchst Du um zu arbeiten und was kannst Du mir am Ende als Ergebnis mitteilen?“), d. h. die Prozess- und Ergebnisdaten. Für beides gibt es heute frei nutzbare Standards, nämlich SiLA und AnIML.

SiLA und AnIML

SiLA (Standardization in Lab Automation) wurde als offener Standard für die Kommunikation zwischen der Laborsoftware und angeschlossenen Geräten entwickelt. Technisch setzt SiLA dabei auf bewährte Web Service-Technik und HTTP 2, für die eine breite Palette an Werkzeugen zur Verfügung steht. Nicht nur Geräte können so aus dem LIMS heraus angesteuert werden, sondern auch andere Software, z. B. Analyse-Tools für die Integration von Photometerdaten oder statistische Software für komplexe Berechnungen. Der Vorteil von SiLA gegenüber herkömmlichen Konzepten für Gerätekommunikation besteht darin, dass nicht mehr Joblisten oder Dateien über Austauschverzeichnisse als Mittel der Kommunikation dienen. Durch die direkte Kommunikation mittels SiLA-Protokoll kann der Validierungsaufwand bereits konzeptionell reduziert werden, da die Zwischenstufe der Austauschdateien und zugehörigen Ablageorte wegfällt. Die Datenintegrität lässt sich so erhöhen.

AnIML (Analytical Information Markup Language) kann als der große Bruder von SiLA aufgefasst werden, da durch diese Datenformatbeschreibung der komplette analytische Prozess über Messtechniken hinweg in einem weiteren offenen Standard beschrieben werden kann. Der technische Hintergrund der Datenformatbeschreibung AnIML ist XML (Extensible Markup Language), eine textbasierte strukturierte Darstellung von Inhalten und ihren hierarchischen Zusammenhängen. Die Mächtigkeit des Formats ist auf der einen Seite begründet durch die Möglichkeit nicht nur Daten, sondern auch Prozessinformation (wer, wann, was, wieso, womit) aufzunehmen und auch weitere Eigenschaften machen AnIML ein wertvolles, frei verfügbares Tool für LIMS-Projekte. Autorisierung, z. B. durch elektronische Unterschriften, oder auch die Einbettung von Rohdaten von Geräten in das Format empfehlen die Nutzung, damit auch die in regulierten Bereichen geforderten Archivierungsanforderungen nach langfristiger Lesbarkeit der Prozess- und Ergebnisinformation erfüllt werden können. Der langfristige Nutzen schließlich liegt auch darin, dass für die in AnIML archivierten Dateien ein AnIML-Viewer als Software ausreicht und keine proprietären Programme für spätere Lesbarkeit von archivierten Daten mehr nötig sind. Der im Archiv vorzuhaltende „Computer-Zoo“ von alten Geräten mit Spezialsoftware kann somit entfallen.

SiLA und AnIML, einmal für eine Geräte (oder Software)-Anbindung umgesetzt und validiert, können der Grundstein für eine modulare Entwicklung zu einem LIMS werden, da die Konzeption in der eigenen Laborumgebung auf der LIMS-Seite gleich bleibt und nur die inhaltlichen Details für das nächste Gerät implementiert werden müssen. In dieser Wiederverwendbarkeit und dem demzufolge reduzierten Validierungsaufwand liegt der Schlüssel zur Effizienz des Einsatzes der beiden offenen Standards SiLA und AnIML.

Schritt-für-Schritt zum LIMS

Wie wird jetzt aus den genannten Zutaten ein funktionierendes LIMS? Dazu ist es notwendig sich auf eine Vorgehensweise für das Projekt zu einigen. Auch wenn Scrum oder eine andere agile Methode nicht unmittelbare Kompetenz des Entwicklungsteams, bestehend aus Anwendern, Entwicklern und einer Leitung, ist, so kann doch der agile Ansatz durch „Zerlegen“ des Projekts in abgrenzbare und eigenständig verwendbare Module helfen.

Ein Beispiel hierzu könnte ein Elisa-Test (Enzyme-Linked Immunosorbent Assay) sein. Der Prozess einer Reihe von manuellen Pipettier- und Inkubationsschritten wird nach Checkliste durchgeführt und schließlich die photometrische Messung z. B. in einer Mikrotiterplatte und dem entsprechenden Plattenlesegerät mit einer vordefinierten Konfiguration erledigt (Abb. 3). Die erhaltenen Daten werden, z. B. zur Ermittlung der Konzentration einer Probe im Vergleich mit einer Standardkurve, ausgewertet und an den Einsender der Proben ausgeliefert.

In diesem einfachen Beispiel sind alle grundlegenden Aspekte eines Labor-LIMS enthalten: Proben und Referenzmaterial für die Standardkurve, eine Prozessvorschrift und die zugehörige Aufzeichnungsvorgabe (Ausfüllen einer Checkliste), ein Messgerät, welches nach einer Test-spezifischen Konfiguration Daten aufnimmt und als Rohdaten bereitstellt, sowie ein Auswerteschritt, der die berechneten Ergebniswerte erzeugt.
Für unser LIMS kann daraus eine Datenstruktur definiert werden, d.h. welche Parameter und Informationen oder Daten sollen im LIMS abgelegt werden. Mehrere Schnittstellen sind zu definieren, z. B. die Mensch-Maschine-Schnittstelle (manchmal auch als Graphical User Interface, GUI, bezeichnet), d. h. wie interagiert der Operator mit dem LIMS, welche Informationen müssen darin erfasst werden. Eine weitere Schnittstelle ist die Ansteuerung des Photometers (Plattenlesegeräts), wodurch das LIMS dem Gerät das Mikrotiterplattenformat, die Plattenbelegung (Standards, Kontrollen, Proben) mitteilt, sowie die Wellenlänge der Messung und ähnliches. Schließlich müssen die Experimentinformationen einschließlich der Messwerte im Sinne von Rohdaten erfasst werden. Hier kann es sein, dass man ein Gerät benutzt, welches vom Hersteller bereits mit einer SiLA-Schnittstelle und AnIML-Ausgabe ausgerüstet ist oder ein eigenes Tool ist zu programmieren, welches die Ergebnisdaten aus der dem Gerät eigenen Schnittstelle, im einfachsten Fall eine abgelegte Datei, übernimmt und in das AnIML-Datenformat abspeichert. Hier können im selben Atemzug auch die Prozessinformationen durch den Operator ins LIMS eingegeben und aus dem LIMS mit in das AnIML-Format integriert werden. Dadurch könnte begleitende Papierdokumentation (Checklisten) entfallen.
Dieser Anwendungsfall für einen einfachen Test kann, um den dokumentierten Nachweis für seine Eignung zu führen (Validierung), Schritt für Schritt beschrieben und geprüft werden. Risikobasiert können die einzelnen, implementierten Schritte in ihrer Auswirkung bei Fehlern auf das Resultat hin bewertet werden und die „Tiefe“ der Tests im Rahmen der Validierung definiert werden.
So wird aus einem „großen Problem“ ein handhabbares kleineres und die Modularität erlaubt auf der einen Seite die Anforderungen mit dem nötigen Detailgrad zu beschreiben und auch zielgerichtete Tests für den Nachweis der Eignung durchzuführen.

Bei diesem Vorgehen könnte der Ansatz zur Dokumentation so gewählt werden, dass Anforderungen den Modulen entsprechend und Benutzerakzeptanztests aus der Implementierung heraus in der Tiefe, die den Risiken entspricht, entworfen werden. Die Entwickler dokumentieren, z. B. überwiegend im umgesetzten Code und relevante Projekt- und Designentscheidungen durch Besprechungsprotokolle als Teil des agilen Ansatzes.
Vorteile einer solchen Vorgehensweise können die modulweise Einführung eines funktionierenden Produktes sein, die Wiederverwendbarkeit von allen Implementierungsdetails, die die Software allgemein betreffen, z. B. Benutzerrechte, Datensicherungskonzepte. Auch die Anlage von SiLA-Schnittstellen und AnIML-Datenformaten, kann sicher zu großen Teilen für einen weiteren Test wiederverwertet werden und demzufolge auch die Konzeption der Benutzerakzeptanztests.

Ausblick

Die Eigenschaft von AnIML als vollständiges Datenmodell für einen bestimmten Test beinhaltet alle Strukturen, die auch in einer LIMS-Datenbank vorgehalten werden müssen. Es ist demzufolge auch denkbar, dass automatisierte Werkzeuge aus einem oder mehreren AnIML-Dokumenten die zur Erstellung der Datenstrukturen im LIMS notwendigen Informationen aus der AnIML-Formatbeschreibung extrahieren können und dann automatisiert die LIMS-Datenbank befüllen. Hier schließt sich dann der Kreis, dass von Benutzern in Excel-Tools oder anderen Hilfsmitteln viele Prozessinformationen vorstrukturiert worden sind und eine AnIML-Umwandlung dann die Basis auch für eine nachvollziehbare LIMS-Integration sein könnte.

Zusammenfassung

Ein LIMS gilt gemeinhin als das größte IT-Projekt für ein Labor und der Weg dahin, insbesondere in der regulierten Welt, als sehr aufwändig und zeitintensiv. Durch methodische Ansätze (agiles Vorgehen) und technische Mittel (AnIML, SiLA) stehen heute auch für eine Entwicklung im regulierten Umfeld geeignete Mittel zur Verfügung. Schließlich ist auch durch das Dokument OECD No 17 ein skalierbarer und durch Risiko-basierte Bewertungen angepasstes Vorgehen für die Validierung möglich. Dadurch eröffnet sich für große aber auch für kleine Laboratorien die Möglichkeit schrittweise LIMS-Module zu entwickeln und produktiv zu nutzen, ohne das ganze Projekt von A-Z spezifiziert zu haben und als Ganzes umzusetzen.

Danksagung

Burkhard Schäfer von BSSN Software für den anregenden Gedankenaustausch zum Thema und die inhaltliche Prüfung und Kommentierung.

 

Autor
Karl Kleine

 

Kontakt
Dr. Karl Kleine

Simply Quality - Qualitätsmanagementberatung
Weilheim i. OB, Germany
www.simply-quality.de

 

Weitere Beiträge zum Thema!

 

Literatur
[1] Wikipedia (deutsch) „V-Modell“ (https://de.wikipedia.org/wiki/V-Modell, zuletzt besucht 05. August 2019)
[2] OECD No 17: “Application of GLP Principles to Computerised Systems” (ENV/JM/MONO(2016)13, 22. April 2016)
[3] EMA: “Guideline for good clinical practice E6(R2)” (EMA/CHMP/ICH/135/1995, 14. Juni 2017)
[4] EMA: “Reflection paper for laboratories that perform the analysis or evaluation of clinical trial samples” (EMA/INS/GCP/532137/2010; 28. Februar 2012)
[5] EU: „Anhang 11 zum EG-Leifaden der Guten Herstellpraxis – Computergestützte Systeme“ (30. Juni 2011)
[6] PIC/S: “Good Practices for Computerized Systems in Regulated “GXP” Environments” (PI 011-3, 25. September 2007)
[7] FDA: “Guidance for Industry – Part 11, Electronic Records, Electronic Signatures – Scope and Application” (August 2003)
[8] DAkkS: “Leitfaden zum Einsatz von Computersystemen in akkreditierten Laboratorien“ (71 DS 0 004, 21. Dezember 2010)
[9] „Manifesto for Agile Software Development“ (https://agilemanifesto.org/ (zuletzt besucht 06. August 2019)

Kontaktieren

Simply Quality – Qualitätsmanagementberatung


Jetzt registrieren!

Die neusten Informationen direkt per Newsletter.

To prevent automated spam submissions leave this field empty.