PAT Patient
Who received care? Store patient name, date of birth, sex, address, and patient account/control number as patient facts.
Lesson 0005
Patient Is Not Always Subscriber
The practical product skill: separate the person who received care from the person whose insurance coverage is being used.
Your Tangible Win
After this lesson, you should be able to route registration and eligibility issues into four buckets: PAT, SUB, REL, or COV.
Primary source to read after the lesson: CMS MLN Key Patient and Claim Information.
The Core Idea
The patient is the person who received care. The subscriber, also called the insured in many claim contexts, is the person whose coverage is being billed. Sometimes they are the same person. Sometimes the patient is a spouse, child, or other dependent.
CMS emphasizes exact patient matching: patient name should be reported as shown on the insurance card, and birth date, sex, address, and related patient facts are separate claim fields (CMS MLN Key Patient and Claim Information). CMS also treats insurance coverage and insured ID as payer information sourced from the insurance card (CMS MLN Insurance and Authorization).
The Four Facts
SUB Subscriber
Whose insurance coverage is used? Store the subscriber or insured separately when the patient is a dependent.
REL Relationship
How is the patient related to the subscriber? Examples include self, spouse, child, and other dependent relationships.
COV Coverage
Which payer, plan, member ID, eligibility period, benefits, and patient responsibility apply? CMS says eligibility data helps prepare accurate claims and determine beneficiary liability (CMS Eligibility Inquiry).
Same Is Allowed
If the patient is the subscriber, store that relationship explicitly. Do not infer it forever from one visit or one card scan.
NUCC Anchor
The NUCC instruction manual is the standardized reference for CMS-1500 completion, including patient and insured claim-form semantics (NUCC 1500 Instructions).
Mini Case
A child receives therapy. The insurance card is under the mother's name. The EMR sends the child's name and DOB as the subscriber, because the registration screen only has one set of insurance identity fields.
Product diagnosis: this is a subscriber modeling failure, not a clinical documentation problem. The product needs separate patient, subscriber, relationship, and coverage facts before claim submission.
Design Rule
Model insurance as a relationship between a patient and a coverage record. Do not attach the payer member ID directly to the patient as if every patient is the subscriber.
| Signal | Bucket | Likely Product Fix |
|---|---|---|
| The person who received care has the wrong DOB. | PAT | Correct patient demographics. |
| The policyholder name is missing for a dependent child. | SUB | Collect subscriber or insured identity. |
| The payer does not know whether the patient is self or child. | REL | Capture patient relationship to subscriber. |
| The member ID is from an inactive plan. | COV | Run eligibility and update coverage. |
Retrieval Practice
Type the bucket code from memory: PAT, SUB, REL, or COV.
What to Ask Me Next
Ask follow-up questions whenever one identity layer feels fuzzy. Good next questions: "How should I model coverage in a database?", "What does eligibility return?", or "How do subscriber loops work in an 837P?"
For review, keep the patient subscriber map nearby.