HL7 Segments Guide
This page is not trying to be the complete HL7 dictionary. HL7 has a lot of segments, and some of them only appear when you are deep inside a very specific workflow. This is the more useful map: the segments you keep seeing in patient admin, lab, radiology, pharmacy, documents, billing, scheduling, and ACK handling, and the sort of job each one is normally meant to do.
The thing to remember is that an HL7 segment is not just a random line with a three-letter name. The segment gets much of its meaning from where it appears in the message. An OBX after an OBR is usually a result. An OBX after an immunisation RXA might be extra immunisation detail. An NTE after a result is a comment on that result. Put the same line in the wrong part of the message and the receiving system may have no idea what story you were trying to tell.
So the practical rule is: use the structured segment when the information needs to be searched, routed, billed, trended, reconciled, or acted on. Use notes for human comments. That one rule prevents a surprising amount of pain.
MSH, EVN, PID, PD1, PV1, NK1, AL1, IAM, DG1, MRG - patient and visit layer
Most HL7 conversations start with the same little family. MSH says where the message came from, where it is going, when it was sent, and what kind of message it is. EVN gives the patient-administration event its own timing and event details. PID identifies the person. PD1 adds patient-level demographic, privacy, publicity, registry, primary care, and advance-directive context when the feed needs that extra layer. PV1 identifies the encounter, visit, location, patient class, doctors, and admission/discharge context.
That split matters in almost every integration. A patient's date of birth belongs in PID because it is about the person. A patient-level immunisation registry status or protection indicator may belong in PD1. The ward, clinic, attending doctor, visit number, and patient class belong in PV1 because they are about this visit. When those boundaries get blurred, downstream systems start making odd decisions, especially where one patient can have several visits, or where the same patient identity is used across emergency, inpatient, outpatient, and billing workflows.
NK1 is the contact and associated-party segment. It is common in ADT feeds, registration feeds, and immunisation messages where a parent, guardian, spouse, emergency contact, or responsible party needs to travel with the patient. It is also one of those segments where repeating is cleaner than cramming every contact into one line. If there are three associated people, send three NK1s and let the relationship and contact reason do their jobs.
Allergies and diagnoses sit nearby but have very different personalities. AL1 is about allergies and adverse reactions, usually one allergy per segment, and it is patient-safety data. IAM is the richer allergy/adverse-reaction shape when an interface needs action codes, unique allergy identifiers, sensitivity type, clinical status, and item-level update behaviour. DG1 is about diagnosis context: admitting diagnosis, working diagnosis, final diagnosis, billing diagnosis, medical necessity, and order context. DG1 is not a perfect problem-list segment. It often behaves more like "these are the diagnoses relevant to this visit, order, or charge".
MRG comes out when identity has gone wrong and two records need to become one story. In the usual patient merge pattern, PID carries the surviving patient identity and MRG carries the prior identity being retired or de-referenced. This is where assigning authority becomes serious. A merge without clear identifier authority is how perfectly good records get glued to the wrong chart.
ORC, TQ1/TQ2, OBR, SPM, OBX, NTE - orders, results, and specimens
For lab and radiology, the familiar shape is ORC, OBR, then OBX. ORC is the order control and order lifecycle line: new, cancel, discontinue, status, placer number, filler number, ordering provider, and so on. OBR is the requested service, diagnostic study, or report header. OBX is the actual observation value: the potassium result, the radiology impression, the LOINC-coded AOE answer, the microbiology organism, the PDF body, or the device measurement.
TQ1 and TQ2 are worth knowing even if you do not use them every day. TQ1 carries timing, quantity, frequency, priority, and service timing. TQ2 adds relationships between those timing requests. They show up more in orders, medication/treatment style flows, and recurring service requests than in a plain result feed.
SPM is the specimen segment, and modern lab interfaces are much nicer when specimen information lives there instead of being stuffed into OBR fields and comments. Blood, urine, swabs, tissue blocks, aliquots, parent/child specimens, collection method, collection time, received time, rejection reason, and specimen condition all belong to the specimen story. OBR says what was ordered or reported. SPM says what physical thing was tested.
NTE is small and everywhere because people always have comments. That does not make it a good place for structured data. "Specimen hemolysed" might be fine as a comment if nobody needs to filter on it. If the lab, clinician, billing system, or quality system needs to make decisions from it, find the real coded field or segment. Notes are for humans first.
SCH, AIS, AIG, AIL, AIP - scheduling
SCH is the appointment's main line. It carries the appointment identifiers, reason, timing, duration, status, and contact details that make an SIU scheduling message understandable. A simple interface may only need SCH plus patient and visit context. A more serious scheduling interface needs the resource family as well.
The scheduling resource segments make the appointment less vague. AIS describes the service being scheduled, such as an MRI, clinic consultation, physiotherapy session, or vaccination clinic slot. AIL is for the location: room, theatre, exam bay, or clinic. AIP is for people: clinician, nurse, technician, anaesthetist, or other personnel. AIG is the general resource bucket, often equipment or non-person resources. When a clinic says "book this patient for this service, in that room, with this doctor and this machine", these are the segments that keep those facts from collapsing into one overloaded comment.
TXA - documents and transcription
TXA is the cover sheet for document management. It gives the document type, document ID, authoring and authentication people, status, availability, confidentiality, replacement links, and other filing metadata. The actual content normally travels in OBX, as text, formatted text, PDF, image, CDA, or another agreed payload style.
You see this in medical document management messages, often for discharge summaries, operative notes, radiology reports, pathology documents, scanned letters, referrals, and transcription-style workflows. It can look similar to an OBR/OBX report feed, but TXA is the better fit when the document lifecycle matters: draft, signed, available, amended, replaced, cancelled, confidential, and distributed.
RXO, RXE, RXD, RXG, RXA, RXR, RXC - pharmacy, treatment, and immunisation
Pharmacy and immunisation segments are a little world of their own. ORC still matters because the order control does not stop being important just because the order is a medication or vaccine. But the details of what was ordered, encoded, dispensed, given, compounded, and administered live in the RX segments.
RXO is the original pharmacy or treatment order. It is the prescriber's intention: what medication or treatment was requested, with dose and related order detail. RXE is the pharmacy's encoded version of that order, after the pharmacy system has turned the request into something dispensable or administrable. RXD is about dispensing. RXG is about giving. RXA is about actual administration, and in immunisation feeds it is the segment people look at to know what vaccine was administered or historically reported.
RXR is the route, site, device, and method companion. Do not bury "left deltoid intramuscular" in a note if RXR is what the profile expects. RXC is for components, which becomes important for IVs, compounds, additives, bases, and mixtures where one product code does not tell the full story. A good pharmacy interface is very clear about whether it is describing an order, a dispense, a scheduled give, or an actual administration. Those are related events, but they are not the same event.
IN1, IN2, IN3, GT1, FT1, PR1, DG1 - billing, insurance, guarantors, and procedures
IN1 is the main insurance segment. It carries payer, plan, group, member, subscriber, coordination, eligibility, authorisation, and coverage details. IN2 and IN3 extend that insurance world. IN2 tends to carry extra policy, employment, Medicare/Medicaid/CMS-style, and subscriber detail. IN3 tends to carry certification, authorisation, and utilisation-management detail. You do not see IN2 and IN3 on every feed, but billing-heavy interfaces can care about them a lot.
GT1 is about the guarantor: the person or organisation financially responsible for the account. This may be the patient, a parent, a spouse, an employer, a government body, or another party depending on the environment. It is related to insurance, but it is not the same thing. Insurance says who may pay under a policy. Guarantor says who the account can chase when money is owed.
FT1 is the charge line. It is common in DFT messages and revenue-cycle feeds, where systems need to post charges, payments, adjustments, procedure codes, quantities, amounts, providers, departments, and diagnosis links. PR1 describes procedures, often for surgery, medical records coding, procedure billing, or historical procedure context. DG1 often sits near this world too, because diagnoses drive medical necessity, grouping, claims, and reporting.
MSA and ERR - acknowledgments and errors
MSA is the answer to the message. At its simplest, it says accepted, errored, or rejected, and it points back to the original message control ID. That sounds tiny until you are debugging retries, duplicates, and messages that were accepted by the interface engine but rejected by the application behind it.
ERR is where the useful detail belongs. It can point at the location of the problem, give an HL7 error code, carry severity, and provide an application error message. In newer profiles you will often see one ERR per error or warning, which is much cleaner than making the sender parse one long human sentence. If you want support people to fix bad messages quickly, good ERR segments are a gift.
How I choose between them
When I am building or debugging an interface, I usually ask what kind of fact I am holding. If it identifies the person, it wants PID. If it is extra patient-level demographic, privacy, publicity, registry, or advance-directive context, look at PD1. If it describes this encounter, it probably wants PV1. If it is a simple allergy snapshot, use AL1; if it is an item-level allergy/adverse-reaction update, use IAM. If it controls an order, start with ORC. If it describes the requested test or report header, look at OBR. If it is the actual measured or observed thing, use OBX. If it is about the physical specimen, use SPM.
For documents, I ask whether the document itself has a lifecycle. If yes, TXA plus OBX is usually the right shape. For scheduling, I ask whether the appointment needs services, rooms, equipment, or people broken out. If yes, SCH alone is too thin and the AIS/AIG/AIL/AIP family earns its keep. For finance, I keep payer coverage, responsible party, procedure, diagnosis, and charge line separate. IN1, GT1, PR1, DG1, and FT1 are not interchangeable just because all of them eventually affect money.
The worst shortcut is using NTE because it is easy. It is fine for remarks, caveats, instructions, and comments. It is a poor place to hide a diagnosis, allergy, specimen type, vaccine route, procedure code, charge amount, appointment location, or error code. If a computer needs to understand it, give the computer a structured segment.
Segment quick map
| Segment and Description | Common use | What it is really for | Deep dive |
|---|---|---|---|
| MSH - Message header | Every HL7 message | Message metadata: sender, receiver, date/time, message type, control ID, processing mode, and HL7 version. | MSH from experience |
| MSA - Acknowledgment | ACK messages | The main acknowledgment line: accepted, errored, rejected, and which message is being answered. | MSA from experience |
| ERR - Error details | ACKs, query responses, application errors | Detailed error or warning information, ideally with location, severity, code, and a useful message. | ERR from experience |
| EVN - Event type | ADT and patient administration | Event timing and trigger-event context, separate from the MSH message type. | EVN from experience |
| PID - Patient identification | ADT, orders, results, documents, scheduling, billing | Patient identity and mostly stable demographics: identifiers, name, birth date, sex, address, phone, and death information. | PID from experience |
| PD1 - Additional demographics | ADT, patient demographics queries, immunisation, public health | Changeable or policy-style patient context: living arrangement, primary care provider, publicity, protection, registry status, advance directives, and military status. | PD1 from experience |
| PV1 - Patient visit | ADT, orders, results, billing, clinical feeds | Visit or encounter details: patient class, location, doctors, visit number, admission/discharge details, and account context. | PV1 from experience |
| NK1 - Associated parties | Registration, ADT, immunisation, patient admin | Next of kin, guardian, emergency contact, responsible party, employer, agency, or other associated person. | NK1 from experience |
| AL1 - Allergies | ADT, registration, medication, surgery, immunisation | One patient allergy or adverse reaction per segment. Small segment, big patient-safety consequences. | AL1 from experience |
| IAM - Adverse reactions | ADT A60, allergy maintenance, EHR synchronization | One adverse-reaction record with action code, unique identifier, sensitivity type, clinical status, reporter, and lifecycle audit detail. | IAM from experience |
| DG1 - Diagnosis | ADT, orders, billing, clinical context | Diagnosis context for a visit, order, claim, or report. Very common around billing and medical necessity. | DG1 from experience |
| MRG - Merge identity | Patient merges and identity maintenance | The old or prior patient/account identity that should be merged or de-referenced into the surviving record. | MRG from experience |
| ORC - Common order | Orders, results, pharmacy, immunisation | Order control and lifecycle: new, cancel, discontinue, status, placer/filler numbers, ordering provider, and order-level timing. | ORC from experience |
| TQ1 - Timing/quantity | Orders, recurring services, pharmacy/treatment, scheduling | Timing, quantity, frequency, priority, start/end date, repeats, and service timing. | TQ1 from experience |
| TQ2 - Timing relationship | Complex order timing | Relationships between timing requests: sequence, dependency, cyclic behaviour, and related service requests. | TQ2 from experience |
| OBR - Observation request | Lab, radiology, pathology, microbiology, orders/results | The observation request or report header: what was ordered, what study/report this is, and report-level status. | OBR from experience |
| SPM - Specimen | Lab, microbiology, pathology, molecular, public health | Specimen identity and specimen facts: type, source, collection, received time, condition, rejection, and parent/child specimen context. | SPM from experience |
| OBX - Observation result | Results, observations, documents, AOE, devices, immunisation details | The actual observation value. It can be numeric, coded, text, formatted text, binary/document content, or other agreed value types. | OBX from experience |
| NTE - Notes and comments | Almost anywhere comments are allowed | Human notes and comments. Useful, but not a substitute for structured fields. | NTE from experience |
| SCH - Scheduling activity | SIU scheduling messages | The main appointment segment: identifiers, reason, timing, duration, status, and appointment contact details. | SCH from experience |
| AIS - Scheduled service | Scheduling services | The service being scheduled: clinic visit, scan, procedure, treatment, class, or other service item. | AIS from experience |
| AIG - General resource | Scheduling general resources | Equipment or general resources needed for the appointment when they are not people or locations. | AIG from experience |
| AIL - Location resource | Scheduling locations | Rooms, operating theatres, exam rooms, clinic locations, or other schedulable places. | AIL from experience |
| AIP - Personnel resource | Scheduling personnel | Schedulable people: clinicians, nurses, technicians, surgeons, anaesthetists, and similar personnel. | AIP from experience |
| TXA - Documents | MDM document messages | Document metadata and lifecycle: type, ID, authoring, authentication, status, availability, confidentiality, replacement, and filing. | TXA from experience |
| RXO - Pharmacy/treatment order | Pharmacy and treatment orders | The original requested pharmacy or treatment order before pharmacy encoding, dispensing, giving, or administration. | RXO from experience |
| RXE - Encoded pharmacy order | Pharmacy encoded orders | The pharmacy/treatment application's encoded order, often closer to what can actually be dispensed or administered. | RXE from experience |
| RXR - Route and site | Pharmacy, treatment, immunisation | Route, administration site, device, and method: oral, IV, IM, left deltoid, pump, and similar delivery facts. | RXR from experience |
| RXC - Components | Compound medications, IVs, additives, mixtures | Components of a compound or complex medication, including bases and additives. | RXC from experience |
| RXD - Dispense | Pharmacy dispense flows | Dispense information: what the pharmacy dispensed, when, how much, and with what dispense identifiers. | RXD from experience |
| RXG - Give | Medication/treatment give flows | Give-level information for medication or treatment administration workflow, before or around actual administration. | RXG from experience |
| RXA - Administration | Immunisation and administration reporting | Actual administration or historical administration information, especially important in vaccine reporting. | RXA from experience |
| IN1 - Insurance | Registration, ADT, billing, orders needing insurance | Main insurance coverage: payer, plan, member/subscriber, group, coordination, eligibility, authorisation, and coverage details. | IN1 from experience |
| IN2 - Insurance extra detail | Detailed insurance feeds | Additional insurance and subscriber detail, often policy, employment, program, and regulatory information. | IN2 from experience |
| IN3 - Insurance certification | Insurance certification and authorisation | Certification, authorisation, review, approval, and utilisation-management information tied to coverage. | IN3 from experience |
| GT1 - Guarantor | Patient admin and billing | The guarantor or financially responsible party for the account. | GT1 from experience |
| FT1 - Financial transaction | DFT and patient accounting | Charge, payment, or adjustment transaction detail for billing and accounting systems. | FT1 from experience |
| PR1 - Procedures | Procedures, surgery, coding, billing | Procedure information, often used for medical records, coding, operative/procedure history, and billing links. | PR1 from experience |
All available segment pages
The guide above focuses on the segments people tend to meet first. There are also plenty of smaller, older, or very domain-specific segments that still matter when you land in that part of HL7. Here are the segment pages currently available in this guide.