Core Insurance Domain Questions

Domain Knowledge & Definitions (Healthcare Insurance)

Here are some key terms I work with daily:

  • Provider: Any person (like a doctor or dentist) or institution (like a hospital or clinic) that provides medical services.
  • Member Enrollment: The process of adding an individual or a group to a health insurance plan. This is the first step in the insurance lifecycle for a member.
  • Coverage: This defines what services and treatments the insurance plan will pay for. For example, a plan might have coverage for dental check-ups but not for cosmetic surgery.
  • Claim: A formal request for payment submitted by a provider to the insurance company for services rendered to a member.
  • Line Item: A single entry on a claim form that represents a specific service or procedure. For example, a dental claim might have one line item for an X-ray and another for a cleaning. Each has its own procedure code and charge.
  • Fee Schedule: A comprehensive list of fees used by insurance companies to determine the maximum amount they will pay for each medical service. If a doctor charges more than the fee schedule amount, the excess may not be covered.
  • Adjudication: This is the core process of reviewing a claim. My code checks the member’s eligibility, coverage, and applies business rules (like checking for duplicate claims or medical necessity) to decide whether to pay, deny, or adjust the claim.
  • EOB (Explanation of Benefits): After a claim is adjudicated, an EOB is sent to the member. It’s not a bill. It explains what the provider billed, what the insurance paid, and what the member’s financial responsibility is (like copay or deductible).
  • COB (Coordination of Benefits): This process is triggered when a member is covered by more than one health plan (e.g., their own and a spouse’s). It determines which plan is primary (pays first) and which is secondary to prevent overpayment.
  • Deductible, Copay, and Coinsurance: These are forms of cost-sharing for the member.
    • Deductible: The amount you pay for covered services before your insurance plan starts to pay.
    • Copay: A fixed amount (e.g., $25) you pay for a service.
    • Coinsurance: Your share of the costs of a service, calculated as a percentage (e.g., 20%).
  • Out-of-Pocket Maximum: The most a member has to pay for covered services in a plan year. Once this limit is reached, the insurance company pays 100% of the costs for covered benefits.
  • Lab Fee: The specific charge for laboratory tests, like blood work or urinalysis, which is often a separate line item on a claim.

What is the difference between a policy and a claim?

A policy is the contract between the insurer and the insured, which outlines the terms of coverage. A claim is a formal request made by the policyholder to the insurer for compensation for a loss covered under that policy. In my work, I’ve dealt with both: configuring policy rules (PBOs) and processing incoming claims against those rules.

What is PBO (Plan Benefit Option) and what was your role in its configuration?

PBO (Plan Benefit Option) refers to the specific set of benefits, coverages, and rules that a member is entitled to under their insurance plan. It defines details like deductibles, co-pays, coverage limits, and which services are included or excluded.

My role in PBO configuration was to translate the client’s business requirements into technical rules within the platform. This involved:

  • Configuring Benefit Structures: Setting up the rules for different plans and how they apply to various medical services.
  • Customizing Logic: Writing custom Java code or using the platform’s rule engine to handle complex benefit calculations that were not supported out-of-the-box.
  • Troubleshooting: Debugging issues where benefits were not being applied correctly during claim adjudication.

Can you explain your work on Claim Auto-Adjudication?

Claim Auto-Adjudication is the process of using a rule-based engine to automatically process and approve or deny claims without human intervention. The goal is to “touch” as few claims as possible manually, which significantly speeds up processing and reduces costs.

My work involved:

  • Designing and Implementing Rules: I wrote business rules in Java and configured the system to automatically check for things like member eligibility, provider network status, duplicate claims, and whether the service performed is covered under the member’s PBO.
  • Setting Thresholds: I helped define rules that would flag a claim for manual review if it was high-value, had unusual service codes, or failed a specific validation step.
  • Improving Straight-Through Processing (STP) Rate: My primary goal was to increase the percentage of claims that could be processed automatically. I did this by analyzing why claims were failing and refining the rules to handle more scenarios automatically.

Can you give an example of a complex business rule you have implemented?

