how test health care application part 1
Forstå helsedomene og teste helseprogrammer:
Dagens artikkel kommer til å handle om helse- domene / forretningsinformasjon, komponenter, hva du skal teste og hvordan du skal teste.
Denne todelte artikkelserien er nyttig for alle som ønsker å utforske og inngå et annet domene for testing, lære og forstå arbeidsflyt for helseprogrammer og testprosess .
Kort sagt, denne artikkelen vil være ditt første skritt og en veiledning for din kunnskapssøke. I del-2 Vi vil gi testscenarier for forskjellige applikasjoner under Healthcare-domenet.
For å utmerke seg i testing, domenekunnskap er nøkkelen . Så vi skal lære om kundens forretningsflyt nå.
Hva du vil lære:
Healthcare Domain- En introduksjon
Helsevesenet eller helseforsikringen ligner på den generelle forsikringen. Som du vet, vil forsikringsselskapet (forsikringsselskapet) i en hvilken som helst forsikring levere planene, og kunden (abonnent eller forsikringstaker) vil kjøpe polisen til ønsket plan. Assurandøren vil motta premiebeløpet fra forsikringstakerne, og forsikringstakerne vil få refusjon fra forsikringsselskapet for de gyldige kravene de har levert.
virtuelt virkelighetshodesett kompatibelt med ps4
Det samme skjer i helseforsikring, men i tillegg til forsikringsselskapet og forsikringstakeren, er det andre viktige bidragsytere som leverandør, TPA (tredjepartsadministrator), megler osv.
Vi vil nå se hver av de største bidragsyterne i detalj:
# 1) Forsikringsselskap: En enhet som oppretter en plan, selger polisen og refunderer forsikringstakeren eller leverandøren for de innsendte gyldige kravene.
# 2) Holder: En person eller en enhet, som kjøper polisen fra forsikringsselskapet eller megleren, betaler en premie til forsikringsselskapet og noen ganger fremlegger et krav.
hvordan du gjør en penetrasjonstest
# 3) Leverandør: En person eller en enhet som tilbyr helsetjenesten til forsikringstakeren og deres pårørende, mottar enten betaling for tjenesten fra forsikringstakeren eller forsikringsselskapet ved å sende inn et krav.
# 4) TPA: En person eller en enhet som administrerer kravene fra forsikringstakeren eller leverandøren og mottar betaling for ledelsen fra den respektive bidragsyteren.
# 5) Megler: Som du har gjettet, er han en agent som selger polisen til kundene på vegne av forsikringsselskapet og mottar en provisjon i retur fra forsikringsselskapet.
For eksempel, Vi kan forstå den grunnleggende funksjonen til bidragsytere fra eksemplet nedenfor.
Mr. Enosh kjøpte en helsepolitikk som dekker generell legekonsultasjon og synsproblemer fra Mr. Ponnar og betaler en premie for det til et helseforetak.
Når Enosh var syk og konsulterte legen Mr. Sabari for bedring, ga Sabari en resept til Enosh og sender inn krav på konsultasjonen til HealthCorp Company og mottar refusjonen. Mr. Ponnar mottar en kommisjon fra HealthCorp Company for betaling av premie av Mr. Enosh.
I eksemplet ovenfor er ‘General Physician Consultation’ og ‘Vision Problems’ fordelene med helseplanen, Enosh er forsikringstaker, Mr. Ponnar er megler, HealthCorp Company er forsikringsselskapet og Mr. Sabari er leverandør.
For å tydelig forstå forskjellen mellom policy og plan, tenk plan som klasse og policy som objekt (en forekomst av klassen). En policy kan kategoriseres som individuell policy og gruppepolicy basert på typen mottakere den dekker.
Individuelle retningslinjer: Et individ vil være forsikringstaker; både individet og hans / hennes avhengige vil nyte fordelene av helseplanen. Her betaler den enkelte premien.
Gruppepolicy: En enhet (vanligvis en arbeidsgiver) vil være forsikringstaker, medlemmene (ansatte) i enheten og deres pårørende vil nyte fordelene av helseplanen. Her betaler enheten premien.
For eksempel, Et eksempel på å ha en klar ide om gruppepolitikken er som følger,
MotoCorp Company kjøper en policy fra HealthCorp Company for sine ansatte og deres familie. Kravene deres administreres av EasyClaim Company. Her er MotoCorp Company forsikringstaker, HealthCorp Company er forsikringsselskapet og EasyCliam Company er TPA.
Hvordan teste en helsevesenssøknad?
Før vi tester en applikasjon, bør vi være oppmerksom på arbeidsflyten i helsevesenet. Det forrige emnet gir bare en introduksjon til administrert helsevesen, flere detaljer er tilgjengelig her .
Et forsikringsselskap trenger forskjellige applikasjoner for å administrere følgende:
- Leverandørdata
- Medlemsdata
- Premium fakturering / betaling
- Meglerdata
- Krav innføring / validering
- Meglerprovisjon beregning / betaling
Generelt vil en Healthcare-applikasjon ha følgende liste over systemer:
- Medlemssystem : For å opprettholde data om forsikringstakere, har forskjellige planer med fordelelisten deres og genererer premiumregninger for forsikringstakeren basert på planene
- Leverandørsystem : For å vedlikeholde leverandørdata
- Meglersystem : For å opprettholde meglerdata og beregne provisjoner
- Skadesystem : For registrering og validering av krav
- Økonomisystem : For å gjøre den nødvendige betalingen til leverandør / medlem / megler
- Medlemsportal : For å vise forsikringstakerinformasjonen, foreta premiumbetalinger og be om endringsinformasjon for forsikringstakere
- Tilbyderportal : For å vise leverandørinformasjon og reise en forespørsel om endringsinformasjon for leverandører
- Meglerportal : for å vise meglerinformasjon og reise en forespørsel om endringsinformasjon for meglere
Dette er kanskje ikke en uttømmende liste. Men dette er listen etter beste kunnskap. Det kan også hende at alle applikasjoner ikke engang blir brukt. Noen ganger er få av disse applikasjonene slått sammen for å lage en annen kombinasjonsapplikasjon - andre ganger er dette frittstående systemer.
For eksempel , kan leverandørsystemet være en del av medlemssystemet i noen helseprogrammer. Med Healthcare-applikasjon mener jeg et sett med systemer som vedlikeholdes av et forsikringsselskap for å lette deres kunder og partnere.
programvare for kunstig intelligens for pc gratis nedlasting
Healthflow Application Testing Workflow
Det unike ved helsevesenet er at disse applikasjonene ikke kan testes i hvilken rekkefølge vi vil. Det er en viss arbeidsflyt som skal følges:
- For at et medlem / forsikringstaker skal bli registrert i en helseplan, må han / hun tildeles en leverandør (Primary Care Physician) eller et leverandørnettverk, så det bør være en måte for medlemssystemet å validere den tildelte leverandøren. Enten medlemssystemet kobles til leverandørsystemet, eller en datafeed skal med jevne mellomrom sendes til medlemssystemet fra leverandørsystemet. Derfor bør leverandørsystemet testes og være klart til bruk før medlemssystemet testes.
- Et krav skal bestå av leverandør-ID og medlems-ID i tillegg til andre detaljer. Skadesystemet skal validere både medlemmet og leverandøren for å validere kravet, så både medlems- og leverandørsystemet skal testes og være klart til bruk før det testes kravsystemet.
- Finanssystemet må ha data fra et medlem, leverandør, krav og meglersystem for å skrive sjekker eller foreta EFT-betalinger til den respektive personen eller enheten.
- Leverandør- og meglersystemer er frittstående.
- Portaler bør endelig testes siden de trenger data fra de andre applikasjonene.
Nå er det rekkefølgen systemene i Healthcare-applikasjonen skal testes.
Hva er det? Neste ?
Ovennevnte opplysninger bør gi oss nok fart til å komme inn i 'Hvordan teste' helseprogrammene, som vil bli behandlet i 2. del av denne artikkelen.
Om forfatteren: Dette er et gjestepost av Vairavan R M. Forfatter har god erfaring med å teste helseprogrammer og lede et team i et multinasjonalt selskap.
I mellomtiden, hvis du har spørsmål eller kommentarer eller trenger hjelp til å forstå helsevesenet bedre, vennligst gi meg beskjed. Følg med for neste artikkel i serien.
Anbefalt lesing
- Testing av helseprogrammer - Tips og viktige testscenarier (del 2)
- Applikasjonstesting - inn i det grunnleggende om programvaretesting!
- Veiledning for testing av webapplikasjoner
- Installere applikasjonen din på enheten og start testing fra Eclipse
- Destruktiv testing og ikke-destruktiv testing
- Ytelsestesting vs belastningstesting vs stresstesting (forskjell)
- Hva er Monkey Testing i Software Testing?
- Topp 20 praktiske programvaretesttips du bør lese før du tester applikasjoner