System dla laboratorium: jak przekazać próbkę między etapami pracy

Próbka trafia do laboratorium z dokumentem zlecenia. Jedna osoba sprawdza oznaczenie, druga przygotowuje materiał do kolejnego etapu, a trzecia potrzebuje informacji, czy zadanie może już rozpocząć. Jeśli status znajduje się na kartce, w arkuszu i w trzech wiadomościach, łatwo stracić czas na ustalenie podstaw: co zostało przyjęte, gdzie się znajduje i kto ma podjąć następną decyzję.

System dla laboratorium może połączyć te informacje z konkretną próbką i pokazać historię jej przekazania. Nie rozstrzyga sam, jak należy przeprowadzić badanie ani czy laboratorium spełnia wymagania akredytacyjne. Zakres zapisu i sposób pracy trzeba ustalić dla rodzaju materiału, stosowanej procedury i odpowiedzialnych osób.

Przykład w artykule jest fikcyjny i dotyczy organizacji obiegu próbek. Nie opisuje diagnozy ani gotowej procedury laboratoryjnej. Podobne pytania mogą pojawić się w laboratorium badawczym, przemysłowym lub medycznym, lecz nie należy zakładać, że wszystkie te miejsca mają identyczne wymagania.

Nadaj próbce tożsamość, którą rozumie cały proces

Zacznijcie od drogi pojedynczej próbki: skąd pochodzi, kto ją przyjmuje, jakie zlecenie jej dotyczy i co musi się wydarzyć przed rozpoczęciem pracy. Następnie ustalcie, jak próbka jest oznaczana oraz jak pracownik sprawdza, że opis w systemie odnosi się do właściwego pojemnika. Sam numer na ekranie nie rozwiązuje problemu, jeśli w miejscu pracy nie ma sposobu jego odczytania i porównania.

W fikcyjnym laboratorium materiał trafia od kilku zakładów. Każdy używa własnego oznaczenia, a laboratorium nadaje dodatkowy identyfikator wewnętrzny. Oba mogą być potrzebne: jeden pomaga znaleźć zlecenie po stronie nadawcy, drugi łączy dalsze etapy w laboratorium. Ustalcie, kto nadaje identyfikator, jak wygląda poprawka i co zrobić, gdy oznaczenie jest nieczytelne.

Nie zakładajcie, że jedna przesyłka zawsze oznacza jedną próbkę albo jedno badanie. Próbka może zostać podzielona na części, a jeden zestaw może zawierać kilka materiałów. Projekt powinien pokazać zależności między zleceniem, oryginalną próbką i jej częściami, jeśli proces tego wymaga. Wtedy osoba przeglądająca historię zobaczy, do którego materiału odnosi się zapis.

Jeśli dane pochodzą z innego programu, ustalcie, które źródło odpowiada za identyfikator i jak wykryć rozbieżność. Więcej o takich decyzjach piszemy w artykule o źródle danych w integracji. Przed automatycznym połączeniem rekordów trzeba potwierdzić, że ich identyfikatory rzeczywiście oznaczają ten sam materiał.

Przyjęcie wymaga decyzji, nie tylko kliknięcia

Przyjęcie próbki może obejmować porównanie oznaczenia z dokumentem, sprawdzenie kompletności informacji i przekazanie materiału do odpowiedniego miejsca. Lista zależy od procesu. System powinien pokazywać osobie przyjmującej, które informacje są potrzebne do decyzji oraz jak postąpić, gdy ich brakuje.

Jeśli etykieta jest uszkodzona albo w zleceniu występuje niezgodność, nie wymuszajcie uzupełnienia pola przypadkową wartością tylko po to, by przejść dalej. Potrzebny jest stan pozwalający zatrzymać sprawę i przekazać ją do wyjaśnienia. Właściciel procesu powinien ustalić, kto może podjąć decyzję o dalszym postępowaniu i jak zapisuje jej uzasadnienie.

Potwierdzenie przyjęcia powinno być odrębne od statusu badania. Materiał może znajdować się w laboratorium, lecz nadal oczekiwać na sprawdzenie dokumentów albo przydział do zespołu. Czytelne nazwy stanów pomagają uniknąć sytuacji, w której nadawca odczytuje „przyjęto” jako informację o ukończeniu pracy.

ISO opisuje osobny zakres dotyczący pobierania i transportu próbek do badań medycznych. Jeśli projekt obejmuje taki proces, należy sprawdzić wymagania właściwe dla organizacji i zakresu jej działalności. Sam wybór systemu ani lista pól z tego artykułu nie potwierdzają zgodności z normą lub przepisami.

Zaprojektuj przekazanie między etapami

