Terveydenhuollon toimialueen testaus esimerkkitestitapauksilla

Ennen kuin aloitamme testauksen, tutkitaan nopeasti terveydenhuollon perustiedot.

Terveydenhuollon toimialueen testaus

Terveydenhuollon toimialueen testaus on prosessi, jolla testataan terveydenhuollon sovelluksia eri tekijöiden, kuten standardien, turvallisuuden, vaatimustenmukaisuuden, ristiriippuvuuden muiden yksiköiden kanssa jne. suhteen. Terveydenhuollon toimialueen testauksen tarkoituksena on varmistaa Healthcare-sovelluksen laatu, luotettavuus, suorituskyky, turvallisuus ja tehokkuus.

Terveydenhuollon perustiedot

Koko terveydenhuoltojärjestelmä on kudottu yhteen yhden tahon, eli sairaalan tai palveluntarjoajan (lääkärin), toimesta.

Vaikka muihin yksiköihin kuuluvat mm.

• Vakuutusyhtiö: Medicare, Medicaid, BCBS jne.
• Potilas/kuluttajat: Potilas ilmoittautunut
• Sääntelyviranomaiset: HIPAA, OASIS-arviointi, CMS-1500 ja UB-04 jne.
• Terveydenhuollon ja Life-Science-ratkaisujen toimittajat

💡 Huomaa: Vanhemmassa materiaalissa näihin vaatimuslomakkeisiin viitataan nimillä HCFA-1500 ja UB-92. Molemmat korvattiin: HCFA-1500:sta tuli CMS-1500 ja UB-92:n korvasi UB-04. Käytä nykyisiä nimiä testitapauksia kirjoittaessasi.

Terveydenhuoltojärjestelmän perusterminologia

• Tarjoaja: Terveydenhuollon ammattilainen (lääkäri), lääketieteellinen ryhmä, klinikka, laboratorio, sairaala jne., jolla on terveydenhuoltopalvelujen toimilupa
• vaatimus: Pyyntö sairausvakuutusyhtiöltäsi maksaa lasku terveydenhuoltopalvelusta
• Välittäjä: Vakuutusalan ammattilainen, joka neuvottelee, hankkii vakuutuksen vakuutetun tai mahdollisen vakuutetun puolesta
• Rahoitus: Vakuutuslaitokset, jotka maksavat sairauskulut, se voi olla hallitus (Medicare tai Medicaid) tai kaupallinen (BCBS)
• Medicare: Liittovaltion sairausvakuutusohjelma ikääntyneille ja pysyvästi vammaisille
• Medicaid: Yhteinen liittovaltion ja osavaltion ohjelma, joka auttaa pienituloisia perheitä ja yksilöitä maksamaan lääketieteelliseen hoitoon liittyvistä kustannuksista
• CPT-koodi: Nykyinen menettelyjen terminologiakoodi on lääketieteellinen koodi, joka kuvaa lääketieteellisiä, kirurgisia ja diagnostisia palveluita
• HIPAA: Se on joukko sääntöjä ja määräyksiä, joita lääkäreiden, sairaaloiden, terveydenhuollon tarjoajien ja terveyssuunnitelmien on noudatettava tarjotakseen palvelujaan

Keskeiset terveydenhuollon standardit, jotka testaajan tulisi tietää

HIPAA-lain lisäksi kourallinen standardeja määrittelee, mitä terveydenhuollon sovelluksen on tehtävä ja siten mitä on testattava. Kunkin standardin tunnistaminen kertoo, mitä testityyppiä se käyttää.

Standard	hallitsee	Testaaminen ajaa
HIPAA	Potilastietojen yksityisyys ja turvallisuus	Pääsyoikeuksien hallinta, salaus, tarkastusloki
HL7 v2 / v3	Kliinisten järjestelmien välinen viestintä	Viestimuoto ja käyttöliittymätestaus
FHIR	Moderni REST API -terveystietojen vaihto	API-ongelmatracja yhteentoimivuustestaus
DICOM	Lääketieteellisen kuvantamisen tallennus ja siirto	Kuvan eheys ja laiteintegraatio
ICD-10 / CPT	Diagnoosi ja toimenpidekoodaus	Väitteiden validointi ja negatiivisen polun testaus
CMS-1500 / UB-04	Ammattimaiset ja institutionaaliset korvaushakemuslomakkeet	Vaatimuksen lähettäminen ja kentän validointi

Terveydenhuollon liiketoimintaprosessi

Useimmat terveydenhuollon organisaatiot ovat ottaneet käyttöön ohjelmistoja järjestelmän sujuvan toiminnan tukemiseksi. Tämä ohjelmistojärjestelmä antaa kaikki tiedot yhdessä asiakirjassa jokaiselle asiaan liittyvälle yksikölle.

