Observance Solutions
Health Insurance

HMO vs PPO vs Medicare vs Medicaid: Understanding US Health Insurance for Healthcare Software Developers

Observance Solutions Engineering8 min read

You don't need to be an insurance expert to build good healthcare software, but you do need to know which of these plan types changes your application's actual logic - referral requirements, prior auth frequency, and claim routing all differ.

HMO vs PPO: the distinction that actually changes your workflow

An HMO (Health Maintenance Organization) plan generally requires the member to choose a primary care provider and get a referral before seeing most specialists, and typically only covers care within its network except in emergencies. A PPO (Preferred Provider Organization) plan doesn't require a PCP or referrals, and covers out-of-network care (usually at a higher member cost) alongside in-network care.

For software, this matters concretely: an HMO-driven scheduling or referral workflow needs to track and enforce referral requirements before a specialist visit is booked or billed, while a PPO-driven one doesn't need that gate but does need to correctly apply different cost-sharing logic for in- vs. out-of-network providers. If your platform serves both plan types, this needs to be a data-driven distinction (read from the patient's actual plan), not a hardcoded assumption about how referrals work.

Medicare: parts, not a single plan type

Medicare isn't one plan - Part A covers hospital/inpatient care, Part B covers outpatient/physician services, Part C (Medicare Advantage) is a private-insurer-administered alternative that often looks and behaves like an HMO or PPO with its own network and referral rules, and Part D covers prescription drugs. A patient can be enrolled in different combinations of these, and Medicare Advantage plans in particular vary enormously in their referral and prior authorization rules because they're run by private payers, not by Medicare directly.

Software handling Medicare patients needs to know which parts apply and, for Medicare Advantage specifically, treat it functionally like whatever private-payer plan type it actually is (often HMO- or PPO-like) rather than assuming 'Medicare' implies one uniform behavior.

Medicaid: state-administered, so 'Medicaid rules' vary by state

Medicaid is jointly funded by federal and state government but administered at the state level, which means eligibility rules, covered services, prior authorization requirements, and even claim formats can differ meaningfully from state to state. A platform operating across multiple states needs to treat Medicaid rules as state-specific configuration, not a single hardcoded ruleset - what requires prior authorization under one state's Medicaid program may not under another's.

Many states have also moved much of their Medicaid population into managed care organizations (MCOs) - private payers administering Medicaid benefits under state contract - which again behave more like HMO/PPO-style managed plans than a single monolithic 'Medicaid' system.

What this means for your data model

Model plan type, network rules, referral requirements, and prior authorization requirements as attributes of the specific plan a patient is enrolled in - sourced from real eligibility/benefit data (a 271 response, or the payer's own plan configuration) rather than inferred from a coarse label like 'HMO' or 'Medicaid.' The label is a useful starting signal, but the actual applicable rules can vary enough within a single label (especially for Medicare Advantage and state Medicaid programs) that treating it as authoritative on its own will produce wrong behavior for real patients.

FAQ

Quick answers

Yes, in most cases. HMO plans typically require a referral from a primary care provider before specialist visits are covered, while PPO plans generally don't. This should be driven by the patient's actual plan data, not a hardcoded assumption, since exceptions and variations exist.

Have a project like this in mind?

Tell us what you're building. A senior healthcare technologist — not a salesperson — will get back to you within one business day.