Digitale Dokumentation in der Arzneimittelproduktion

Der Kunde, ein Unternehmen der produzierenden Pharmaindustrie, beauftragte CONET mit der Entwicklung einer Software-Lösung als Ersatz für den bislang papierbasierten Dokumentationsprozess in der Produktion von Medizinprodukten. Die Anwendung muss Produktionsvorschriften berücksichtigen und soll dem Kunden die eigene Erstellung, Verwaltung und Nutzung validierter elektronischer Formulare ermöglichen.

Inhaltsverzeichnis

• Ausgangsituation des Kunden
  • GMP und GAMP als Grundlage
  • Papier-basierte Qualitätsdokumentation
  • Definition von Vorlagen für QA-Dokumente
  • Anforderungen an die Dokumentation
  • Archivierung der Dokumentation
• Aufgabenstellung: Proof of Concept für die Digitalisierung der Qualitätsdokumentation
  • Zielsetzung
  • Projekt und Projektteam
  • Vorgehen des Projektteams
  • Ansatz für die PoC-Lösung
  • Erkenntnisse aus dem PoC
• Hauptprojekt
  • Zielsetzung
  • Projekt und Projektteam
  • Vorgehensmodell
  • Nutzersicht
  • Rohdaten-Handhabung
  • Multi-Tenant-Konzept
  • Technische Umsetzung
  • Projektdokumentation
• Fazit

Ausgangsituation des Kunden

Der Kunde arbeitet in der Arzneimittelproduktion. Im Rahmen der Produktion muss das Unternehmen zahlreiche Qualitätskontrollen durchführen und dokumentieren. Der Gesamtprozess reicht dabei von der Anlieferung von Rohmaterialien bis hin zu Auslieferung des Endprodukts und der Vernichtung von nicht auslieferbaren Produkten. Da Anlagen zur Herstellung von mehreren unterschiedlichen Produkten verwendet werden, muss während sämtlicher Prozesse sichergestellt werden, dass Kreuzkontaminationen mit anderen Rohstoffen oder Betriebsmitteln vermieden oder identifiziert werden.

GMP und GAMP als Grundlage

Die gesamte Produktion und Dokumentation muss gemäß den Vorschriften der Good Manufacturing Practice (GMP) erfolgen. Überall dort, wo automatisierte Systeme zur Produktion, Qualitätssicherung oder Dokumentation eingesetzt werden, gelten die Vorschriften der Good Automated Manufacturing Practice (GAMP). Als Grundlage wurde – wo anwendbar – die Version GAMP 5 2nd Edition referenziert.

Das Unternehmen produziert an verteilten Standorten weltweit Wirkstoffe sowie flüssige und feste Arzneimittel. Die Produktion der einzelnen Standorte wird durch unterschiedliche Produktionssysteme unterstützt. Diese Systeme sind in der Regel standortspezifisch ausgelegt und implementiert.

Papierbasierte Qualitätsdokumentation

Zu Projektbeginn erfolgt die gesamte Qualitätsdokumentation auf Papierbasis. Das umfasst sowohl die Dokumentation in den einzelnen Betrieben (beispielsweise in Produktion und Verpackung) als auch die Qualitätssicherung von Produkten und Dokumentation. Der Kunde verwendet für die Dokumentation ein fälschungssicheres Papier („Blaueckenpapier“ oder „blue corner paper“), das für jeden einzelnen Vorgang situativ von entsprechend berechtigten Mitarbeitenden auf speziellen Druckern ausgegeben wird. Jede einzelne Seite erhält dabei automatisch eine eindeutige Kennung. Die Ausgabe wird mit Datum und Uhrzeit, Kennung der Seiten, Art des Dokumentationsprozesses und Empfänger dokumentiert. Dieser Prozess erfolgt manuell und soll sicherstellen, dass Seiten nicht verloren gehen bzw. der Verlust von Seiten festgestellt und dokumentiert werden kann.

