Czy i dlaczego firmy informatyczne uzależniają od siebie szpitale i… cały system ochrony zdrowia
Redaktor: Bartłomiej Leśniewski
Data: 27.03.2018
Źródło: BL, Wiktor Górecki
| Tagi: | Wiktor Górecki |
Jak smakujesz swojej firmie informatycznej? Czujesz jak wypija z ciebie soki? Co dzieje się, gdy chcesz odejść, a… po prostu możesz? To taka gra w mrówki hodujące i uzależniające mszyce. Skąd się to bierze i jak temu przeciwdziałać? To pytanie, które spędza sen z powiek nie tylko szpitalom i przychodniom, ale i centralnym dla zdrowia instytucjom.
Problem jest znany, dyskutuje się o nim na seminariach, a wciąż i wraca jak bumerang.
Prezentujemy analizę Wiktora Góreckiego:
- Nie zmienia się firmy utrzymującej system informatyczny dla jakiegoś widzimisię. Nikogo nie stać na igraszki z dostawcą oprogramowania po to tylko, żeby mu dokuczyć. Czym wobec tego jest problem uzależnienia użytkownika – przychodni, szpitala czy ogólnokrajowej instytucji rządowej od firmy informatycznej lub nawet od konkretnych osób zatrudnionych wewnątrz w celu uruchomienia lub utrzymania systemu informatycznego?
Otóż bywa całkiem często, że zainstalowany system odbiega od naszych oczekiwań, już w pierwszej fazie funkcjonowania, a trzeba przyjąć, że z biegiem czasu musi wręcz od nich odbiegać, choćby dlatego, że będą one się zmieniać w miarę zmieniającej się sytuacji wewnętrznej i zewnętrznej użytkownika.
Informatyzacja – lek na własny czy cudzy problem?
Informatyzacji zakładu zaczyna się od ustalenia elementów zamówienia na podstawie ustrukturalizowanej mapy problemów i potrzeb. W praktyce jednak zakład odczuwa to w pełni dopiero z chwilą rozpoczęcia wdrożenia. Problemy i potrzeby bowiem często wydają się być z góry znane na podstawie obserwacji innych, cudzych wdrożeń oraz na podstawie przedstawionej oferty, która jest wyrazem doświadczeń wytwórcy lub dostawcy oprogramowania. Gdyby analiza potrzeb była bardzo poważnie potraktowana, wówczas proces informatyzacji rozpoczynałby się rzeczywiście od niej. Faza tej analizy jakkolwiek w deklaracjach określana jako ważna, w praktyce jednak traktowana jest niejasno. Metody lub raczej sposoby tej analizy wydają się budzić wątpliwości i rzucać światło szerzej, na całość praktyk zarządczych w ochronie zdrowia. Podlaskie e-zdrowie na przykład skonstruowane zostało w bliźniaczy sposób w stosunku do ogólnokrajowego rozwiązania – Platformy P1. Wbrew płynącym z rożnych stron sygnałom uznano to rozwiązanie za najbardziej korzystne i pewne. Było zapewne owocem analizy strategicznej uwzględniającej perspektywę urzędników z Białegostoku i Warszawy oraz twórców Studium Wykonalności wcześniej przygotowujących taki sam dokument dla Platformy P1 w Warszawie. Musiało jednak zabraknąć innych, jak się okazało, ważniejszych interesariuszy, skoro ostatni audyt przeprowadzony przez NIK sygnalizuje bardzo niski stopień wykorzystania przygotowanych rozwiązań.
W metodzie grzech pierworodny
Doświadczenie mówi, że grzechu pierworodnego należy szukać w metodach wpływających na rozumienie i formułowanie własnych problemów oraz celów i w konsekwencji na kształt zamówienia. Wypróbowane i znane metody planowania strategii operują rozbudowanym instrumentarium eliminującym powstawanie tego rodzaju sytuacji, w szczególności narzędziami do modelowania i zarządzania procesami biznesowymi, produkcyjnymi, administracyjnymi i logistycznymi oraz partycypacyjną metodologią budowania strategii z udziałem wszystkich interesariuszy.
Informatyzacja zakładu jest niewątpliwie ważną zmianą wywołującą nadzieje i lęki. Te ostatnie szczególnie wśród personelu. Ostatnie dwadzieścia lat w ochronie zdrowia było też, szczególnie dla szpitali swego rodzaju torem przeszkód. To powinno czynić je nie tylko uodpornionymi na stresy towarzyszące zmianie, ale przyczynić się do szerokiego stosowania wypróbowanych skądinąd metod i narzędzi z dziedziny zarządzania zmianą. Do narzędzi tych zaliczam wymienione wyżej pakiety oprogramowania do symulacji i modelowania procesowego oraz procedury partycypacyjne budowania strategii. Tego jednak nie obserwujemy w Polsce chyba zupełnie. Przyczyny tego nie są jasne.
Uzależnienie, szpital w potrzasku
Okoliczności te sprawiają, że system i jego uczestnicy mimo przeżywanych wstrząsów wciąż nie są przygotowania do zmian. To w przypadku informatyzacji przyczynia się do błędów przy określenia własnych problemów i potrzeb przed informatyzacja, błędów w negocjacjach z dostawcą oprogramowania i kłopotów nie tylko w czasie wdrożenia, ale również i później. Pojawia się kwestia uzależnienia użytkownika od dostawcy oprogramowania, gdy ten pierwszy spostrzega, że otrzymał coś innego niż jest mu potrzebne i okazuje się, że nie może zwrócić się z tym do nikogo innego niż ten drugi.
Uzależnienie od firmy lub projektu informatycznego, czyli dostawcy IT jest rzeczą znaną. Bolączka dotyka liczne instytucje, organizacje i przedsiębiorstwa, również szpitale. Sprawa jest od dawna przedmiotem dyskusji, seminariów i regulacji prawnych: krajowych i unijnych, a także rekomendacji proceduralnych. Tłem jest z jednej strony pewien fatalizm panujący wśród zamawiających oprogramowanie, z drugiej - swego rodzaju zepsucie rynku informatycznego przez małe wymagania i duże pieniądze instytucji sektora publicznego, które w tym rynku mają niebagatelny udział.
Zamawiającym nazbyt często wydaje się, że są skazani na uzależnienie od informatyków, a informatycy nie tylko potrafią godzić się z tym, ale też traktują to jako dopuszczalna formę utrzymania klienta.
Jeden z wiceministrów zdrowia przyznał niedawno, mówiąc o kosztach usług informatycznych, że wzrosły one na rynku ze względu na zapisy w umowach szpitali z firmami serwisowymi o dostosowanie systemów do ewentualnych zmian ustawowych w okresie serwisowym czy gwarancyjnym jako obowiązku serwisowym. Są to jednak zwykle, zdaniem ministra, zapisy ogólne, mogące rodzić różnice zdań. To potwierdza niepokojące sygnały o nieprzygotowaniu zarówno szpitali jak i dostawców oprogramowania do partnerstwa.
Oprogramowanie sztywne stwarzające problem z dostosowaniem się do zmian legislacyjnych i szerzej niezależnych od szpitala zmian w procesach informacyjnych stawia szpital w sytuacji uzależnienia od dostawcy oprogramowania lub serwisu. Zwykle bowiem musi to kosztować dodatkowo. Naturalna w tej sytuacji ochota na zmianę firmy informatycznej kończy się niepowodzeniem. Okazuje się bowiem bardzo szybko, że modyfikacja cudzego oprogramowania jest dla nowej firmy tak kłopotliwa, że sprawa staje się jeszcze bardziej kosztowna. Zmiana firmy informatycznej wymaga dodatkowo współpracy między firmami: nową i uprzednio zaangażowaną – łatwo zrozumieć, jakie to może być trudne.
Oswajanie zmiany
Są środki zaradcze. Zleceniodawca, myślimy głównie o szpitalu czy przychodni, powinien potraktować informatyzację nie jako sposób na „zakodowanie szpitala na stałe” – na utrwalenie dotychczasowych procesów komunikacyjnych w umowie zaszytej w Studium Wykonalności. Odwrotnie - powinien potraktować informatyzację jako okazję do otwarcia mechanizmów i struktur zarządczych oraz powiązań komunikacyjnych szpitala, wewnętrznych i zewnętrznych na ciągłe zmiany. Informatyzacja zamiast usztywnić organizację powinna ją uelastyczniać. Ważnym elastycznym i uelastyczniającym elementem tego procesu powinno być na przykład Studium Wykonalności. To stwierdzenie może niejednego dziwić. Wiemy jak łatwo właśnie w tym momencie zrobić coś zupełnie odwrotnego. Pamiętamy bowiem, jaką rolę w usztywnianiu informatyzacji całej polskiej ochrony zdrowia odgrywa Studium Wykonalności Platformy P1.
Należy zatem odnajdować w mechanizmach zarządczych i komunikacyjnych zakładu tych elementów, które podlegają lub mogą podlegać zmianie spowodowanej czynnikami zewnętrznymi i wewnętrznymi. Co więcej, szukać tych elementów, które chcielibyśmy uczynić zmiennymi. Nieodzowne byłyby tu wspomniane już dwukrotnie oprogramowanie do modelowania i zarządzania procesami biznesowymi, produkcyjnymi, administracyjnymi i logistycznymi. Poprzestanę na przykładach banalnych: skład zespołów obsługujących procedury medyczne, normy które mogą ulegać zmianie czy zestawy danych przekazywanych do regionalnych czy ogólnokrajowych repozytoriów i rejestrów. Dotyczy to również regulacji, o których mówił minister.
Za szczególny przykład posłużyć tu może wydarzenie dotyczące statystyki medycznej. Niektórzy zapewne pamiętają, jaki problem powstał swego czasu, gdy okazało się, że dostawca oprogramowania dla tej statystyki dostarczył rozwiązanie na „sztywno zaszywające” określenie zestawu zbieranych danych statystycznych ochrony zdrowia. Tymczasem wiadomo było, że zestaw tych danych podlegał corocznej dyskusji na poziomie centralnym, dopuszczając wprowadzenie regulacji modyfikujących. Niemożliwość rekonfiguracji oprogramowania przez użytkowników-statystyków sprawiała, że ku zaskoczeniu managementu raczej wyższego niż niższego szczebla oprogramowanie to stało się wówczas już na starcie nieaktualne, skazując zainteresowanych w kolejnym roku na papier.
System jak z plasteliny
Wszystkie te zmienne elementy, o których była mowa, powinny być zatem przedmiotem modelowania czy inaczej konfigurowania i rekonfigurowania bez udziału informatyków, angażując w zamian możliwie szeroko management szpitala i środowisko medyczne. Jak najszersze umożliwienie tego powinno być przedmiotem oczekiwania w stosunku do dostawcy oprogramowania. Powinien on w ofercie wykazać w jakim zakresie i w jaki sposób gotów jest spełnić to oczekiwanie.
Najbardziej bulwersującym zapewne, ale koniecznym i możliwym do spełnienia postulatem jest jednak coś więcej. Należy oczekiwać od dostawcy, że wykaże w jaki sposób i jakim kosztem jego oprogramowanie może być przekazane do obsługi serwisowej, w tym do modyfikacji innemu operatorowi.
Zmienność może rodzić niepewność, przede wszystkim jednak powinno być odpowiedzią na niepewność. Źródłem choć nie jedynym niepewności dla uczestników ochrony zdrowia w Polsce jest centrum zarządcze i regulacyjne w Warszawie. Przykładem są tu dotychczasowe niepowodzenia w dziedzinie ogólnopolskiego e-zdrowia. Jest trwająca niepewność co do losów Platformy P1. Jest bardzo tajemnicza sprawa nowej strategii e-zdrowia i nierozstrzygnięte kwestie związane z aktualnością technologiczną rozwiązań forsowanych obecnie, tych samych, których aktualność lat temu już przeszło dziesięć była kwestionowana. To czyni aktualnym wymóg jaki stawiać musi szpital dostawcy oprogramowania, żeby zdawał sobie sprawę z zakresu niepewności co do możliwych rozwiązań, które mogą być przyjęte przez regulatora na poziomie centralnym.
Szpital przygotowany na wszystko
Istnieje dodatkowo obawa, że regulacje polskie będą nie nadążały lub rozchodziły się z trendami kształtującymi się w pozostałych krajach UE. Dostawca oprogramowania musi zatem przygotować szpital do obsługi pacjentów leczonych równocześnie również za granicą, biorąc pod uwagę inną niż polska przestrzeń komunikacyjną, w której równolegle funkcjonują jako pacjenci. Regulator na poziomie centralnym zajmuje się zagadnieniami obsługi transgranicznej. Doświadczenie przemawia jednak niestety za powstrzymaniem się przed przedwczesnym optymizmem w tej kwestii. Trudno przewidzieć, na ile zarysowujące się różnice między Polską a pozostałymi krajami UE, zwłaszcza w dziedzinie na przykład myślenia o modelowaniu danych, nie będą pogłębiać się, choć chyba raczej z powodu zaniedbań niż premedytacji, utrudniając transgraniczne procesy komunikacyjne.
Można wymagać i spełniać wymagania
Szczególnie przykre konsekwencje uzależnienia od jednego dostawcy dotyka szpital, gdy zamierzając rozbudować system spostrzega, że zmuszony jest zwrócić się o to tylko do dotychczasowego partnera informatycznego. Może to wynikać z niekorzystnego dlań kontraktu. Może być jeszcze gorzej, gdy wynika to z wadliwego technicznie oprogramowania, które czy to ze złej woli wytwórcy, czy z powodu jego niekompetencji jest tak wykonane, że niejako systemowo niezdolne jest do wiązania się z nowymi elementami oprogramowania wytworzonymi przez innych wytwórców. Użytkownik, szpital czy przychodnia powinien wymagać, żeby firma informatyczna udowodniła, że jej oprogramowanie nie tylko dopuszcza, ale jest wręcz przyjazne tak rozumianej rozbudowie.
Uzależnienie może mieć kolejny wymiar. Dotyczy to danych. Jak są modelowane? Jakie są ich struktury? Jeżeli dostawca oprogramowania zastosował rozwiązanie unikalne ignorujące standardy, wówczas to tylko on może się okazać jedynym specjalistą od modyfikowania wdrożonego przez siebie oprogramowania za każdym razem, gdy szpital będzie chciał wymieniać informacje z kolejnymi, innymi niż dotychczasowi, partnerami zewnętrznymi. Za każdym razem na przykład gdy zmienią się regulacje dotyczące wymiany informacji z repozytoriami danych na poziomie centralnym lub regionalnym, czy rozszerza lub zmienia komunikacja z rejestrami medycznymi, może okazać się, że konieczna będzie interwencja czyniąc oprogramowanie coraz mniej przejrzystym. W skrajnej sytuacji jedynym sposobem na pozbycie się uzależnienia będzie wymiana systemu – informatyzacja, czasem prawie od nowa.
Zlekceważone standardy
Aspektem tego zagrożenia jest niewyjaśniona postawa w tej kwestii regulatorów na poziomie centralnym oraz obawa, czy dotyczące tego zagadnienia standardy unijne będą w Polsce rzeczywiście wdrażane. Wciąż bowiem niejasny jest stosunek regulatorów centralnych, ministerstw: zdrowia i cyfryzacji w kwestii normy PN-EN 13 606 w zakresie modelowania danych. Dostawca oprogramowania powinien zaproponować szpitalowi najlepszy jego zdaniem sposób, w jaki szpital dzięki rozwiązaniom zastosowanym w oferowanym mu oprogramowaniu będzie mógł minimalizować tego rodzaju ryzyka.
Wreszcie przy najlepszych relacjach z dostawcą oprogramowania a także serwisu szpital musi brać pod uwagę możliwość całkowitej wymianę systemu w przyszłości. Niezależnie od przyczyn, celów czy okoliczności dostawca oprogramowania nie może blokować tego rodzaju decyzji. Może tak się stać, gdy z różnych przyczyn, choćby tylko technicznych, migracja danych do nowego systemu może być bardzo utrudniona lub w praktyce uniemożliwiona. Zatem kolejnym wymogiem w stosunku do dostawcy oprogramowania jest wykazanie, że oferowane oprogramowanie nie tylko nie blokuje, ale wręcz odwrotnie ułatwia migrację danych przy zmianie systemu.
Czy te postulaty są do przyjęcia ze strony partnerów informatycznych? Zdecydowanie tak. Formułowanie takich oczekiwań ze strony użytkownika i spełnianie ich ze strony dostawcy jest świadectwem dojrzałego partnerstwa i dojrzałych relacji biznesowych.
Wiktor Górecki
Autor jest ekspertem w dziedzinie informatyzacji ochrony zdrowia
Przeczytaj również: "Wójciech Górnik i Kajetan Wojsyk już nie pracują w CSIOZ".
Prezentujemy analizę Wiktora Góreckiego:
- Nie zmienia się firmy utrzymującej system informatyczny dla jakiegoś widzimisię. Nikogo nie stać na igraszki z dostawcą oprogramowania po to tylko, żeby mu dokuczyć. Czym wobec tego jest problem uzależnienia użytkownika – przychodni, szpitala czy ogólnokrajowej instytucji rządowej od firmy informatycznej lub nawet od konkretnych osób zatrudnionych wewnątrz w celu uruchomienia lub utrzymania systemu informatycznego?
Otóż bywa całkiem często, że zainstalowany system odbiega od naszych oczekiwań, już w pierwszej fazie funkcjonowania, a trzeba przyjąć, że z biegiem czasu musi wręcz od nich odbiegać, choćby dlatego, że będą one się zmieniać w miarę zmieniającej się sytuacji wewnętrznej i zewnętrznej użytkownika.
Informatyzacja – lek na własny czy cudzy problem?
Informatyzacji zakładu zaczyna się od ustalenia elementów zamówienia na podstawie ustrukturalizowanej mapy problemów i potrzeb. W praktyce jednak zakład odczuwa to w pełni dopiero z chwilą rozpoczęcia wdrożenia. Problemy i potrzeby bowiem często wydają się być z góry znane na podstawie obserwacji innych, cudzych wdrożeń oraz na podstawie przedstawionej oferty, która jest wyrazem doświadczeń wytwórcy lub dostawcy oprogramowania. Gdyby analiza potrzeb była bardzo poważnie potraktowana, wówczas proces informatyzacji rozpoczynałby się rzeczywiście od niej. Faza tej analizy jakkolwiek w deklaracjach określana jako ważna, w praktyce jednak traktowana jest niejasno. Metody lub raczej sposoby tej analizy wydają się budzić wątpliwości i rzucać światło szerzej, na całość praktyk zarządczych w ochronie zdrowia. Podlaskie e-zdrowie na przykład skonstruowane zostało w bliźniaczy sposób w stosunku do ogólnokrajowego rozwiązania – Platformy P1. Wbrew płynącym z rożnych stron sygnałom uznano to rozwiązanie za najbardziej korzystne i pewne. Było zapewne owocem analizy strategicznej uwzględniającej perspektywę urzędników z Białegostoku i Warszawy oraz twórców Studium Wykonalności wcześniej przygotowujących taki sam dokument dla Platformy P1 w Warszawie. Musiało jednak zabraknąć innych, jak się okazało, ważniejszych interesariuszy, skoro ostatni audyt przeprowadzony przez NIK sygnalizuje bardzo niski stopień wykorzystania przygotowanych rozwiązań.
W metodzie grzech pierworodny
Doświadczenie mówi, że grzechu pierworodnego należy szukać w metodach wpływających na rozumienie i formułowanie własnych problemów oraz celów i w konsekwencji na kształt zamówienia. Wypróbowane i znane metody planowania strategii operują rozbudowanym instrumentarium eliminującym powstawanie tego rodzaju sytuacji, w szczególności narzędziami do modelowania i zarządzania procesami biznesowymi, produkcyjnymi, administracyjnymi i logistycznymi oraz partycypacyjną metodologią budowania strategii z udziałem wszystkich interesariuszy.
Informatyzacja zakładu jest niewątpliwie ważną zmianą wywołującą nadzieje i lęki. Te ostatnie szczególnie wśród personelu. Ostatnie dwadzieścia lat w ochronie zdrowia było też, szczególnie dla szpitali swego rodzaju torem przeszkód. To powinno czynić je nie tylko uodpornionymi na stresy towarzyszące zmianie, ale przyczynić się do szerokiego stosowania wypróbowanych skądinąd metod i narzędzi z dziedziny zarządzania zmianą. Do narzędzi tych zaliczam wymienione wyżej pakiety oprogramowania do symulacji i modelowania procesowego oraz procedury partycypacyjne budowania strategii. Tego jednak nie obserwujemy w Polsce chyba zupełnie. Przyczyny tego nie są jasne.
Uzależnienie, szpital w potrzasku
Okoliczności te sprawiają, że system i jego uczestnicy mimo przeżywanych wstrząsów wciąż nie są przygotowania do zmian. To w przypadku informatyzacji przyczynia się do błędów przy określenia własnych problemów i potrzeb przed informatyzacja, błędów w negocjacjach z dostawcą oprogramowania i kłopotów nie tylko w czasie wdrożenia, ale również i później. Pojawia się kwestia uzależnienia użytkownika od dostawcy oprogramowania, gdy ten pierwszy spostrzega, że otrzymał coś innego niż jest mu potrzebne i okazuje się, że nie może zwrócić się z tym do nikogo innego niż ten drugi.
Uzależnienie od firmy lub projektu informatycznego, czyli dostawcy IT jest rzeczą znaną. Bolączka dotyka liczne instytucje, organizacje i przedsiębiorstwa, również szpitale. Sprawa jest od dawna przedmiotem dyskusji, seminariów i regulacji prawnych: krajowych i unijnych, a także rekomendacji proceduralnych. Tłem jest z jednej strony pewien fatalizm panujący wśród zamawiających oprogramowanie, z drugiej - swego rodzaju zepsucie rynku informatycznego przez małe wymagania i duże pieniądze instytucji sektora publicznego, które w tym rynku mają niebagatelny udział.
Zamawiającym nazbyt często wydaje się, że są skazani na uzależnienie od informatyków, a informatycy nie tylko potrafią godzić się z tym, ale też traktują to jako dopuszczalna formę utrzymania klienta.
Jeden z wiceministrów zdrowia przyznał niedawno, mówiąc o kosztach usług informatycznych, że wzrosły one na rynku ze względu na zapisy w umowach szpitali z firmami serwisowymi o dostosowanie systemów do ewentualnych zmian ustawowych w okresie serwisowym czy gwarancyjnym jako obowiązku serwisowym. Są to jednak zwykle, zdaniem ministra, zapisy ogólne, mogące rodzić różnice zdań. To potwierdza niepokojące sygnały o nieprzygotowaniu zarówno szpitali jak i dostawców oprogramowania do partnerstwa.
Oprogramowanie sztywne stwarzające problem z dostosowaniem się do zmian legislacyjnych i szerzej niezależnych od szpitala zmian w procesach informacyjnych stawia szpital w sytuacji uzależnienia od dostawcy oprogramowania lub serwisu. Zwykle bowiem musi to kosztować dodatkowo. Naturalna w tej sytuacji ochota na zmianę firmy informatycznej kończy się niepowodzeniem. Okazuje się bowiem bardzo szybko, że modyfikacja cudzego oprogramowania jest dla nowej firmy tak kłopotliwa, że sprawa staje się jeszcze bardziej kosztowna. Zmiana firmy informatycznej wymaga dodatkowo współpracy między firmami: nową i uprzednio zaangażowaną – łatwo zrozumieć, jakie to może być trudne.
Oswajanie zmiany
Są środki zaradcze. Zleceniodawca, myślimy głównie o szpitalu czy przychodni, powinien potraktować informatyzację nie jako sposób na „zakodowanie szpitala na stałe” – na utrwalenie dotychczasowych procesów komunikacyjnych w umowie zaszytej w Studium Wykonalności. Odwrotnie - powinien potraktować informatyzację jako okazję do otwarcia mechanizmów i struktur zarządczych oraz powiązań komunikacyjnych szpitala, wewnętrznych i zewnętrznych na ciągłe zmiany. Informatyzacja zamiast usztywnić organizację powinna ją uelastyczniać. Ważnym elastycznym i uelastyczniającym elementem tego procesu powinno być na przykład Studium Wykonalności. To stwierdzenie może niejednego dziwić. Wiemy jak łatwo właśnie w tym momencie zrobić coś zupełnie odwrotnego. Pamiętamy bowiem, jaką rolę w usztywnianiu informatyzacji całej polskiej ochrony zdrowia odgrywa Studium Wykonalności Platformy P1.
Należy zatem odnajdować w mechanizmach zarządczych i komunikacyjnych zakładu tych elementów, które podlegają lub mogą podlegać zmianie spowodowanej czynnikami zewnętrznymi i wewnętrznymi. Co więcej, szukać tych elementów, które chcielibyśmy uczynić zmiennymi. Nieodzowne byłyby tu wspomniane już dwukrotnie oprogramowanie do modelowania i zarządzania procesami biznesowymi, produkcyjnymi, administracyjnymi i logistycznymi. Poprzestanę na przykładach banalnych: skład zespołów obsługujących procedury medyczne, normy które mogą ulegać zmianie czy zestawy danych przekazywanych do regionalnych czy ogólnokrajowych repozytoriów i rejestrów. Dotyczy to również regulacji, o których mówił minister.
Za szczególny przykład posłużyć tu może wydarzenie dotyczące statystyki medycznej. Niektórzy zapewne pamiętają, jaki problem powstał swego czasu, gdy okazało się, że dostawca oprogramowania dla tej statystyki dostarczył rozwiązanie na „sztywno zaszywające” określenie zestawu zbieranych danych statystycznych ochrony zdrowia. Tymczasem wiadomo było, że zestaw tych danych podlegał corocznej dyskusji na poziomie centralnym, dopuszczając wprowadzenie regulacji modyfikujących. Niemożliwość rekonfiguracji oprogramowania przez użytkowników-statystyków sprawiała, że ku zaskoczeniu managementu raczej wyższego niż niższego szczebla oprogramowanie to stało się wówczas już na starcie nieaktualne, skazując zainteresowanych w kolejnym roku na papier.
System jak z plasteliny
Wszystkie te zmienne elementy, o których była mowa, powinny być zatem przedmiotem modelowania czy inaczej konfigurowania i rekonfigurowania bez udziału informatyków, angażując w zamian możliwie szeroko management szpitala i środowisko medyczne. Jak najszersze umożliwienie tego powinno być przedmiotem oczekiwania w stosunku do dostawcy oprogramowania. Powinien on w ofercie wykazać w jakim zakresie i w jaki sposób gotów jest spełnić to oczekiwanie.
Najbardziej bulwersującym zapewne, ale koniecznym i możliwym do spełnienia postulatem jest jednak coś więcej. Należy oczekiwać od dostawcy, że wykaże w jaki sposób i jakim kosztem jego oprogramowanie może być przekazane do obsługi serwisowej, w tym do modyfikacji innemu operatorowi.
Zmienność może rodzić niepewność, przede wszystkim jednak powinno być odpowiedzią na niepewność. Źródłem choć nie jedynym niepewności dla uczestników ochrony zdrowia w Polsce jest centrum zarządcze i regulacyjne w Warszawie. Przykładem są tu dotychczasowe niepowodzenia w dziedzinie ogólnopolskiego e-zdrowia. Jest trwająca niepewność co do losów Platformy P1. Jest bardzo tajemnicza sprawa nowej strategii e-zdrowia i nierozstrzygnięte kwestie związane z aktualnością technologiczną rozwiązań forsowanych obecnie, tych samych, których aktualność lat temu już przeszło dziesięć była kwestionowana. To czyni aktualnym wymóg jaki stawiać musi szpital dostawcy oprogramowania, żeby zdawał sobie sprawę z zakresu niepewności co do możliwych rozwiązań, które mogą być przyjęte przez regulatora na poziomie centralnym.
Szpital przygotowany na wszystko
Istnieje dodatkowo obawa, że regulacje polskie będą nie nadążały lub rozchodziły się z trendami kształtującymi się w pozostałych krajach UE. Dostawca oprogramowania musi zatem przygotować szpital do obsługi pacjentów leczonych równocześnie również za granicą, biorąc pod uwagę inną niż polska przestrzeń komunikacyjną, w której równolegle funkcjonują jako pacjenci. Regulator na poziomie centralnym zajmuje się zagadnieniami obsługi transgranicznej. Doświadczenie przemawia jednak niestety za powstrzymaniem się przed przedwczesnym optymizmem w tej kwestii. Trudno przewidzieć, na ile zarysowujące się różnice między Polską a pozostałymi krajami UE, zwłaszcza w dziedzinie na przykład myślenia o modelowaniu danych, nie będą pogłębiać się, choć chyba raczej z powodu zaniedbań niż premedytacji, utrudniając transgraniczne procesy komunikacyjne.
Można wymagać i spełniać wymagania
Szczególnie przykre konsekwencje uzależnienia od jednego dostawcy dotyka szpital, gdy zamierzając rozbudować system spostrzega, że zmuszony jest zwrócić się o to tylko do dotychczasowego partnera informatycznego. Może to wynikać z niekorzystnego dlań kontraktu. Może być jeszcze gorzej, gdy wynika to z wadliwego technicznie oprogramowania, które czy to ze złej woli wytwórcy, czy z powodu jego niekompetencji jest tak wykonane, że niejako systemowo niezdolne jest do wiązania się z nowymi elementami oprogramowania wytworzonymi przez innych wytwórców. Użytkownik, szpital czy przychodnia powinien wymagać, żeby firma informatyczna udowodniła, że jej oprogramowanie nie tylko dopuszcza, ale jest wręcz przyjazne tak rozumianej rozbudowie.
Uzależnienie może mieć kolejny wymiar. Dotyczy to danych. Jak są modelowane? Jakie są ich struktury? Jeżeli dostawca oprogramowania zastosował rozwiązanie unikalne ignorujące standardy, wówczas to tylko on może się okazać jedynym specjalistą od modyfikowania wdrożonego przez siebie oprogramowania za każdym razem, gdy szpital będzie chciał wymieniać informacje z kolejnymi, innymi niż dotychczasowi, partnerami zewnętrznymi. Za każdym razem na przykład gdy zmienią się regulacje dotyczące wymiany informacji z repozytoriami danych na poziomie centralnym lub regionalnym, czy rozszerza lub zmienia komunikacja z rejestrami medycznymi, może okazać się, że konieczna będzie interwencja czyniąc oprogramowanie coraz mniej przejrzystym. W skrajnej sytuacji jedynym sposobem na pozbycie się uzależnienia będzie wymiana systemu – informatyzacja, czasem prawie od nowa.
Zlekceważone standardy
Aspektem tego zagrożenia jest niewyjaśniona postawa w tej kwestii regulatorów na poziomie centralnym oraz obawa, czy dotyczące tego zagadnienia standardy unijne będą w Polsce rzeczywiście wdrażane. Wciąż bowiem niejasny jest stosunek regulatorów centralnych, ministerstw: zdrowia i cyfryzacji w kwestii normy PN-EN 13 606 w zakresie modelowania danych. Dostawca oprogramowania powinien zaproponować szpitalowi najlepszy jego zdaniem sposób, w jaki szpital dzięki rozwiązaniom zastosowanym w oferowanym mu oprogramowaniu będzie mógł minimalizować tego rodzaju ryzyka.
Wreszcie przy najlepszych relacjach z dostawcą oprogramowania a także serwisu szpital musi brać pod uwagę możliwość całkowitej wymianę systemu w przyszłości. Niezależnie od przyczyn, celów czy okoliczności dostawca oprogramowania nie może blokować tego rodzaju decyzji. Może tak się stać, gdy z różnych przyczyn, choćby tylko technicznych, migracja danych do nowego systemu może być bardzo utrudniona lub w praktyce uniemożliwiona. Zatem kolejnym wymogiem w stosunku do dostawcy oprogramowania jest wykazanie, że oferowane oprogramowanie nie tylko nie blokuje, ale wręcz odwrotnie ułatwia migrację danych przy zmianie systemu.
Czy te postulaty są do przyjęcia ze strony partnerów informatycznych? Zdecydowanie tak. Formułowanie takich oczekiwań ze strony użytkownika i spełnianie ich ze strony dostawcy jest świadectwem dojrzałego partnerstwa i dojrzałych relacji biznesowych.
Wiktor Górecki
Autor jest ekspertem w dziedzinie informatyzacji ochrony zdrowia
Przeczytaj również: "Wójciech Górnik i Kajetan Wojsyk już nie pracują w CSIOZ".
