HL7^® Reference Guide

HL7 IN2 Insurance Additional Information

Examine the usage of every IN2 field from experience.

HL7 field reference IN2 fields from HL7 v2.5.1 Show fields

These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.

Fields

Field	Name	Required	Repeatable	Type	Table
IN2.1	Insured's Employee ID	No	Yes	CX
IN2.2	Insured's Social Security Number	No	No	ST
IN2.3	Insured's Employer's Name and ID	No	Yes	XCN
IN2.4	Employer Information Data	No	No	IS	0139
IN2.5	Mail Claim Party	No	Yes	IS	0137
IN2.6	Medicare Health Ins Card Number	No	No	ST
IN2.7	Medicaid Case Name	No	Yes	XPN
IN2.8	Medicaid Case Number	No	No	ST
IN2.9	Military Sponsor Name	No	Yes	XPN
IN2.10	Military ID Number	No	No	ST
IN2.11	Dependent Of Military Recipient	No	No	CE	0342
IN2.12	Military Organization	No	No	ST
IN2.13	Military Station	No	No	ST
IN2.14	Military Service	No	No	IS	0140
IN2.15	Military Rank/Grade	No	No	IS	0141
IN2.16	Military Status	No	No	IS	0142
IN2.17	Military Retire Date	No	No	DT
IN2.18	Military Non-Avail Cert On File	No	No	ID	0136
IN2.19	Baby Coverage	No	No	ID	0136
IN2.20	Combine Baby Bill	No	No	ID	0136
IN2.21	Blood Deductible	No	No	ST
IN2.22	Special Coverage Approval Name	No	Yes	XPN
IN2.23	Special Coverage Approval Title	No	No	ST
IN2.24	Non-Covered Insurance Code	No	Yes	IS	0143
IN2.25	Payor ID	No	Yes	CX
IN2.26	Payor Subscriber ID	No	Yes	CX
IN2.27	Eligibility Source	No	No	IS	0144
IN2.28	Room Coverage Type/Amount	No	Yes	RMC	0145
IN2.29	Policy Type/Amount	No	Yes	PTA	0147
IN2.30	Daily Deductible	No	No	DDI
IN2.31	Living Dependency	No	No	IS	0223
IN2.32	Ambulatory Status	No	Yes	IS	0009
IN2.33	Citizenship	No	Yes	CE	0171
IN2.34	Primary Language	No	No	CE	0296
IN2.35	Living Arrangement	No	No	IS	0220
IN2.36	Publicity Code	No	No	CE	0215
IN2.37	Protection Indicator	No	No	ID	0136
IN2.38	Student Indicator	No	No	IS	0231
IN2.39	Religion	No	No	CE	0006
IN2.40	Mother's Maiden Name	No	Yes	XPN
IN2.41	Nationality	No	No	CE	0212
IN2.42	Ethnic Group	No	Yes	CE	0189
IN2.43	Marital Status	No	Yes	CE	0002
IN2.44	Insured's Employment Start Date	No	No	DT
IN2.45	Employment Stop Date	No	No	DT
IN2.46	Job Title	No	No	ST
IN2.47	Job Code/Class	No	No	JCC	0327
IN2.48	Job Status	No	No	IS	0311
IN2.49	Employer Contact Person Name	No	Yes	XPN
IN2.50	Employer Contact Person Phone Number	No	Yes	XTN
IN2.51	Employer Contact Reason	No	No	IS	0222
IN2.52	Insured's Contact Person's Name	No	Yes	XPN
IN2.53	Insured's Contact Person Phone Number	No	Yes	XTN
IN2.54	Insured's Contact Person Reason	No	Yes	IS	0222
IN2.55	Relationship to the Patient Start Date	No	No	DT
IN2.56	Relationship to the Patient Stop Date	No	Yes	DT
IN2.57	Insurance Co. Contact Reason	No	No	IS	0232
IN2.58	Insurance Co Contact Phone Number	No	No	XTN
IN2.59	Policy Scope	No	No	IS	0312
IN2.60	Policy Source	No	No	IS	0313
IN2.61	Patient Member Number	No	No	CX
IN2.62	Guarantor's Relationship to Insured	No	No	CE	0063
IN2.63	Insured's Phone Number - Home	No	Yes	XTN
IN2.64	Insured's Employer Phone Number	No	Yes	XTN
IN2.65	Military Handicapped Program	No	No	CE	0343
IN2.66	Suspend Flag	No	No	ID	0136
IN2.67	Copay Limit Flag	No	No	ID	0136
IN2.68	Stoploss Limit Flag	No	No	ID	0136
IN2.69	Insured Organization Name and ID	No	Yes	XON
IN2.70	Insured Employer Organization Name and ID	No	Yes	XON
IN2.71	Race	No	Yes	CE	0005
IN2.72	CMS Patient's Relationship to Insured	No	No	CE	0344