“Certainly. A common yet complex scenario I’ve worked on is implementing the adjudication rules for a major dental procedure, like a ‘Dental Crown’, which often has multiple conditions.

Business Requirements:

  1. Frequency Limitation: A member is only eligible for one crown on the same tooth every 5 years.
  2. Age Restriction: The procedure is not covered for members under 18.
  3. Benefit Calculation: The plan covers 50% of the billed amount, but only after the annual deductible has been met.

My Technical Implementation: As a backend developer, I translated these requirements into a sequence of checks within our Java-based rules engine:

  1. Frequency Check: First, I’d query the member’s claim history for the specific tooth code. If a crown procedure was paid for that tooth within the last 5 years, the current claim line would be denied with a reason code like ‘EXCEEDS_FREQUENCY_LIMIT’.
  2. Eligibility Check: Next, I’d check the member’s date of birth against the service date. If the member is under 18, the claim line is denied with a reason code like ‘AGE_INELIGIBLE’.
  3. Financial Calculation: If the first two checks pass, I’d then retrieve the member’s PBO to get their remaining deductible. I’d apply the billed amount to the deductible first. Any remaining amount would then be subject to the 50% coinsurance.

This entire logic was encapsulated in a service that returned a detailed adjudication result, including the calculated payment and any denial reasons. Writing comprehensive unit tests for each condition was critical to ensure accuracy.”

What are CPT and ICD codes, and why are they important in claims processing?

CPT and ICD codes are the universal language of medical billing, and they are fundamental to claims processing.

  • ICD (International Classification of Diseases) codes represent a patient’s diagnosis (e.g., J45.909 for Unspecified asthma).
  • CPT (Current Procedural Terminology) codes represent the medical services and procedures performed by a provider (e.g., 99213 for an office visit).

In my work on auto-adjudication, these codes are the primary inputs for the rules engine. For example, I’ve implemented rules that state ‘CPT code X is only payable if the claim also has a diagnosis code from a specific list of ICD codes.’ Without these standardized codes, automating claim processing would be impossible.

Explain the typical lifecycle of an insurance claim.

The claim lifecycle generally follows these steps:

  1. First Notice of Loss (FNOL): The policyholder reports the loss or damage.
  2. Claim Assignment: The claim is assigned to an adjuster for investigation.
  3. Investigation & Verification: The adjuster verifies the policy coverage and investigates the details of the loss.
  4. Adjudication & Evaluation: The claim is evaluated against the policy’s terms and business rules to determine the payable amount. This is where much of my backend logic comes into play.
  5. Resolution & Payment: The claim is either paid out, partially paid, or denied.
  6. Closure: Once the payment is made and all matters are settled, the claim is closed.

What is HCSA Claim?

HCSA stands for Health Care Spending Account.

Business Use Case: A member has an HCSA with a $500 balance. They buy prescription glasses for $300 and submit a claim for reimbursement.

  1. The member uploads the receipt through the member portal.
  2. Our system receives the HCSA claim.
  3. The adjudication logic first checks if ‘prescription eyewear’ is an eligible expense according to the plan rules.
  4. If it is, the system then checks the member’s current HCSA balance. Since the $300 expense is less than the $500 balance, the system approves the claim.
  5. It then deducts $300 from the member’s HCSA balance and processes the reimbursement payment to the member.

Explain Claims Processing.

Claims Processing is the end-to-end workflow for handling a request for payment from a healthcare provider or member.

Business Use Case: Let’s walk through a simple dental claim.

  1. Submission: A dentist’s office submits a claim electronically for a member’s annual check-up.
  2. Intake & Validation: Our system receives the claim data. The first thing my code does is validate the data format and check for required fields like member ID, provider ID, and service codes (CPT codes).
  3. Eligibility Check: The system then calls the MemberService to confirm that the member’s policy was active on the date of service.
  4. Adjudication: This is the core logic. The system applies business rules: Is this check-up covered? Has the member already had their one free check-up for the year? Is the provider in-network?
  5. Pricing & Payment: Based on the rules, the system calculates the payable amount. For an in-network check-up, this might be 100% of the negotiated rate.
  6. Finalization: The claim is finalized, an Explanation of Benefits (EOB) is generated for the member, and a payment instruction is sent to the PaymentService.

