Healthcare Application Testing Guide with Sample Test Cases and Scenarios

By Swati

By Swati

I’m Swati. I accidentally started testing in 2004, and since then have worked with at least 20 clients in 10 cities and 5 countries and am still counting. I am CSTE and CSQA certified. I love my job and the value it adds to software…

Learn about our editorial policies.
Updated January 17, 2025
Edited by Vijay

Edited by Vijay

I'm Vijay, and I've been working on this blog for the past 20+ years! I’ve been in the IT industry for more than 20 years now. I completed my graduation in B.E. Computer Science from a reputed Pune university and then started my career in…

Learn about our editorial policies.

This guide is a detailed understanding of the Healthcare Domain and Healthcare Application Testing. Also explore, the test scenarios for different applications under the Healthcare domain:

This is going to be all about healthcare- domain/business information, components, what to test, and how to test.

Towards the end, we will pick each application/system and come up with conditions that we are going to validate in each one of them.

Healthcare Application Testing: Step-By-Step Guide

Healthcare Application Testing

This article is useful for anyone who is already in the Healthcare domain or for those who want to enter into a different domain for testing, learning, and understanding the healthcare application workflow and testing process.

To excel in testing, domain knowledge is the key. So, we are going to learn about the client’s business flow now.

Introduction to Healthcare Domain

Health Care or Health Insurance is similar to general insurance. As you know, in any insurance, the insurer (Insurance company) will provide the plans and the customer (Subscriber or Policyholder) will buy the policy of his desired plan. The insurer will receive the premium amount from the policyholders and the policyholders will get reimbursements from the insurer for the valid claims they have submitted.

The same happens in healthcare insurance but in addition to the insurer and policyholder, there are other major contributors such as providers, TPA (Third Party Administrator), brokers, etc.

We will now look at each of the major contributors in detail:

#1) Insurer: An entity that creates a plan, sells the policy, and reimburses the policyholder or provider for submitted valid claims.

#2) Policy Holder: A person or entity who buys a policy from an insurer or broker, pays a premium to the insurer, and sometimes submits a claim.

Healthcare policy holder

#3) Provider: A person or entity that provides healthcare services to the policyholder and their dependents and either receives payment for the services from the policyholder or the insurer by submitting a claim.

#4) TPA: A person or entity that manages the claims of the policyholder or provider and receives payment for the management from the respective contributor.

#5) Broker: As you have guessed, he is an agent who sells the policy to the customers on behalf of the insurer and receives a commission in return from the Insurer.

Healthcare insurance broker

For example, we can understand the basic function of contributors from the below example.

Mr. Enosh bought a healthcare policy that covers general physician consultation and vision problems from Mr. Ponnar and paid a premium for the same to a healthcare company.

Once Mr. Enosh was sick and consulted the Physician Mr. Sabari for recovery, Sabari provided a prescription to Enosh and submitted a claim for the consultation to HealthCorp Company and received the reimbursement. Mr. Ponnar receives a commission from HealthCorp Company for the payment of premiums by Mr. Enosh.

In the above example, ‘General Physician Consultation’ and ‘Vision Problems’ are the benefits of the health plan, Mr. Enosh is the policyholder, Mr. Ponnar is the broker, HealthCorp Company is the insurer and Mr. Sabari is the provider.

To clearly understand the difference between a policy and a plan, think of a plan as a class and a policy as an object (an instance of the class). A policy can be categorized as an individual policy or a group policy based on the type of beneficiaries it covers.

Individual Policy: An individual will be the policyholder; both the individual and his/her dependents will enjoy the benefits of the health plan. Here the individual pays the premium.

Group Policy: An entity (generally an employer) will be the policyholder, and the members (employees) of the entity and their dependents will enjoy the benefits of the health plan. Here the entity pays the premium.

An example to have a clear idea of group policy is as follows,

MotoCorp Company buys a policy from HealthCorp Company for its employees and their families. Their claims are managed by EasyClaim Company. Here MotoCorp Company is the policyholder, HealthCorp Company is the Insurer and EasyClaim Company is the TPA.

Further Reading => List of the TOP EMR & EHR Software to Look For

How to Test a Healthcare Application

Before testing an application, we should be aware of the healthcare industry workflow. The previous topic just gives an introduction to managed health care, more details are available here.

