HL7 AL1 Patient Allergy Information
HL7 field reference AL1 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
AL1 is small enough that people sometimes underestimate it. That is a mistake. This is the segment that says a patient reacts badly to penicillin, peanuts, latex, contrast, adhesive, pollen, or whatever else might change what a clinician orders next. Six fields, but very real consequences.
The standard idea is simple: each AL1 segment describes a single patient allergy or adverse reaction. If the patient has three allergies, you normally send three AL1 segments. Do not turn AL1 into one giant text note. A downstream medication system, diet system, theatre system, radiology system, or clinical decision support rule needs the allergen and the reaction in predictable places.
You will see AL1 most often around PID and PV1 in ADT, registration, orders, pharmacy, diet, referral, and patient-summary style feeds. It is not the only way to communicate allergy information, though. In newer or more precise HL7 work, IAM can be a better fit when you need action codes, unique allergy identifiers, clinical status, inactivation, reported-by details, or proper update semantics. AL1 is very good for a snapshot-style allergy list. It is thin for maintaining an allergy list one item at a time.
That example is deliberately ordinary. The useful things are not fancy: each allergy is separate, the broad type is present, the allergen is named, severity is not hidden in the reaction text, and the reactions are readable. If your receiver can use RxNorm, SNOMED CT, or another standard vocabulary for the allergen, that is better again, but a clear local code with an agreed coding system is still better than a mysterious free-text blob. Open the sample in HL7 Soup Web and it is easy to see whether each AL1 repeat is splitting cleanly before you start mapping it into the receiving allergy list.
Where AL1 actually earns its keep
The obvious case is medication ordering. A drug allergy should make its way to the places where prescribing, dispensing, and administration decisions are made. But AL1 is not just a pharmacy segment. Food allergies matter to diet and catering. Latex and adhesive reactions matter to procedures and theatres. Contrast reactions matter to radiology. Environmental allergies may be less urgent in an order feed, but they can still matter in clinical summaries and patient portals.
Immunisation is a slightly different world. Vaccine contraindications and reactions are often sent as OBX observations using implementation-guide-specific LOINC and coded values, rather than as AL1. So if someone says "this is an allergy to egg, therefore it must be AL1", pause and look at the profile. AL1 is the allergy-list shape. Public health and immunisation profiles may want a contraindication or reaction observation instead.
The other big practical question is no known allergies. An absent AL1 segment can mean "no allergies", or it can mean "we did not send allergies", or it can mean "nobody reviewed them". Those are very different statements. Many interfaces use agreed values such as NKA or NKDA in AL1-3, but only do that if both systems understand the convention and know how to reconcile it when a real allergy arrives later.
This is the sequence number for the allergy segment. If there are three AL1 segments, they are usually numbered 1, 2, and 3. It is required, but it is not the allergy identifier. It just tells you which repetition of AL1 you are looking at inside this message.
That distinction matters when allergy lists are updated. If today's message sends penicillin as AL1-1 and tomorrow's message sends peanut as AL1-1, that does not mean the peanut allergy replaced the penicillin allergy by identifier. It just means it was first in that message. If you need add, update, delete, or inactivate behaviour for individual allergies, you need a clear snapshot rule, a local matching rule on the allergen code, or a segment such as IAM that was designed for action-code style updates.
This field gives the broad category of the allergy. The HL7 table includes drug allergy, food allergy, environmental allergy, pollen allergy, plant allergy, animal allergy, miscellaneous allergy, and miscellaneous contraindication. In real feeds the ones you see most often are drug, food, environmental, miscellaneous, and sometimes miscellaneous contraindication for things like contrast or procedure-related warnings.
It is tempting to treat this as a small decorative field, but it often decides who cares about the segment. A diet system may pay close attention to FA. A prescribing system will care about DA. Radiology may care about MC. Do not put the specific allergen here, and do not put the reaction here. This field says the broad family. AL1-3 says what the patient reacts to, AL1-4 says how serious it is, and AL1-5 says what actually happened.
This is the heart of the segment. If AL1-3 is vague, the rest of the allergy record is shaky. The field uses a coded element, so the useful pattern is code, text, and coding system, for example PENICILLIN^Penicillin^LOCAL. If the organisation has a standard medication or allergy vocabulary, use it. If it uses local codes, make the local coding system explicit and stable.
The biggest design decision is whether you are sending a substance, a product, a class, or a negative statement. "Penicillin", "amoxicillin", and "penicillins class" are not the same integration fact. One may fire a broad class alert, another may fire only a specific-product alert. Be deliberate. If there are two unrelated suspected allergens, send two AL1 segments rather than one awkward combined description.
For no known allergies, agree the convention before the interface goes live. A code such as NKA or NKDA can be useful because it says the allergy list was reviewed and nothing was found. But it must be treated as a real statement that needs reconciliation. If a peanut allergy is later added, the old "no known food allergy" style record should not sit beside it and confuse everyone.
This is one of the fields that downstream systems really look at. The common table values are mild, moderate, severe, and unknown. A severe allergy may create a hard stop, a moderate allergy may create a warning, and a mild allergy may be displayed as useful context. Those behaviours are local, but the point is the same: severity can drive clinical decision support.
Be careful with the word severity. Some systems use this field as the overall potential danger of re-exposure, which is close to what FHIR calls criticality. Other systems use it as the severity of a past reaction event. Those are related, but not identical. A historical rash, anaphylaxis, nausea, and "patient unsure" should not all collapse into the same workflow just because the word allergy is present.
Do not guess severity just to avoid an empty field. If the source does not know, use unknown if your profile allows it, or leave it blank if that is the agreed local rule. A false severe alert causes alert fatigue. A false mild alert can be dangerous. This is one of those fields where boring accuracy beats dramatic certainty.
The name says code, but in v2.5.1 this field is ST, so a lot of real interfaces send short text values such as rash, hives, anaphylaxis, wheeze, vomiting, swelling, or contact dermatitis. It can repeat, which is handy because patients often report more than one manifestation from the same allergen.
This field gives clinicians the "what happened" part. It also helps systems and people distinguish a side effect from a serious immune reaction. "Nausea" and "anaphylaxis" should not produce the same confidence or urgency. If your organisation has a coded reaction vocabulary, document it and use it consistently. If you are sending text, keep it short and meaningful. Long stories belong in NTE or a fuller clinical structure, not crammed into AL1-5.
One more little trap: do not put the allergen itself in the reaction field. "Penicillin" belongs in AL1-3. "Rash" or "anaphylaxis" belongs here. It sounds obvious, but allergy imports are full of swapped columns because both fields are human-readable text in many source systems.
This is the date the allergy was identified or documented, not necessarily the exact date of the reaction. If the patient says, "I had an anaphylactic reaction to penicillin in 2015", and the clinic records it today, you need to decide whether this field means the 2015 allergy-identification date or today's documented date in your local workflow.
In v2.5.1 this field is still present and optional. Later HL7 references mark it as withdrawn, and v2.9 no longer has an active AL1-6 in the same way. That is a clue that AL1 is not the best segment for rich allergy history. If you need onset date, reported date, recorder, status, inactivation, or update history, look at IAM or a more modern allergy model.
If you do populate it, do not simply send the message date unless that is genuinely the date the allergy was identified. A message generated today may be carrying an allergy documented ten years ago. That difference can matter when clinicians are trying to understand old, uncertain, or patient-reported allergies.
What about IAM and newer allergy detail?
AL1 is good when the message is saying, "Here is the patient's current allergy list as I know it." IAM is better when the message is saying, "Add this allergy, update that one, delete this one, mark that one inactive, and here is the person and date behind those changes." That is why IAM has fields for action code, unique identifier, onset, reported date, clinical status, and the people or organisations involved.
So I would not call AL1 obsolete. It is still common, simple, and useful. I would just avoid asking it to do work it was not built to do. If your interface has to maintain a trustworthy allergy list over time, write down whether each incoming message is a full replacement snapshot, an additive update, or an item-level update. A tiny allergy segment can create a very large patient-safety problem if that rule is left to guesswork.