What are Business Rules?

Business Rules are configurable logic that defines how insurance processes behave. For example:

  • Eligibility validation
  • Coverage verification
  • Copay calculation
  • Deductible validation
  • Claim approval logic

These rules make the application flexible, allowing us to adapt to client needs without changing the core code.

Explain Member Enrollment.

Member Enrollment is the process of registering members into an insurance plan.

Business Use Case: A new employee joins a company and enrolls in their health plan.

  1. The company’s HR department sends an enrollment file (often a standard 834 EDI file) to us.
  2. A batch process I’ve worked on ingests this file.
  3. The system creates a new member record, links their chosen plan (PBO), and adds any dependents (like a spouse or children) to the policy.
  4. It also involves setting the coverage start date and ensuring all required information is present. This process is critical because claim processing depends entirely on having accurate and up-to-date member enrollment data.

What is PBO Configuration?

PBO stands for Plan Benefit Option. PBO Configuration is used to customize benefits, coverages, and rules for different insurance plans. This allows for client-specific customizations without major code changes.

What is an EOB (Explanation of Benefits)?

An EOB (Explanation of Benefits) is a document sent to a member after a claim is processed. It is not a bill. It details what the insurance plan covered, what the insurer paid, and what the member’s financial responsibility is (like deductibles, co-pays, or co-insurance).

Real-life Example: Imagine you go to the doctor for a visit that costs $150. A few weeks later, you get an EOB in the mail. It might show: Amount Billed: $150, Plan Discount: $50, Amount Covered: $100, Your Copay: $25, What Insurance Paid: $75, and finally, Amount You Owe: $25. This EOB clarifies that you only need to pay the doctor your $25 copay, not the full $150.

In my role, I worked on the batch process that generated these EOB documents, ensuring all these financial details from the adjudicated claim were accurately reflected.

What is COB (Coordination of Benefits)?

COB (Coordination of Benefits) is the process used to determine which insurance plan pays first when a member is covered by more than one health insurance policy (e.g., through their own job and their spouse’s job).

Real-life Example: Let’s say a member has a $1,000 medical bill. Their primary plan has a $100 deductible and 80% coinsurance. The primary plan pays 80% of ($1000 - $100), which is $720. The remaining balance is $280. The member’s secondary plan then processes a claim for this $280 and might cover it in full. The goal of COB is to ensure the total payment doesn’t exceed 100% of the bill.

I have implemented business rules to identify when COB applies and to correctly calculate the payment responsibilities of the primary and secondary payers during claim adjudication.

What is the difference between a Deductible, Coinsurance, and a Copay?

These are all forms of cost-sharing for the member, but they work differently:

  • Deductible: This is the fixed amount a member must pay out-of-pocket for covered services before the insurance plan starts to pay. For example, if a plan has a $1000 deductible, the member pays the first $1000 of costs.
  • Copay: This is a fixed dollar amount a member pays for a specific service, like a $25 fee for a doctor’s visit. It usually applies after the deductible is met, but some plans apply it before.
  • Coinsurance: This is the percentage of costs a member pays for a covered service after their deductible has been met. For example, with 20% coinsurance, the member pays 20% of the bill, and the insurance company pays 80%.

Real-life Calculation Example: Let’s say a member has a plan with a $1,000 deductible and 20% coinsurance. They have a hospital bill for a covered service that costs $5,000.

  1. Apply Deductible: The member first pays the $1,000 deductible. The remaining bill is $4,000.
  2. Apply Coinsurance: The member is responsible for 20% of the remaining $4,000, which is $800. The insurance plan pays the other 80%, which is $3,200.
  3. Total Member Responsibility: $1,000 (deductible) + $800 (coinsurance) = $1,800.