An insurer needs different applications to manage the following:

  • Provider data
  • Member Data
  • Premium Billing/Payment
  • Broker data
  • Claims entry/validation
  • Broker commission calculation/payment

Further Reading => TOP Healthcare Software Testing Services to Look For

Generally, a Healthcare application will have the following list of systems:

  • Member System: To maintain policyholder data, various plans with their list of benefits and generate premium bills for the policyholder based on their plans.
  • Provider System: To maintain provider data
  • Broker System: To maintain broker data and calculate commissions
  • Claims System: For claim entry and validation
  • Finance System: To make the necessary payment to provider/member/broker
  • Member Portal: To display the policyholder information, make premium payments, and raise a request for change information for policyholders.
  • Provider Portal: To display provider information and raise a request for change information for providers
  • Broker Portal: To display broker information and raise a request to change information for brokers

This might not be an exhaustive list. But this is the list to the best of my knowledge. Also, all applications might not even be used. Sometimes, a few of these applications are merged to make another, more complex application- other times, these are stand-alone systems.

For example, the Provider system can be part of the Member system in some healthcare applications. By Healthcare application, I mean a set of systems maintained by an Insurer to facilitate their customers and partners.

Health Care Application Testing Workflow

The unique feature of the Health Care system is that these applications cannot be tested in any order we like. There is a certain workflow to be followed:

  • For a member/policyholder to be enrolled in a health plan he/she needs to be assigned to a provider (Primary Care Physician) or a provider network, so there should be a way for the member system to validate the assigned provider. Either the member system connects to the provider system or a data feed should periodically send to the member system from the provider system. Therefore, the provider system should be tested and ready to use before testing the member system.
  • A claim should consist of provider ID and member ID in addition to other details. The claims system should validate both the member and provider to validate the claim, so both the member and provider systems should be tested and ready to use before testing the claims system.
  • The finance system needs to have data from a member, provider, claim, and broker system to write checks or make EFT payments to the respective person or entity.
  • Provider and broker systems are stand-alone.
  • Portals should be tested last since they need data from the other applications.
Health Care Work flow

Now, that’s not the order in which the systems in a Healthcare application should be tested.


Healthcare Application Testing – Sample Test Scenarios

So far we had a brief introduction about the healthcare domain, this section covers the basics of the healthcare domain and a way to test healthcare applications with sample test scenarios.

This is the Sample Test Scenarios for:

Health Insurance System - Testing Components

Testing of Provider System

#1) The Provider System should be let us enter, edit and save provider data.

#2) Positive flow System testing: include scenarios to enter different types of Providers, change, save and inquire about them.

#3) Negative flow System testing: include scenarios to

  • Save a provider with incomplete data.
  • Save a provider with a contract effective date less than the provider license date.
  • Enter data of the provider which is already available in the system and save.

#4) System Integration testing should include scenarios to

  • Validate the feed to downstream systems such as the feed to Member system, Provider portal, Claim system, and Finance system.
  • Validate if the changes from the Provider portal are incorporated in the respective provider record.

Testing of Broker System

#1) Broker System should be capable of the following:

  • Enter, edit and save broker data.
  • Calculate the broker commission based on the premium payment details from the member system.

#2) Positive flow System Testing should include scenarios to

  • Enter, edit and save broker record for different types of the broker.
  • Calculate the commission for the active broker by creating a feed file with the respective record for members with a different plan.

#3) Negative flow System Testing should include scenarios to

  • Enter a broker record with insufficient data and save for different types of the broker.
  • Calculate the commission for the terminated broker by creating a feed file with the respective record for members with a different plan
  • Calculate the commission for the invalid broker by creating a feed file with the respective record for members with a different plan

#4) System Testing should include scenarios to

  • Validate the feeds to the downstream systems such as the Broker portal, Finance system, and Member system.
  • Validate if the changes from the Broker portal are incorporated in the respective broker record.

Testing of Member System

Member System should be capable of the following:

  1. Enroll, terminate, reinstate, and re-enroll a member
  2. Add and remove a dependent
  3. Generate premium bill
  4. Process premium payments

Enrollment: In an Individual Policy, a policyholder is added under a plan with an effective date from which he/she will be paying a premium for the benefits provided by the insurer and from which he/she is eligible to submit claims and receive coverage.

In Group Policy, a member is added to the group (which is already added under a plan) with an effective date of which he/she is eligible to submit claims and receive coverage.

