HL7 Table HL70907: Adverse Event Type (Patient Care)

HL70907 is the HL7 v2 code table for Adverse Event Type (Patient Care) — a short categorical vocabulary that labels what kind of adverse event occurred during patient care. It was introduced in v2.7 to support the Patient Care Adverse Event segment (PCA) and is also referenced from the broader PEX Product Experience family. The table is HL7-defined and carries ten values through v2.8.1.

Purpose

HL70907 answers the question "what category of harm or near-harm happened?" at a level of detail useful for downstream surveillance and quality reporting — fine enough to drive a triage workflow, coarse enough to be safely tallied across thousands of events. It is deliberately not a clinical diagnosis vocabulary; richer detail (specific organism, drug name, anatomical site, MedDRA term) belongs on accompanying observation segments, not in HL70907 itself.

The table feeds patient-safety reporting workflows: incident-reporting systems, infection-control surveillance, fall-prevention dashboards, and FDA/MAUDE adverse-event submissions. Because the receiver expects a small, stable enumeration, HL70907 stays narrow.

Where it's used

• PCA segment Patient Care Adverse Event — PCA-1 (Set ID), PCA-2 (Adverse Event Code) is the canonical home of HL70907 in v2.7+.
• PEX segment Product Experience family — PEX-related event-categorization fields reuse HL70907 when the event being reported is a patient-care event rather than a pure product-experience event.
• Local extension segments (Z-segments) in some EHR-to-quality-reporting feeds borrow HL70907 as a categorical label even outside PCA/PEX.

Code list

Code system OID

• OID: 2.16.840.1.113883.18.400
• Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0907

The OID resolves on the HL7 Terminology server. Vorro emits this OID in CWE.14 when downstream profiles bind PCA-2 to OID-qualified coded values.

HL7-defined vs user-defined

HL70907 is HL7-defined. The table number falls inside the HL7-reserved range, and although the codes are short English words (rather than the single-character symbols of older tables), the value set is normative. Receivers are expected to accept the ten codes without local extension; senders should not invent additional codes inside this table.

When a site needs a category outside the ten — for example to flag a specific equipment malfunction or a behavioral-health event — the recommended path is to send Other in HL70907 and carry the richer concept in an accompanying observation or note segment bound to SNOMED CT or MedDRA, rather than extending HL70907.

Version differences

• v2.1 – v2.6 — Table did not exist. Adverse-event categorization was site-specific or carried entirely outside v2 messaging.
• v2.7 — HL70907 introduced alongside the PCA segment as part of the patient-safety expansion of the standard. Ten codes published.
• v2.7.1 – v2.8 — No changes to the value set; HL70907 referenced from additional fields in PEX.
• v2.8.1 — Set frozen at ten codes. No additions or removals.
• v2.9 — HL70907 unchanged; FHIR-direction guidance updated to recommend AdverseEvent.event as the target mapping for new profiles.

Common mistakes

• Sending the free-text description in PCA-2 — "Patient fell out of bed" instead of Fall. PCA-2 is a coded field; the narrative belongs in PCA-5 (Event Description) or an associated NTE segment.
• Using Other as a default when a more specific category fits. Other is reserved for genuinely uncategorizable events; over-using it destroys the downstream surveillance value of the table.
• Confusing case. HL70907 codes are mixed-case (MedError, not MEDERROR or mederror). Engines that uppercase on ingest will produce values not present in the published value set.
• Treating HL70907 as a diagnosis vocabulary. It is a category. The specific clinical detail — drug name for MedError, organism for Infection, site for Wound — must be carried separately, typically on OBX segments bound to SNOMED CT or RxNorm.
• Reusing HL70907 outside PCA/PEX without profile agreement. Local Z-segments that borrow the table without explicit trading-partner agreement will fail conformance checks at the receiver.

Examples

A PCA segment reporting a patient fall with no injury:

PCA|1|Fall^Patient fall^HL70907|20260601143000|||N|Witnessed fall from chair, no injury, returned to bed

PCA reporting a medication error caught before reaching the patient:

PCA|1|MedError^Medication error^HL70907|20260601090000|||N|Wrong-dose insulin prepared, intercepted at bedside

Same Fall event translated to a FHIR AdverseEvent.event Coding (with a SNOMED CT crosswalk):

{
  "resourceType": "AdverseEvent",
  "status": "completed",
  "actuality": "actual",
  "event": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/v2-0907",
        "code": "Fall",
        "display": "Patient fall"
      },
      {
        "system": "http://snomed.info/sct",
        "code": "1912002",
        "display": "Fall"
      }
    ]
  }
}

Mapping failure example — unknown vendor code:

PCA|1|Pressure^Pressure ulcer^HL70907|20260601100000|||N|Stage 2 pressure injury identified at sacrum

Pressure is not in HL70907. A conformant engine should route the message to the terminology curation queue, where the integration team either remaps to Wound (the closest valid category) with the original detail preserved on an NTE, or rejects the message back to the sender for correction.

FHIR mapping

The HL7 v2-to-FHIR Implementation Guide does not publish a per-code ConceptMap for HL70907; the recommended target is AdverseEvent.event (a CodeableConcept) and the v2 code is carried as one Coding with system = http://terminology.hl7.org/CodeSystem/v2-0907. Modern profiles enrich the same CodeableConcept with a second Coding drawn from SNOMED CT or MedDRA:

Because the FHIR AdverseEvent.event binding is example/preferred rather than required in most profiles, both the HL70907 Coding and the SNOMED Coding should be emitted on the same CodeableConcept so downstream consumers can use whichever they understand.

Engine considerations

• Case-preserving validation — HL70907 values are case-sensitive mixed case (MedError, not Mederror). Engines must not uppercase on normalization.
• Default-to-Other policy — define explicit policy on whether unmapped inbound categories silently downgrade to Other (and surface in a queue) or hard-fail the message.
• SNOMED enrichment — modern outbound FHIR profiles benefit from a second Coding drawn from SNOMED CT; maintain a one-to-one HL70907→SNOMED crosswalk and emit both Codings.
• Version gating — HL70907 did not exist before v2.7. When routing to a v2.5/v2.6 destination, the engine must downgrade the field to a Z-segment, drop it, or use an alternative agreed adverse-event vocabulary.

How Vorro handles HL70907

Vorro validates PCA-2 against the ten HL70907 codes on ingest. Values that match pass through to downstream channels untouched, optionally enriched with a SNOMED CT Coding on the FHIR side. Values that fail validation — including casing variants, vendor extensions, and accidental display strings — are routed to the terminology curation queue, where they either resolve to one of the ten canonical codes (and a remap rule is created) or are returned to the sender with a NACK explaining the violation.

On outbound, Vorro emits HL70907 in PCA-2 with CWE.14 populated for v2.7+ destinations that advertise OID-bound coded values. For v2.6 and earlier destinations, the field is suppressed and the underlying adverse-event detail is routed through a destination-specific Z-segment or alternate channel agreed with the trading partner. The original HL70907 code is always preserved when round-tripping through FHIR AdverseEvent.event.

Related pages

• PCA segment — Patient Care Adverse Event
• PEX segment — Product Experience
• HL70127 code table — Allergen Type

Sources

• HL7 Terminology — CodeSystem v2-0907 Adverse Event Type (Patient Care)
• HL7 v2 product brief
• HL7 v2-to-FHIR Implementation Guide