Technical Implication: In my role, I implemented the adjudication logic to correctly sequence these calculations. This involves fetching the member’s current accumulator for their deductible, applying it to the claim’s allowed amount, and then calculating the coinsurance on the remainder, all based on the rules in their PBO.

What is an Out-of-Pocket Maximum (OOPM)?

The Out-of-Pocket Maximum (OOPM) is the absolute most a member will have to pay for covered medical services in a plan year. This includes money spent on deductibles, copayments, and coinsurance. Once the member reaches this limit, the insurance plan pays 100% of the cost of covered benefits for the rest of the year.

Real-life Example: A member has a plan with a $5,000 OOPM. After a major surgery, their total payments (deductible + coinsurance) reach $5,000. For any subsequent medical care in that year, they pay nothing, and the insurance plan covers everything at 100%.

Technical Implication: This is a critical accumulator to manage in the backend. The adjudication engine must track the member’s year-to-date OOPM balance in real-time. When processing a claim, my code needs to check if applying the current claim’s cost-sharing will cause the member to hit their OOPM. If it does, the logic must cap the member’s responsibility at the OOPM limit and adjust the plan’s payment accordingly.

What is a TPA (Third-Party Administrator)?

A TPA (Third-Party Administrator) is a company that manages and processes insurance claims on behalf of an insurance company. They act as an operational arm, handling tasks like member enrollment, premium collection, and, most importantly, claim adjudication.

What is a Fee Schedule?

A Fee Schedule is a comprehensive price list that an insurance company uses to determine the maximum amount it will pay for a given medical service (identified by a CPT code). This is often a pre-negotiated rate between the insurer and in-network providers. It’s also known as the “allowed amount” or “negotiated rate.”

Real-life Example: A doctor’s standard charge (billed amount) for a specific office visit is $200. However, they have a contract with an insurance company, and the agreed-upon fee schedule rate for that service is only $120. The insurance company will only consider $120 as the basis for payment.

Technical Implication: In the claims adjudication engine, one of the first steps after validation is pricing the claim. My code takes the CPT code from the claim line and looks up the corresponding price in the correct fee schedule for that provider’s specific contract. This “allowed amount” of $120, not the billed amount of $200, is then used for all subsequent deductible and coinsurance calculations.

Real-life Example: When you go to a hospital for a cashless claim, you often interact with a TPA, not the insurance company directly. For instance, your insurance card might be from New India Assurance, but the processing might be handled by a TPA like Medi Assist or Vidal Health. The TPA verifies your identity, checks your policy coverage, and authorizes the treatment.

Technical Implication: As a backend developer, my system would need to integrate with TPA systems. This involves building and consuming APIs to:

  • Synchronize member eligibility data with the TPA.
  • Receive claim information submitted by the TPA.
  • Send back adjudication results and payment instructions.

Explain the difference between In-Network and Out-of-Network providers.

This distinction is critical for benefit calculation in health insurance.

  • In-Network Providers: These are doctors, hospitals, and clinics that have a contract with the insurance company to provide services at discounted rates.
  • Out-of-Network Providers: These providers do not have a contract with the insurance company.

Real-life Example: Let’s say you need a dental check-up. If you go to an in-network dentist, your plan might cover 90% of the cost after your deductible. If you go to an out-of-network dentist, the plan might only cover 60%, and you would be responsible for the rest.

Technical Implication: In the auto-adjudication engine, checking the provider’s network status is a fundamental rule. When a claim comes in, my code would take the provider’s ID (like an NPI number) and check it against a database to see if they are in-network for that specific member’s plan. The result of this check directly determines which benefit rules (e.g., coinsurance percentage, deductible amount) are applied to the claim.

What is the difference between an HMO and a PPO plan?