Definition von Vorlagen für QA-Dokumente

Für die einzelnen Dokumentationsschritte existieren Vorlagen, die entsprechend geschulte und berechtigte Mitarbeiter (Editoren) in der Regel in Microsoft Word erstellen. Grundlage der Gestaltung dieser so genannten Master Form Sheets waren und sind die in den zugehörigen Regularien, den Standard Operating Procedures (SOP), vorgegebenen Dokumentationsnotwendigkeiten. Als Master Form Sheets werden die Dokumente bezeichnet, die als Vorlagen für die in der Produktion verwendeten situationsrelevanten Aufzeichnungsdokumente dienen. Diese Vorlagen unterliegen einem formalen Review- und Freigabeprozess. Lediglich freigegebene Dokumente werden veröffentlicht (gültig gesetzt) und dürfen in der Produktion verwendet werden. Diese werden in einem zentralen Repository vorgehalten und können nur von dort gedruckt werden.

Obwohl die SOPs über die gesamte Organisation hinweg gleich sind, liegt die Verantwortung für die Ausgestaltung der zugehörigen Master Form Sheets, deren Review und Freigabe innerhalb der jeweiligen Organisationseinheit. An einem Standort des Kunden existierten zu Beginn des Projektes an einem Standort rund 2.500 verschiedene Dokumenttypen (Master Form Sheets), die in unterschiedlicher Häufigkeit benötigt wurden.

Anforderungen an die Dokumentation

In der Produktion werden die entsprechenden Informationen als so genannte „Rohdaten“ (Raw Data) erfasst. Rohdaten unterliegen einer Reihe von Vorschriften für deren Handhabung. Es muss jederzeit erkennbar sein, welche Person wann einen entsprechenden Dateneintrag in ein Formular getätigt hat. Werden erfasste Daten geändert, muss zusätzlich ein Grund für die Änderung erfasst werden. Einzelne Dokumentationsschritte können die Bestätigung eines zusätzlichen Mitarbeiters erfordern, insbesondere dann, wenn flüchtige Messwerte erfasst werden (4-Augen-Prinzip). Ist ein Dokumentationsschritt vollständig abgeschlossen, kann ein zusätzlicher Qualitätssicherungsschritt notwendig sein, um die formale und inhaltliche Nachvollziehbarkeit sicherzustellen.

Archivierung der Dokumentation

Die gesamte Dokumentation im Zusammenhang mit einer Produktionseinheit (Charge) wird in oben beschriebenem Umfang – also von den Rohstoffen über Produktion und Verpackung bis zur Auslieferung – in einer zusammenfassenden Dokumentation in einem oder mehreren Aktenordnern zusammengeführt und physikalisch für den gesetzlich vorgegebenen Zeitraum (bis zu 30 Jahren) archiviert. Eine Digitalisierung dieser Dokumente erfolgte zum Zeitpunkt des Projektstarts nicht. Sollte die Dokumentation etwa im Rahmen eines Audits eingesehen werden müssen, muss der physikalische Ordner aus einem Lager beigebracht werden.

Aufgabenstellung: Proof of Concept für die Digitalisierung der Qualitätsdokumentation

Zielsetzung

Der Kunde wünschte, die Qualitätsdokumentation zu digitalisieren. Damit sollten die Mitarbeitenden ein Medium erhalten, das ihnen die aufwändige Dokumentation erleichtert und sie bestmöglich (im Rahmen der Vorgaben von GAMP) unterstützt. Über die digitale Verfügbarkeit von Rohdaten und Metadaten (beispielsweise Durchlaufzeiten) sollten sich zudem prozessuale Schwachstellen erkennen und grundsätzliche Kennzahlen ableiten lassen.

Gleichzeitig wollte das Unternehmen im Sinne der Nachhaltigkeit den Verbrauch an Papier wesentlich reduzieren.