IN2 is the extra insurance segment. It is not usually where you start. You start with IN1, because IN1 tells you the payer, plan, group, subscriber, policy number, coverage dates, and coordination details. IN2 comes after that when the billing system needs more: employer identifiers, Medicare or Medicaid numbers, military benefit detail, eligibility source, subscriber contact information, policy scope, member numbers for dependents, and a few older benefit flags that live mostly in patient accounting land.

The reason IN2 feels strange is that it is a companion segment, not a clean little standalone object. The IN1 segment has the set ID. IN2 does not. If a patient has two insurance plans, you normally get an IN1/IN2/IN3 group for plan one, then another IN1/IN2/IN3 group for plan two. So when you parse IN2, do not ask "which IN2 is this?" in isolation. Ask which IN1 it belongs to.

Another thing to know is that IN2 contains a lot of fields defined around CMS, military, Medicaid, benefit administration, and local payer rules. That means you should be suspicious of a very full IN2 unless the sending system really knows what the values mean. A short, accurate IN2 is much better than a long one full of copied registration trivia, stale eligibility values, or sensitive identifiers that nobody downstream should have received.

The example is deliberately a bit billing-heavy. Most real feeds will not fill everything. The key values to notice are the employer employee ID, payer ID, payer subscriber ID, eligibility source, policy scope/source, patient member number, and the patient relationship to the insured. Those are the values that explain who owns the policy, who is receiving care, which payer/member identifiers should be used, and why the receiver should trust the coverage snapshot. Open it in HL7 Soup Web and you can see why IN2 is easiest to understand beside its IN1 partner, not as a lonely segment floating by itself.

Why IN2 exists beside IN1

IN1 is the insurance card in segment form. IN2 is the paperwork drawer behind it. IN1 says "Acme Health Plan, group GRP-4455, policy POL-778899, subscriber Jane Smith". IN2 can then say "Jane's employee number is EMP7788, this member number is different for the covered patient, the source of the policy was the card, eligibility came from the insurer, and this is the contact number to use for claim questions".

I would not create IN2 just because the standard has one. Use it when the receiver has a real billing, eligibility, payer, government program, or subscriber-detail reason to receive the data. If the value is already cleanly represented in IN1, do not duplicate it into IN2 unless the trading partner asks for it. Duplication is where IN1 policy number says one thing, IN2 subscriber ID says another, and then everybody gets to enjoy a billing mystery.

This is useful when the insured person's coverage comes through an employer and the employer's employee number matters to the payer or billing system. It should be treated as the insured person's employee identifier, not automatically the patient's employee identifier. If a child is covered through a parent, this value belongs to the parent subscriber, not the child.

This field is old and sensitive. You will still see legacy billing feeds that expect it, but it should not be sent casually. Social Security numbers are identity data, not just convenient insurance numbers. For Medicare, the old SSN-based HICN world has been replaced by Medicare Beneficiary Identifiers for ordinary billing and eligibility transactions, so do not assume IN2-2 is a modern Medicare identifier.

This is the employer attached to the insured person. It is handy for employer-sponsored coverage, workers' compensation-adjacent workflows, and payer matching where the group number alone is not enough. I would rather see a clear organization identifier here than just a display name, because employer names vary wildly once abbreviations, payroll entities, and subsidiaries get involved.