HMO and PPO are two of the most common types of health insurance plans, and they primarily differ in how members access care, particularly regarding provider networks and referrals.

  • HMO (Health Maintenance Organization):
    • Primary Care Physician (PCP): Members must choose a PCP from within the HMO’s network.
    • Referrals: To see a specialist (like a cardiologist), you almost always need a referral from your PCP.
    • Network: Care is only covered if you use doctors, hospitals, and specialists within the HMO’s network (except in emergencies).
    • Cost: Generally has lower premiums and out-of-pocket costs.
  • PPO (Preferred Provider Organization):
    • Flexibility: Members have the freedom to see any doctor or specialist they want, both in-network and out-of-network, without a referral.
    • Network: You get the maximum benefit and pay less if you use providers in the PPO’s network. Going out-of-network results in higher out-of-pocket costs.
    • Cost: Generally has higher premiums for the flexibility it offers.

Technical Implication: From a backend perspective, this directly impacts the claim adjudication logic. For an HMO plan, the rules engine must verify:

  1. If the claim is from a specialist, is there a valid, approved referral from the member’s PCP on file?
  2. Is the provider who submitted the claim part of the member’s specific HMO network?

For a PPO plan, the logic is different. The engine checks if the provider is in-network or out-of-network and applies a different benefit structure (e.g., 80% coinsurance for in-network vs. 60% for out-of-network) accordingly.

What is Pre-authorization (or Prior Authorization)?

Pre-authorization is the process of getting approval from the insurance company before a specific, non-emergency medical service is performed. It’s typically required for expensive procedures like an MRI, a planned surgery, or high-cost prescription drugs.

Real-life Example: Your doctor recommends a knee replacement surgery. Before scheduling it, the hospital’s administrative staff submits a pre-authorization request to your insurance company with your medical records. The insurer reviews the request to confirm that the surgery is medically necessary and covered under your plan. If approved, the insurer provides an authorization number.

Technical Implication: I’ve worked on the backend workflows that manage these pre-authorization requests. This involves:

  1. Creating API endpoints for providers to submit authorization requests electronically.
  2. Building a rules engine to auto-approve requests that meet clear criteria.
  3. Developing a workflow to route complex cases to a human reviewer (like a nurse or doctor).
  4. Storing the approved authorization so that when the final claim is submitted, the adjudication system can automatically verify that the required pre-authorization was obtained.

What is Subrogation?

Subrogation is the right of an insurer to pursue a third party that caused an insurance loss to the insured, in order to recover the amount the insurer paid.

For example, if our member is injured in a car accident caused by another driver, we would pay our member’s medical bills first. Then, through subrogation, our company would seek reimbursement from the at-fault driver’s auto insurance. From a technical standpoint, I’ve worked on workflows where a claim is flagged as having ‘subrogation potential’ based on certain incident codes. This flag would trigger a process to create a case in a separate recovery module, ensuring that the opportunity to recover funds is not lost.

What is Underwriting?

Underwriting is the process insurers use to evaluate the risk of insuring a person or asset. Underwriters determine whether to accept the risk, and if so, at what price (the premium) and under what terms.

Real-life Example: When you apply for life insurance, the underwriter looks at your age, health records, and lifestyle (e.g., if you’re a smoker). Based on this risk assessment, they decide your premium. A healthy 30-year-old will pay a much lower premium than a 60-year-old with a history of health issues. This entire risk evaluation process is underwriting.

While my primary focus was on claims, the underwriting rules directly impact the policy terms that the claims system adjudicates against.

What is a Formulary?

A Formulary is a list of prescription drugs covered by a health insurance plan. Drugs on the formulary are often grouped into “tiers.” Drugs in lower tiers (like generics) cost less out-of-pocket for the member, while drugs in higher tiers (like brand-name or specialty drugs) cost more.

Real-life Example: A doctor prescribes a brand-name medication. When the member goes to the pharmacy, they find out it’s a “Tier 3” drug with a $100 copay. The pharmacist informs them that a generic equivalent is a “Tier 1” drug with only a $10 copay.

Technical Implication: When processing a pharmacy claim, the backend system uses the drug’s NDC (National Drug Code) to look it up in the member’s specific formulary. The rules engine then identifies the drug’s tier and applies the correct copay or coinsurance. If a drug is not on the formulary, the claim might be denied unless a pre-authorization is on file.

What are EDI files like 837 and 834?