Mithilfe eines Proof of Concept (PoC) sollten Möglichkeiten eruiert werden, in welcher Art und in welchem Umfang die bestehenden Dokumentationsanforderungen realistisch digitalisiert werden können.

Projekt und Projektteam

Als Projektvorgehen wählte der Auftraggeber einen agilen Ansatz im Sinne der Scrum-Methodik.

Das CONET-Projektteam setzte sich aus einem Software-Architekten (0,5 FTE), zwei Anwendungsentwicklern (1,5 FTE), einem Anforderungsmanager (0,5 FTE) und einem Scrum Master (0,5 FTE) zusammen. Die Kundenseite stellte den Product Owner und die Subject Matter Experts (SME).

Das gesamte Team wurde intensiv von dem UX/UI-Team von CONET in der Gestaltung der User Experience begleitet und beraten.

Vorgehen des Projektteams

Das CONET-Projektteam verschaffte sich in intensiven Gesprächen mit den Mitarbeitenden in Produktion und QA sowie über Vor-Ort-Besuche in den unterschiedlichen Betrieben eines Standorts einen Überblick über die Gegebenheiten. Der Kunde hatte zuvor einzelne Prozessschritte identifiziert, die als gute Grundlage für einen PoC verstanden wurden. Über die Methode des „Apprenticing“ („Über-die-Schulter-schauen“) konnte das Team nicht nur Inhalt und Aufbau einzelner Master Form Sheets, sondern auch die konkrete Anwendung und die Rahmenbedingungen in der Realität der Produktion nachvollziehen.

Ansatz für die PoC-Lösung

Für den PoC wählte das Projektteam den Ansatz einer Desktop-Anwendung für Windows 10 oder höher auf Basis von Microsoft .NET und WPF.

Für jeden Formulartyp vereint eine individuelle Anwendung damit die gesamte Logik des Ausfüllens (inklusiv aller Restriktionen), unterstützende Funktionen (Datenabfrage, Berechnungen) und Funktionen zur abschließenden Qualitätssicherung. Einzelne Schritte des Ausfüllens werden automatisch im Sinne eines Audit Trail aufgezeichnet. Dadurch entfällt die Notwendigkeit, dass Mitarbeitende jeden Dokumentationsschritt wie zuvor beschrieben separat unterzeichnen müssen.

Die Datenhaltung erfolgt dabei in der AWS Cloud mit den Diensten DynamoDB und S3.

Erkenntnisse aus dem PoC

Während des PoCs hat das Entwicklerteam sechs Master Form Sheets aus den vier Betriebsbereichen Solida (Feststoffbetrieb), Parenteralia (Flüssigstoffbetrieb), Verpackung und Qualitätssicherung umgesetzt.

Die gewählte Vorgehensweise im Sinne einer agilen Projektdurchführung hat sich dabei hervorragend bewährt. Die hochgradige Integration des Fachpersonals aus den einzelnen Betrieben war nicht nur dringend notwendig, sondern für die Qualität des PoC wesentlich.

Es wurde deutlich, dass der gewählte Ansatz, pro Master Form Sheet eine individuelle Anwendung zu implementieren, wegen der Menge der existierenden Master Form Sheets und der individuellen Anforderungen des Kunden nicht zielführend war. Vergleichbare Funktionen in den einzelnen Anwendungen wären zwar grundsätzlich wiederverwendbar gewesen, hätten aber bei Änderungen in jeder einzelnen Anwendung angepasst werden müssen. Mit der nativen Windows-Lösung legte sich der Kunde zudem auf eine Client-Plattform fest, was als langfristiges Risiko eingeschätzt wurde.

Entscheidend war schließlich, dass die Erstellung von neuen oder die Anpassung bestehender Master Form Sheets nicht mehr durch die Editoren würde erfolgen können, sondern das Unternehmen sich langfristig von der Verfügbarkeit entsprechender (externer) Software-Entwickler abhängig machen würde.

