Testiranje domene HealthCare s uzorcima testnih slučajeva

Prije nego počnemo s testiranjem, proučimo na brzinu osnovno znanje o domeni zdravstvene zaštite.

Testiranje domene HealthCare

Testiranje zdravstvene domene je postupak testiranja zdravstvenih aplikacija za različite čimbenike kao što su standardi, sigurnost, usklađenost, unakrsna ovisnost s drugim subjektima, itd. Svrha testiranja zdravstvene domene je osigurati kvalitetu, pouzdanost, izvedbu, sigurnost i učinkovitost zdravstvene aplikacije.

Osnovna znanja iz područja zdravstvene njege

Cijeli zdravstveni sustav isprepleten je jednim tijelom, a to je bolnica ili pružatelj usluga (liječnik).

Dok ostali entiteti uključuju-

• Osiguravajuće društvo: Medicare, Medicaid, BCBS itd.
• Pacijent/potrošači: Pacijent upisan
• Regulatorno tijelo: HIPAA, OASIS procjena, CMS-1500 i UB-04, itd.
• Dobavljači rješenja za zdravstvenu njegu i životnu znanost

💡 Napomena: U starijem materijalu ovi se obrasci zahtjeva nazivaju HCFA-1500 i UB-92. Oba su zamijenjena: HCFA-1500 postao je CMS-1500, a UB-92 zamijenjen je s UB-04. Koristite trenutna imena prilikom pisanja testnih slučajeva.

Osnovno nazivlje zdravstvenog sustava

• Davatelj: zdravstveni djelatnik (liječnik), medicinska skupina, klinika, laboratorij, bolnica itd. licenciran od strane zdravstvenih službi
• Zahtjev: Zahtjev vašem zdravstvenom osiguravajućem društvu za plaćanje računa za zdravstvene usluge
• broker: Osiguravatelj, koji pregovara, pribavlja osiguranje u ime osiguranika ili potencijalnog osiguranika
• Finance: Osiguravajuća tijela koja plaćaju medicinske troškove, mogu biti državna (Medicare ili Medicaid) ili komercijalna (BCBS)
• Zdravstvena zaštita: Savezni program zdravstvenog osiguranja za starije građane i osobe s trajnim invaliditetom
• Medicaid: Zajednički savezni i državni program koji pomaže obiteljima i pojedincima s niskim primanjima da plate troškove povezane s medicinskom skrbi
• CPT kod: Trenutačni kodeks proceduralne terminologije medicinski je kodeks koji opisuje medicinske, kirurške i dijagnostičke usluge
• Hipaa: To je skup pravila i propisa kojih se liječnici, bolnice, pružatelji zdravstvenih usluga i zdravstveni plan moraju pridržavati kako bi pružili svoje usluge

Ključni zdravstveni standardi koje tester treba znati

Osim HIPAA-e, nekoliko standarda oblikuje što zdravstvena aplikacija mora raditi i stoga što se mora testirati. Prepoznavanje svakog od njih govori vam koju vrstu testa pokreće.

Standard	Vlada	Testiranje pogona
Hipaa	Privatnost i sigurnost podataka o pacijentima	Kontrola pristupa, enkripcija, revizijski trag
HL7 v2 / v3	Poruke između kliničkih sustava	Testiranje formata poruke i sučelja
FHIR	Moderna REST API razmjena zdravstvenih zapisa	API kontract i testiranje interoperabilnosti
DICOM	Pohrana i prijenos medicinskih slika	Integritet slike i integracija uređaja
MKB-10 / CPT	Dijagnoza i kodiranje postupka	Validacija tvrdnji i testiranje negativnog puta
CMS-1500 / UB-04	Profesionalni i institucionalni obrasci zahtjeva	Podnošenje zahtjeva i validacija polja

Poslovni proces u zdravstvu

Većina zdravstvenih organizacija usvojila je softverske programe za podršku nesmetanom funkcioniranju sustava. Ovaj softverski sustav pruža sve informacije u jednom dokumentu za svaki entitet koji se time bavi.

