HL7 IN1 Insurance
HL7 field reference IN1 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 |
|---|---|---|---|---|---|
| IN1.1 | Set ID - IN1 | Yes | No | SI | |
| IN1.2 | Insurance Plan ID | Yes | No | CE | 0072 |
| IN1.3 | Insurance Company ID | Yes | Yes | CX | |
| IN1.4 | Insurance Company Name | No | Yes | XON | |
| IN1.5 | Insurance Company Address | No | Yes | XAD | |
| IN1.6 | Insurance Co Contact Person | No | Yes | XPN | |
| IN1.7 | Insurance Co Phone Number | No | Yes | XTN | |
| IN1.8 | Group Number | No | No | ST | |
| IN1.9 | Group Name | No | Yes | XON | |
| IN1.10 | Insured's Group Emp ID | No | Yes | CX | |
| IN1.11 | Insured's Group Emp Name | No | Yes | XON | |
| IN1.12 | Plan Effective Date | No | No | DT | |
| IN1.13 | Plan Expiration Date | No | No | DT | |
| IN1.14 | Authorization Information | No | No | AUI | |
| IN1.15 | Plan Type | No | No | IS | 0086 |
| IN1.16 | Name Of Insured | No | Yes | XPN | |
| IN1.17 | Insured's Relationship To Patient | No | No | CE | 0063 |
| IN1.18 | Insured's Date Of Birth | No | No | TS | |
| IN1.19 | Insured's Address | No | Yes | XAD | |
| IN1.20 | Assignment Of Benefits | No | No | IS | 0135 |
| IN1.21 | Coordination Of Benefits | No | No | IS | 0173 |
| IN1.22 | Coord Of Ben. Priority | No | No | ST | |
| IN1.23 | Notice Of Admission Flag | No | No | ID | 0136 |
| IN1.24 | Notice Of Admission Date | No | No | DT | |
| IN1.25 | Report Of Eligibility Flag | No | No | ID | 0136 |
| IN1.26 | Report Of Eligibility Date | No | No | DT | |
| IN1.27 | Release Information Code | No | No | IS | 0093 |
| IN1.28 | Pre-Admit Cert (PAC) | No | No | ST | |
| IN1.29 | Verification Date/Time | No | No | TS | |
| IN1.30 | Verification By | No | Yes | XCN | |
| IN1.31 | Type Of Agreement Code | No | No | IS | 0098 |
| IN1.32 | Billing Status | No | No | IS | 0022 |
| IN1.33 | Lifetime Reserve Days | No | No | NM | |
| IN1.34 | Delay Before L.R. Day | No | No | NM | |
| IN1.35 | Company Plan Code | No | No | IS | 0042 |
| IN1.36 | Policy Number | No | No | ST | |
| IN1.37 | Policy Deductible | No | No | CP | |
| IN1.38 | Policy Limit - Amount | No | No | CP | |
| IN1.39 | Policy Limit - Days | No | No | NM | |
| IN1.40 | Room Rate - Semi-Private | No | No | CP | |
| IN1.41 | Room Rate - Private | No | No | CP | |
| IN1.42 | Insured's Employment Status | No | No | CE | 0066 |
| IN1.43 | Insured's Administrative Sex | No | No | IS | 0001 |
| IN1.44 | Insured's Employer's Address | No | Yes | XAD | |
| IN1.45 | Verification Status | No | No | ST | |
| IN1.46 | Prior Insurance Plan ID | No | No | IS | 0072 |
| IN1.47 | Coverage Type | No | No | IS | 0309 |
| IN1.48 | Handicap | No | No | IS | 0295 |
| IN1.49 | Insured's ID Number | No | Yes | CX | |
| IN1.50 | Signature Code | No | No | IS | 0535 |
| IN1.51 | Signature Code Date | No | No | DT | |
| IN1.52 | Insured's Birth Place | No | No | ST | |
| IN1.53 | VIP Indicator | No | No | IS | 0099 |
IN1 is the insurance segment. It tells the receiver how this patient's care may be paid for: the payer, the plan, the employer group, the subscriber, the policy number, the coverage order, and a collection of billing and verification details. You see it most often around ADT, DFT, BAR, referral, and order messages, where the clinical system still needs enough coverage data for registration, billing, eligibility checks, or downstream claims work.
The mental model that helps is this: IN1 is not the patient, not the visit, and not the guarantor. The PID says who the patient is. The PV1 says what encounter this is. The IN1 says what coverage might pay for it. Sometimes the patient is also the insured person. Sometimes the insured person is a parent, spouse, policyholder, employee, or someone else entirely. That is where many insurance interfaces quietly go wrong.
The first handful of fields matter much more than they look: plan ID, insurance company ID, group number, insured name, relationship to patient, policy number, coverage type, and verification details. The rest can still matter a lot in billing-heavy systems, but I would rather see a short IN1 with trustworthy identifiers than a beautifully full segment where nobody can tell which number is the member ID and which number is the employer group. A quick pass through HL7 Soup Web is often enough to catch whether the payer, plan, and subscriber values are actually in IN1 or have drifted into a note or local extension.
So let's go through each of the IN1 fields and talk about how they tend to behave in real interfaces.
Sequence matters as soon as a patient has more than one coverage. The first IN1 is usually sent with set ID 1, the second with 2, and so on. Many receivers read that as primary, secondary, tertiary insurance, especially when the interface has no better coordination-of-benefits logic.
I would still be a little careful about making IN1-1 do all the work. If the sender also populates IN1-21 and IN1-22, those fields may be the more explicit statement about coordination of benefits. The clean pattern is to keep the IN1 segments in the same order as the billing priority and make the COB fields agree. If they disagree, the receiver is left guessing which payer gets billed first, and that is a surprisingly expensive guess.
The plan code is the receiver's shortcut to a particular insurance product. It might represent "Commercial PPO", a local Blue Cross product, a regional public plan, a self-pay bucket, or a plan configured inside the practice management system. The standard points to table 0072, but in practice this is normally a local or trading-partner table.
Do not treat the plan ID as a friendly label. The insurance company name might stay the same while the plan changes completely, and a payer can have many plans with different rules, networks, and benefits. I like to see the identifier and text together, such as COMM^Commercial Plan^HL70072, but the code is the thing the receiver can map. If the receiver has its own plan table, expect to maintain a crosswalk.
Payer identity is where insurance interfaces either become clean or quietly painful. IN1-3 is the insurance company ID, and it is required and repeatable. IN1-4 through IN1-7 add the company name, address, contact person, and phone number. The name and contact details are useful for display and human follow-up, but the payer ID is what you want for matching and routing.
In the real world this may be an internal payer code, clearinghouse payer ID, national payer identifier, or some site-specific value that only makes sense inside one billing system. That is fine if everyone agrees. What is not fine is keying payer logic from the display name Acme Health Plan and hoping spelling, abbreviations, mergers, and payer branding never change. Use a CX value with an assigning authority where you can, and keep the name as supporting information.
The contact fields deserve the same discipline as patient contact fields. Put phone numbers in XTN properly, use separate repeats for different phone numbers, and do not assume the web number is the claims number. Some cards carry different contacts for member support, provider support, pharmacy, dental, vision, and behavioral health. A single "insurance phone" can be less helpful than it looks.
The group number is one of the big values people copy from the insurance card. It usually identifies the employer group or plan group the member belongs to, and it helps the payer identify the benefits attached to that group. It is not the same thing as the individual policy number or member ID.
IN1-9 is the group name, while IN1-10 and IN1-11 identify the insured person's group employer. These fields matter most in employer-sponsored coverage, workers compensation-ish workflows, and billing systems that need to tie a plan back to an employer contract. If the patient bought individual coverage directly, there may be no group number at all, and forcing a fake value into IN1-8 just makes the feed look more certain than it is.
The common mistake is to swap group and policy values because the insurance card uses casual wording. If the card says "Member ID" or "Policy ID", that usually belongs with the individual policy/member/subscriber concept, not IN1-8. If it says "Group", "Group Plan", or "Employer Group", IN1-8 is the better fit.
Coverage dates are simple in the message and complicated in life. IN1-12 is the start date of the coverage period and IN1-13 is the end date. They map nicely to the idea of a coverage period, and they are very useful when a registration system is sending the coverage snapshot it has on file.
The trap is treating those dates as a guarantee. Eligibility can change, employer coverage can terminate, cards can be old, and payer verification can return a different answer. If your system bills or authorizes care from this data, pair the dates with the verification fields and be honest about when the coverage was last checked.
Authorization information is one of those fields that sounds broad enough to solve everything and then does not. It uses the AUI data type and is intended for authorization-related information, often around a prior authorization or approval context. In many feeds it is empty, because detailed authorization workflows often live in IN3, payer systems, or separate authorization messages.
If you use it, document exactly what is being sent. A referral authorization, pre-admit certification, procedure authorization, and payer eligibility response are not the same thing. I have a strong preference for putting the actual pre-admit certification number in IN1-28 when that is what it is, and using IN1-14 only when both systems know what the AUI components mean.
Plan type is the broad product style: HMO, PPO, POS, indemnity, Medicare-style, commercial, and whatever local categories the site has configured. The base table is user-defined, so the code system is usually local even when the values look familiar.
This is helpful for classification and display, but it is not a payer ID and it is not the same as coverage type in IN1-47. Plan type says what kind of insurance product this is. Coverage type says what kind of services this IN1 is meant to cover, such as hospital, professional, both, or pharmacy. Mixing those two makes later mapping to billing systems and FHIR Coverage much harder than it needs to be.
The insured person is the subscriber or policyholder side of the coverage. When the patient is the subscriber, IN1-16 may look just like PID-5, and IN1-17 should say self. When the patient is covered through a spouse or parent, IN1-16, IN1-18, and IN1-19 describe that other person, not the patient.
This is one of the most important IN1 concepts to get right. Do not overwrite patient demographics with insured demographics just because both contain names and dates of birth. A child's PID-5 might be Smith^Ava, while IN1-16 might be Smith^Jane because Jane is the subscriber. The relationship field is what explains that story.
For IN1-17, table 0063 gives values such as SEL for self, SPO for spouse, CHD for child, PAR for parent, and UNK for unknown. The field name is easy to read backwards, so confirm the local direction of the relationship. In many coverage models it behaves like the patient's relationship to the subscriber, so a child covered by a parent is often CHD, not PAR. You may also see sites use non-standard values like SELF, because insurance language leaks in from forms and payer files. Be forgiving on inbound if you have to, but choose one documented code set for outbound.
Assignment of benefits says whether payment benefits are assigned to the provider. In plain English, it helps answer whether the payer can pay the provider directly rather than reimbursing the patient or subscriber. The usual values are yes, no, or modified assignment.
This is a billing/legal field, not a clinical field. If your interface is purely clinical, it may not matter. If the receiver posts claims or prepares billing forms, it can matter a great deal. Do not default it to Y just because that keeps the billing system quiet; send it when the source system actually knows the assignment status.
Multiple insurance plans are common, and coordination of benefits is how you keep them from fighting over who pays first. IN1-21 says whether the coverage is coordinated or independent. IN1-22 gives the priority, often a simple 1, 2, or 3.
The set ID, the physical order of repeated IN1 segments, and the COB priority should all tell the same story. For a patient with primary and secondary insurance, I want to see the primary coverage first, set ID 1, and priority 1. If you only update one IN1 segment during an ADT update and leave the others stale, downstream billing may keep an old secondary payer around long after the patient has changed plans.
Some payers need to be notified when a patient is admitted. IN1-23 says whether that notice was required or given, depending on the local implementation, and IN1-24 gives the notice date. The value set is only yes/no at the base level, so the surrounding interface agreement has to carry the detail.
These fields are mostly inpatient and billing-administration territory. They should not be invented from the fact that an ADT A01 exists. A hospital can admit a patient without having notified the payer yet, and that difference may matter for authorization or claim timing.
Eligibility fields tell you whether eligibility has been reported and when. They are useful as a small status flag on the coverage snapshot, especially in systems where staff verify insurance at registration or before service.
Just be careful with the word eligibility. An IN1 segment is not a full eligibility transaction. It does not replace a proper payer eligibility response, and it does not prove the payer will pay the claim. If the value is populated, read it as "this coverage was checked or reported in this local workflow", not as a universal promise from the payer.
Release information code says whether information may be released for insurance processing. The old table is basically yes, no, and user-defined codes, which tells you this field is more about local policy than rich consent modelling.
I would not use this as a general patient privacy consent. It is tied to billing and claim processing, and signature fields later in the segment can also describe authorization paperwork. If a privacy, consent, or information-sharing workflow really matters, use the specific segment or profile your implementation guide defines.
Pre-admit certification is the kind of field that looks optional until a claim is denied. It normally carries a pre-admission or pre-authorization number from the payer. For elective inpatient care, surgery, high-cost imaging, and other payer-controlled workflows, this can be very important.
Keep it as the payer issued it, including letters, dashes, and leading zeros. Do not normalize it into a number. If there are several authorizations for different services, the IN1 field may not be enough, and you should look at IN3 or a more detailed authorization workflow.
Verification date/time is when the coverage was checked. Verification by is the person or system that did the checking. In a tidy registration feed this might be a user ID for the registrar. In a more automated setup it may represent an eligibility service, clearinghouse, or system account.
These fields are most useful when they are honest. A verification from this morning is a different thing from a verification six months ago. If the status is also sent in IN1-45, keep the three values consistent: when it was checked, who checked it, and what the result was.
Agreement code is a quieter billing field that can classify the agreement type, with suggested values like standard, unified, or maternity. You will not see it in every feed, and many interfaces leave it empty forever.
If your receiver cares about payer contracts or special billing arrangements, this is where the local guide may suddenly become specific. Outside that kind of defined use, it is usually better empty than populated with a code nobody downstream understands.
Billing status indicates whether this insurance has been billed and, if so, what kind of bill status applies. The base table is user-defined, so there is no universal set of values you can count on.
This is a workflow state, and workflow states are fragile when sent between systems. If the billing system is the system of record, think carefully before letting an upstream ADT feed overwrite it. In many integrations, IN1 is used to send coverage data, while billing status is maintained inside the billing application itself.
Lifetime reserve days and the delay before lifetime reserve days are old-school insurance benefit fields. They are most familiar around inpatient Medicare-style coverage, where there may be a limited number of reserve days available after ordinary benefit days are exhausted.
Most modern general interfaces leave them blank, and that is not a problem. If you do populate them, make sure the value is current and payer-derived. A stale "days remaining" value is worse than no value because it invites someone to trust a benefit calculation that may no longer be true.
Company plan code further defines the insurance company ID. Think of it as another local plan/product code that may be meaningful to a particular payer, billing system, or interface partner.
The natural question is "how is this different from IN1-2?" The honest answer is that you have to read the local implementation guide. IN1-2 is the main insurance plan ID. IN1-35 is an additional company-plan detail. If both are used, document the mapping and do not let two slightly different plan codes drift apart over time.
This is one of the fields people care about most. IN1-36 carries the individual policy number of the insured, and HL7 specifically recommends filling it even when special insurance numbers are also sent in IN2 fields for Medicare, Medicaid, or military coverage.
On real insurance cards, the same idea may be labelled Policy Number, Policy ID, Subscriber ID, Member ID, or Identification Number. That does not mean every one of those labels maps automatically to IN1-36, but it does mean this field often becomes the practical home for the member/policy identifier the claims people need. Preserve leading zeros, suffixes, and punctuation unless the receiver explicitly says otherwise.
Do not confuse it with group number. Group number points at the employer or plan group. Policy/member/subscriber number points at the covered person or policy record. If you get those two backwards, eligibility and claims can fail while the message still looks perfectly valid.
These fields carry financial benefit details: policy deductible, policy limit amount, policy limit days, semi-private room rate, and private room rate. They are attractive because they look like they could save someone from checking eligibility or benefits somewhere else.
Be suspicious of them unless you know the sender keeps them current. Deductibles and benefits change, patient accumulators move, networks matter, and an insurance card is not a full benefits response. Also note that some of the older limit and room-rate fields were deprecated or withdrawn in later HL7 versions. For v2.5.1 interfaces you may still see them structurally, but in many modern feeds they are blank for good reason.
Employment status, administrative sex, and employer address here belong to the insured person, not automatically to the patient. That distinction matters when a child is covered under a parent's employer plan or a spouse is the subscriber.
Employment status uses table 0066, with values such as full-time employed, part-time employed, unemployed, self-employed, retired, active military duty, and unknown. Use it only when it helps the receiving billing or eligibility workflow. If the receiver wants the patient's employment details, do not assume these fields are the right place unless the patient and insured are the same person.
Verification status is the short result of the insurance check. Because the field is plain ST in v2.5.1, sites often invent values like active, verified, failed, pending, rejected, or local two-character codes.
If you use it, define the code set. A status of A might mean active in one system and accepted in another. Pair it with IN1-29 and IN1-30 so the receiver knows when the check happened and who or what performed it.
Prior plan ID is for the previous insurance plan. It can help when a payer or plan has changed and the receiver needs to understand the transition.
This is not a place to keep every old payer the patient ever had. If you need a history of coverages, send the history through the proper account/coverage workflow or keep it in the receiving system. IN1-46 is just a small pointer to the previous plan, and many interfaces never populate it.
Coverage type says what services this insurance coverage applies to for billing purposes. The suggested values include hospital/institutional, physician/professional, both, and pharmacy. That is very different from plan type in IN1-15.
This becomes useful when a patient has separate medical, pharmacy, dental, vision, or professional billing coverage, or when a receiver only wants coverage relevant to its own billing lane. A physician billing system may not want hospital-only insurance. A pharmacy workflow may care about the pharmacy coverage even if the medical payer looks similar. Do not map this to a broad "PPO" or "HMO" product type.
This field contains a code describing the insured person's disability, using a user-defined table. It is sensitive and often empty.
If a payer or public program genuinely needs it for eligibility or benefits, follow the local profile exactly. Otherwise, do not send disability-related information just because the field exists. Insurance feeds already carry a lot of personal data; this is one to keep on a short leash.
Insured's ID number is a CX field for healthcare institution identifiers for the insured, and the assigning authority and identifier type are strongly recommended. This field overlaps conceptually with the member/subscriber ID language people use in insurance, which is why it needs a clear local agreement.
Some interfaces put the member ID in IN1-36 as the policy number. Others use IN1-49 because it is a structured CX identifier and maps more naturally to subscriber/member identifier concepts. Either can work if both sides agree. The problem is sending one value in IN1-36, another in IN1-49, and no documentation about which one the billing system should trust.
Signature code says how the patient or subscriber authorization signature was obtained and retained. The v2.5.1 values cover things like a CMS-1500 signature on file, assignment of benefits authorization, provider-generated signature because the patient was not physically present, and release-of-information authorization. IN1-51 gives the date that signature was obtained.
These fields are paperwork evidence. They should line up with your registration, consent, and billing forms. Do not use the signature code as a vague "consent exists somewhere" flag. If the receiver bills from it, a vague flag can become a compliance problem later.
Birth place is a free-text description for the insured person's birthplace. HL7's own example is the sort of long hospital/place description that tells you this was never meant to be a tidy coded geography field.
Most insurance interfaces leave it blank. If it is used for identity matching or a very specific payer workflow, send it as recorded and be aware that free text is weak for matching. The insured's actual address belongs in IN1-19, not here.
VIP indicator identifies the type of VIP for the insured. It uses a user-defined table, so the meaning is entirely local.
Handle this carefully. A patient or insured VIP flag can affect privacy, billing handling, or customer-service routing, and those are not always things every downstream system should know. If you send it, make sure the receiving system has a legitimate reason to receive it and knows what the local code means.