Dennoch wurde der Gesamtansatz, die Dokumentation zu digitalisieren, als realisierbar und dringend notwendig identifiziert.

Hauptprojekt

In der kritischen Auseinandersetzung mit diesen Erkenntnissen erarbeitete das CONET-Projektteam einen geänderten Ansatz, der schließlich als Grundlage des Hauptprojekts definiert wurde.

Zielsetzung

Mit dem neu gewählten Ansatz sollte eine Anwendung geschaffen werden, die es den Editoren auf Kundenseite ermöglicht, Master Form Sheets mit entsprechenden Bedienkomponenten zu erstellen. Darüber hinaus sollte der gesamte Freigabe- und Veröffentlichungsprozess über die neue Anwendung gesteuert werden.

Auf dieser Basis sollte das Erzeugen neuer Formulare für die Dokumentation im Betrieb ermöglicht, die GAMP-konforme Dokumentation und Genehmigung von Rohdaten abgebildet und deren Prüfung und Freigabe sichergestellt werden.

Projekt und Projektteam

Für das Projekt wurde – wie schon beim PoC – agiles Vorgehen auf Basis der Scrum-Methodik festgelegt.

Das CONET-Projektteam bestand nach einer Anlaufphase aus einem Cloud-Architekten, vier Frontend-Entwicklern, drei Backend-Entwicklern, einem Cloud Engineer, zwei Anforderungsmanagern, einem UX/UI-Berater und einem Projektleiter. Im späteren Verlauf wird das Projekt um zwei Personen ergänzt, die sich speziell mit den GxP-Anforderungen des Kunden auseinandersetzten und für die entsprechend konforme Dokumentation verantwortlich zeichnen.

Auf Kundenseite war der Product Owner angesiedelt. Diesem stand eine sich nach Bedarf dynamisch anpassende Auswahl von SME aus den Betrieben, vor allem aus der Qualitätssicherung, zur Seite.

Im Projektverlauf wurde das Potential und die Bedeutung dieser Lösung für die gesamte weltweite Organisation des Kunden ersichtlich und wahrgenommen. Daher ging die Gesamtverantwortung für das Projekt nach drei Vierteln der Laufzeit von der lokalen Kundenorganisation auf die globale Organisation über. Damit sollte sichergestellt werden, dass das System weltweit eingesetzt werden kann und nicht durch lokale Spezifika eingeschränkt wird.

Vorgehensmodell

Neben den fachlichen Erfahrungen und Erkenntnissen aus dem PoC wurde die Anforderung des Kunden in intensivem Austausch mit den SME erfasst und dokumentiert. Als zentrales Dokumentationsmedium nutzte das Projekt Azure DevOps, das zusätzlich die Aktivitäten der Software-Entwickler steuernd unterstützte und die direkte Nachvollziehbarkeit zwischen Anforderung und entsprechend implementiertem Code ermöglichte.

Die Scrum-Zeremonien Review, Retrospektive und Planung sowie ein mehrstufiges Refinement („Grooming“) boten eine hervorragende Plattform, um den steten Projektfortschritt zu präsentieren und zu diskutieren, aber auch, um neue Erkenntnisse und Ideen zu generieren und als Kandidaten für die zukünftige Entwicklung zu erfassen.

Nutzersicht

Aus Nutzersicht stellt sich die Lösung als IT-System auf Basis von folgenden drei Modulen dar:

