Vendor lock-in: ukryty koszt zamkniętego systemu medycznego
Cena systemu medycznego, którą widzisz na fakturze, to nie jest jego pełny koszt. Najdroższe jest to, czego na fakturze nie ma: moment, w którym chcesz coś zmienić, a okazuje się, że nie możesz. Zmiana dostawcy, integracja z nowym sprzętem, wyjęcie własnych danych. Wtedy ujawnia się vendor lock-in, czyli uzależnienie od jednego dostawcy. I wtedy szpital płaci najwięcej.
Czym jest vendor lock-in
Vendor lock-in to stan, w którym odejście od dostawcy jest tak kosztowne lub tak ryzykowne, że praktycznie niemożliwe. Szpital formalnie ma wybór. W praktyce go nie ma. Jak ujął to radca prawny na jednym z webinarów o systemach legacy: organizacja staje się zakładnikiem dostawcy, który jako jedyny dysponuje wiedzą techniczną i kodem źródłowym.
To nie jest awaria ani błąd. To często wynik decyzji sprzed lat, których konsekwencji nikt nie policzył.
Jak powstaje lock-in
Uzależnienie nie pojawia się nagle. Narasta przez kilka typowych mechanizmów:
- Brak dostępu do kodu i danych. Szpital kupuje licencję na używanie systemu, ale nie ma praw do kodu ani pełnego dostępu do własnej bazy danych. Wszystko, co wykracza poza standardowe ekrany, wymaga dostawcy.
- Zamknięte formaty danych. Dane są zapisane w sposób, którego nie da się odczytać bez systemu, który je stworzył. Wyjęcie ich do innego rozwiązania to osobny, płatny projekt.
- Drogie i powolne integracje. Każde połączenie z nowym sprzętem, laboratorium czy systemem zewnętrznym przechodzi przez dostawcę. On wycenia, on ustala termin. Tygodnie na wycenę, miesiące na realizację.
- Stare kontrakty. Umowy sprzed dekady zwykle nie zawierają klauzul o przekazaniu praw, dokumentacji ani warunkach wyjścia. Problem ujawnia się dopiero, gdy chcesz odejść.
- Wiedza tylko po stronie dostawcy. Nikt w szpitalu nie wie do końca, jak system działa pod spodem. Bez tej wiedzy każdy ruch wymaga zewnętrznej pomocy.
Każdy z tych punktów osobno wygląda niewinnie. Razem tworzą ścianę.
Realne koszty, których nie widać
Lock-in nie kosztuje, dopóki wszystko idzie gładko. Rachunek przychodzi w trzech momentach.
| Sytuacja | Co się dzieje | Ukryty koszt |
|---|---|---|
| Chcesz zmienić dostawcę | Migracja danych z zamkniętego formatu, odtworzenie integracji, ryzyko utraty historii | Koszt wyjścia często wielokrotnie wyższy niż się wydaje |
| Codzienna zależność | Każda zmiana, integracja i wycena przechodzi przez jednego dostawcę | Wolniejsza praca, brak siły negocjacyjnej, rosnące rachunki |
| Koniec wsparcia | Dostawca znika z rynku, zmienia model lub kończy utrzymanie systemu | System bez łatek bezpieczeństwa, brak ścieżki wyjścia |
Najgroźniejszy jest scenariusz trzeci. Gdy producent przestaje wydawać aktualizacje, szpital zostaje z systemem, którego nie wolno bezpiecznie używać i którego nie da się szybko zastąpić. W świetle RODO i NIS-2 to nie jest już problem działu IT. To ryzyko prawne po stronie zarządu placówki, bo utrzymywanie systemu bez wsparcia bywa traktowane jako akceptacja wysokiego ryzyka incydentu.
Warto też pamiętać, że koszt migracji prawie zawsze jest niedoszacowany. Na papierze to przeniesienie danych. W praktyce to odtworzenie lat integracji, konfiguracji i wiedzy, której nikt nie spisał.
Jak się chronić
Przed lock-inem chroni się na etapie wyboru i zapisów w umowie, nie po latach. Cztery rzeczy, o które warto zadbać:
- Dostęp do danych. Szpital musi mieć możliwość wyjęcia własnych danych w czytelnym formacie, bez pośrednictwa dostawcy. To podstawowe prawo, nie dodatkowa usługa.
- Otwarte REST API. System powinien udostępniać otwarte API, dzięki któremu integracje robi się bez czekania w kolejce u jednego dostawcy. Otwarte API to nie to samo co publikowanie kodu na zewnątrz. To gwarancja, że można się z systemem połączyć.
- Standardy zamiast formatów własnych. HL7 FHIR dla danych medycznych, DICOM dla obrazowania. Standardy oznaczają, że dane są przenośne i zrozumiałe poza jednym systemem.
- Kod i dane u szpitala. Najmocniejsza ochrona to sytuacja, w której szpital ma dostęp do kodu i pełną kontrolę nad swoją bazą. Wtedy zależność od dostawcy jest wyborem, a nie przymusem.
Te cztery punkty można sprawdzić jeszcze przed podpisaniem umowy. Wystarczy zapytać wprost: co się stanie, gdy zechcemy odejść? Kto ma dostęp do kodu? W jakim formacie odzyskamy dane? Jeśli odpowiedzi są mgliste, to też jest odpowiedź.
Otwartość zamiast zamknięcia
W OneCare traktujemy otwartość jako warunek, nie dodatek. OpenCare daje szpitalowi dostęp do danych, otwarte REST API oraz pracę na standardach HL7 FHIR i DICOM. Nie nazywamy tego open source. Nazywamy to otwartą architekturą, w której Twój szpital zachowuje kontrolę nad własnym systemem i własnymi danymi.
Sens jest prosty: dostęp do danych i otwarte API to dla zarządu szpitala nie funkcja systemu, lecz sposób ograniczenia ryzyka. Zależność od jednego dostawcy przestaje być pułapką, a staje się decyzją, którą można w każdej chwili zmienić.
Podsumowanie
Vendor lock-in to koszt, który nie widnieje na fakturze, a potrafi przewyższyć cenę całego systemu. Powstaje cicho: przez brak dostępu do kodu i danych, zamknięte formaty i drogie integracje. Chroni się przed nim na początku, przez dostęp do danych, otwarte API, standardy i kontrolę nad kodem. Wybierając system, warto zadać jedno pytanie: ile będzie kosztowało wyjście?
Chcesz wiedzieć, jak ocenić otwartość systemu jeszcze przed przetargiem? Zobacz jak prowadzimy transformację cyfrową szpitala albo przejrzyj bazę wiedzy.