Termination: In an Individual Policy, the policy is terminated with a termination date of which a policyholder will not be covered by the insurance plan.

In Group Policy, either the member alone can be terminated with a termination date or the whole group can be terminated.

Reinstatement: If a terminated member asks for the policy to be active again and the current date is within the grace period from the termination date then the member can be reinstated without a coverage gap. The policy effective date will be the same old effective date and not the current date.

Re-enrollment: If a terminated member asks for the policy to be active again and the current date is beyond the grace period from the termination date then the member can be re-enrolled with a coverage gap. The policy effective date will be the current/future date and not be the same old effective date.

For Example, A member is enrolled in a policy with an effective date of 1/1/2013 and terminated on 12/31/2013. lets us take 30 days as the grace period fixed by the insurance company.

Case 1: If the member comes back on 1/15/2014 and wants the policy to be effective against then it is Reinstatement if the member pays the premium for the period 12/31/2013 to 1/15/2014 then the policy effective date will be the same old 1/1/2013.

Case 2: If the member comes back on 2/1/2014 and wants the policy to be effective again then it is Re-enrollment and the policy effective date will be 2/1/2014. Here there is a coverage gap (1/1/2014 to 1/31/2014).

Positive flow System Testing should include scenarios to

  • Enroll different types of members with past, current, and future effective dates.
  • Change and inquire about members.
  • Generate a premium bill for an active member for next month.
  • Terminate an active member with a past, current, and future termination date greater than the effective date.
  • Re-enroll a terminated member with past, current, and future effective dates.
  • Reinstate a terminated member.

Negative flow System Testing should include scenarios to

  • Enroll a member with insufficient data.
  • Generate a premium bill for next month for a terminated member.

System Integration Testing should include scenarios to

  • Validate the feed to downstream systems such as Member portal, Provider portal, Broker system, Claim system, and Finance system.
  • Validate if the changes from the Member portal are incorporated in the respective member record.
  • Process the payment of a generated premium bill with the feed from the Member portal that has details of payment made.

Testing of Claims System

Claims in healthcare have a diagnosis code and procedure code for the claim to be in detail.

  • Diagnosis Code: Refers to the disease the patient had.
  • Procedure Code: Refers to the treatment provided to the patient.

Claims System should be capable of the following:

  • Enter, edit, and process claims for the member as well as a dependent.
  • Should throw errors for invalid claims based on the incorrect data entered.

Positive flow System Testing should include scenarios to enter, edit, and process claims for the member as well as a dependent.

Negative flow System Testing should include scenarios to

  • Enter and validate a claim with an invalid diagnosis code and procedure code.
  • Enter and validate a claim with an inactive provider ID.
  • Enter and validate a claim with a terminated member.

System Integration testing should include scenarios to validate the feed to downstream systems such as finance and provider portals.

Testing of Finance System

Finance System should be capable of writing paychecks and making EFT payments to the respective recipient by processing the feeds from various upstream systems such as claims, member, provider, and broker systems.

Positive flow System Testing should include scenarios to check whether the correct address or account number is chosen for the respective provider, member or broker for the payment.

Negative flow System Testing should include scenarios to

  • Check whether payment is done for the invalid member, provider or broker ID by creating respective records in the feed.
  • Check whether payment is done for the invalid amount (Zero or negative) for the member, provider or broker by creating respective records in the feed.

System Integration Testing is not needed as this doesn’t have any downstream systems and the feeds from the upstream are validated in the System Integration testing of respective systems.

Testing of Member Portal

Member Portal should be capable of the following:

  • View policy details and claim status.
  • Make change requests in policy details.
  • Make premium payments.

Positive flow System Testing should include scenarios to

  • Log in and view policy details and claim status.
  • Make a change request to change address, name, phone number, etc.
  • Make premium payments.

Negative flow System Testing should include scenarios to

  • Log in with invalid credentials.
  • Make payment for a paid premium bill.
  • Make payment with an invalid check.

System Integration Testing is not needed as this doesn’t have any downstream systems and the feeds from the upstream systems are validated in the system integration testing of respective systems.

Testing of Provider Portal

Provider Portal should be capable of the following:

  • View provider details, member details, and claim status.
  • Make change requests in provider details.

Positive flow System Testing should include scenarios to

  • Log in and view provider details, member details, and claim status.
  • Make a change request to change address, name, phone number, etc.