This is a small classification field for employer information, and it is very local in practice. If the receiving system does not have an agreed table for it, leave it alone. A vague code such as E or 1 is only useful when both systems know exactly what kind of employer information it means.

This says who should receive mailed claim-related material. The suggested values include patient, employer, insurance company, guarantor, and other. You will not use this in every integration, but when paper claims, statements, or employer-administered processes are still in play, it can stop the receiver from sending the paperwork to the wrong party.

This field is historically important, but the wording is showing its age. Older interfaces may call this the Medicare Health Insurance Claim Number. Modern Medicare transactions use the Medicare Beneficiary Identifier, and CMS specifically moved away from SSN-based HICNs. If you use this field today, document whether it contains an old HICN, a current MBI, or a local Medicare identifier, because those are not the same operational promise.

Even when a special Medicare number is sent here, IN1-36 can still carry the policy or member number if the trading partner expects it. The danger is splitting one identifier across several fields and then not saying which one drives billing. Choose the system-of-record field and make the mapping explicit.

Medicaid programs can be case-based, and the case name is not always the same as the patient name. This is a good example of IN2 being more about program administration than clinical identity. If the receiver does Medicaid billing or eligibility reconciliation, this may matter; if not, it is usually just extra sensitive data.

This is the Medicaid case identifier, and it deserves the same care as any payer-issued identifier. Preserve leading zeros, suffixes, and punctuation unless the trading partner has a very clear normalization rule. Do not put a general member ID here just because the patient has Medicaid; use it when the source is really sending a Medicaid case number.

Military and TRICARE-style coverage often depends on the sponsor, not just the patient receiving care. This field names the sponsor. It is especially important when the patient is a spouse or dependent and eligibility comes through the sponsor's service status.

Be careful with this one. In military coverage, there can be several tempting numbers on a card, and not all of them are claims numbers. For TRICARE, the DoD Benefits Number is used for eligibility and claims, while the DoD ID number should not be used to submit claims. If this field is populated, the interface guide should say exactly which military identifier it is carrying.

This tells whether the patient is dependent on the military recipient or sponsor. The real value is not the code itself; it is the claim story it supports. If the patient is covered through a service member, the receiver needs to know whether the patient is the sponsor, spouse, child, or another dependent category.

This is the military organization tied to the coverage or sponsor. In many ordinary feeds it is blank, but in military provider networks, government billing, or eligibility-heavy workflows, it can help identify the program context. Treat it as a coverage/program detail, not a patient demographic.

The station is the location or station associated with the military record. It is not the patient's hospital location, and it should not be confused with PV1. If it appears, it normally belongs to military eligibility or benefit administration.

This identifies the service branch or military service, using a local or suggested table. It can matter for coverage routing and program reporting. If the interface is not military-aware, the best approach is usually to pass it through unchanged rather than trying to translate it into a home-grown code.

Rank or grade is another military program detail. It may be needed by a specific payer or government workflow, but it is not a general patient title. Keep it out of patient name fields and avoid displaying it as if it were a clinical salutation.

This describes the military status, such as active duty, retired, or deceased in the older suggested values. In coverage terms, status can change eligibility, so stale values can be harmful. If it matters, it should come from an eligibility source that is kept current.

The retire date gives the timing behind a retired military status. It is rarely needed outside military-specific coverage. When it is used, send a real date and do not infer it from age, registration notes, or the patient's own recollection unless the workflow is explicitly built that way.

This yes/no field says whether a military non-availability certificate is on file. That is a very specific administrative artifact. If the receiving billing system needs it, the source system should be the system that actually knows the certificate was collected, not a generic ADT feed guessing from insurance type.

Baby coverage is used around newborn billing, where coverage for the baby may be handled through the mother's policy or a special newborn rule for a limited time. This is one of those fields that can look small but affect claims. It should line up with the newborn's actual coverage workflow and not be set merely because the patient is young.

This indicates whether the baby bill should be combined with another bill, commonly the mother's. It is billing behaviour, not a clinical relationship. The receiver needs to know exactly how combined billing is expected to work, because it affects statements, guarantor handling, and payer submission.