Dla każdego etapu ustalcie, co pozwala uznać go za zakończony, kto może przekazać materiał dalej i co musi zobaczyć kolejna osoba. W przykładzie pracownik przygotowujący próbkę potwierdza jej identyfikator, zapisuje wykonane czynności i przekazuje ją do zespołu odpowiedzialnego za następne zadanie. Odbiorca powinien móc odróżnić materiał oczekujący od tego, który faktycznie przejął.

Warto rozdzielić przekazanie od potwierdzenia odbioru, jeżeli między etapami mija czas lub pracują różne zespoły. Gdy pierwsza osoba oznaczy próbkę jako wysłaną, druga nie musi jej jeszcze mieć. Aplikacja może pokazać oba zdarzenia, ich czas oraz odpowiedzialne osoby. Nie powinna jednak tworzyć fikcyjnego potwierdzenia tylko dlatego, że poprzedni etap został zamknięty.

Zapytajcie, co dzieje się przy zmianie kolejności. Niektóre zadania można prowadzić równolegle, inne wymagają wcześniejszej decyzji lub przygotowania. Reguły zależą od konkretnej procedury i powinny zostać uzgodnione z osobami prowadzącymi pracę. W automatyzacji zleceń podobnie rozróżniamy przydzielenie sprawy od potwierdzenia wykonania.

Jeżeli materiał zostaje podzielony, historia każdej części powinna wskazywać jej pochodzenie. Gdy część jest wykorzystywana do innego zadania, system może potrzebować osobnego statusu i identyfikatora. Nie zakładajcie, że wszystkie laboratoria potrzebują tego samego modelu. Najpierw narysujcie rzeczywiste rozgałęzienia i poproście pracowników o sprawdzenie przykładów.

Ustal, co oznacza lokalizacja materiału

W laboratorium lokalizacja próbki może zmieniać się w trakcie pracy. Zespół potrzebuje wiedzieć, czy materiał czeka na przyjęcie, został przekazany do konkretnego stanowiska, czy znajduje się w miejscu przechowywania. Nazwy tych miejsc powinny odpowiadać rzeczywistej organizacji pracy. Zbyt ogólny zapis „w laboratorium” nie pomoże, gdy pracownik szuka jednej części zlecenia.

Zaplanujcie także postępowanie po zmianie miejsca. Czy osoba odkładająca materiał zapisuje lokalizację od razu? Czy następna osoba potwierdza przejęcie? Co zrobić, gdy system wskazuje jedno miejsce, a pojemnik znajduje się gdzie indziej? Nie każda zmiana wymaga identycznej procedury, lecz odpowiedzialność za wyjaśnienie rozbieżności powinna być jasna.

Jeśli laboratorium zapisuje warunki przechowywania lub transportu, najpierw ustalcie, skąd pochodzą dane i kto je weryfikuje. Informacja wpisana ręcznie i odczyt z urządzenia mogą wymagać różnych oznaczeń. Nie należy przyjmować uniwersalnych zakresów temperatury ani czasu przechowywania bez odniesienia do konkretnego materiału i właściwej procedury.

Sprawdźcie również przypadek, w którym etykieta jest czytelna, ale lokalizacja w systemie nie zgadza się z rzeczywistą. Pracownik powinien móc zgłosić różnicę bez usuwania wcześniejszego wpisu. Osoba odpowiedzialna ustali dalszy krok, a historia pozwoli później zrozumieć, kiedy i dlaczego informację poprawiono.

Wynik badania może być jedną z informacji potrzebnych do oceny zgłoszenia dotyczącego wyrobu. Powiązanie materiałów z partią i zadaniami zespołu opisujemy w tekście o reklamacjach produkcyjnych.

Uzgodnij słownik statusów z odbiorcami

Te same słowa mogą znaczyć coś innego dla laboratorium i nadawcy. „W trakcie” może oznaczać oczekiwanie na przydział albo rozpoczętą pracę. Przed publikacją statusu w portalu klienta sprawdźcie, czy jego nazwa i opis nie sugerują zakończenia czynności, której jeszcze nie potwierdzono.

Jeśli system wysyła powiadomienia, ustalcie, które zmiany są istotne dla odbiorcy oraz kto może je zobaczyć. Próbne powiadomienie powinno trafić do testowego adresata. Warto sprawdzić także przypadek, w którym stan został poprawiony: czy nowa informacja wyjaśnia zmianę bez ujawniania danych osobie nieuprawnionej?

Wyjątek musi mieć właściciela

W codziennej pracy pojawiają się brakujące informacje, uszkodzone oznaczenia albo zadania, których nie da się rozpocząć w planowanym czasie. System powinien umożliwić oznaczenie problemu bez gubienia wcześniejszej historii. Osoba przeglądająca sprawę potrzebuje wiedzieć, czego brakuje, kto został poproszony o decyzję i co wolno zrobić do czasu odpowiedzi.

