Understanding Health Care Domain and Testing Health Care Applications:
Today’s article is going to be all about healthcare- domain/business information, components, what to test and how to test.
This two-part article series is useful for anyone who wants to explore and enter into a different domain for testing, learn and understand healthcare application workflow and testing process.
In short, this article will be your first step and a guide on your healthcare knowledge quest. In part-2 we will provide test scenarios for different applications under the Healthcare domain.
To excel in testing, domain knowledge is the key. So, we are going to learn about the client’s business flow now.
What You Will Learn:
Healthcare Domain- An Introduction
Health Care or Health Insurance is similar to general insurance. As you know, in any insurance, insurer (Insurance company) will provide the plans and customer (Subscriber or Policyholder) will buy the policy of his desired plan. The insurer will receive the premium amount from the policyholders and the policy Holders will get reimbursements from the insurer for the valid claims they have submitted. The same happens in healthcare insurance but in addition to insurer and policyholder, there are other major contributors such as provider, TPA (Third Party Administrator), broker, etc.
We will now see each of the major contributors in detail:
An entity which creates a plan, sell the policy and reimburses policyholder or provider for the submitted valid claims.
#2. Policy Holder:
A person or an entity, who buys the policy from the insurer or broker, pay a premium to the insurer and sometimes submit a claim.
A person or an entity, which provides the healthcare service to the policyholder and their dependents, either receive payment for the service from the policyholder or the insurer by submitting a claim.
A person or an entity that manages the claims of the policyholder or provider and receives payment for the management from the respective contributor.
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.
Example: We can understand the basic function of contributors from the below example.
Mr. Enosh bought a health care policy which covers general physician consultation and vision problems from Mr. Ponnar and pays 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 submits a claim for the consultation to HealthCorp Company and receives the reimbursement. Mr. Ponnar receives a commission from HealthCorp Company for the payment of premium 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 policy and plan, think plan as a class and policy as an object ( an instance of the class). A policy can be categorized as individual policy and group policy based on the type of beneficiaries it covers.
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.
An entity (Generally an employer) will be the policyholder, the members (Employees) of the entity and their dependents will enjoy the benefits of the health plan. Here the entity pays the premium.
Example: 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 family. Their claims are managed by EasyClaim Company. Here MotoCorp Company is the policyholder, HealthCorp Company is the Insurer and EasyCliam Company is the TPA.
How To Test a Healthcare Application?
Before testing an application, we should be aware of 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
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 do the necessary payment to provider/member/broker
- Member portal – To display the policyholder information, make premium payments and raise 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 for 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, few of these applications are merged to make another combination application- other times, these are stand-alone systems.
For example, the Provider system can be part of Member system in some healthcare application. 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 member system to validate the assigned provider. Either member system connects to the provider system or a data feed should periodically send to member system from provider system. Therefore the provider system should be tested and ready to use before testing member system.
- A claim should consist of provider ID and member ID in addition to other details. Claim system should validate both the member and provider to validate the claim, so both member and provider system should be tested and ready to use before testing the claims system.
- 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 at last since it needs data from the other applications.
(Click on image to enlarge)
Now, that’s the order in which the systems in healthcare application should be tested.
The above-mentioned information should give us enough momentum to get into “How to test” the healthcare applications, which will be dealt with the 2nd part of this article.
About the Author: This is a guest post by Vairavan R M. Author is having good experience in testing Health Care Applications and leading a team in a multinational corporation.
In the meantime, if you have any question or comments or need any help in understanding the Health Care domain better, please let me know. Stay tuned for the next article in the series.