Negative flow System Testing should include scenarios to

  • Login with invalid credentials
  • View member details with an invalid member ID

System integration testing is not needed as this doesn’t have any downstream systems and the feeds from the upstream system are validated in the system integration testing of respective systems.

Testing of Broker Portal

Broker Portal should be capable of the following:

  • View broker details and commission payment.
  • Make change requests in broker details.

Positive flow System Testing should include scenarios to

  • Log in and view broker details and commission payment.
  • Make a change request to change address, name, phone number, etc.

Negative flow System Testing should include scenarios to log in with invalid credentials.

System Integration Testing is not needed as this doesn’t have any downstream systems and the feeds from the upstream are validated in the System Integration Testing of respective systems.

That’s it- that’s all the modules and the aspects we would test in them.

Further Reading => TOP Reading Healthcare Software Development Companies

Important Tips for Testing Healthcare Software

Tip #1) Dates are important and have to be accurate because a slight change in the date may cause a major defect to go unnoticed.

Tip #2) In Healthcare, there are many test parameters such as different types of plans, members, providers, brokers, commission calculation methods, etc., – so care should be taken while designing test cases by keeping track of parameters covered and not covered.

Tip #3) Know the business users of the respective systems and think from their perspective to find any of the best defects.

Tip #4) It is not needed to follow the same order for system testing and the scenarios provided here just cover the overall functionality of a healthcare application. You may also need to include some more scenarios (more hints in this post) based on the requirements you receive.

Tip #5) Health care is now moving towards a cost-effective way of providing care. Thus they have introduced an exchange model where the subscriber can have a view of plans given by all the insurers which increases the competitive nature of the insurers thereby indirectly stating the need for cost reduction.

As healthcare evolves, there will be a need for the change in software being used and there comes the revenue for IT by creation, modification, and testing of software applications involved – which means we can anticipate more projects in this domain. So, keep a lookout, if this interests you.

Tip #6) The key to success in health care application testing is claims – the complete knowledge of them and how they are adjudicated, etc.

Conclusion

Well, that covers the basics of the healthcare domain and a way to test healthcare applications.

As testers, we know nothing is defect-free. This article may also have some defects, if you find any defect or have a question please leave a comment. We welcome your valuable feedback on the article, as it will drive us towards excellence and improvement.

In the meantime, if you have any questions or comments or need any help in understanding the Health Care domain better, please let me know.

Was this helpful?

Thanks for your feedback!

Recommended Reading

  • Security Testing of Web Applications

    How to make sure your web application is secure before release? Web site security testing is important part of software testing life cycle like other functionality and performance testing. This article will guide you with different type of attacks on web applications and information on how to perform security testing…

  • Application Testing

    Introduction to Application Testing Application Testing is an activity that is performed frequently by almost every software tester in his career. These two words are extremely broad in practical aspects. However, only the core and most important areas will be discussed here. The purpose of this tutorial is to touch…

  • Testing from Eclipse

    Upload and install your mobile application on any device to kick off your Appium testing directly from Eclipse: Your mobile applications can be managed within the Eclipse through a dedicated Application Pane in Appium Studio for Eclipse. Your application can quickly and easily be uploaded and launched on any device. This…

  • Destructive and Non Destructive Testing

    Difference Between Destructive Testing and Non-Destructive Testing with Its Types and Methods: In this article, we are going to discuss details about destructive testing and non-destructive software testing. We will learn about them one by one and will also see the differences between these two testing types at the end…

  • What is Monkey Testing in Software Testing_

    What is Monkey Testing in Software Testing? Introduction: Monkey testing is a technique in software testing where the user tests the application by providing random inputs and checking the behavior (or trying to crash the application). Mostly this technique is done automatically where the user enters any random invalid inputs…

  • Practical Software Testing Tips

    This is a collection of top 20 practical testing tips for testing any product or web based application I learned over time. I wish all testers read these software testing good practices and try to implement them in your day to day software testing activities. Finally your skill and experience…

  • Soak Testing

    This Comprehensive Guide on Soak Testing Explains What is Soak Testing, Why do we need it, its Application, Advantages, Best Practices and Disadvantages: Various types of testing need to be performed while testing a software application. Functional and Non-functional testing are the two broad categories into which we can categorize…

  • Software Testing Exercises

    Software Testing Exercises: Read on to refresh and strengthen your brain. With excellent response to the STH posts as always, we have decided to fill this place with more fun and help. No matter, who you are – a senior quality manager or a fresher who has just joined the…