Nie każdy wyjątek oznacza ten sam skutek. Przy błędzie w danych kontaktowych można potrzebować wyjaśnienia z nadawcą; przy wątpliwości co do tożsamości materiału decyzja może należeć do osoby odpowiedzialnej za konkretną procedurę. Aplikacja ma pokazać ustaloną ścieżkę, a nie wymyślać ją na podstawie ogólnego komunikatu „błąd”.

Kolejka spraw oczekujących powinna mieć właściciela i sposób przekazania podczas nieobecności. Przy dłuższym oczekiwaniu przyda się możliwość przypomnienia lub eskalacji, ustalona odpowiednio do procesu. O tym, dlaczego wykrycie problemu musi prowadzić do działania, piszemy w artykule o monitorowaniu automatyzacji.

Warto sprawdzić również poprawki po zamknięciu etapu. Jeśli pracownik zorientuje się, że zapisał niewłaściwy identyfikator pojemnika, potrzebna jest droga zgłoszenia i zatwierdzenia korekty. Nadpisanie wartości bez śladu może utrudnić odtworzenie przebiegu. Zakres historii oraz dostęp do niej powinny wynikać z uzgodnionej procedury.

Dostęp i przekazywanie wyników

Pracownik przyjmujący materiał, osoba prowadząca badanie i klient oczekujący na wynik mogą potrzebować innych informacji. Wspólny system nie oznacza, że każdy powinien widzieć wszystkie sprawy. Ustalcie role, zakres przypisanych zleceń oraz czynności dostępne poszczególnym osobom. Zabezpieczenie musi obejmować także pobierane pliki, eksport i integracje.

Jeżeli wynik trafia do innego systemu, potwierdźcie, który rekord jest odbiorcą oraz co oznacza poprawne przekazanie. Przyjęcie wiadomości przez połączenie nie zawsze oznacza, że odbiorca zapisał ją we właściwym miejscu. Potrzebne mogą być osobne stany i procedura wyjaśnienia. O granicach wymiany informacji piszemy w artykule o API i webhookach w automatyzacji.

Przy braku odpowiedzi nie zakładajcie, że operacja na pewno nie została wykonana. Powtórne wysłanie bez sprawdzenia może utworzyć zduplikowaną wiadomość lub zapis. Sposób ponowienia zależy od możliwości systemu odbiorcy. Ustalcie, jak znaleźć wcześniejszy wynik i kto rozstrzyga sprawę, jeśli stan nadal jest nieznany.

Zespół utrzymania potrzebuje informacji o problemach, ale nie zawsze pełnej zawartości zlecenia. Dzienniki techniczne i widok obsługi wyjątków powinny zawierać dane potrzebne do diagnozy w zakresie odpowiadającym uprawnieniom. Szczególne wymagania dotyczące danych i okresów przechowywania należy sprawdzić dla właściwego procesu.

Sprawdź obieg na przykładach z pracy zespołu

Przygotujcie fikcyjne zlecenie oraz kilka próbek testowych z odrębnymi identyfikatorami. Poproście pracownika o przyjęcie jednej z nich, przekazanie do kolejnego etapu i odnalezienie historii. Następnie sprawdźcie nieczytelne oznaczenie, brak danych oraz próbę przekazania części, której pochodzenie nie zostało potwierdzone. Oczekiwany wynik należy uzgodnić przed testem.

Próba powinna objąć nie tylko główny ekran. Sprawdźcie wyszukiwanie, eksport, pobranie dokumentu i działanie kont o różnych uprawnieniach. Upewnijcie się, że osoba odpowiedzialna za jedno zlecenie nie otrzymuje dostępu do informacji z innego bez właściwego powodu. Zwróćcie uwagę również na czytelność statusów oraz możliwość odnalezienia sprawy po identyfikatorze używanym przez nadawcę.

Zapiszcie także, kto weryfikuje wynik i jak zgłasza problem. W tekście o kryteriach odbioru aplikacji opisujemy sposób formułowania sprawdzalnych scenariuszy. Warto przetestować prototyp z osobami pracującymi na różnych etapach, zanim powstanie pełna integracja. O takiej próbie przeczytasz w artykule o testowaniu prototypu z pracownikami.

Widok zbiorczy może wskazywać sprawy oczekujące i ich etap, ale liczba próbek nie mówi jeszcze, co blokuje pracę. Ustalcie definicje stanów i możliwość przejścia z wyniku do odpowiedniego zlecenia. Pomocne będą pytania z artykułu o dashboardzie operacyjnym.

Jeśli planujesz uporządkować przekazywanie próbek, wyślij krótki brief opisujący etapy, użytkowników i jedno miejsce, w którym brakuje informacji. Możemy omówić zakres oprogramowania na zamówienie, integracji i testów. Skontaktuj się z Archifutura, korzystając z fikcyjnego przykładu zamiast rzeczywistych danych wrażliwych.