Menu

Sådan tester du ansøgning om sundhedspleje - Del 1

how test health care application part 1

Prøv Vores Instrument Til At Fjerne Problemer

Forståelse af sundhedsvæsenet og test af sundhedsplejeapplikationer:

Dagens artikel handler om sundheds- domæne / forretningsinformation, komponenter, hvad man skal teste og hvordan man tester.

Denne todelte artikelserie er nyttig for alle, der ønsker at udforske og gå ind i et andet domæne til test, lære og forstå sundhedsapplikationsarbejdsprocesser og testproces .

Kort sagt, denne artikel vil være dit første skridt og en guide til din viden om sundhedsviden. I del 2 Vi giver testscenarier for forskellige applikationer under Healthcare-domænet.

Sådan testes sundhedspleje ansøgning

For at udmærke sig ved testning, domæne viden er nøglen . Så vi vil lære om kundens forretningsstrøm nu.

Hvad du lærer:

Healthcare Domain - En introduktion

Sundhedspleje eller sundhedsforsikring svarer til almindelig forsikring. Som du ved, vil forsikringsselskabet (forsikringsselskabet) i enhver forsikring levere planerne, og kunden (abonnent eller forsikringstager) vil købe politikken for den ønskede plan. Forsikringsselskabet modtager præmiebeløbet fra forsikringstagerne, og forsikringstagerne får refusion fra forsikringsselskabet for de gyldige krav, de har afgivet.

standard gateway er ikke tilgængelig konstant

Det samme sker i sundhedsforsikring, men ud over forsikringsselskab og forsikringstager er der andre vigtige bidragydere som udbyder, TPA (tredjepartsadministrator), mægler osv.

Vi vil nu se hver af de største bidragydere i detaljer:

# 1) Forsikringsselskab: En enhed, der opretter en plan, sælger politikken og godtgør forsikringstageren eller udbyderen for de indsendte gyldige krav.

# 2) Politikindehaver: En person eller en enhed, der køber forsikringen fra forsikringsselskabet eller mægleren, betaler en præmie til forsikringsselskabet og indgiver undertiden et krav.

Indehaver af sundhedspolitikken

hvad er netværkssikkerhedsnøgle til wifi

# 3) Udbyder: En person eller en enhed, der leverer sundhedstjenesten til forsikringstageren og deres pårørende, modtager enten betaling for tjenesten fra forsikringstageren eller forsikringsselskabet ved at fremsætte et krav.

# 4) TPA: En person eller en enhed, der administrerer forsikringstagerens eller udbyderens krav og modtager betaling for ledelsen fra den respektive bidragsyder.

# 5) Mægler: Som du har gættet, er han en agent, der sælger politikken til kunderne på vegne af forsikringsselskabet og modtager en kommission til gengæld fra forsikringsselskabet.

Mægler for sundhedsforsikring

For eksempel, Vi kan forstå den grundlæggende funktion af bidragydere fra nedenstående eksempel.

Mr. Enosh købte en sundhedspolitik, der dækker generel lægekonsultation og synsproblemer fra Mr. Ponnar og betaler en præmie for det samme til et sundhedsfirma.

Når Mr. Enosh var syg og konsulterede lægen Mr. Sabari for helbredelse, gav Sabari en recept til Enosh og fremsætter et krav om konsultation til HealthCorp Company og modtager refusionen. Mr. Ponnar modtager en kommission fra HealthCorp Company til betaling af præmien af ​​Mr. Enosh.

I ovenstående eksempel er 'General Physician Consultation' og 'Vision Problems' fordelene ved sundhedsplanen, Mr. Enosh er forsikringstager, Mr. Ponnar er mægler, HealthCorp Company er forsikringsselskabet og Mr. Sabari er udbyderen.

For tydeligt at forstå forskellen mellem politik og plan, tænk plan som en klasse og politik som et objekt (en forekomst af klassen). En politik kan kategoriseres som individuel politik og gruppepolitik baseret på den type modtagere, den dækker.

Individuel politik: En person vil være forsikringstager; både individet og hans / hendes afhængige vil nyde fordelene ved sundhedsplanen. Her betaler den enkelte præmien.

Gruppepolitik: En enhed (generelt en arbejdsgiver) vil være forsikringstager, enhedens medlemmer (medarbejdere) og deres pårørende vil nyde fordelene ved sundhedsplanen. Her betaler virksomheden præmien.