51 thoughts on “Healthcare Application Testing Guide with Sample Test Cases and Scenarios”

  1. Kindly let me know the information about Gym products. i thought even Gym facility comes under Health Domain.kindly rectify ……Help me out with the application,test cases, and how to automate it.

    Reply
  2. Hi guys ,can you tell me what will the endpoints in API’S for health care domain and what is key points in healthcare domain in a simple manner asking from interview purpose plz reply fast.

    Reply
  3. @ Prasad Bhavanashi
    Hope you have read the second part, to explain the points you have mentioned takes much time. The main aim of this article is to give an introduction to health care domain and show a way to test the end to end flow of a health care application.
    Sorry that I haven’t been detail but you can always go through the book that was mentioned in the article for more details.
    Thanks

    Reply
  4. Hi,
    In this article you have talked about insurance application, but there many more application in Health care. so pleas provide some generic information on health care

    Reply
  5. @ all – thanks all for your comments and huge support.
    The first article was mainly to introduce you to the healthcare domain (health insurance as an example). In second part we will explain how to test this application with test scenarios.

    Also we got your inputs and soon we will provide more domain info (downloadable) on Healthcare, BFSI and other domains.

    Reply
  6. very useful and explain by flow of process in health care domain. great presentation..Hope so with continous sharing of knowledge..@ Thanks vairavan

    Reply
  7. In healthcare there are different areas to be tested.
    could be in insurance are or hospital are(inpatient,Outpatient ,observation and ER)
    the insurance is used in different ways and billing is also done in different ways.
    There are Various applications used as Epic,Allscript,Aurora,meditech etc.Each applications are used for different purposes.While you are using this applications,you need to have the understanding of basic billing and claims.Primary and secondary insurances.The HCPC codes how many digits and the HIPPA regulations.Medicare and medicaid understanding and how its being used as a Medicare advantage plan

    Reply
  8. My best Wishes and thanks for provided valuable information in part1 it self to all of them .

    Even me also waiting for 2 nd part 🙂

    I hope it will cover ,
    1. Mediclaim process
    2.HMO (Health Maintenance Organisation )
    3.PCP (Primary care Phycian)
    4. PPO (Preffered provider organisation)process
    5.HSA (Health Savings account)
    6. CoPay,Co insurance.
    7. COmplete Claim process (Its a big subject )

    Thanks,
    Prasad Bhavanasi

    Reply
  9. Health care domain and Health Insurance or policy is different
    Health insurance or policy related details are will come under Insurance related domain.

    Health care is a full and full hospital related applications
    Inpatient ,out patient Emergency dept and clinic related applications should be avilable

    Reply
  10. This very help for who have less or no knowledge about health care domain. We all are waiting for the part -2 with more examples for web & mobile application. Nice work. Lots of thanks

    Reply
  11. This is basically about health insurance but what about various application used for health care services & various health care app.

    Any details on testing those type of health care application?

    Reply
  12. Hi sir.This is suresh Reddy. Thanks for nice presentation.i got some knowledge after reading this part1.will wait for your part2 and future other domain . Thanks.

    Reply
  13. Thanks for giving an idea about the Health Insurance Domain testing. Waiting for part 2….hope it will cover Health Care Domain (Hospital related) also.

    Thanks

    Reply
  14. I am working for US Health Care Services in Insurance claims processing , Please provide me more information and regular updates to my mail Id …Thanks

    Reply
  15. wow!!! This was awesome..very clear..can you provide the same structure of article with banking domain..i m intrested to know about that..anyways great

    Reply
  16. I’m working as test Engg with an EHR software which don’t have detailed functionality of providers/brokers.We are having modules like IP,OP,ER.Please include these workflows too.

    Reply
  17. @Sameer and @ Anuradha,

    Thanks for the comments. We will keep you posted on the date of publish of the second part of this article.

    Reply
  18. Nice information , I would request to publish article on SAP functional (Finance , HR ect) as SAP is more complicated and interesting to know.

    Reply
  19. I am a medical biller and hope to land a job in this domain as I feel I know it pretty well! Glad to have come across this article

    Reply
  20. I want to know about Banking, Financial services and Insurance (BFSI) domain. How to test BFSI application.
    Kindly post asap.

    Reply

Leave a Comment