Povezivanje cijelog ovog sustava s jednom web aplikacijom ogroman je zadatak, a učiniti ga učinkovitim radom još je veći zadatak. Rigorozno testiranje ove zdravstvene aplikacije je obavezno i ​​mora proći kroz različite faze testiranja.

U donjim odjeljcima redom su navedeni primjeri scenarija i testni slučajevi za svaki podsustav.

Testiranje sustava pružatelja usluga

Ogledni testni scenariji i testni slučajevi za pružatelje (liječnik/bolnica) sustav:

Sr#	Testni scenarij	Testni slučajevi
1)	Pristup sustavu pružatelja usluga	Sustav pružatelja usluga trebao bi nam omogućiti unos, uređivanje i spremanje podataka pružatelja usluga
2)	Pozitivan protok Ispitivanje sustava	Uključuje scenarije za unos različitih vrsta pružatelja usluga, promjenu detalja pružatelja usluga, njihovo spremanje i traženje
3)	Ispitivanje sustava s negativnim protokom	Omogućuje spremanje informacija o pružatelju usluga s nepotpunim podacima, contracdatum stupanja na snagu, unos podataka o postojećim pružateljima usluga u sustav
4)	sistem Ispitivanje integracije	Potvrdite feed do sustava članova, financijskog sustava, sustava potraživanja i portala pružatelja usluga. Također provjerite jesu li promjene s portala pružatelja usluga unesene u zapis dotičnog pružatelja usluga
5)	Testiranje portala pružatelja pozitivnih protoka	Prijavite se i pogledajte pojedinosti pružatelja usluga, status zahtjeva i pojedinosti o članu Podnesite zahtjev za promjenu imena, adrese, broja telefona itd.
6)	Testiranje portala pružatelja negativnih protoka	Pregledajte podatke o članu s nevažećim ID-om Prijavite se nevažećim vjerodajnicama
7)	Testiranje portala Positive flow Broker	Prijavite se i pogledajte detalje o brokeru i plaćanju provizije Podnesite zahtjev za promjenu imena, adrese, broja telefona itd.
8)	Negative flow Broker portal testiranje	Treba uključiti scenarije za prijavu s nevažećim vjerodajnicama

Testiranje brokerskog sustava

Primjeri testnih scenarija i testnih slučajeva za Broker System:

Sr#	Testni scenarij	Testni slučajevi
1)	Brokerski sustav	Trebao bi moći uređivati, unositi i spremati podatke brokera Izračun brokerske provizije na temelju podataka o plaćanju premije iz sustava za članove
2)	Ispitivanje sustava pozitivnog protoka	Unesite, spremite i uredite zapis brokera za različite vrste brokera Za aktivne brokere izračunajte proviziju stvaranjem feed datoteke s odgovarajućim zapisom za članove s drugačijim planom
3)	Ispitivanje sustava s negativnim protokom	Unesite brokerski zapis s nepotpunim podacima i spremite za različite vrste brokera Stvaranjem feed datoteke s odgovarajućim zapisom za članove s različitim planom izračunajte proviziju za raskinutog brokera Stvaranjem feed datoteke s odgovarajućim zapisom za članove s različitim planom izračunajte proviziju za nevažećeg brokera
4)	Ispitivanje sustava	Za nizvodni sustav, kao što je financijski sustav, brokerski portal i sustav za članove, potvrdite feedove Provjerite jesu li promjene s brokerskog portala uključene u odnosni brokerski zapis

Testiranje sustava članova

Primjeri testnih scenarija i testnih slučajeva za sustav za članove (pacijente).:

Sr#	Testni scenarij	Testni slučajevi
1)	Članski sustav	Učlanite, ponovno aktivirajte i isključite člana Uklonite i dodajte uzdržavanu osobu Generirajte premium račun Obradite plaćanja premija
2)	Ispitivanje sustava pozitivnog protoka	S trenutnim, prošlim i budućim datumima stupanja na snagu upišite različite vrste članova Raspitajte se i promijenite članove Izradite premium račun za aktivnog člana za sljedeći mjesec Raskinite aktivnog člana s prošlim, sadašnjim i budućim datumima raskida većim od datuma stupanja na snagu Ponovno učlanite prekinutog člana s trenutnim, prošlim i budućim datumima stupanja na snagu Ponovno uključivanje isključenog člana
3)	Ispitivanje sustava s negativnim protokom	Uz nedovoljno podataka učlanite člana Za člana koji je prekinut, napravite račun za premiju za sljedeći mjesec
4)	Testiranje integracije sustava	Potvrdite feed do nizvodnih sustava kao što su portal pružatelja usluga, portal brokera, financijski sustav i sustav potraživanja Provjerite jesu li izmjene s portala za članove uključene u odgovarajući zapis o članu Obradite plaćanje premijskog računa generiranog s feedom s portala za članove koji sadrži pojedinosti o izvršenoj uplati

Testiranje sustava potraživanja

Primjeri testnih scenarija i testnih slučajeva za Claims System:

Sr#	Testni scenariji	Testni slučajevi
1)	Sustav potraživanja	Zahtjevi u zdravstvu trebaju uređivati, unositi i obrađivati ​​zahtjeve za člana kao i uzdržavane osobe Za nevažeće zahtjeve trebao bi izbaciti pogreške kada se unesu netočni podaci
2)	Ispitivanje sustava pozitivnog protoka	Trebao bi uključivati ​​scenarij za uređivanje, unos i obradu zahtjeva za člana kao i uzdržavane osobe
3)	Ispitivanje sustava negativnog protoka	Treba potvrditi i unijeti zahtjev s nevažećim kodom postupka i kodom dijagnoze Potvrdite i unesite zahtjev s neaktivnim ID-om pružatelja usluga Potvrdite valjanost i unesite zahtjev za otkazanim članom
4)	Integracija sustava	Trebao bi uključivati ​​scenarij za provjeru valjanosti feeda prema nizvodnim sustavima kao što su pružatelj usluga i financijski portal

Testiranje financijskog sustava

Primjeri testnih scenarija i testnih slučajeva za Financijski sustav

Sr#	Testni scenariji	Testni slučajevi
1)	Financijski sustav	Učlanite, ponovno aktivirajte i isključite člana
2)	Ispitivanje sustava pozitivnog protoka	Treba provjeriti je li izabran ispravan broj računa ili adresa za dotičnog člana, pružatelja usluga ili posrednika za plaćanje
3)	Ispitivanje sustava s negativnim protokom	Provjerite je li plaćanje izvršeno za nevažeći ID člana, davatelja ili brokera stvaranjem odgovarajućeg zapisa u feedu Provjerite je li izvršeno plaćanje za nevažeći iznos za člana, pružatelja usluge ili brokera stvaranjem odgovarajućih zapisa u feedu

Ispitivanje usklađenosti s propisima

Zaštita osjetljivih podataka pacijenata i zdravstvenih informacija najveći je prioritet za regulatorna zdravstvena tijela. Ispitivanje treba provoditi u skladu s takvim regulatornim tijelima.

Primjeri testnih scenarija i testnih slučajeva za usklađenost s propisima:

Sr#	Testni scenariji	Testni slučajevi
1)	Autentifikacija korisnika	Korištenje metode provjere kako bi se osiguralo da ispravni korisnici dobiju prijavu i zabranili drugima
2)	Otkrivanje informacija	Odobravanje pristupa informacijama temelji se na ulozi korisnika i ograničenjima pacijenta
3)	Prijenos podataka	Na svim točkama prijenosa osigurajte šifriranje podataka
4)	Revizijski trag	Bilježe se sve transakcije i svi pokušaji pristupa podacima s odgovarajućim skupom podataka revizijskog traga
5)	Testiranje uračunljivosti povezano s regulatornim tijelom	Provedite testiranje ispravnosti i provjerite je li enkripcija podataka učinjena u određenim područjima kao što je EPHI (Electronic Protected Health Information)