This is a benefit detail around blood deductible handling. Most modern general-purpose interfaces leave it blank. If it is used, it should come from current benefit information, not a stored registration value that may have been copied forward for years.

This names the person associated with a special coverage approval. It is not the same as a normal authorization number, and it is not a general approver field for all billing. Use it only when the payer or program actually has a named approval contact that the receiver needs to retain.

The approval title goes with the approval name. It is useful when the human role matters, such as a benefits administrator, case worker, or program officer. If the approval is just a payer authorization code, this field is usually the wrong place.

This can identify services or situations that are not covered by the insurance. It is tempting to treat this as a broad "payer will not pay" flag, but it should be more precise than that. A non-covered code should be tied to a defined benefit rule or local billing table, otherwise it becomes a vague warning that nobody trusts.

This is one of the important IN2 fields. It is a CX identifier for the payer, and it may overlap with IN1-3 Insurance Company ID. The safest pattern is to decide which identifier drives routing, eligibility, or claims, and then keep IN1 and IN2 consistent. If IN1-3 says one payer and IN2-25 says another, the receiver has to guess whether one is a display payer, clearinghouse payer, legacy payer, or a mistake.

This is another key one. The payer subscriber ID identifies the subscriber as known by the payer. It may be the value that appears on a card as subscriber ID, member ID, policy ID, or identification number, depending on the payer. Because it is CX, include assigning authority and identifier type when you can. A naked subscriber number can collide across payers.

The subtle point is that the subscriber ID and the patient's own member number may differ. A family policy can have a subscriber identifier for the parent and a dependent/member identifier for each covered child. That is why IN2-61 exists. If you only ever test with self-covered adults, you will miss this problem until a dependent claim fails.

This tells where the eligibility information came from: insurer, employer, policy, card, signed statement, verbal information, or none in the older suggested table. It is a small field with a big honesty problem. "Patient showed a card" is not the same as "payer verified active coverage". If the receiver bills from this data, the source matters.

This describes room coverage by type and amount, such as private, semi-private, or intensive care categories in older inpatient billing models. Many modern feeds do not populate it because benefit detail changes and is better obtained from eligibility/benefit transactions. If you do send it, make sure the amount is current and the room type coding matches the receiver's billing rules.

This is a structured place for policy type and benefit amount. It can be a better home than older IN1 policy limit fields when a trading partner really needs benefit amounts. I would still be conservative: benefit amounts go stale quickly, and a payer eligibility response is often a better source than registration data.

The daily deductible is another benefit detail. It belongs in billing and benefits workflows, not general clinical interfaces. If the receiver does not actively use it, leave it blank rather than sending a guessed deductible that might mislead staff or billing logic.

This describes dependency in the insured person's living situation, such as children or spouse dependent, medical supervision required, or unknown. It is sensitive and often not needed for insurance exchange. Use it only when the payer or administrative workflow has a defined reason for it.

Ambulatory status describes functional mobility limitations for the insured. It can be relevant to certain coverage or program contexts, but it can also look like clinical/disability information that is being sent too broadly. If your receiving system is not using it for a defined billing or eligibility rule, be cautious.

Citizenship belongs to the insured person here, not automatically to the patient. It may matter in government, military, or regional coverage programs. In many commercial insurance feeds, sending it is unnecessary and sensitive, so the interface should justify why it is present.

This is the insured person's primary language. If the insured is also the patient, it may match PID. If the subscriber is a parent or spouse, it may not. Do not overwrite patient language preferences from this field unless the patient and insured are known to be the same person.

Living arrangement describes the insured person's primary residence situation, such as alone, family, institution, relative, or spouse only in the old suggested table. It is more social/admin detail than ordinary insurance detail. Treat it as optional and sensitive unless a profile or payer really asks for it.

This indicates what level of publicity or disclosure is allowed for the insured, such as no publicity or family only. It is easy to misunderstand this as a modern consent model. It is not. If privacy or information blocking rules matter in your environment, use the specific consent and access-control workflow your implementation guide defines.

This yes/no field says whether access to the insured's information should be restricted. It should be handled seriously because it affects privacy. Do not strip it just because the receiving billing system is old, and do not set it casually just because a patient is considered VIP. It should reflect a real protection rule.

