HL7 IN3 Insurance Additional Information, Certification
HL7 field reference IN3 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 |
|---|---|---|---|---|---|
| IN3.1 | Set ID - IN3 | Yes | No | SI | |
| IN3.2 | Certification Number | No | No | CX | |
| IN3.3 | Certified By | No | Yes | XCN | |
| IN3.4 | Certification Required | No | No | ID | 0136 |
| IN3.5 | Penalty | No | No | MOP | 0148 |
| IN3.6 | Certification Date/Time | No | No | TS | |
| IN3.7 | Certification Modify Date/Time | No | No | TS | |
| IN3.8 | Operator | No | Yes | XCN | |
| IN3.9 | Certification Begin Date | No | No | DT | |
| IN3.10 | Certification End Date | No | No | DT | |
| IN3.11 | Days | No | No | DTN | 0149 |
| IN3.12 | Non-Concur Code/Description | No | No | CE | 0233 |
| IN3.13 | Non-Concur Effective Date/Time | No | No | TS | |
| IN3.14 | Physician Reviewer | No | Yes | XCN | 0010 |
| IN3.15 | Certification Contact | No | No | ST | |
| IN3.16 | Certification Contact Phone Number | No | Yes | XTN | |
| IN3.17 | Appeal Reason | No | No | CE | 0345 |
| IN3.18 | Certification Agency | No | No | CE | 0346 |
| IN3.19 | Certification Agency Phone Number | No | Yes | XTN | |
| IN3.20 | Pre-Certification Requirement | No | Yes | ICD | 0150 |
| IN3.21 | Case Manager | No | No | ST | |
| IN3.22 | Second Opinion Date | No | No | DT | |
| IN3.23 | Second Opinion Status | No | No | IS | 0151 |
| IN3.24 | Second Opinion Documentation Received | No | Yes | IS | 0152 |
| IN3.25 | Second Opinion Physician | No | Yes | XCN | 0010 |
IN3 adds insurance certification and authorization details that do not fit cleanly in the core IN1/IN2 insurance segments.
The standard describes IN3 this way: The IN3 segment contains additional insurance information for certifying the need for patient care. Fields used by this segment are defined by CMS, or other regulatory agencies.
Patient-administration segments add detail around the person, visit, account, diagnosis, procedure, insurance, merge, death, disability, and grouping state carried by the message.
These fields often drive matching, billing, encounter routing, reporting, and front-desk workflow. Separate patient identity, visit identity, account identity, and clinical facts carefully.
The v2.5.1 structures show IN3 in ADR_A19 - Patient query, ADT_A01 - Admit/visit notification, ADT_A03 - Discharge/end visit, and ADT_A05 - Pre-admit a patient, and 26 other message structures. That tells you where it can appear, but the implementation guide still decides which optional fields are meaningful.
For practical interface work, read the generated field panel for datatype, required, repeatable, and table details, then use the notes below to decide what the field should mean in the receiving workflow.
IN3-1 is the sequence number for this IN3 segment within its repeating group. It keeps multiple IN3 lines in order; it is not the business identifier for the patient-administration workflow.
IN3-2 identifies the Certification Number for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
IN3-3 carries Certified By for this patient-administration workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
IN3-4 carries Certification Required for this patient-administration workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0136; many real interfaces narrow that list further, so follow the receiver's implementation guide.
IN3-5 carries Penalty for this patient-administration workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0148; many real interfaces narrow that list further, so follow the receiver's implementation guide.
IN3-6 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
IN3-7 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
IN3-8 identifies a person, provider, staff member, or contact involved in this patient-administration workflow. Use the structured name or provider datatype instead of flattening everything into display text.
When more than one person is sent, repeats should carry role or identifier context so the receiver can tell who did what.
IN3-9 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
IN3-10 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
For effective and end dates, make the boundary rule explicit. Receivers need to know whether the value is inclusive, exclusive, planned, actual, or merely informational.
IN3-11 carries Days for this patient-administration workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0149; many real interfaces narrow that list further, so follow the receiver's implementation guide.
IN3-12 is human-readable context. Keep it useful for display and troubleshooting, but do not hide required workflow logic here unless the implementation guide explicitly says the receiver parses it.
The generated panel links this to HL7 table 0233; many real interfaces narrow that list further, so follow the receiver's implementation guide.
IN3-13 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
For effective and end dates, make the boundary rule explicit. Receivers need to know whether the value is inclusive, exclusive, planned, actual, or merely informational.
IN3-14 carries Physician Reviewer for this patient-administration workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0010; many real interfaces narrow that list further, so follow the receiver's implementation guide.
IN3-15 identifies a person, provider, staff member, or contact involved in this patient-administration workflow. Use the structured name or provider datatype instead of flattening everything into display text.
IN3-16 carries contact details. Use the datatype components for use code, equipment type, address type, country, and other qualifiers rather than squeezing everything into one formatted string.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
IN3-17 qualifies the patient-administration workflow rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
Use the agreed value set, starting from HL7 table 0345. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
IN3-18 carries Certification Agency for this patient-administration workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0346; many real interfaces narrow that list further, so follow the receiver's implementation guide.
IN3-19 carries contact details. Use the datatype components for use code, equipment type, address type, country, and other qualifiers rather than squeezing everything into one formatted string.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
IN3-20 carries Pre-Certification Requirement for this patient-administration workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0150; many real interfaces narrow that list further, so follow the receiver's implementation guide.
IN3-21 carries Case Manager for this patient-administration workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
IN3-22 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
IN3-23 tells the receiver the state of this patient-administration workflow. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0151 or the narrower table in the local profile.
IN3-24 carries Second Opinion Documentation Received for this patient-administration workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0152; many real interfaces narrow that list further, so follow the receiver's implementation guide.
IN3-25 carries Second Opinion Physician for this patient-administration workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0010; many real interfaces narrow that list further, so follow the receiver's implementation guide.