Testiranje izvedbe zdravstvene aplikacije

Prije pripreme testnih scenarija treba uzeti u obzir određene zahtjeve sustava. Na primjer, pružatelji zdravstvene zaštite (liječnici/bolnice) pružaju skrb 24/7, tako da softver za prijavu pacijenata mora biti dostupan u svakom trenutku. Također, mora komunicirati s osiguravajućim društvima radi provjere informacija o policama, slanja zahtjeva i primanja uplata. Ovdje bi arhitektura trebala definirati različite komponente sustava, protokol za komunikaciju s osiguravajućim društvima i kako implementirati sustav tako da bude u skladu s propisima 24/7.

Kao tester, trebate osigurati da zdravstveni softverski sustav zadovoljava željenu referentnu vrijednost opterećenja/performansi.

Druge vrste testiranja za primjenu u zdravstvu

• Funkcionalno ispitivanje: Testiranje zdravstvene aplikacije u odnosu na funkcionalne mogućnosti
• Ispitivanje sukladnosti: Test sukladnosti Zahtjevi zdravstvene zaštite i industrijski okviri
• Testiranje platforme: Testiranje aplikacija na Kontakt broj testiranje platformi i aplikacija za kompatibilnost s više preglednika
• Ispitivanje interoperabilnostiTestiranje usklađenosti sa standardima interoperabilnosti (npr. DICOM, HL7, CCD/CDA)

Izazovi testiranja u primjeni u zdravstvu

Izazovi testiranja u testiranju zdravstvenih aplikacija ne razlikuju se od ostalih testiranja web aplikacija.

• Zahtijeva stručnost u testiranju i obično je visoka cijena
• Zahtijeva interoperabilnost, usklađenost, regulatorno, sigurnosno i sigurnosno testiranje osim uobičajenih tehnika testiranja (nefunkcionalno, funkcionalno i integracijsko testiranje)
• Testiranje treba obavitiping imajući na umu sigurnosne i regulatorne standarde - jer svaka pogreška može izravno utjecati na život pacijenta
• Tim za testiranje mora biti dobro svjestan različitih funkcionalnosti, kliničke upotrebe i okruženja za koje će se softver koristiti
• Zdravstveni proizvod mora biti u skladu s raznim standardima kao što su FDA, ISO i CMMI prije nego što se može koristiti
• Unakrsna ovisnost testera softvera mora osigurati da bilo kakve promjene u jednoj komponenti ili sloju ne dovedu do nuspojava na drugoj.

Ispitivanje zdravstvenih uređaja

Iako softver zdravstvenih uređaja nije izravna briga pacijenta, on također zahtijeva rigorozno testiranje kao i svaki drugi softver. Na primjer, rendgenski uređaji kojima upravljaju softverski programi trebaju biti dobro testirani jer svaka pogreška u testiranju softvera može dovesti do ozbiljnih posljedica za pacijenta.

FDA (Food and Drug Administration) ima smjernice za mobilne i web aplikacije za medicinske uređaje. Tijekom ispitivanja ispravnosti medicinskih uređaja Plan testiranja zajedno s kriterijima za prolaz i pad također je dio FDA smjernica. Kada se plan testiranja izvrši, rezultati se prikupljaju i prijavljuju FDA-i. Ovaj proces osigurava da uređaj zadovoljava standarde regulatornih tijela.

Korisni savjeti za testiranje u zdravstvu

Dok testirate softver, možete razmotriti neke važne savjete za testiranje zdravstvenog sustava.

• Datumi su važni i moraju biti točni
• Dok dizajnirate testne slučajeve, uzmite u obzir različite parametre poput različitih vrsta planova, brokera, članova, provizije itd.
• Potrebno je potpuno poznavanje domene
• Nikada ne koristite žive pacijentove zapise kao testne podatke. Koristite anonimizirane ili sintetičke podatke, jer kopiranje produkcijskih zaštićenih zdravstvenih podataka u testno okruženje samo po sebi predstavlja kršenje HIPAA-e.

Pitanja i odgovori