Student status is one of the IN2 fields that has caused real billing pain historically, especially for dependent coverage where full-time student status once affected eligibility. The suggested values are full-time, part-time, or not a student. Modern payer rules vary, so do not assume the field matters for every plan, but if the receiver asks for it, send the exact status you know.

This is the insured person's religion, not a payer identifier. It is rarely needed for insurance billing and should be treated as sensitive demographic information. If a regional implementation guide does not require it, I would normally leave it blank.

This field is sometimes used for identity matching, but it is also a very sensitive identity-verification value. It belongs to the insured, not necessarily the patient. If the receiver wants it for matching, challenge that requirement a little and make sure there is a privacy reason for passing it around.

Nationality can be different from citizenship in countries where national grouping matters. It is rarely useful in ordinary insurance feeds. If it is used, keep the coding system clear and do not collapse it into country of address, citizenship, race, or ethnicity; those are different concepts.

Ethnicity here is the insured person's ethnic group. Like race and religion, this should not be copied around just because it exists in registration. In some government reporting contexts the coding may be defined very precisely, but for most insurance interfaces it is either blank or profile-specific.

Marital status can affect some coverage relationships, especially spouse coverage and dependent rules. Still, it should be read as the insured's marital status, not automatically the patient's. Keep it separate from PID marital status unless your data model has proven they are the same person.

This date can help explain employer-sponsored eligibility. It may matter when coverage begins after employment starts, or when a payer needs employment history. Do not infer it from the policy effective date; employment start date and coverage start date are related but not identical.

Employment stop date can be important when coverage is ending, changing to COBRA-like coverage, or being checked against employer records. If this date is stale or wrong, it can make a coverage look inactive when it is not, or active when it has ended. Only send it when the source system really knows it.

Job title is free text, so it is mainly useful for display or human follow-up. It is not a stable job classification. If the receiver needs coded occupation or job class, IN2-47 is the more structured field.

This is the coded version of the insured person's job role or class. It can matter for employer benefit plans, occupational health, or compensation-related coverage. Since the table is user-defined, a code like PROG or RN only makes sense if both sides share the same job-code vocabulary.

Job status says whether the insured's job is permanent, temporary, other, or unknown in the older suggested values. It can affect benefit eligibility. If the feed has both employment status in IN1 and job status in IN2, document the difference so one does not quietly overwrite the other.

This names the person at the insured's employer who should be contacted about the policy. It is not a general next-of-kin contact and it is not the patient contact. Think benefits administrator, HR contact, or employer plan contact.

This carries the phone number for the employer contact. Use XTN properly, with use code and equipment type where possible. Also remember that multiple phone numbers here are for the same contact person, not a list of different people.

This explains why the employer contact should be used. It is a helpful field when the contact is only for benefits, claim questions, employment verification, or address changes. If you put a name and phone number in IN2-49 and IN2-50, this field keeps the receiver from treating that person as a general catch-all contact.

This is a contact person for the insured, separate from the employer contact. It may overlap with NK1, but the context is different. NK1 is patient-associated parties; this field is part of the insurance/insured detail. Do not merge the two without a deliberate rule.

This is the phone number for the insured's contact person. As with other XTN fields, structure the number instead of sending a blob of text when you can. If the insured is not the patient, this number may not belong anywhere near the patient's ordinary contact list.

This says why the insured's contact person exists in the record. It helps distinguish an emergency contact from a billing contact, a benefits contact, or someone used for administrative follow-up. Without the reason, the receiver may use the contact in the wrong context.

This date says when the insured-to-patient relationship began. That can matter for coverage history, especially dependents, spouses, guardianship, and changing family situations. It is not the same as plan effective date, even if they often start near each other.

This says when that relationship ended. It is repeatable in v2.5.1, which tells you it was designed for messy administrative history rather than a simple current-state flag. If you send it, make sure the receiver understands whether it is a historical relationship date or a current coverage termination indicator.

This explains what the insurance company contact is for. The suggested table includes Medicare claim status, Medicaid claim status, and name/address change. It is a nice little field when a payer has different phone queues for different work. It is less useful if everyone just sends "claims" and leaves staff to work it out.

