"Integrujemy się z Waszym HIS." Ale jak?
To zdanie pojawia się w niemal każdej ofercie voicebota medycznego. Problem w tym, że "integracja" to słowo, pod którym mogą kryć się diametralnie różne architektury — od bezpośredniego API w czasie rzeczywistym, po plik CSV eksportowany raz na dobę i wczytywany przez bota.
Różnica między nimi nie jest technicznym szczegółem. To różnica między systemem, który nigdy nie pokaże pacjentowi zajętego slotu jako wolnego, a systemem, który doprowadzi do sytuacji, w której dwóch pacjentów dostaje potwierdzenie wizyty na ten sam termin.
Pięć typów "integracji" — od najszybszej do najwolniejszej
Typ 1: Natywna integracja API (REST/SOAP) — standard
Voicebot wywołuje API systemu HIS bezpośrednio. Każda operacja — sprawdzenie kalendarza, rezerwacja, anulowanie — to bezpośrednie zapytanie do HIS z natychmiastową odpowiedzią.
Latencja: 50–200 ms od zapytania do odpowiedzi HIS. Spójność danych: silna (strong consistency) — bot widzi aktualny stan HIS w momencie zapytania. Obsługa równoczesnych rezerwacji: optimistic locking na poziomie HIS — dwie równoległe próby rezerwacji tego samego slotu kończą się potwierdzeniem dla jednej i odmową dla drugiej.
Typ 2: Middleware/iPaaS (Zapier, Make, n8n)
Między voicebotem a HIS stoi platforma automatyzacji workflow. Zapytanie bota → middleware → HIS → middleware → bot.
Latencja: 500–2000 ms per operacja (każdy "zap" lub "scenario" ma własny czas przetwarzania). Spójność danych: eventualista (eventual consistency) — middleware może buforować dane, polling co X sekund zamiast real-time. Problem: Zapier i podobne narzędzia nie są zaprojektowane do obsługi transakcji medycznych w czasie rzeczywistym. Są narzędziami automatyzacji workflow — nie silnikami integracyjnymi dla danych wrażliwych.
Typ 3: Custom adapter layer (własna warstwa pośrednicząca)
Software house buduje własny mikroserwis między voicebotem a HIS. Elastyczniejszy niż iPaaS, ale:
Problem utrzymania: Każda aktualizacja API HIS (a polskie systemy jak Medisoft czy mMedica regularnie publikują nowe wersje) wymaga aktualizacji adaptera. Jeśli software house nie utrzymuje adaptera aktywnie — integracja się psuje po cichu, bez alarmu.
Typ 4: Webhooks jednostronne
HIS wysyła zdarzenia do bota (np. "wizyta odwołana"), ale bot nie może zapytać HIS o aktualny stan bez czekania na kolejne zdarzenie. Integracja jednostronna — bot widzi tylko to, o czym HIS zdecydował się poinformować.
Problem: Bot nie może sprawdzić w czasie rzeczywistym, czy slot jest wolny — musi polegać na ostatnim otrzymanym stanie, który może być nieaktualny.
Typ 5: Eksport pliku / CSV
HIS eksportuje kalendarz do pliku CSV raz na godzinę (lub raz na dobę). Bot wczytuje plik.
Latencja synchronizacji: do 60 minut lub więcej. Realny problem: Pacjent rejestrujący się o 10:47 może zobaczyć stan kalendarza z 10:00 — 47 minut nieaktualnych danych.
Realne konsekwencje w klinice: trzy scenariusze katastrofy
Scenariusz A: Podwójna rezerwacja
10:32:15 — Pacjent Jan dzwoni do bota. Bot sprawdza kalendarz przez middleware (polling sprzed 3 minut): slot u kardiologa w środę 14:00 jest wolny.
10:32:17 — Rejestratorka w tym samym momencie odbiera telefon i rezerwuje ten sam slot przez HIS.
10:32:19 — Bot potwierdza rezerwację Janowi. HIS — nie wiedząc o konflikcie — zapisuje oba wpisy, bo middleware nie użył optimistic locking.
W środę o 14:00 zjawia się dwóch pacjentów.
Scenariusz B: "Ghost appointment" — wizyta-duch
Pacjent rozmawia z botem, który przez middleware potwierdza rezerwację. W tym momencie middleware ma timeout — zapytanie do HIS nie dochodzi. Bot wysyła pacjentowi SMS z potwierdzeniem. HIS nie ma żadnej rezerwacji.
Pacjent przyjeżdża. W systemie nie ma jego wizyty. Rejestratorka jest bezradna.
Scenariusz C: RODO i dane zdrowotne przez pośrednika
Bot zbiera PESEL i specjalność wizyty (np. psychiatria) i przesyła to przez zewnętrzną platformę iPaaS do HIS. Te dane — obejmujące potencjalnie wskazanie na specjalność psychiatryczną — przechodzą przez serwery Zapier lub Make, które mogą być poza EOG.
Dane zdrowotne (art. 9 RODO) przetwarzane przez dodatkowego podprocessora bez DPA = naruszenie prawa.
Jak natywna integracja API eliminuje te ryzyka
| Problem | Middleware | Natywna integracja API |
|---|---|---|
| Latencja synchronizacji | 500–2000 ms (lub minuty przy polling) | 50–200 ms (real-time) |
| Podwójna rezerwacja | Ryzyko wysokie (brak distributed locking) | Eliminowane przez optimistic locking w HIS |
| Ghost appointment | Możliwe przy timeout middleware | Niemożliwe — brak potwierdzenia = brak wpisu |
| Dane przez pośrednika | Dodatkowy DPA wymagany | Dane przepływają tylko między botem a HIS |
| Awaria middleware | Integracja zrywa się mimo działania obu systemów | Brak single point of failure |
| Aktualizacja API HIS | Wymaga aktualizacji adaptera (zewnętrzna zależność) | Utrzymywana bezpośrednio przez dostawcę bota |
| Spójność danych | Eventual consistency | Strong consistency |
Checklist: jak zweryfikować architekturę integracji dostawcy?
Pytania, które warto zadać każdemu dostawcy voicebota przed podpisaniem umowy:
- "Czy Wasz bot wywołuje API naszego HIS bezpośrednio, czy przez warstwę pośredniczącą?"
- "Jak obsługujecie równoczesne próby rezerwacji tego samego slotu przez różne kanały?"
- "Jaka jest latencja między zapytaniem bota a odpowiedzią z HIS w Waszej architekturze?"
- "Co się dzieje z rezerwacją, jeśli HIS nie odpowie w ciągu 3 sekund?"
- "Przez czyje serwery przechodzą dane pacjenta podczas integracji?"
- "Kto i jak szybko aktualizuje integrację po nowej wersji API naszego HIS?"
FAQ — Integracja natywna API vs. middleware
Czy natywna integracja API wymaga specjalnych uprawnień w naszym HIS? Tak — potrzebne jest konto API lub klucz dostępowy z odpowiednimi uprawnieniami (odczyt kalendarza, zapis rezerwacji, weryfikacja pacjenta). W większości polskich systemów HIS (Medisoft, mMedica, Comarch Optimed) takie konto tworzy administrator systemu w ciągu kilku minut.
Co jeśli nasz HIS nie ma publicznego API? Starsze systemy HIS bez publicznego API są rzadkością, ale istnieją. W takich przypadkach jedyne możliwe podejście to middleware lub — co lepsze — przejście na nowszą wersję HIS z API. Decyzja o wyborze voicebota to dobry moment, żeby ocenić, czy stary HIS nie staje się większym problemem niż brak automatyzacji.
Czy bezpośrednia integracja API oznacza, że dane kliniki są przechowywane u dostawcy voicebota? Nie — w modelu natywnej integracji dane rezerwacji i pacjenta są przechowywane w HIS kliniki. Voicebot wywołuje API HIS i przetwarza odpowiedź, ale nie jest repozytorium danych. To odwrotność modelu middleware, w którym dane przechodzą przez zewnętrzną infrastrukturę.
Podsumowanie: "Mamy integrację" to za mało. Pytaj: jak?
Natywna integracja API to nie przewaga techniczna dla inżynierów — to gwarancja operacyjna dla kliniki: że żaden pacjent nie dostanie potwierdzenia wizyty, która nie istnieje w systemie, i że żaden slot nie zostanie zarezerwowany dwukrotnie z powodu opóźnienia synchronizacji.
VoiceLink integruje się bezpośrednio z polskimi systemami HIS przez natywne API — bez pośredników, bez buforowania, bez dodatkowych podprocessorów danych. Sprawdź szczegóły architektury na demonstracji technicznej.