Tämän koko järjestelmän yhdistäminen yhteen verkkosovellukseen on valtava tehtävä, ja sen saaminen toimimaan tehokkaasti on vielä isompi tehtävä. Tämän terveyssovelluksen tiukka testaus on pakollista, ja sen on käytävä läpi useita testausvaiheita.

Seuraavissa osioissa on esimerkkiskenaarioita ja testitapauksia kullekin osajärjestelmälle vuorotellen.

Providers-järjestelmän testaus

Näytteiden testiskenaariot ja testitapaukset palveluntarjoajille (lääkäri/sairaala) järjestelmä:

Sr#	Testiskenaario	Testitapaukset
1)	Pääsy palveluntarjoajan järjestelmään	Palveluntarjoajan järjestelmän tulisi antaa meidän syöttää, muokata ja tallentaa palveluntarjoajan tietoja
2)	Positiivinen virtaus Järjestelmän testaus	Se sisältää skenaarioita erityyppisten palveluntarjoajien syöttämiseksi, palveluntarjoajan tietojen vaihtamiseksi, tallentamiseksi ja tiedustelemiseksi
3)	Negatiivisen virtauksen järjestelmän testaus	Mahdollistaa palveluntarjoajan tietojen tallentamisen epätäydellisillä tiedoilla, contracvoimaantulopäivä, syöttämällä järjestelmään tietoja olemassa olevista palveluntarjoajista
4)	järjestelmä Integraation testaus	Vahvista syöte jäsenjärjestelmään, rahoitusjärjestelmään, korvausjärjestelmään ja palveluntarjoajaportaaliin. Tarkista myös, onko toimittajaportaalista tehdyt muutokset kirjattu kyseisen palveluntarjoajan tietueeseen
5)	Positiivisen virtauksen tarjoajien portaalin testaus	Kirjaudu sisään ja katso palveluntarjoajan tiedot, vaatimuksen tila ja jäsentiedot Tee muutospyyntö muuttaaksesi nimeä, osoitetta, puhelinnumeroa jne.
6)	Negatiivisen virtauksen tarjoajien portaalin testaus	Katso jäsenen tiedot virheellisellä tunnuksella Kirjaudu sisään virheellisillä tunnistetiedoilla
7)	Positive flow Broker -portaalin testaus	Kirjaudu sisään ja katso tiedot välittäjästä ja provisiomaksusta Tee pyyntö nimen, osoitteen, puhelinnumeron jne. muuttamisesta.
8)	Negatiivisen virtauksen Broker-portaalin testaus	Sen tulisi sisältää skenaarioita kirjautumisesta virheellisillä tunnistetiedoilla

Välittäjäjärjestelmän testaus

Broker Systemin testiskenaariot ja testitapaukset:

Sr#	Testiskenaario	Testitapaukset
1)	Välittäjäjärjestelmä	Sen pitäisi pystyä muokkaamaan, syöttämään ja tallentamaan välittäjän tietoja Välittäjäpalkkiolaskenta jäsenjärjestelmän palkkion maksutietojen perusteella
2)	Positiivisen virtausjärjestelmän testaus	Syötä, tallenna ja muokkaa välittäjien tietueita erityyppisille välittäjille Aktiiviset välittäjät laskevat palkkion luomalla syötetiedoston, jossa on vastaava tietue jäsenille, joilla on erilainen suunnitelma
3)	Negatiivisen virtauksen järjestelmän testaus	Syötä välittäjätietue epätäydellisillä tiedoilla ja tallenna erityyppisille välittäjille Luomalla syötetiedoston vastaava tietue jäsenille, joilla on eri suunnitelma, laske irtisanotun välittäjän provisio Luomalla syötetiedoston vastaavan tietueen jäsenille, joilla on eri suunnitelma, laske virheellisen välittäjän palkkio
4)	Järjestelmän testaus	Myöhempiin järjestelmiin, kuten rahoitusjärjestelmään, välittäjäportaaliin ja jäsenjärjestelmään, vahvista syötteet Tarkista, onko välittäjäportaalista tehdyt muutokset sisällytetty vastaavaan välittäjätietueeseen

Jäsenjärjestelmän testaus

Näytteiden testiskenaariot ja testitapaukset jäsen (potilas) järjestelmälle:

Sr#	Testiskenaario	Testitapaukset
1)	Jäsenjärjestelmä	Liity jäseneksi, palauta ja lopeta jäsen Poista ja lisää huollettava Luo premium-lasku Käsittele palkkiomaksut
2)	Positiivisen virtausjärjestelmän testaus	Nykyisten, menneiden ja tulevien voimaantulopäivien mukaan rekisteröi erityyppisiä jäseniä Tiedustele ja vaihda jäseniä Tee palkkiolasku aktiiviselle jäsenelle seuraavalle kuukaudelle Irtisanoa aktiivinen jäsen, jonka entinen, nykyinen ja tuleva irtisanomispäivä on suurempi kuin voimaantulopäivä Rekisteröi eronnut jäsen uudelleen nykyisten, menneiden ja tulevien voimaantulopäivien mukaan Erotetun jäsenen palauttaminen
3)	Negatiivisen virtauksen järjestelmän testaus	Jos tietoja ei ole riittävästi, rekisteröidy jäseneksi Erotetulle jäsenelle esitä palkkiolasku seuraavalta kuukaudelta
4)	Järjestelmäintegraation testaus	Vahvista syöte loppupään järjestelmiin, kuten toimittajaportaaliin, välittäjäportaaliin, rahoitusjärjestelmään ja korvausjärjestelmään Tarkista, onko jäsenportaalista tehdyt muutokset sisällytetty vastaavaan jäsentietueeseen Käsittele jäsenportaalin syötteellä luodun premium-laskun maksu, jossa on tiedot suoritetusta maksusta

Vaatimusjärjestelmän testaus

Esimerkkejä testiskenaarioista ja testitapauksista vaatimusjärjestelmälle:

Sr#	Testiskenaariot	Testitapaukset
1)	Vaatimusjärjestelmä	Terveydenhuollon vaatimuksissa tulee muokata, syöttää ja käsitellä jäseniä ja huollettavia koskevia vaatimuksia Virheellisten vaatimusten kohdalla sen pitäisi antaa virheitä, kun syötetään virheellisiä tietoja
2)	Positiivisen virtausjärjestelmän testaus	Sen tulee sisältää skenaario jäsenen ja huollettavana olevien vaatimusten muokkaamiseen, syöttämiseen ja käsittelyyn
3)	Negatiivisen virtausjärjestelmän testaus	Sen tulee vahvistaa ja syöttää vaatimus virheellisellä menettelykoodilla ja diagnoosikoodilla Vahvista ja syötä vaatimus ei-aktiivisella palveluntarjoajan tunnuksella Vahvista ja syötä vaatimus eronneen jäsenen kanssa
4)	Järjestelmän integrointi	Sen tulisi sisältää skenaario syötteen validoimiseksi loppupään järjestelmiin, kuten toimittaja- ja rahoitusportaaliin

Rahoitusjärjestelmän testaus

Esimerkkitesti skenaariot ja testitapaukset rahoitusjärjestelmälle

Sr#	Testiskenaariot	Testitapaukset
1)	Rahoitusjärjestelmä	Liity jäseneksi, palauta ja lopeta jäsen
2)	Positiivisen virtausjärjestelmän testaus	Sen tulee tarkistaa, onko maksua varten valittu oikea tilinumero tai osoite kyseiselle jäsenelle, palveluntarjoajalle tai välittäjälle
3)	Negatiivinen virtausjärjestelmän testaus	Tarkista, onko maksu suoritettu virheellisestä jäsen-, tarjoaja- tai välittäjätunnuksesta luomalla syötteeseen vastaava tietue Tarkista, onko maksu suoritettu virheellisestä summasta jäsenelle, palveluntarjoajalle tai välittäjälle luomalla vastaavat tietueet syötteeseen

Testataan säännöstenmukaisuutta

Potilaiden arkaluonteisten tietojen ja terveystietojen suojaaminen on terveydenhuollon sääntelyelinten ensisijainen tavoite. Testaus olisi suoritettava tällaisten sääntelyelinten vaatimusten mukaisesti.

Esimerkkitestausskenaariot ja -testitapaukset säännöstenmukaisuuden varmistamiseksi:

Sr#	Testiskenaariot	Testitapaukset
1)	Käyttäjän todennus	Varmistusmenetelmän käyttäminen varmistaaksesi, että oikeat käyttäjät saavat kirjautumisen ja estävät muut
2)	Tiedot julkistamisesta	Tietoihin pääsyn valtuuttaminen perustuu käyttäjän rooliin ja potilasrajoituksiin
3)	Tiedonsiirto	Varmista kaikissa siirtopisteissä, että tiedot on salattu
4)	Tarkastusreitti	Kaikki tapahtumat ja kaikki yritykset päästä käsiksi tietoihin asianmukaisella kirjausketjutiedolla tallennetaan
5)	Sääntelyelimeen liittyvä järkevyystestaus	Suorita tervejärkisyystestaus ja varmista, että tietojen salaus on tehty tietyillä alueilla, kuten EPHI (Electronic Protected Health Information)

Terveydenhuollon sovelluksen suorituskyvyn testaus

