Testni sustav i certifikacija CEZIH softvera

Što je testni sustav i zašto postoji

Testna okolina izgledom kopira produkciju, ali radi s izmišljenim pacijentima i liječnicima koji ne postoje u stvarnim registrima. Tu proizvođač provjerava hoće li program ispravno slati i primati poruke prije nego ikad dotakne stvarnog pacijenta. Rad u testnoj okolini nije korak koji se može preskočiti ili zamijeniti vlastitim uvjerenjem da program radi kako treba.

Postupak pokreće proizvođač, ne HZZO. Kad tim koji razvija program procijeni da je spreman, prijavljuje provjeru spremnosti i dobiva termin za testiranje. Dotad program ostaje izvan popisa, bez obzira na to koliko dobro radi u vlastitim internim testovima developera.

Pristup testnoj okolini dobiva se tek nakon što proizvođač dostavi osnovnu dokumentaciju. Potreban je naziv tvrtke, kontakt osoba za tehnička pitanja i izjava o tome koje poruke program namjerava podržati. Nije isto podržavati samo slanje nalaza i podržavati cijeli krug, uključujući storno i zamjenu verzijom. Opseg prijave zato određuje i koliko će testnih slučajeva biti potrebno proći.

Koraci provjere spremnosti

Provjera prolazi kroz niz konkretnih testnih slučajeva u testnoj okolini. Redoslijed nije uvijek isti, ali popis radnji koje program mora odraditi jest.

• Prijava karticom AKD i prijava certifikatom u oblaku, oba načina odvojeno
• Dohvat podataka pacijenta i liječnika iz nadležnih registara
• Otvaranje nove posjete i slučaja
• Slanje kliničkog dokumenta vezanog za taj slučaj
• Zamjena poslanog dokumenta novom verzijom
• Storniranje pogrešno poslanog dokumenta
• Pretraga i ponovni dohvat već poslanih dokumenata

Svaka stavka mora proći pojedinačno – sustav ne priznaje djelomičan rezultat. Ako jedna od sedam provjeri padne, cijeli krug se ponavlja nakon što proizvođač ispravi grešku, ne samo ta jedna stavka. To proizvođače tjera da sami, unutar vlastitog tima, prođu isti popis prije prijave, umjesto da ga prvi put vide na dan provjere.

Dio tih testnih slučajeva zvuči trivijalno na papiru, a u praksi otkriva sitne propuste. Dohvat podataka pacijenta iz registra mora podnijeti i rubne situacije. Jedan primjer je pacijent s dva prebivališta zabilježena u različitim razdobljima. Program koji uzme samo prvi zapis bez provjere datuma pada na toj stavci. Osnovna funkcija dohvata pri tome može raditi uredno u devet od deset slučajeva. Upravo zato se provjera ne radi po uzorku, nego po cijelom propisanom popisu.

Nakon što program jednom prođe sve stavke, rezultat vrijedi za tu točno definiranu verziju programa. Svaka naredna izmjena koja utječe na razmjenu poruka s CEZIH-om, čak i manja, znači ponovnu prijavu i ponovni krug provjere, a ne samo obavijest da je verzija promijenjena.

Razlika između testne i produkcijske okoline

Testna okolina povremeno se čisti i podaci koje ste tamo stvorili ne ostaju trajno. Slučaj koji je jučer bio otvoren danas može biti nestao jer je tim CEZIH-a resetirao okolinu za novi krug provjera drugih proizvođača. Zato nije razumno čuvati u testu nešto na što ćete se osloniti tjednima unaprijed.

Isto vrijedi za testne pacijente i liječnike koje dobijete uz pristup. Njihovi podaci su smišljeni za provjeru rubnih slučajeva. Jedan nema OIB u standardnom formatu. Drugi ima dva aktivna osiguranja istovremeno. Program mora znati nositi se s takvim neurednim stvarnim stanjem, ne samo s urednim primjerom iz priručnika. Tim koji preskoči te rubne slučajeve u vlastitom testiranju obično ih prvi put susretne tek na dan provjere spremnosti. Tada je već kasno za mirno rješavanje.

Certifikat i vremenska usklađenost računala ponašaju se strože u produkciji nego u testu. Program koji je u testnoj okolini radio s certifikatom isteklim prije par sati, u produkciji odbija svaki pokušaj prijave bez jasne poruke o uzroku. Proizvođači koji to ne znaju unaprijed gube sate tražeći grešku u vlastitom kodu umjesto u datumu na serveru.

