Historia pytania
Sektor technologii medycznych działa w ścisłych ramach regulacyjnych, które wyprzedzają nowoczesne metodologie Agile. FDA 21 CFR cz. 820 wymaga plików historii projektowania (DHF), które wykazują śledzenie od potrzeb użytkowników do wejść projektowych i wyników weryfikacji. Jednocześnie HIPAA nałożyło rygorystyczne kontrole dostępu na PHI. W miarę jak organizacje wdrażają hybrydowe modele dostarczania, analitycy biznesowi stają przed bezprecedensowym wyzwaniem utrzymania śladów audytu w stylu Waterfall, przy jednoczesnym umożliwieniu szybkości iteracji Agile.
Problem
Tradycyjne podejścia do śledzenia się załamują, gdy historie Jira zmieniają się co dwa tygodnie, ale wymagania Azure DevOps muszą pozostać zamrożone dla baz danych FDA. PHI osadzone w historiach użytkowników stwarza naruszenia zgodności, gdy są widoczne dla nieautoryzowanych członków zespołu. Ręczne macierze śledzenia wymagają 3-5 dni na wygenerowanie, co nie spełnia wymogu odpowiedzi audytora w czasie 4 godzin. Niezgodność między elastycznością Agile a niezmiennością Waterfall zagraża zatwierdzeniu regulacyjnemu i terminom wprowadzenia na rynek.
Rozwiązanie
Zaprojektuj federacyjną ramę śledzenia, wykorzystując Jira jako operacyjny system rejestru i Azure DevOps jako system zgodności regulacyjnej. Wdrażaj automatyczną synchronizację za pomocą integracji REST API, które promują historie do podstawowych wymagań po zobowiązaniu sprintu. Wprowadź szyfrowanie na poziomie pola dla PHI z użyciem schematów bezpieczeństwa wystąpień Jira, połączonych z etykietami klasyfikacyjnymi Azure DevOps. Ustanów niezmienne dzienniki zmian, używając podpisów zatwierdzenia Git, powiązanych z identyfikatorami wymagań, co umożliwia zapytania o dwukierunkowe śledzenie za pośrednictwem centralnego panelem połączonego z obiema platformami.
Wielkośredniej firmy produkującej urządzenia medyczne potrzebowała zintegrować platformę monitorowania pacjentów z ich legacy ERP podczas przygotowań do złożenia wniosku FDA 510(k). Zespół programistyczny pracował w 2-tygodniowych sprintach Agile przy użyciu Jira, ale zespół ds. zapewnienia jakości wymagał specyfikacji wymagań w stylu Waterfall w Azure DevOps, aby zachować DHF wymagany przez 21 CFR cz. 820. Dodatkowo wymagania zawierały PHI z badań klinicznych, co wywołało zabezpieczenia wymagane przez regułę bezpieczeństwa HIPAA. CIO nakazał dwukierunkowe śledzenie w ciągu 4 godzin na prośby audytorów, ale stosowane obecnie podejście ręczne oparte na arkuszach kalkulacyjnych trwało 3 dni i miało 30% dokładności.
Trzy potencjalne rozwiązania pojawiły się w przypadku dylematu dotyczącego śledzenia. Pierwsze podejście obejmowało Ręczne Podwójne Wprowadzanie, w którym analitycy aktualizowaliby zarówno Jira, jak i Azure DevOps dla każdej zmiany. Metoda ta oferowała prostotę i zerowe koszty integracji. Jednak wprowadzało to nieakceptowalne ryzyko błędów ludzkich, z szacowaną stawką rozbieżności wynoszącą 15%, naruszało zasady integralności danych FDA ALCOA+, pochłaniało 40% pojemności analityków i nie mogło spełnić wymogu odpowiedzi audytora w ciągu 4 godzin.
Druga opcja to Migracja Tylko Waterfall, zmuszająca wszystkie zespoły do porzucenia ceremonii Agile i korzystania wyłącznie z Azure DevOps. Choć stworzyło to jedno źródło prawdy i zadowoliło wymagania dokumentacyjne FDA, to zabiłoby prędkość rozwoju przy szacowanej stracie wydajności sprintów wynoszącej 60%. Podejście to narażało się na bunt zespołu, eliminowało korzyści Agile dla cech nieregulacyjnych i marnowało istniejące licencje Jira dla 200 użytkowników.
Trzecie rozwiązanie rekomendowało Automatyczną Synchronizację z Warstwą Zgodności, implementując OpsHub lub niestandardową integrację API pomiędzy Jira i Azure DevOps z algorytmami wykrywania PHI oraz niezmiennym logowaniem audytowym. To podejście utrzymało szybkość Agile, jednocześnie zapewniając zgodność Waterfall, automatyzowało etykietowanie PHI za pomocą wzorców regex, osiągało cel dwukierunkowego śledzenia w ciągu 4 godzin i zachowywało zasady ALCOA+. Wady obejmowały wysokie początkowe koszty integracji wynoszące 50 000 USD, potrzebę zatwierdzenia CISO dla transmisji PHI między systemami i złożoną resolucję konfliktów, gdy historie dzieliły się w ramach wydania.
Zespół wybrał trzecią opcję, ponieważ ryzyko regulacyjne błędów ręcznych przewyższało koszty integracji. Wdrożyli OpsHub Integration Manager z niestandardowym mapowaniem pól, które automatycznie promowało historie Jira do pozycji pracy w Azure DevOps po zobowiązaniu sprintu. System zaszyfrował pola PHI przy użyciu AES-256 i utrzymywał niezmienny łańcuch skrótów w stylu Blockchain dla historii zmian.
Audyt FDA zakończył się sukcesem, bez żadnych obserwacji 483. Zapytania o śledzenie są teraz rozwiązywane w 45 minut. Szybkość rozwoju utrzymana na poziomie 95% przed poziomem wdrożenia. Rozwiązanie stało się standardem przedsiębiorstwa dla regulowanych projektów Agile.
Jak radzisz sobie z PHI w historiach użytkowników, gdy HIPAA wymaga minimalnego koniecznego dostępu, ale Agile popiera przejrzystość?
Wdrożenie maskowania opartego na rolach w Jira za pomocą Schematów Bezpieczeństwa Wystąpień. Tworzenie niestandardowych pól dla PHI, które są wyświetlane tylko dla autoryzowanych ról, przy jednoczesnym zachowaniu opisów historii na poziomie ogólnym. Użyj automatyzacji Jira Service Management, aby redagować PHI z powiadomień e-mail. Utrzymuj osobną przestrzeń Confluence z ograniczeniami widoku dla szczegółowych danych klinicznych, powiązanych za pomocą identyfikatorów historii, a nie wbudowanej treści. To spełnia minimalny standard HIPAA, zachowując jednocześnie szybkość zespołu.
Co odróżnia śledzenie kontroli projektowania FDA od standardowego śledzenia wymagań oprogramowania?
FDA 21 CFR cz. 820 wymaga śledzenia między potrzebami użytkowników, wejściami projektowymi, wyjściami projektowymi, weryfikacją i walidacją, zgodnie z modelem V. W przeciwieństwie do standardowego śledzenia Agile od historii do kodu do testu, kontrole projektowania wymagają formalnych przeglądów projektowych w określonych kamieniach milowych z udokumentowanymi dowodami. Śledzenie musi wykazywać, że każde wejście projektowe jest weryfikowane, a każda potrzeba użytkownika jest walidowana. To wymaga unikalnych identyfikatorów, które utrzymują się w różnych wersjach oraz formalnych przepływów zatwierdzających, które Jira nie może zapewnić bez wtyczek eSignature, takich jak DocuSign dla zgodności GMP.
Jak pogodzić dzielenie historii Agile z zarządzaniem konfiguracją FDA, które traktuje każdą bazę wymagań jako niezmienną?
Użyj wzoru Bazowy i Gałąź. Kiedy historie dzielą się w trakcie sprintu, traktuj oryginalną historię jako rodzica wejścia projektowego, który pozostaje w bazie, a stwórz połączone wyjścia projektowe, odnosząc je do nowych historii. Nigdy nie zmieniaj zamrożonych wymagań; zamiast tego stwórz Zlecenia Zmiany Inżynieryjnej (ECO), które odnoszą się do oryginalnej bazy. W Azure DevOps użyj Ścieżek Obszarów, aby oddzielić zamrożoną pracę od aktywnej, i wdrożyć tagi Git, które odpowiadają podstawom wymagań. To utrzymuje niezmienioną historię wymaganą dla DHF, jednocześnie pozwalając na elastyczność Agile.