Ennen testiskenaarioiden valmistelua on otettava huomioon tietyt järjestelmän vaatimukset. Esimerkiksi terveydenhuollon tarjoajat (lääkärit/sairaalat) tarjoavat hoitoa 24/7, joten potilaiden kirjautumisohjelmiston on oltava käytettävissä koko ajan. Sen on myös kommunikoitava vakuutusyhtiöiden kanssa vakuutustietojen validoimiseksi, korvaushakemusten lähettämiseksi ja maksujen vastaanottamiseksi. Tässä arkkitehtuurin tulisi määritellä järjestelmän eri komponentit, vakuutusyhtiöiden kanssa kommunikointiin käytettävä protokolla ja se, miten järjestelmä otetaan käyttöön, jotta se on vaatimusten mukainen 24/7.

Testaajana sinun on varmistettava, että terveydenhuollon ohjelmistojärjestelmä täyttää halutun kuormituksen/suorituskyvyn vertailuarvon.

Muut terveydenhuollon sovellusten testaustyypit

• Toiminnallinen testaus: Terveydenhuollon sovellusten toiminnallisten ominaisuuksien testaus
• Vaatimustenmukaisuuden testaus: Vaatimustenmukaisuustesti Terveydenhuollon tietoturvavaatimukset ja alan puitteet
• Alustan testaus: Sovellusten testaus päällä Puhelinnumero alustan ja sovellusten testaus selainten välisen yhteensopivuuden varmistamiseksi
• Yhteentoimivuuden testausYhteentoimivuusstandardien (esim. DICOM, HL7, CCD/CDA) vaatimustenmukaisuuden testaus

Terveydenhuollon sovellusten haasteiden testaus

Terveydenhuollon sovellusten testaamisen testaushaasteet eivät eroa muista verkkosovellusten testauksista.

• Vaatii testauksen asiantuntemusta, ja yleensä se on korkea hinta
• Vaatii yhteentoimivuuden, vaatimustenmukaisuuden, sääntelyn, turvallisuuden ja turvallisuustestauksen tavanomaisten testaustekniikoiden lisäksi (ei-toiminnallinen, toiminnallinen ja integraatiotestaus)
• Testaus kannattaa tehdä piakkoinping ottaen huomioon turvallisuus- ja sääntelystandardit – sillä mikä tahansa virhe voi vaikuttaa suoraan potilaan elämään
• Testaustiimin on oltava hyvin tietoinen erilaisista toiminnoista, kliinisestä käytöstä ja ympäristöstä, jossa ohjelmistoa käytetään
• Terveydenhuoltotuotteen tulee täyttää useita standardeja, kuten FDA, ISO ja CMMI, ennen kuin sitä voidaan käyttää
• Ohjelmistostaajien ristiriippuvuuden on varmistettava, että yhden komponentin tai kerroksen muutokset eivät johda sivuvaikutuksiin toisessa.

Terveydenhuollon laitteiden testaus

Vaikka terveydenhuollon laitteiden ohjelmistot eivät olekaan potilaan suoranaisia ​​huolenaiheita, ne vaativat myös perusteellista testausta kuten mikä tahansa muu ohjelmisto. Esimerkiksi ohjelmistojen ohjaamat röntgenlaitteet tulisi testata huolellisesti, koska mikä tahansa testausvirhe ohjelmistossa voi johtaa vakaviin seurauksiin potilaalle.

FDA:lla (Food and Drug Administration) on ohjeet lääketieteellisten laitteiden mobiili- ja verkkosovelluksista. Kun testataan lääkinnällisiä laitteita asianmukaisesti toimivia Testisuunnitelma läpäisy- ja hylkäyskriteerit ovat myös osa FDA:n ohjeita. Kun testisuunnitelma suoritetaan, tulokset kerätään ja raportoidaan FDA:lle. Tämä prosessi varmistaa, että laite täyttää sääntelyelinten standardit.

Hyödyllisiä vinkkejä terveydenhuollon testaukseen

Ohjelmistoja testattaessa voit ottaa huomioon joitain tärkeitä vinkkejä terveydenhuoltojärjestelmän testaamiseksi.

• Päivämäärät ovat tärkeitä ja niiden on oltava tarkkoja
• Testitapauksia suunniteltaessa otetaan huomioon erilaiset parametrit, kuten erilaiset suunnitelmat, välittäjät, jäsenet, provisio jne.
• Edellytetään täydellistä toimialueen tuntemusta
• Älä koskaan käytä reaaliaikaisia ​​potilastietoja testidatana. Käytä anonymisoitua tai synteettistä dataa, koska suojatun terveystiedon kopioiminen tuotantoympäristöön on itsessään HIPAA-tietomurto.

UKK