This is the phone number to use for insurance policy or claim questions. Later HL7 guidance warns not to infer meaning from the first, second, or third repetition of phone numbers. Use explicit telecom components and contact reason rather than "the first one is claims and the second one is eligibility" folklore.

Policy scope describes the extent of coverage for the participating member, such as single or family in typical payer language. This is different from plan type and coverage type. It answers "who is covered by this policy scope?" more than "what kind of product is this?"

This says how the policy information was established. A card presented by the patient, an employer file, a payer eligibility check, and a signed statement are not equivalent. When coverage later fails, this field can explain whether the system had payer-verified information or just a registration snapshot.

This is a very useful IN2 field and probably one of the easiest to underuse. It is the payer-assigned number for the individual covered by the policy. On family coverage, the subscriber may have one identifier while each dependent has a different member or dependent number. That is the exact space this field was built for.

Do not automatically copy IN1-36 or IN2-26 into IN2-61. If the patient is the subscriber, the values may match or may not be needed. If the patient is a dependent, IN2-61 can be the value that makes the claim line up with the right beneficiary under the subscriber's policy.

This connects the GT1 world to the insurance subscriber world. The guarantor is the person or organization financially responsible for the account. The insured/subscriber is the person who holds the policy. They may be the same person, but they do not have to be. This field helps explain that relationship when billing needs it.

This is the insured person's home phone number. If the insured is not the patient, this should not overwrite the patient's phone number in PID. Keep subscriber contact and patient contact separate unless the relationship field says they are the same person and your mapping rules allow it.

This is the phone number for the insured's employer. It is different from the named employer contact phone in IN2-50. Use this when the receiver needs the general employer number or benefits office number, and use IN2-49 through IN2-51 when a specific contact person matters.

This indicates the military program for disability or handicapped-program coverage. It is very specific and sensitive. Unless the trading partner is operating in that military benefits space, it will usually be blank.

This yes/no field indicates whether charges should be suspended for the patient. That is operationally serious. If a system acts on it, it may stop billing activity. Do not populate it from a vague registration note; it should come from the billing or payer workflow that actually controls charge suspension.

This indicates whether the patient has reached the co-pay limit, so no more co-pay charges should be calculated. It is benefit/accounting logic, and it can change as claims accumulate. If the value is not current, it can cause bad patient balances.

This says whether the patient has reached the stoploss limit established in the contract master. Again, this is not something to guess in an interface. It should be maintained by the system that owns the benefit accumulator or contract logic.

Sometimes the insured or subscriber is an organization rather than a person. This field is for that organization name and identifier. It can matter for employer, trust, government, corporate, or special program coverage where the subscriber is not a human being.

This identifies the insured's employer, or the organization that purchased the insurance for the insured, when that employer is an organization. It overlaps conceptually with earlier employer fields, so the interface agreement should say which employer identifier is authoritative.

Race here belongs to the insured, not automatically the patient. It is sensitive demographic information and should only be sent where the receiving system has a legitimate reporting, coverage, or regulatory reason. If you need patient race, look at the patient demographic fields instead.

This is one of the fields that explains why IN2 exists. Claims care deeply about whether the patient is the subscriber, spouse, child, foster child, ward, employee, sponsored dependent, unknown, or another relationship. If the relationship is wrong, a claim can be rejected even when the payer ID and member number are correct.

Do not assume this is just a duplicate of IN1-17. IN1-17 is the general HL7 insured relationship field. IN2-72 is the CMS/regulatory relationship-to-insured field. In a simple self policy they may agree. In real claim mapping, especially when going toward X12, the exact code system and direction of relationship matter a lot.

What about newer IN2 fields?

The v2.5.1 shape used here ends at IN2-72. Later HL7 versions add IN2-73 Co-Pay Amount. That is a practical addition, but I would treat it the same way as the deductible and limit fields: useful if the sender has a current payer-derived value, risky if it is stale or guessed. Do not let a static co-pay in an ADT feed pretend to be a full eligibility or benefit response.