HL7 AFF Segment: Professional Affiliation

The AFF (Professional Affiliation) segment records the organizations a staff member or practitioner is professionally affiliated with. It is one of the personnel detail segments that travel with a staff record, naming the professional organization, its address, and the dates the affiliation was in effect. AFF is repeatable, so a single practitioner can carry several affiliations in one record.

AFF is part of the same personnel family as EDU (Educational Detail) and LAN (Language Detail). Together these segments describe a practitioner's credentials, training, and capabilities and share consistent personnel and credential terminology across the staff master file.

Purpose

The purpose of AFF is to express which professional bodies a practitioner belongs to or is associated with. Typical examples include a medical society, a specialty board, a nursing association, or a hospital admitting-privileges relationship. Each AFF occurrence pairs the organization with its postal address and the date range during which the affiliation applied, giving downstream systems enough context to validate credentials, populate provider directories, and track membership lapses.

Because AFF is a detail segment, it never stands alone. It always supplements a staff record introduced by STF and qualified by PRA (Practitioner Detail). The affiliation it describes belongs to the person identified earlier in that staff record.

Used in

AFF is a staff/practitioner detail segment used in the MFN^M02 message (Master File Notification - Staff/Practitioner). Within that message it follows the STF and PRA segments, repeating once per professional affiliation that the staff member holds. The MFN^M02 message synchronizes practitioner master data between systems, and AFF contributes the affiliation portion of that record.

Field-by-field reference

