Vendor lock-in: ukryty koszt zamkniętego systemu medycznego
Laboratorium szpitala dostaje nowy analizator. Żeby wyniki trafiały do dokumentacji pacjenta, analizator trzeba połączyć z systemem szpitalnym. Wycenę, termin i kolejkę ustala jeden podmiot: dostawca systemu, bo tylko on zna strukturę bazy danych. Tak wygląda vendor lock-in, czyli uzależnienie od jednego dostawcy. Na fakturze za system go nie widać. Widać go przy każdej zmianie: nowym sprzęcie, nowym systemie dziedzinowym, próbie wyjęcia własnych danych albo odejścia do innego dostawcy.
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, bo wiedzę techniczną o systemie i o strukturze danych ma tylko dostawca. Uzależnienie nie siedzi w aplikacji, siedzi w bazie danych.
Skala zmienia wagę problemu. W przychodni z jednym systemem gabinetowym wyjście to głównie przeniesienie danych z jednego miejsca. Szpital ma system szpitalny, laboratorium, diagnostykę obrazową, aptekę i rozliczenia, połączone ze sobą integracjami, więc każdy z tych systemów wiąże pozostałe. Więcej o tym, jak rozwiązania IT dobiera się do wielkości placówki, w artykule Kwestia skali: IT a wielkość placówki.
Lock-in rzadko jest czyimś błędem. Zwykle to skutek decyzji sprzed lat, których konsekwencji nikt wtedy nie policzył.
Jak powstaje lock-in
Uzależnienie nie pojawia się nagle. Narasta przez kilka typowych mechanizmów:
- Brak dostępu do danych. Szpital kupuje licencję na używanie systemu, ale nie ma pełnego dostępu do własnych danych ani opisu ich struktury. 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 i kolejność.
- Stare kontrakty. Umowy sprzed lat często nie zawierają klauzul o eksporcie danych, przekazaniu dokumentacji ani warunkach wyjścia. Problem ujawnia się dopiero, gdy szpital chce 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 |
|---|---|---|
| Zmiana dostawcy | Migracja danych z zamkniętego formatu, odtworzenie integracji, ryzyko utraty historii | Koszt wyjścia wyższy, niż zakładano przy zakupie |
| 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 da się bezpiecznie utrzymać i którego nie da się szybko zastąpić. To nie jest już tylko problem działu IT. Zabezpieczenie dokumentacji medycznej wymaga dbałości o aktualizację oprogramowania (§ 1 ust. 5 pkt 4 rozporządzenia Ministra Zdrowia w sprawie rodzajów, zakresu i wzorów dokumentacji medycznej oraz sposobu jej przetwarzania), a RODO wymaga środków bezpieczeństwa adekwatnych do ryzyka i uwzględniających stan wiedzy (art. 32 ust. 1 RODO). Szpital, który jest podmiotem kluczowym albo ważnym w rozumieniu ustawy o krajowym systemie cyberbezpieczeństwa, ma w systemie zarządzania bezpieczeństwem informacji zapewnić regularne aktualizacje oprogramowania (art. 8 ust. 1 pkt 5 lit. b ustawy o KSC) oraz bezpieczeństwo i ciągłość łańcucha dostaw, w tym relacji z dostawcą oprogramowania (art. 8 ust. 1 pkt 2 lit. e). Za te obowiązki odpowiada kierownik podmiotu, także gdy powierzył je innej osobie (art. 8c ust. 1 i 3 ustawy o KSC).
Koszt migracji łatwo niedoszacować. Na papierze to przeniesienie danych. W praktyce to odtworzenie lat integracji, konfiguracji i wiedzy, której nikt nie spisał, a przez okres przejściowy stary i nowy system działają równolegle, więc szpital płaci za oba. Do tego dochodzi archiwum: dokumentację z wyłączonego systemu trzeba umieć odczytać przez cały okres jej przechowywania. Migracja danych to prawdziwa bariera wyjścia.
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 wymóg prawny: system, w którym prowadzi się dokumentację medyczną, ma umożliwiać eksport całości danych w standardach i formatach pozwalających odtworzyć je w innym systemie (§ 1 ust. 6 pkt 8 rozporządzenia w sprawie dokumentacji medycznej). Gdy dostawca przetwarza dane w imieniu szpitala, umowa powierzenia określa, że po zakończeniu usług zwraca albo usuwa dane, zależnie od decyzji szpitala (art. 28 ust. 3 lit. g RODO).
- Otwarte REST API. System powinien udostępniać udokumentowane REST API z kontrolą uprawnień i dziennikiem zdarzeń, dzięki któremu integracje robi się bez czekania w kolejce u jednego dostawcy. Otwarte API nie oznacza publikowania kodu ani bazy bez hasła. Oznacza, że inny system, po nadaniu uprawnień, może się połączyć według opisanych zasad, a każde odczytanie danych zostaje zapisane.
- Standardy zamiast formatów własnych. Dokumentację prowadzi się i udostępnia w formatach i standardach wydanych przez ministra, a gdy ich brak, w standardach HL7 oraz DICOM lub innych (§ 1 ust. 6 pkt 6 rozporządzenia w sprawie dokumentacji medycznej). Standardy oznaczają, że dane są przenośne i zrozumiałe poza jednym systemem.
- Dane u szpitala, zasady w umowie. Dane są szpitala, oprogramowanie jest na licencji. Najmocniejsza ochrona to umowa, która zapisuje eksport danych, dokumentację struktury danych i warunki wyjścia, a gdy szpital zamawia prace rozwojowe, także zakres dostępu do kodu warstwy bazy danych w umowie rozwojowej. Wtedy zależność od dostawcy jest wyborem.
Te cztery punkty można sprawdzić jeszcze przed podpisaniem umowy. Wystarczy zapytać wprost: co się stanie, gdy zechcemy odejść? W jakim formacie i w jakim terminie odzyskamy dane? Jaką dokumentację struktury danych dostaniemy? Jak długo stary system będzie działał równolegle z nowym i ile kosztuje pomoc przy migracji? Jeśli odpowiedzi są mgliste, to też jest odpowiedź. Pełniejszą listę pytań zawiera PDF z pytaniami do dostawcy oprogramowania medycznego, a zapisy o eksporcie danych i wyjściu z umowy pomaga sprawdzić lista kontrolna umowy z dostawcą.
Jak to rozwiązujemy w OpenCare
OpenCare jest oprogramowaniem na licencji. Dane udostępniamy przez REST API, a dokumenty i zdarzenia medyczne wymieniamy w standardach HL7. Zalecamy, by szpital w każdej umowie, także z nami, wymagał dostępu do API na podstawie nadanych uprawnień i zapisu każdego odczytu danych w dzienniku zdarzeń. Nie nazywamy tego open source. Nazywamy to otwartą architekturą: dane są szpitala, a warunki wyjścia są zapisane w umowie, więc zależność od dostawcy staje się decyzją, którą można zmienić.
Pytanie przed kolejną umową
Dla zarządu dostęp do danych i otwarte API to sposób ograniczenia ryzyka. Zanim szpital przedłuży umowę albo wybierze nowy system, warto policzyć dwie liczby: ile kosztuje utrzymanie tego, co działa dziś, przez kolejne pięć lat, i ile kosztowałoby wyjście. Pierwszą pomaga policzyć kalkulator kosztu systemu na 5 lat. Drugą zna tylko dostawca, więc trzeba go o nią zapytać, zanim umowa zostanie podpisana. Co chcecie osiągnąć zmianą systemu i ile kosztuje was utrzymanie tego, który macie?
Pytania z tego artykułu warto zadać każdemu dostawcy, także nam. Zobacz, jak prowadzimy wdrożenie, albo przejrzyj bazę wiedzy.