HL7 IAM Patient Adverse Reaction Information
HL7 field reference IAM 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 |
|---|---|---|---|---|---|
| IAM.1 | Set ID - IAM | Yes | No | SI | |
| IAM.2 | Allergen Type Code | No | No | CE | 0127 |
| IAM.3 | Allergen Code/Mnemonic/Description | Yes | No | CE | |
| IAM.4 | Allergy Severity Code | No | No | CE | 0128 |
| IAM.5 | Allergy Reaction Code | No | Yes | ST | |
| IAM.6 | Allergy Action Code | Yes | No | CNE | 0323 |
| IAM.7 | Allergy Unique Identifier | No | No | EI | |
| IAM.8 | Action Reason | No | No | ST | |
| IAM.9 | Sensitivity to Causative Agent Code | No | No | CE | 0436 |
| IAM.10 | Allergen Group Code/Mnemonic/Description | No | No | CE | |
| IAM.11 | Onset Date | No | No | DT | |
| IAM.12 | Onset Date Text | No | No | ST | |
| IAM.13 | Reported Date/Time | No | No | TS | |
| IAM.14 | Reported By | No | No | XPN | |
| IAM.15 | Relationship to Patient Code | No | No | CE | 0063 |
| IAM.16 | Alert Device Code | No | No | CE | 0437 |
| IAM.17 | Allergy Clinical Status Code | No | No | CE | 0438 |
| IAM.18 | Statused by Person | No | No | XCN | |
| IAM.19 | Statused by Organization | No | No | XON | |
| IAM.20 | Statused at Date/Time | No | No | TS |
IAM is the allergy segment you reach for when AL1 starts to feel a bit too thin. AL1 is fine when the message is basically saying, "Here is the allergy list as I know it right now." IAM is different. IAM says, "This exact adverse reaction record was added, updated, deleted, confirmed, made inactive, reported by this person, and it has this identifier." That is a much more useful shape when you are maintaining an allergy list over time.
The standard describes IAM as patient adverse reaction information, not just allergy information. That wording matters. A real allergy, an intolerance, a side effect, a contraindication, and a general adverse reaction can look very similar in a patient-facing list, but they should not always drive the same clinical behaviour. IAM gives you places to say what the causative agent is, what kind of sensitivity it is, how certain the clinician is, and what update action is being requested.
You will most naturally see IAM in an ADT A60 update adverse reaction message, but the same idea turns up anywhere a system is trying to synchronize allergy records instead of just repeating a snapshot. If you are building the receiver, the big fields to understand are IAM-3, IAM-6, IAM-7, IAM-9, IAM-10, and IAM-17. Those are the fields that stop the allergy list becoming a pile of similar-looking text rows.
That sample shows the bit IAM adds over AL1. The allergy is not just present. It has an action code, an identifier, a reason for the action, a sensitivity type, and a clinical status. The receiver can now do something sensible with the individual allergy record instead of trying to guess whether the latest list should replace, merge, or delete what it already has. This is a useful one to open in HL7 Soup Web, because the difference between IAM-6 action and IAM-17 status is much clearer when you can click through the fields.
AL1 and IAM are not quite the same job
| Question | AL1 | IAM |
|---|---|---|
| What style of update? | Snapshot style. The sender usually repeats the known allergy list. | Action-code style. Each reaction can say add, update, delete, or no change. |
| How is one allergy identified? | Usually by allergen code/text and local matching rules. | Prefer IAM-7, a unique identifier for that allergy record. IAM-3 can be a fallback only if the systems have agreed it is unique enough. |
| How much clinical context? | Type, allergen, severity, reaction, and date. | Those fields plus sensitivity type, allergen group, onset, reporter, status, statused-by details, and later lifecycle audit fields. |
| Where is it strongest? | Simple ADT and registration feeds where a current allergy list is enough. | Allergy-maintenance feeds, A60 updates, EHR synchronization, and systems that need reliable add/update/delete behaviour. |
I would not call AL1 wrong or obsolete. It is still common, easy to read, and good enough for a lot of interfaces. The important thing is not to pretend it has IAM's update semantics. If both segments appear in the same project, write down exactly which one is authoritative and whether AL1 is a display snapshot while IAM is the maintenance feed. Otherwise you will eventually get duplicate penicillin allergies, ghost allergies that never disappear, or a deleted allergy that comes back in the next ADT message.
Where IAM usually hurts
The first pain point is identity. IAM-1 is just the sequence number in the message. It is not the allergy identifier. If the sender does not populate IAM-7, the receiver either has to use IAM-3 as a surrogate key or build a local matching rule from patient, allergen, type, and source system. That can work, but it should be an explicit contract, not a late-night guess in a transformation script.
The second pain point is the difference between action and status. IAM-6 tells the receiver what to do with this message row. IAM-17 tells you the clinical status of the allergy itself. An allergy can be sent with an update action and a clinical status of inactive. An allergy can be deleted because it was entered in error. Those are not the same story, and the interface should preserve that difference if the receiving system can handle it. If the receiver needs translation from local action/status codes, keep that mapping auditable in Integration Soup rather than flattening both ideas into one flag.
The third pain point is vocabulary. Medication allergens are much more useful when they use a real vocabulary such as RxNorm, SNOMED CT, or a well-managed local code set with a stable coding-system name. Free text is sometimes unavoidable, especially when the clinician typed "red dye in tablets" or "unknown antibiotic as a child", but coded allergens and coded statuses are what make decision support and reconciliation possible.
This is the row number for the IAM segment in the message. First IAM is 1, second IAM is 2, and so on. It is useful for humans, logging, and error messages, but it is not stable across messages.
Do not use this as the allergy key in a database. If peanut is IAM-1 today and penicillin is IAM-1 tomorrow, nothing magical happened to peanut. The sender just ordered the rows differently. For a durable allergy identity, look at IAM-7 or a formally agreed surrogate using IAM-3.
This gives the broad family of the adverse reaction: drug, food, environmental, pollen, plant, animal, miscellaneous allergy, or contraindication-style categories depending on the table in use. It is the same sort of field you see in AL1-2.
It sounds small, but it often controls routing. A diet system may care only about food allergies. A pharmacy system will care most about drug allergens. Radiology may care deeply about contrast reactions. Keep the broad type here and the actual substance in IAM-3.
This is the centre of the segment. If you get only one clinical thing right in IAM, make it this one. It identifies the substance, product, class, food, material, or other agent the patient should not be exposed to.
The best interfaces use a clear code, text, and coding system. For drug allergens, a canonical vocabulary is much easier to reconcile than a local spelling of "Penecillin" floating through the feed. But local codes can be perfectly workable if they are stable and both systems understand the coding authority.
There is also an update-mode wrinkle. If the sender does not provide IAM-7 and both sides agree that IAM-3 is unique enough, then IAM-3 may become the surrogate identifier for the allergy. Be careful with that. "Penicillin", "Amoxicillin", and "Penicillin class" can be clinically related without being the same record.
This is the broad severity of the allergy or adverse reaction. Mild, moderate, severe, and unknown-style values are common. Downstream systems may use this for display, sorting, warnings, or clinical decision support.
The tricky part is deciding what severity means locally. Some systems mean "how bad was the past reaction?" Others mean "how dangerous is re-exposure?" A rash, anaphylaxis, and "patient unsure" should not all be squeezed into the same workflow just because the source field was optional.
This field says what actually happened: rash, hives, anaphylaxis, wheeze, swelling, vomiting, dizziness, or whatever the source can report. In many HL7 versions it is ST and it can repeat, so you often see simple text values repeated with the HL7 repeat separator.
Do not put the allergen here. Penicillin belongs in IAM-3. "Anaphylaxis" belongs here. If you are working with a newer profile that supports IAR as well, that can carry richer reaction-detail rows, but IAM-5 is still the quick, practical reaction summary most receivers will look for first.
This is the field that makes IAM behave differently from AL1. It tells the receiver what to do with this allergy record. Typical values are add/insert, delete, update, and sometimes no change depending on the version/profile table being used.
If you are receiving IAM, build the interface around this field. Add should create a record if it is not already there. Update should change the matching allergy. Delete should remove, retire, or mark the matching allergy according to local policy. No change should not accidentally overwrite richer local data just because a message happened to arrive.
And this is where IAM-7 becomes almost mandatory in real life. An action code without a reliable identity is a dangerous little machine. You cannot safely delete "the sulfa allergy" if three different sulfa-related rows exist and the sender did not identify which one it meant.
This should be the durable identifier for one adverse reaction record for one patient. It uses EI, so include the assigning authority where you can. A plain number is better than nothing, but an identifier plus authority is much safer when several systems can create allergy records.
This is the field I most want to see in a serious IAM feed. It lets you update, delete, inactivate, and reconcile the same allergy over time. If the sending system cannot provide it, document the fallback very clearly. In some feeds IAM-3 is used as the surrogate key, but that only works when the source vocabulary is clean and the interface rules are boringly precise.
Here you get the human reason behind IAM-6. "Entered in error", "reaction clarified", "patient confirmed allergy at clinic", "duplicate removed", or "historical record imported" are the kinds of things that make this useful.
Do not rely on this field to drive the core behaviour. The action code should do that. Treat the reason as audit and context unless your implementation guide says otherwise. It is especially helpful when deletes and inactive statuses need to be reviewed later.
This field says what kind of sensitivity you are really talking about. The useful distinction is allergy versus intolerance versus side effect versus contraindication versus a more general adverse reaction.
This is one of IAM's best fields because it saves everything from being called an allergy. Nausea from codeine may be an intolerance or side effect, while anaphylaxis to penicillin is a very different patient-safety fact. If the receiver has a single "allergy" bucket, still preserve this value if you can. It may matter when the data is later exported, mapped to FHIR AllergyIntolerance, or used for smarter decision support.
This is where you can carry the allergen group or class alongside the specific allergen. For example, IAM-3 might say Bactrim and IAM-10 might say sulfonamide antibiotics. Or IAM-3 might say amoxicillin while IAM-10 says penicillins.
That split is very useful in medication safety because different systems alert at different levels. A clinician may document the exact product the patient reacted to, while a pharmacy system also wants to know the broader class. If you only know the class, then it may belong in IAM-3 as the primary allergen rather than hiding in IAM-10 by itself.
This is the date of the first reaction, if known. It is not the same as the date the allergy was reported, entered, modified, or sent in the HL7 message.
Many real allergy histories are fuzzy. A patient may remember "as a child" but not a date. Do not invent a neat date just to make the field look complete. Use IAM-12 when the timing is approximate.
This field is for the messy-but-useful timing story: childhood, adolescence, spring 1990, after surgery, or "many years ago". It gives you a place to keep the patient's rough history without pretending it is a proper date.
Receivers should display this gently and avoid treating it as something sortable. It is context, not a timestamp.
This is when the allergy was reported to a caregiver. It is different from onset. A patient might report today that a reaction happened twenty years ago.
It is also different from message date/time. If every reported date equals MSH-7, check the interface mapping. Sometimes that is legitimate, but often it means the source system did not actually send the clinical reporting time.
This is the person who reported the allergy. Often that is the patient, but it might be a parent, spouse, caregiver, clinician, or another informant.
The value is a person name, not the verifier. If you need to know who assigned the clinical status, use IAM-18. If you need to know the relationship between the reporter and the patient, use IAM-15.
This tells you how the reporter relates to the patient. Self, mother, father, spouse, guardian, caregiver, and similar values are the kind of thing you expect here.
It matters because reported allergies have different degrees of reliability. A parent reporting a child's peanut allergy is not the same workflow as an adult guessing about a vague childhood antibiotic reaction. Do not overdo the logic, but keep the context.
This describes an allergy alert device the patient carries or wears, such as a bracelet, necklace, or wallet card. You will not see it in every feed, but when it is present it is worth preserving.
I would treat it as supporting evidence or display context rather than the allergy itself. The actual adverse reaction still needs IAM-3, IAM-5, IAM-9, and IAM-17 to be useful.
This says how clinically trusted or active the allergy is: confirmed, suspect, unconfirmed, pending, doubt raised, erroneous, inactive, and similar status ideas depending on the table. This is not the same as IAM-6.
A common receiver mistake is to treat delete, inactive, and erroneous as the same thing. They are not. Delete is an action in the message. Inactive is a clinical state. Erroneous means the record was wrong. If your target system has only active/inactive, you may have to simplify, but keep the raw status somewhere if patient safety or audit matters.
This is the provider or user who assigned the clinical status. For a confirmed allergy, that may be the clinician who verified it. For an erroneous allergy, it may be the person who marked it as wrong.
It belongs with IAM-17 and IAM-20 as a little audit cluster. If your receiver cannot store it as structured audit, consider at least preserving it in an interface audit table.
This gives the organization behind the clinical status update. In a single hospital interface it may feel obvious, but in a shared-care, HIE, or migration feed it becomes important.
Try not to flatten all organizations into "source system". The source application that sent the message and the clinical organization that statused the allergy may not be the same thing.
This is when the allergy status was assigned. It completes the IAM-17 through IAM-20 cluster: what status, who assigned it, which organization, and when.
For older v2.5.1-style IAM, this is often the end of the segment. Later versions add more lifecycle fields after this, especially around inactivation, initial recording, and modification.
IAM-21: Inactivated by Person
When present, this identifies the person who inactivated the allergy record. It is a more specific audit field than the general "statused by" person.
This becomes useful when the allergy remains in the historical record but should no longer act like an active clinical warning. Do not confuse inactivation with deleting the data entirely.
IAM-22: Inactivated Date/Time
This is the time the allergy was inactivated. If your target system supports inactive allergies, this date is often more useful than the message arrival time.
If the source sends an inactive clinical status but no inactivation date, decide whether you store the status date from IAM-20 as a fallback. Do not quietly make up a date without documenting the rule.
IAM-23: Initially Recorded by Person
This identifies the person who first created the allergy entry in the source record. It is not necessarily the person who reported the allergy and not necessarily the person who verified it.
That distinction is surprisingly helpful during migrations. You may want to know whether the allergy was originally recorded by a clinician, imported from an old system, or added by registration staff.
IAM-24: Initially Recorded Date/Time
This is when the allergy entry was first created in the source record. It is a record-history date, not the reaction onset date.
Do not map this into onset unless the source explicitly says they are the same. A peanut allergy can be first recorded today and still have started in childhood.
IAM-25: Modified by Person
This identifies the person who last modified the allergy. It is handy when a reaction, severity, or clinical status changes after review.
In a receiver, this is usually audit data rather than display data. Store it if you can, especially if the target system needs to explain why allergy information changed.
IAM-26: Modified Date/Time
This is the timestamp of the last allergy modification. It helps distinguish old clinical data from a recent update.
One good receiver pattern is to store both the inbound message time and the source modification time. If a delayed interface replays an old IAM, you do not want it to overwrite newer allergy data just because it arrived last.
IAM-27: Clinician Identified Code
This field can preserve the clinician-entered allergen description or code associated with the allergy. Think of it as the clinical phrase the user selected or typed, which may not be identical to the normalized allergen code in IAM-3.
That is useful when normalization changes the wording. IAM-3 might carry a clean coded substance for decision support, while IAM-27 keeps the clinician's original concept close by. In a mapping to a modern allergy model, this may become an additional coding or display value rather than replacing the primary allergen.
IAM-28: Initially Recorded by Organization
This is the organization that first recorded the allergy. It pairs naturally with IAM-23 and IAM-24.
It is easy to ignore in a single-site feed, but it becomes useful in shared records and historical imports where the original authoring organization matters.
IAM-29: Modified by Organization
This names the organization that last modified the allergy. It is the organization-level companion to IAM-25.
If you are receiving from an HIE or enterprise record, this field can help you tell whether the update came from the primary EHR, an outside clinic, a pharmacy review, or a migration process.
IAM-30: Inactivated by Organization
This is the organization that inactivated the allergy. It completes the inactivation audit story with IAM-21 and IAM-22.
If your target system only supports a simple inactive flag, this may look excessive. Still, it is valuable in a safety review when someone asks who retired a major allergy warning and why.
How I would implement IAM
I would store allergy records by patient, source system, and IAM-7 whenever IAM-7 is present. I would keep IAM-3 as the primary allergen code, IAM-10 as the group/class, IAM-9 as the sensitivity type, IAM-17 as the clinical status, and IAM-6 as the inbound operation. I would also store the raw action and status values even if the receiving system has to simplify them for display.
If IAM-7 is missing, I would not pretend everything is fine. I would ask the sender whether IAM-3 is intended to be the unique key. If it is, I would document exactly which components matter: code, text, coding system, alternate code, and assigning authority. If it is not, I would probably treat the feed as snapshot-like and reconcile very carefully, because item-level delete and update behaviour will be risky.