• Der Designer stellt alle Funktionen bereit, die Editoren benötigen, um Master Form Sheets zu erstellen. Die Anwendung stellt eine Auswahl an Funktionskomponenten (wie Texteingabe und Checkbox-Gruppen) und Strukturierungskomponenten (wie Überschriften, Trenner, und Gruppierung) zur Verfügung, aus denen der Anwender ein entsprechendes Dokument per Drag-and-Drop zusammenstellen kann. Die Komponenten können dann je nach Anforderung durch den Editor konfiguriert werden. Das Werkzeug steuert die zusätzlichen Abläufe „Review“ (Qualitätsprüfung), „Approval“ (mehrstufige Freigabe), „Publishing“ (Gültig-Setzen, Veröffentlichung) und „Invalidation“ (Rücknahme, Ungültig-Setzen). Die Aufgaben im Design, Review und Approval können durch die jeweils berechtigten Mitarbeiter an andere Personen delegiert werden.
• Das Modul Forms nutzt die veröffentlichten Master Form Sheets, um daraus neue Formulare zu generieren und den Mitarbeitenden in der Produktion (Operator) das Erfassen von Informationen zu ermöglichen. Jedes digitale Formular ist dabei eindeutig identifiziert. Das digitale Formular deckt Funktionen ab, die Restriktionen für Eingaben durchsetzen und die einzelnen Eingabeschritte im Sinne eines manipulationssicheren Audit Trail dokumentieren. Die Logik zusätzlicher Funktionen wie die 4-Augen-Prüfung und die abschließende Qualitätskontrolle und Freigabe eines Formulars sind ebenso verfügbar.
• Die Cloud ist die verbindende technische Komponente, in der sämtliche Daten gespeichert werden und die gesamte Logik des Backend implementiert ist.

Ein Command Line Interface (CLI) unterstützt speziell legitimierte Systemoperatoren dabei, sämtliche Aktivitäten innerhalb der Systeme auch per Kommandozeile auszuführen, um Problemsituationen zu beheben. Dabei steht dem Systemoperator eine größere Auswahl an Funktionen zur Verfügung als für andere Anwender über die Benutzerschnittstelle (UI) nutzbar. Diese Eingriffe werden aus einem strengen Support-Prozess heraus getätigt und durch das System aufgezeichnet.

Rohdaten-Handhabung

Das wesentliche Augenmerk der Anforderungsdefinition und der Implementierung lag auf der Handhabung sensibler Rohdaten. Um den strengen Anforderungen gerecht zu werden, entwickelte das Team von Beginn an Lösungen, die Erfassung der Metadaten eines jeden Dateneintrags (Benutzer, Zeitstempel, Datenfeld, alter Wert, neuer Wert) zu automatisieren. Diese Informationen werden in zeitlicher Abfolge in einem manipulationssicheren Audit Trail gespeichert.

Die gesamte Ablauflogik von Formularen wird durch die verwendeten Komponenten (und deren Zusammenarbeit) so gesteuert, dass die Eingabefolge von Informationen konsistent gehalten wird.

Multi-Tenant-Konzept

Eine zentrale Anforderung seitens des Kunden war es, den einzelnen Standorten weltweit ein einheitliches Benutzererlebnis zu bieten, die Standorte aber datenseitig voneinander zu trennen. Während die Anwendung zentral zur Verfügung gestellt wird – alle Standorte nutzen dieselbe Code-Basis –, werden die Datentöpfe für jeden Standort individuell erzeugt und gepflegt (Tenant). Die Struktur der Datentöpfe bleibt dabei weltweit einheitlich. Der Benutzer meldet sich über eine Tenant-spezifische URL am System an und bekommt damit die seiner Rolle im jeweiligen Tenant entsprechenden Zugriffsrechte.

Technische Umsetzung

