Często zdarza się, że osoby, które pracują na nowym systemie, narzekają, bo w starym było to zrobione w inny sposób. Co ciekawe, czasami nawet gorszy, mniej zautomatyzowany. I wtedy my jako manager, powinniśmy zawsze przypominać o głównym celu, jaki nam przyświecał, aby wdrożyć zmianę. Natomiast jeżeli wejdziemy do tego problemu dopiero teraz, to będziemy ocenieni jako ci, którzy nie interesują się pracą danej osoby, natomiast, jeżeli byliśmy od początku procesu, to wtedy jest zdecydowanie łatwiej przekonać taką osobę, która blokuje zmianę z “błahego” problemu.
Proces przeniesienia bazy:
Są różne możliwości i z różnych korzystają placówki. Natomiast nie ukrywajmy, że to jest trochę skomplikowane w przypadku placówek medycznych, bo aktualna baza musi być “ciągle”, a proces przenoszenia czasami niestety trwa.
Jak możemy ustalić proces przenoszenia bazy?
Po pierwsze: oprogramowanie medyczne mają obowiązek prawny, aby udostępnić plik z bazą danych w formacie możliwym do zaimportowania przez inny system. Niestety widziałem już kilka razy sytuacje, w których twórcy oprogramowań, albo partnerzy tych twórców starają sie uniknąć tego obowiązku. Oczywiście sprawa jest do wygrania bez problemu, ale nie oszukujmy się, nam nie zależy na tym, aby sie z twórcą systemu sądzić, ale na tym, aby przenieść dane do innego.
Co robią twórcy systemów:
1. Dają plik w formacie, który trzeba odkodować,
2. Dają niepełne dane,
3. Twierdzą, że są oprogramowaniem komputerowym, a nie medycznym, a więc ich ten przepis nie obowiązuje — taką odpowiedź klient otrzymał od jednego z systemów
Przyjmijmy, że mamy ten plik już w odkodowanej wersji i w jaki sposób zaplanować wtedy przeniesieni danych? Najlepszym rozwiązaniem jest zacząć pracę na nowym systemie i w międzyczasie przenieść dane z systemu poprzedniego.
Oczywiście, w tym międzyczasie zachowujemy dostęp do startego systemu, aby mieć ciągle podgląd do kart pacjenta, rozliczeń etc. Ustalmy z dostawcą systemu, ile ten miedzy czas będzie trwał, abyśmy poinformowali zespół.
Bazę ze starego systemu eksportujemy w dniu, w którym pracujemy już na nowym systemie, aby mieć pewność, że po eksporcie już nic nowego w starym systemie się nie pojawia.