Wstęp
Najdroższy moment wymiany systemu HIS nie jest wpisany w fakturę za licencję. To stawka za eksport bazy, której nie ustalono w umowie pięć lat wcześniej — i którą poprzedni dostawca wycenia dopiero wtedy, gdy szpital nie ma już drogi odwrotu. W projektach cyfryzacji finansowanych z Krajowego Planu Odbudowy, rozliczanych do 31 maja 2026 roku, to właśnie etap przenoszenia danych — nie wybór oprogramowania — okazuje się punktem, w którym przedsięwzięcie najczęściej się załamuje.
Ten artykuł nie powtarza poradnika wyboru i wdrożenia HIS. Skupia się na jednym, najczęściej bagatelizowanym aspekcie zmiany: co dzieje się z danymi i jak nie uwięznąć u jednego dostawcy. To uzupełnienie szerszego przewodnika — jeśli stoisz dopiero przed decyzją zakupową, zacznij od tekstu o tym, jak wybrać oprogramowanie HIS i przeprowadzić wdrożenie bez chaosu. Tutaj zawężamy temat do zarządzania danymi, migracji i strategii wyjścia.
Czym naprawdę jest vendor lock-in w systemie HIS
Vendor lock-in to sytuacja, w której koszt lub ryzyko zmiany dostawcy oprogramowania jest tak wysoki, że placówka pozostaje przy obecnym systemie nie dlatego, że jest najlepszy, lecz dlatego, że wyjście stało się nieopłacalne lub technicznie niewykonalne. W szpitalu mechanizm ten nie sprowadza się do umowy licencyjnej. Zbudowany jest z czterech splecionych warstw: zamkniętego formatu bazy danych, autorskich interfejsów bez dokumentacji, uzależnienia od jednego zespołu serwisowego znającego konfigurację oraz braku zapisanej z góry ceny i trybu eksportu archiwum.
Różnica między uzależnieniem technologicznym w szpitalu a w typowej firmie polega na tym, że tu stawką nie jest tylko budżet IT. Niedostępna historia leczenia to bezpośrednie ryzyko kliniczne — przerwana terapia, brak informacji o uczuleniach, utracone wyniki sprzed lat. Dlatego ochrona przed lock-in nie jest decyzją finansową działu zakupów, lecz elementem zarządzania ryzykiem, za który odpowiada osobiście kierownik podmiotu leczniczego.
Migracja danych: gdzie projekt pęka najczęściej
Z doświadczeń placówek wymieniających HIS wynika powtarzalny wzorzec: poważne kryzysy nie pojawiają się na etapie ustaleń ani prezentacji handlowych, lecz w trakcie samego przenoszenia danych. To wtedy na światło dzienne wychodzą wieloletnie zaniedbania ukryte w bazie — niespójne słowniki medyczne, zduplikowane kartoteki tego samego pacjenta, rozjazdy w formatach zapisu rozpoznań i procedur.
Najgroźniejszy nie jest sam wolumen danych, lecz ich jakość. Surowy zrzut bazy z poprzedniego systemu nie jest migracją — to materiał, którego nowy system nie potrafi bezpiecznie zinterpretować. Rzeczywista migracja oznacza mapowanie świadczeń, ujednolicenie słowników i kontrolowaną weryfikację, że historia leczenia pozostała kompletna i czytelna dla lekarza kontynuującego terapię. Problem nasila się, gdy dane muszą trafić do środowiska złożonego z wielu aplikacji — szerzej opisuje to materiał o tym, jak połączyć HIS, LIS i RIS w jeden spójny ekosystem.
Tabela poniżej porządkuje najczęstsze punkty zapalne migracji i działania, które ograniczają ryzyko.
| Punkt zapalny | Objaw podczas migracji | Działanie zabezpieczające |
|---|---|---|
| Zduplikowane kartoteki | Jeden pacjent jako kilka rekordów; rozproszona historia | Deduplikacja i reguły scalania przed startem, nie po |
| Niespójne słowniki | Te same rozpoznania w różnych formatach i klasyfikacjach | Mapowanie do jednolitej klasyfikacji, słownik konwersji |
| Brak mapowania świadczeń | Luki w rozliczeniach, niekompletna sprawozdawczość | Tabela mapowań uzgodniona z działem rozliczeń |
| Format archiwum | Dane historyczne nieczytelne w nowym systemie | Wymóg ustrukturyzowanego eksportu od dotychczasowego dostawcy |
| Brak właściciela danych | Nikt nie odpowiada za poprawność po wczytaniu | Imienne przypisanie odpowiedzialności za walidację |
Strategia wyjścia od pierwszego dnia umowy
Najskuteczniejsza ochrona przed vendor lock-in powstaje zanim dojdzie do uzależnienia — na etapie negocjowania umowy, a nie w momencie, gdy placówka chce odejść. Strategia wyjścia wpisana do kontraktu od pierwszego dnia jest tańsza niż jakiekolwiek późniejsze negocjacje z pozycji słabszego.
Umowa wdrożeniowa powinna twardo regulować zasady organizacyjne i finansowe rozstania z dostawcą jeszcze zanim współpraca się rozpocznie. Brak wpisanej maksymalnej stawki za przyszły eksport danych prowadzi do najkosztowniejszej formy uzależnienia: szpital płaci nie za wartość, lecz za to, że nie zabezpieczył sobie drogi wyjścia.
Poniższe klauzule stanowią minimum kontraktowe chroniące przed lock-in.
| Klauzula | Co zabezpiecza | Konsekwencja braku |
|---|---|---|
| Maksymalna stawka za eksport bazy | Cena migracji wyjściowej znana z góry | Dowolna wycena przez dostawcę pod presją czasu |
| Format eksportu (ustrukturyzowany, otwarty) | Dane czytelne dla kolejnego systemu | Zrzut nieprzydatny operacyjnie |
| Gwarantowany czas i jakość wsparcia w okresie przejściowym | Ciągłość pracy podczas przepinania baz | Spadek SLA dokładnie wtedy, gdy najbardziej potrzebny |
| Własność i prawo do danych | Brak wątpliwości, czyje są dane | Spór o dostęp do własnej historii leczenia |
| Zobowiązanie do dokumentacji integracji | Kolejny dostawca rozumie konfigurację | Wiedza tylko w głowach jednego zespołu serwisowego |
Otwarte standardy jako polisa: HL7, FHIR, DICOM
Najtańsza polisa przeciw uzależnieniu nie jest klauzulą prawną, lecz wymaganiem technicznym postawionym na etapie wyboru: system musi natywnie posługiwać się międzynarodowymi standardami wymiany danych. HL7 i jego nowsza odsłona FHIR odpowiadają za dane kliniczne i administracyjne, DICOM — za obrazowanie medyczne. System trzymający się tych standardów można podmienić; system zamknięty w autorskim środowisku trzeba wykupić ponownie razem z migracją.
Tworzenie przez producentów zamkniętych, autorskich środowisk to droga, która w przyszłości drastycznie podnosi koszt każdej zmiany. Na etapie wyboru nie wystarczy słowna deklaracja przedstawiciela handlowego o „gotowości do integracji”. Trzeba zweryfikować, które interfejsy działają już produkcyjnie w innych szpitalach, a które dopiero zostałyby dopisane — co oznacza prace programistyczne na żywym organizmie i kolejną warstwę uzależnienia od konkretnego wykonawcy.
EDM, EHDS i interoperacyjność — stan prawny, który wymusza otwartość
Wymóg interoperacyjności przestał być argumentem technicznym, a stał się obowiązkiem prawnym z konkretnym harmonogramem. Dla placówki planującej wymianę HIS oznacza to, że system zamknięty jest nie tylko ryzykowny biznesowo, ale i prawnie nietrwały — nie sprosta nadchodzącym wymogom wymiany danych.
Stan prawny na maj 2026 roku wyznaczają trzy nakładające się reżimy. Krajowy: rozporządzenie Ministra Zdrowia z 9 lipca 2025 r. (Dz.U. 2025 poz. 930) rozszerzyło katalog elektronicznej dokumentacji medycznej o kartę medycznych czynności ratunkowych i kartę medyczną lotniczego zespołu ratownictwa medycznego, obowiązkowe od 1 stycznia 2026 r. Akredytacyjny: od 1 maja 2026 r. Centrum Monitorowania Jakości w Ochronie Zdrowia przy ocenie nie uwzględnia dokumentacji papierowej — bez pełnej EDM placówka traci szansę na certyfikat. Unijny: rozporządzenie EHDS (UE) 2025/327 z 11 lutego 2025 r. weszło w życie 26 marca 2025 r., a kluczowe obowiązki wymiany danych zaczną być stosowane stopniowo. Pełen zakres obowiązków dokumentacyjnych zbiera osobny przegląd najważniejszych obowiązków EDM na 2026 rok, a stronę praktyczną wymiany z platformą centralną — poradnik o tym, jak prawidłowo korzystać z platformy P1.
Tabela poniżej zestawia terminy, które każda decyzja o wyborze systemu powinna uwzględniać z wyprzedzeniem.
| Termin | Reżim | Co zaczyna obowiązywać |
|---|---|---|
| 1 stycznia 2026 | Krajowy (EDM) | Obowiązkowe nowe typy EDM: KMCR i KMLZRM |
| 1 maja 2026 | Akredytacja CMJ | Dokumentacja papierowa nieuwzględniana w ocenie |
| 31 maja 2026 | KPO | Termin rozliczenia projektów cyfryzacji z KPO |
| 26 marca 2029 | Unijny (EHDS) | Wymiana priorytetowych kategorii: Patient Summary, e-recepty |
| 26 marca 2031 | Unijny (EHDS) | Wymiana badań obrazowych, wyników, wypisów ze szpitali |
Awaria i ciągłość działania — drugi wymiar ryzyka danych
Uzależnienie od dostawcy ujawnia się nie tylko przy planowej wymianie, ale i w sytuacji awaryjnej. Gdy system zamknięty przestaje działać, placówka nie ma jak samodzielnie odzyskać dostępu do danych — jest zdana na czas reakcji jednego zespołu serwisowego. Dlatego ocenę odporności systemu warto połączyć z analizą, czy ubezpieczenie pokryje straty wynikające z przestoju systemów IT. Plan ciągłości działania i strategia wyjścia to dwa elementy tej samej polisy: zachowania kontroli nad własnymi danymi niezależnie od kondycji dostawcy.
Checklista wymagań bezwzględnych przed podpisem umowy
Przed złożeniem podpisu pod dokumentami inwestycyjnymi warto skonfrontować ofertę z twardą listą wymagań, które muszą zostać udowodnione, a nie tylko zadeklarowane. Pełną, rozszerzoną wersję tej checklisty — z polami do odhaczenia i miejscem na notatki negocjacyjne — przygotowaliśmy jako materiał do pobrania.
- Maksymalna stawka i ustrukturyzowany format eksportu bazy wpisane do umowy
- Interfejsy wymiany danych działające produkcyjnie w innych szpitalach, potwierdzone u referencyjnego klienta
- Natywne wsparcie HL7/FHIR i DICOM, zweryfikowane technicznie, nie deklaratywnie
- Gwarantowany czas i jakość wsparcia w okresie przejściowym przepinania baz
- Imienne przypisanie odpowiedzialności za walidację danych po migracji
- Plan zgodności z harmonogramem EDM i EHDS na lata 2026–2031
Pobierz pełną checklistę migracji HIS
Gotowa do druku checklista migracji danych i ochrony przed vendor lock-in — komplet klauzul kontraktowych, punktów zapalnych migracji i harmonogram prawny. Materiał na spotkanie negocjacyjne z dostawcą.
FAQ
Co to jest vendor lock-in w systemie HIS?
Vendor lock-in to uzależnienie placówki od jednego dostawcy oprogramowania, w którym koszt lub ryzyko zmiany systemu jest tak wysokie, że szpital pozostaje przy obecnym rozwiązaniu mimo jego wad. W HIS budują go zamknięty format bazy, autorskie interfejsy, uzależnienie od jednego zespołu serwisowego oraz brak ustalonej z góry ceny eksportu danych.
Jak długo przechowuje się dokumentację medyczną?
Co do zasady dokumentację medyczną przechowuje się 20 lat, licząc od końca roku kalendarzowego, w którym dokonano ostatniego wpisu, z wyjątkami przewidzianymi w przepisach (m.in. krótszymi terminami dla skierowań oraz dłuższym okresem dla niektórych kategorii danych). Przy wymianie HIS oznacza to, że migracja musi obejmować pełen wymagany okres archiwizacji, a nie tylko dane bieżące.
Czy nowy system HIS musi być zgodny z EHDS?
Tak. Rozporządzenie EHDS (UE) 2025/327 weszło w życie 26 marca 2025 r., a obowiązki wymiany kluczowych danych będą stosowane stopniowo — od 26 marca 2029 r. dla Patient Summary i e-recept, a od 26 marca 2031 r. dla badań obrazowych, wyników i wypisów. System zamknięty, niezgodny ze standardami wymiany, nie sprosta tym wymogom.
Od kiedy obowiązuje pełna elektroniczna dokumentacja medyczna w szpitalu?
Obowiązek prowadzenia EDM funkcjonuje od kilku lat, ale w 2026 roku nabiera nowego znaczenia. Od 1 stycznia 2026 r. obowiązkowe stały się nowe typy EDM (KMCR i KMLZRM), a od 1 maja 2026 r. Centrum Monitorowania Jakości w Ochronie Zdrowia nie uwzględnia w ocenie akredytacyjnej dokumentacji papierowej.
Jak zabezpieczyć się przed vendor lock-in przy wyborze HIS?
Najskuteczniej — kontraktowo i technicznie jednocześnie. W umowie należy zapisać maksymalną stawkę i otwarty format eksportu bazy, własność danych oraz gwarancję wsparcia w okresie przejściowym. Technicznie — wymagać natywnego wsparcia standardów HL7/FHIR i DICOM, zweryfikowanego produkcyjnie u innego klienta, a nie zadeklarowanego w prezentacji.
Źródła
- Rozporządzenie Ministra Zdrowia z dnia 9 lipca 2025 r. zmieniające rozporządzenie w sprawie rodzajów elektronicznej dokumentacji medycznej (Dz.U. 2025 poz. 930)
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2025/327 z dnia 11 lutego 2025 r. w sprawie europejskiej przestrzeni danych dotyczących zdrowia (EHDS)
- Komunikat Centrum Monitorowania Jakości w Ochronie Zdrowia w sprawie elektronicznej dokumentacji medycznej w procesie akredytacji (obowiązuje od 1 maja 2026 r.)
- Ustawa z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia (przepisy o elektronicznej dokumentacji medycznej i jej wymianie)
- Centrum e-Zdrowia — materiały i komunikaty dla beneficjentów Krajowego Planu Odbudowy dotyczące cyfryzacji podmiotów leczniczych (2026)
tm, fot abcs