For eksempel, Et eksempel på at få en klar idé om gruppepolitik er som følger,

MotoCorp Company køber en politik fra HealthCorp Company for sine ansatte og deres familie. Deres krav administreres af EasyClaim Company. Her er MotoCorp Company forsikringstager, HealthCorp Company er forsikringsselskabet og EasyCliam Company er TPA.

Sådan tester du en sundhedsansøgning?

Før vi tester en applikation, skal vi være opmærksomme på sundhedsindustriens arbejdsgang. Det forrige emne giver bare en introduktion til administreret sundhedspleje, flere detaljer er tilgængelig her .

Et forsikringsselskab har brug for forskellige applikationer for at administrere følgende:

  • Udbyderdata
  • Medlemsdata
  • Premium fakturering / betaling
  • Mæglerdata
  • Registrering / validering af krav
  • Meglerprovisionsberegning / betaling

Generelt vil en Healthcare-applikation have følgende liste over systemer:

  • Medlemssystem : For at vedligeholde forsikringstagerdata, forskellige planer med deres liste over fordele og generere premiumregninger til forsikringstageren baseret på deres planer
  • Udbydersystem : For at vedligeholde udbyderdata
  • Mæglersystem : For at vedligeholde mæglerdata og beregne provision
  • Erstatningssystem : Til registrering og validering af krav
  • Finanssystem : For at foretage den nødvendige betaling til udbyder / medlem / mægler
  • Medlemsportal : For at få vist forsikringstageroplysningerne, foretage præmiebetalinger og rejse en anmodning om ændringsoplysninger for forsikringstagere
  • Udbyderportal : For at få vist udbyderoplysninger og rejse en anmodning om ændringsoplysninger for udbydere
  • Mæglerportal : for at vise mæglerinformation og rejse en anmodning om ændringsinformation for mæglere

Dette er muligvis ikke en udtømmende liste. Men dette er listen efter min bedste overbevisning. Også alle applikationer kan muligvis ikke engang bruges. Nogle gange er få af disse applikationer slået sammen for at lave en anden kombinationsapplikation - andre gange er disse enkeltstående systemer.

For eksempel kan udbydersystemet være en del af medlemssystemet i nogle sundhedsapplikationer. Med Healthcare-applikation mener jeg et sæt systemer, der vedligeholdes af et forsikringsselskab for at lette deres kunder og partnere.

dobbeltkoblet listeklasse c ++

Healthflow Application Testing Workflow

Det unikke ved Health Care-systemet er, at disse applikationer ikke kan testes i den rækkefølge, vi kan lide. Der er en bestemt arbejdsgang, der skal følges:

  • For at et medlem / forsikringstager kan blive tilmeldt en sundhedsplan, skal han / hun tildeles en udbyder (Primary Care Physician) eller et udbydernetværk, så der skal være en måde for medlemssystemet at validere den tildelte udbyder. Enten medlemssystem opretter forbindelse til udbydersystemet, eller et datafeed skal regelmæssigt sendes til medlemssystem fra udbydersystem. Derfor skal udbydersystemet testes og være klar til brug inden test af medlemssystemet.
  • Et krav skal bestå af udbyder-id og medlems-id ud over andre detaljer. Skadesystemet skal validere både medlemmet og udbyderen for at validere kravet, så både medlems- og udbydersystemet skal testes og være klar til brug inden testningssystemet.
  • Finanssystemet skal have data fra et medlem, udbyder, krav og mæglersystem til at skrive checks eller foretage EFT-betalinger til den respektive person eller enhed.
  • Udbyder- og mæglersystemer er enkeltstående.
  • Portaler skal endelig testes, da de har brug for data fra de andre applikationer.

Sundhedsvæsen Arbejdsflow

Nu er det den rækkefølge, hvor systemerne i Healthcare-applikationen skal testes.

Hvad er der? Næste ?

Ovennævnte information skal give os tilstrækkelig fart til at komme ind i 'Sådan tester' vi sundhedsapplikationerne, som vil blive behandlet i 2. del i denne artikel.

Om forfatteren: Dette er et gæstepost af Vairavan R M. Forfatter har god erfaring i at teste sundhedsapplikationer og lede et team i et multinationalt selskab.

I mellemtiden, hvis du har spørgsmål eller kommentarer eller har brug for hjælp til at forstå Health Care-domænet bedre, så lad mig det vide. Hold øje med den næste artikel i serien.

Anbefalet læsning

^