EDI (Electronic Data Interchange) files are the standard electronic format for exchanging healthcare business documents. As a backend developer, the two most common ones are:

  • EDI 837: This is the standard format for submitting healthcare claims. A single 837 file can contain thousands of claims from a hospital or provider group.
  • EDI 834: This is the standard format for benefit enrollment and maintenance. Companies use it to send employee enrollment data to insurance carriers.

Real-life Example: Instead of manually entering thousands of claims into a web portal, a large hospital’s billing system automatically generates a single, massive 837 file at the end of the day and transmits it to the insurance company’s server.

Technical Implication: I have worked on the backend batch processes that are responsible for ingesting and parsing these files. This involves:

  1. Receiving the file via a secure FTP or API.
  2. Using a specialized library to parse the complex, segment-based structure of the EDI file.
  3. Validating the data against HIPAA standards.
  4. Transforming the data from the EDI format into claim or member objects that our internal systems can understand and process.

This is a critical data-intake process for any large-scale insurance platform.

How does Property & Casualty (P&C) insurance differ from Health Insurance?

They cover different types of risks and have different business models:

  • Health Insurance covers medical expenses for individuals. The claims are typically high-volume and have a wide range of values (from small prescription costs to large surgery bills).
  • P&C (Property & Casualty) Insurance covers property (like a home or car) and liability (legal responsibility for damage or injury to others). P&C claims are usually lower-volume but can be very high-value (e.g., a house fire or a major car accident). The claims processing logic is also different, often involving detailed damage assessments, liability investigations, and subrogation.

Simple Analogy: Health insurance is for you (your body). P&C insurance is for your stuff (your car, your house) and for accidents where you are at fault. A health claim might be for a $500 doctor’s visit. A P&C claim could be for a $300,000 house fire.

Have you worked with any retirement products like Annuities?

While my core experience is in health insurance, I have a foundational understanding of retirement products like Annuities. An annuity is a contract with an insurance company where you make a lump-sum payment or series of payments, and in return, you receive regular disbursements, either immediately or in the future.

From a technical perspective, managing annuities involves:

  • Accumulation Phase: Tracking contributions and investment growth.
  • Payout Phase: Calculating and processing regular payments based on the contract terms, which can be complex.
  • Batch Processing: Running batches for interest calculations, statement generation, and payment disbursements, which is very similar to the batch processes I’ve managed in health insurance.

What is HIPAA and how does it impact your work as a backend developer?

HIPAA (Health Insurance Portability and Accountability Act) is a critical US law that sets the standard for protecting sensitive patient data. As a backend developer, it’s not just a concept; it’s a core part of my daily work. It impacts my code in several ways:

  • Data Security: I must ensure that any PHI (Protected Health Information) is encrypted both at rest (in the database) and in transit (over HTTPS).
  • Access Control: My code must enforce strict authorization rules. For example, in the APIs I’ve built, I ensure a member can only access their own claim data by validating their identity from the JWT against the resource being requested.
  • Logging and Auditing: I am extremely careful not to log any raw PHI. My logging practices involve masking sensitive fields or excluding them entirely. We also implement audit trails to track who accessed or modified PHI.
  • Data De-identification: When providing data for testing or analytics, I’ve written scripts to de-identify or anonymize the data to comply with HIPAA.

How would you design a system for fraudulent claims detection?

This is a great system design question. I would design a multi-layered system:

  1. Rule-Based Engine: Implement a set of predefined business rules to flag suspicious claims. For example, flagging multiple claims for the same incident or claims filed shortly after a policy is purchased.
  2. Data Analytics & Machine Learning: Use data analytics to identify unusual patterns. For instance, a provider who submits a significantly higher number of a specific type of claim compared to their peers could be flagged. A machine learning model could be trained on historical data to predict a “fraud score.”
  3. Integration with Third-Party Services: Integrate with external databases to verify information, such as checking a claimant’s history or vehicle information.
  4. Scoring and Routing: Each claim would pass through these layers and receive a fraud score. Claims with a score above a certain threshold would be automatically routed to a special investigation unit for manual review, while low-score claims could proceed with auto-adjudication.