Brzina odgovora sustava razlikuje se isto tako. Testna okolina deli infrastrukturu s drugim proizvođačima koji istovremeno provode vlastite provjere. Odgovor na upit tad nekad kasni i po nekoliko sekundi, bez ikakve greške u pozadini. Tim koji to protumači kao kvar vlastitog programa gubi vrijeme popravljajući nešto što nije pokvareno. Razlika je samo u opterećenju okoline tog dana, ne u kodu.

Što nas je u razvoju najviše zbunilo

Dok smo radili na vlastitom CEZIH modulu, pretpostavili smo da storno dokumenta i njegova ispravljena nova verzija moraju ići pod istim slučajem, bez obzira na vremenski razmak između njih. U testnoj okolini je to prolazilo bez upozorenja. U produkciji je isti slijed, poslan nekoliko dana kasnije nego u testu, tražio da se prije ispravka otvori novi slučaj – jer je stari u međuvremenu zatvoren automatski.

Poruka greške nije objašnjavala zašto, samo da slučaj ne postoji. Trebalo je nekoliko sati razgovora s podrškom da povežemo kašnjenje s automatskim zatvaranjem. Od tada svaku promjenu provjeravamo zasebno u testu i u produkciji, i ne pretpostavljamo da se jedno ponaša isto kao drugo samo zato što su test slučajevi identični.

Druga stvar koja nas je iznenadila bila je stroga provjera redoslijeda. To se odnosi na slanje više dokumenata za istog pacijenta u kratkom razmaku. Pretpostavili smo da sustav sam sortira poruke prema vremenu kad su stvarno nastale. Nije tako. Odlučujuće je vrijeme kad su poruke stigle na red za obradu, ne vrijeme njihovog nastanka u programu. Kod sporije mrežne veze to zna okrenuti redoslijed. Situacija tada izgleda kao greška, a zapravo je samo posljedica kašnjenja negdje usput.

Koliko traje postupak i zašto kasni

Trajanje provjere ovisi o tri stvari. Koliko je program kompletan prije prijave, koliko brzo proizvođač reagira na primjedbe i koliko je red čekanja pun u trenutku prijave. Točan rok ne obećavamo. Viđali smo brze provjere u danima, a i spore koje su se protegnule kroz mjesece zbog ponavljanja istog koraka.

Najčešći razlog kašnjenja nije sam kod programa, nego administrativni dio. Certifikat ili iskaznica često još nisu izdani u trenutku prijave. Ili tim prijavi provjeru prerano, pa prvi pokušaj padne na osnovnom koraku. Svaka veća nadogradnja postojećeg programa kasnije traži novi krug provjere – ne samo prvi put kad se proizvođač pojavi na popisu.

• Dokumentacija o opsegu poruka nepotpuna ili promijenjena nakon prijave
• Certifikat u oblaku ili iskaznica AKD još nisu stigli do tima koji testira
• Prijava prerana, prije nego su svi testni slučajevi interno provjereni
• Promjena verzije programa tijekom samog postupka provjere

Nijedan od tih razloga nije iznenađenje za nekoga tko je prošao postupak jednom. Za tim koji to radi prvi put, ipak, svaki zna izgledati kao nepredviđen zastoj. Riječ je o poznatim i čestim uzrocima. Svi se mogu provjeriti unaprijed, prije nego se zatraži termin.

eDoktor priprema vlastiti CEZIH modul uz online naručivanje i portal nalaza, upravo kroz ovaj postupak. Rok ne obećavamo dok provjera ne prođe u cijelosti, u testu i u produkciji. Ako želite obavijest kad modul bude dostupan za vašu ordinaciju, javite se kroz partner stranicu eDoktora.

Tko tek bira program za ordinaciju, prije potpisa ugovora vrijedi provjeriti je li proizvođač doista proveden kroz ovaj postupak. Pregled kriterija donosimo u tekstu o odabiru softvera s popisa G500. Sam postupak povezivanja na sustav, od iskaznice do šifre ustanove, opisali smo u članku o povezivanju na CEZIH u pet koraka. Razliku između VPN-a i pristupa preko interneta pročitajte u tekstu o instalaciji CEZIH-a i VPN pristupu.

Izvori

• HLK – Povezivanje privatnih pružatelja zdravstvene zaštite na CEZIH
• CEZIH – službene stranice sustava
• Hrvatski zavod za zdravstveno osiguranje

Naslovna slika: Brett Sayles / Pexels