Die technische Umsetzung der Plattform folgte modernen Cloud-nativen Konzepten und der 12-Factor-App-Methode (https://12factor.net/de/). Die gesamte Backend-Infrastruktur wird dabei in mehreren AWS Accounts betrieben und automatisiert als Infrastructure-as-Code aufgesetzt.

Dabei basiert die Lösung auf einer „serverless“ Microservices-Architektur, um ein Maximum an Skalierbarkeit und Kosteneffizienz zu erzielen. Außerdem setzt die Realisierung konsequent auf Managed Services. Natürlich kann jeder Microservice individuell verteilt, skaliert und überwacht werden.

Da das System bei AWS, einem Hyperscaler, gehostet wird und über das öffentliche Internet erreichbar ist, wurde während der Entwicklung konsequent auf Sicherheit geachtet. Dies schloss beispielweise die Nutzung eines sicheren Entwicklungsprozesses ein, beinhaltete aber auch mehrfache Security Audits.

Zu den technischen Highlights zählen:

• asynchrone Kommunikation per WebSockets
• auditierbare Datenspeicherung durch kryptografische Verkettung der gespeicherten Events
• Authentisierung mittels OpenID Connect und OAuth
• Command Query Response Segregation (CQRS)
• Event Sourcing
• Event-basierte Kommunikation zwischen Microservices (SQS, SNS)
• NoSQL-basierte Persistenz (DynamoDB, Elasticsearch/Opensearch, S3)
• REST-basiertes, idempotentes API
• Single Sign-on gegen Azure Active Directory

Zur Umsetzung wurden unter anderem die folgenden Techniken und Programmiersprachen eingesetzt:

• .NET
• Angular
• AWS
• Azure DevOps
• C#
• Docker
• Git
• HTML/CSS/SCSS
• JavaScript/ECMAScript
• PowerShell
• Svelte
• Terraform
• Typescript

Projektdokumentation

Im gesamten Projektverlauf stellte das Projektteam sicher, dass die Dokumentation der Implementierung, insbesondere die Definition der Anforderungen, bereits den Anforderungen an die Vorgaben der Computer System Validation entsprachen.

Mit der Übergabe einzelner Inkremente und ganzer Software-Versionen konnte das Team die nach der Good documentation practice (GDP) vorgesehenen Dokumente, insbesondere die fachlichen und technischen Dokumentationen, automatisch aus dem Azure DevOps extrahieren. Dafür kam in diesem Projekt die Systemerweiterung Smart Docs von Modern Requirements zum Einsatz.

Die so erzeugten Dokumente konnten anschließend ohne weitere Bearbeitung oder Formatierung in den Electronic Document Management System Approval Process des Kunden eingespeist und durch alle beteiligten Parteien freigegeben werden.

Fazit

Mit der neuen Plattform hat das Unternehmen eine Lösung zur Verfügung, die einerseits dem Wunsch nach intuitiver Bedienbarkeit gerecht wird, andererseits aber auch hinsichtlich der Richtlinien von GMP und GAMP vollständige Compliance garantiert. Das tiefe fachliche Verständnis, dass sich das CONET-Team über die Projektzeit erarbeitet hat, schlägt sich in unzähligen Detailaspekten nieder, die das Arbeiten mit der Lösung einfacher und komfortabler machen. Die technische Expertise des Teams ermöglicht es, diese Lösung auf ein technisches Niveau zu heben, die nicht nur „state of the art“, sondern bereits jetzt für zukünftige Weiterentwicklungen offen ist.

Der Kunde hat mit dieser Lösung einen Weg eingeschlagen, der in der Branche einmalig ist, den strengen Richtlinien von GMP und GAMP gerecht wird und der problemlos und ohne erheblichen Aufwand für eine weltweite Nutzung skaliert.

Der professionelle und engagierte Umgang des CONET-Teams mit den sich ständig entwickelnden oder ändernden Anforderungen des Kunden war ausschlaggebend für den Fortschritt und den Erfolg der Initiative. Die Identifikation des Teams mit den Problemstellungen des Kunden geben diesem stets das Gefühl, gehört und verstanden zu werden. Das CONET-Team ist ob seiner tiefen fachlichen Expertise darüber hinaus jederzeit in der Lage, den Kunden richtungsweisend zu beraten.

War dieser Artikel hilfreich für Sie? Oder haben Sie weiterführende Fragen zum Thema Software-Entwicklung? Schreiben Sie uns einen Kommentar oder rufen Sie uns gerne an.