Portfolio – Ausgewählte Arbeiten
🎯 Auf einen Blick
- Fokus: Beispiele für Connector‑Arbeit in Medizintechnik und Gesundheitswesen mit Schwerpunkt auf Struktur, Dokumentation und Prozessen.
- Umfang: Anonymisierte Fälle, die zeigen, wie ich technische Inhalte, Abläufe und Research‑Übersichten klarer und nutzbarer mache.
- Was dies nicht ist: Kein vollständiges Projektverzeichnis und keine Kundenreferenzliste – es geht um Arbeitsweisen, nicht um Namen.
Diese Seite bietet einen kurzen, webtauglichen Überblick über ausgewählte Arbeiten als Connector und technische:r Autor:in im Umfeld von Medizintechnik und Gesundheitswesen. Die Beispiele basieren auf einem internen Portfolio‑Arbeitsbereich, in dem ich detailliertere Notizen, Versionen und Reflexionen pflege.
Der Schwerpunkt liegt auf Struktur und Anwendungsfall, nicht auf der Nennung konkreter Organisationen.
Language / Sprache / Sprog
English – Portfolio – Selected Work · Deutsch (aktuell) · Dansk – Portfolio – Udvalgte arbejder
Wie dieses Portfolio aufgebaut ist
Jedes Beispiel folgt vier Fragen:
- Kontext – In welcher Umgebung und mit welcher Art Problem haben wir es zu tun?
- Meine Rolle – Wo habe ich beigetragen, und wofür lag die Verantwortung ausdrücklich nicht bei mir?
- Was ich getan habe – Konkrete Struktur‑, Dokumentations‑ oder Prozessarbeit.
- Ergebnis – Was wurde für das Team klarer, einfacher oder robuster?
Ausführlichere Arbeitsstände (inklusive Entwürfen, alternativen Strukturen und Lernnotizen) halte ich in einer internen Portfolio‑Datenbank.
Beispiel 1 – Technische Beschreibung für unterschiedliche Zielgruppen strukturieren
Kontext
Ein kleines MedTech‑Team hatte eine über die Zeit gewachsene technische Beschreibung eines Geräts mit zugehöriger Software. Der Text mischte:
- Implementierungsdetails,
- regulatorisch relevante Aussagen,
- und interne Designnotizen.
Das Dokument ließ sich schwer als gemeinsame Referenz für Entwicklung, QA/RA und Management nutzen.
Meine Rolle
Unterstützung bei Struktur, Klarheit und Zielgruppen‑Trennung, nicht bei klinischer oder regulatorischer Freigabe. Die Verantwortung für inhaltliche und regulatorische Korrektheit lag bei internen RA/QA‑Rollen.
Was ich getan habe
- Aufteilung des vorhandenen Dokuments in eine Kernbeschreibung und zwei Anhänge (implementierungsnahe Notizen und interne Design‑Begründungen).
- Einführung einer klaren, wiederholbaren Gliederung: Übersicht, Verwendungszweck, Systemkomponenten, Informationsflüsse, sicherheitsrelevante Aspekte.
- Kennzeichnung von Abschnitten mit besonderer Relevanz für Risikobetrachtung und regulatorische Dokumentation, damit RA/QA sie leichter referenzieren kann.
- Vereinfachung zentraler Textpassagen, sodass sie auch außerhalb des Kernentwicklungsteams verständlich sind.
Ergebnis
- Eine zentrale technische Beschreibung, die sowohl für Engineering als auch für RA/QA nutzbar ist.
- Leichtere Wiederverwendung in verwandten Dokumenten (z. B. Input für Risikobetrachtungen, interne Schulungen).
- Weniger Reibung in Diskussionen, da Struktur und Terminologie nun geteilt sind.
- Reviews konnten sich stärker auf Inhalte und Entscheidungen konzentrieren, statt auf das Auffinden von Informationen im Dokument.
Beispiel 2 – Dokumentationsprozess vom Impuls bis zum freigegebenen Dokument sichtbar machen
Kontext
In einer Organisation mit mehreren qualitätsrelevanten Dokumenten gab es kein gemeinsames Bild davon,
- wie ein neuer Dokumenttyp angestoßen wird,
- wer ihn prüfen und freigeben muss,
- und wie Änderungen über die Zeit gehandhabt werden sollen.
An den Schnittstellen zwischen Entwicklung, Qualität und Management kam es zu Verzögerungen und Unklarheiten.
Meine Rolle
Connector und Struktur‑Unterstützung: keine Entscheidungsbefugnis über das QMS selbst, aber Verantwortung dafür, Abläufe und Rollen transparent zu machen.
Was ich getan habe
- Kurze, strukturierte Gespräche mit Schlüsselrollen (Entwicklung, QA/RA, Management), um ihre jeweilige Sicht auf den Prozess zu erfassen.
- Erstellung einer einfachen Prozessdarstellung vom „Bedarf für ein Dokument“ bis zum „freigegebenen, abgelegten und kommunizierten Dokument“.
- Klärung von Rollen nach RACI‑Logik (wer initiiert, wer entwirft, wer prüft, wer freigibt, wer informiert werden muss).
- Beschreibung von Entscheidungspunkten und Eskalationswegen so, dass sie in bestehende QM‑Dokumentation eingebettet werden können.
Ergebnis
- Eine gemeinsame, visuelle Prozessbeschreibung für Onboarding und interne Abstimmung.
- Klarere Erwartungen, wer zu welchem Zeitpunkt eingebunden sein muss.
- Eine praktische Grundlage für spätere QMS‑Arbeit, ohne vorzugeben, dass das gesamte System bereits umgebaut sei.
- Die Darstellung konnte in Audit‑Vorbereitung direkt verwendet werden, ohne dass der Prozess jedes Mal neu erklärt werden musste.
Beispiel 3 – Zielgerichtete Research‑Übersicht zu einem neuen MedTech‑Thema
Kontext
Ein Team musste die regulatorischen und strukturellen Implikationen eines neuen Themas (z. B. eine neue softwaregestützte Funktion) verstehen, hatte aber nur begrenzte Kapazität für eine erste Desk‑Research‑Phase.
Meine Rolle
Bereitstellung einer strukturierten Erstkarte des Themenfelds, keine Rechtsberatung oder abschließende regulatorische Bewertung.
Was ich getan habe
- Identifikation und Sammlung relevanter Normen, Leitfäden und Positionspapiere.
- Erstellung eines kurzen, referenzierten Übersichtsdokuments mit:
- Kernaussagen pro Quelle,
- einer einfachen Vergleichstabelle,
- und Hinweisen darauf, worauf die Quellen jeweils den Schwerpunkt legen (Risiko, Prozess, Dokumentation, Rollen).
- Hinweise darauf, wo diese Informationen bestehende interne Prozesse berühren könnten (z. B. Dokumentation, Risikodenken, Übergaben zwischen Rollen).
Ergebnis
- Ein klarer Startpunkt für Gespräche des Teams mit eigenen RA/QA‑Fachpersonen und externen Berater:innen.
- Weniger Zeitaufwand für das „Suchen der richtigen PDFs“, mehr Zeit für die Frage, wie darauf reagiert werden soll.
- Eine dokumentierte Basis, die später erweitert oder angepasst werden kann, wenn sich das regulatorische Umfeld weiterentwickelt.
- Externe Beratung konnte direkt auf einer gemeinsamen, referenzierten Übersicht aufsetzen, statt auf mehreren losen Notizen.
Interne Portfolio‑Datenbank
Hinter diesem öffentlichen Überblick pflege ich in Notion eine interne Portfolio‑Datenbank mit Entwürfen, alternativen Strukturen und Lernnotizen.
Für ein erstes Gespräch ist weniger die Anzahl der Projekte entscheidend als die Frage, ob die hier gezeigten Arbeitsweisen zu Ihrer Situation passen.
Bei Bedarf kann ich anonymisierte Beispiele in einem Gespräch detaillierter erläutern.