Source: HAPI HL7v2 v2.5.1 javadocs (https://hapifhir.github.io/hapi-hl7v2/v251/apidocs/ca/uhn/hl7v2/model/v251/segment/AFF.html) for sequence, name, data type, and repetition. Length is not published in the javadocs (—); Required and Table # are filled from the HL7 v2.5.1 standard where well-established.

Seq	Name	Data Type	Length	Req	Repeat	Table #	Description
AFF-1	Set ID - AFF	si	—	R	—	—	Sequence number for this AFF occurrence
AFF-2	Professional Organization	xon	—	O	—	—	Organization the practitioner is affiliated with
AFF-3	Professional Organization Address	xad	—	O	—	—	Postal address of the professional organization
AFF-4	Professional Organization Affiliation Date Range	dr	—	O	Y	—	Start and end dates of the affiliation
AFF-5	Professional Affiliation Additional Information	st	—	O	—	—	Free-text note about the affiliation

Most-used fields

AFF-1 (Set ID) is mandatory and simply numbers the affiliations within the staff record, starting at 1. AFF-2 (Professional Organization) is the field that carries the actual meaning of the segment: the name and identifier of the affiliated body. AFF-4 (Affiliation Date Range) is the second most-used field, because membership and privilege windows are central to credential validation; it repeats so that a lapsed-then-renewed affiliation can be expressed as multiple ranges. AFF-3 and AFF-5 are commonly left empty when only the organization name and dates are exchanged.

Version differences (2.3 to 2.8.2)

AFF was introduced with the staff/practitioner master file machinery in HL7 v2.3 and has remained remarkably stable. The five-field structure seen in v2.5.1 is essentially unchanged from v2.3 through v2.8.2. The most visible drift is in data-type definitions rather than the segment itself: the XON type used by AFF-2 and the XAD type used by AFF-3 gained additional components in later versions (for example expanded check-digit and address-representation handling), and AFF-5 remains a simple ST throughout. No fields were added, removed, or renumbered across this range, so AFF parsers written against v2.3 generally read v2.8.2 AFF segments without modification.

Common mistakes

A frequent error is omitting AFF-1 (Set ID) or restarting it within the same message; the Set ID must be present and increment within the staff record. Another is overloading AFF-2 by stuffing both the organization name and an internal code into the name component instead of using the XON identifier components, which breaks normalized lookups. Implementers also misuse AFF-4 by sending a single date in a TS-style field when the DR type expects a range with distinct start and end values. Finally, teams sometimes place free-text affiliation notes in AFF-2 rather than AFF-5, where additional information belongs.

Examples

Minimal AFF (Set ID plus organization only):

AFF|1|^American Medical Association

Fully-populated AFF:

AFF|1|1934567^American Medical Association^L|330 N Wabash Ave^Suite 39300^Chicago^IL^60611^USA|20180101^20251231|Active fellow in good standing

Annotated breakdown:

AFF|1|1934567^American Medical Association^L|330 N Wabash Ave^...|20180101^20251231|Active fellow in good standing
    |  |                                    |                     |                  |
    |  |                                    |                     |                  +--> AFF-5 Additional Information (ST)
    |  |                                    |                     +---------------------> AFF-4 Affiliation Date Range (DR) 2018-01-01 to 2025-12-31
    |  |                                    +-------------------------------------------> AFF-3 Organization Address (XAD)
    |  +--------------------------------------------------------------------------------> AFF-2 Professional Organization (XON)
    +-----------------------------------------------------------------------------------> AFF-1 Set ID (SI) = 1

In-context excerpt 1 — AFF inside an MFN^M02 staff master-file message, following STF and PRA, with two affiliations:

MSH|^~&|HRPORTAL|VORRO|REGISTRY|STATE|20260610120000||MFN^M02^MFN_M02|MSG00041|P|2.5.1
MFI|PRA^Practitioner Master^HL70175|||UPD|20260610120000
MFE|MAD|||PROV4471
STF|PROV4471|9988776^^^NPI~554433^^^SL|Okafor^Adaeze^N|P|F|19840712|A
PRA|PROV4471|VORRO^Vorro Health^L|CARD^Cardiology^HL70358|||MD^Doctor of Medicine^HL70360
AFF|1|1934567^American Medical Association^L|330 N Wabash Ave^^Chicago^IL^60611^USA|20120601^20251231|
AFF|2|7781234^American College of Cardiology^L|2400 N St NW^^Washington^DC^20037^USA|20150301^|Board-certified member

In-context excerpt 2 — AFF inside an MFN^M02 for a nursing affiliation:

MSH|^~&|HRPORTAL|VORRO|REGISTRY|STATE|20260610123000||MFN^M02^MFN_M02|MSG00042|P|2.5.1
MFI|PRA^Practitioner Master^HL70175|||UPD|20260610123000
MFE|MAD|||PROV5512
STF|PROV5512|6655443^^^NPI|Lindqvist^Erik^J|P|M|19900223|A
PRA|PROV5512|VORRO^Vorro Health^L|MED^Medical-Surgical^HL70358|||RN^Registered Nurse^HL70360
AFF|1|4456789^American Nurses Association^L|8515 Georgia Ave^Suite 400^Silver Spring^MD^20910^USA|20160815^|Active membership

FHIR mapping

There is no segment-level ConceptMap published in the v2-to-FHIR Implementation Guide for AFF, so the target is "Not mapped at the segment level." Conceptually, AFF aligns with Practitioner.qualification: AFF-2 (Professional Organization) corresponds to qualification.issuer, and AFF-4 (Affiliation Date Range) corresponds to qualification.period. Because no normalized mapping is standardized, any AFF-to-Practitioner.qualification transform must be defined locally and verified per interface.

Engine considerations

AFF is a repeating detail segment, so an interface engine must treat all AFF occurrences within a staff record as a group keyed by the preceding STF/PRA. Engines should preserve the AFF-1 Set ID ordering when re-serializing, since some receivers rely on it to detect adds, updates, and deletes. The DR data type in AFF-4 requires range-aware handling — splitting on the component delimiter into start and end — rather than the simpler date parsing used for DT/TS fields. When an organization identifier in AFF-2 is absent, engines should avoid synthesizing a code, because doing so can collide with normalized organization registries downstream.

How Vorro parses and produces AFF

When Vorro parses AFF, each occurrence is read into a normalized affiliation record linked to the practitioner established from STF/PRA. AFF-2 is decomposed into its XON components so the organization name and any identifier are stored as separate normalized fields, and AFF-4 is expanded into discrete start and end dates so date-range queries work without re-parsing the raw range. The AFF-1 Set ID is retained as the stable ordering key.

When Vorro produces AFF, it emits one segment per affiliation on the source record, assigns AFF-1 sequentially from 1, and writes the normalized organization back into XON components. Date ranges are reassembled into the DR format expected by AFF-4, and any free-text note is placed in AFF-5 rather than being merged into the organization name.

Sources

← Back to HL7 v2 Guide