NEWFree ROI Calculators — quantify what prior auth and siloed data are costing your organization.Prior Auth ROI Siloed Data ROI
HL7 v2Segment10 min read

HL7 STF Segment: Staff Identification

The STF (Staff Identification) segment carries the core master-file record for a member of staff or a practitioner. It is the anchor segment of the Staff/Practitioner master file: a single STF segment identifies one person and records their identifiers, name, type, demographics, contact details, and employment status, after which PRA and ORG segments add practitioner-specific and organizational detail. STF is most often exchanged inside MFN^M02 master file notification messages so that downstream systems can keep a synchronized directory of clinicians and other staff.

Purpose

The purpose of STF is to communicate, create, or update a master record describing a single staff member. It supplies a stable primary key (STF-1), one or more institution-assigned identifiers (STF-2), the person's name (STF-3), and a broad set of attributes ranging from staff type and department to demographic, contact, and credentialing information. Because the master file framework treats STF as the parent of the staff record, every PRA and ORG segment that follows it in a message is understood to belong to the same individual.

Used in

STF is used in MFN^M02 Master File Notification messages for staff and practitioner records. In that context the MFE (Master File Entry) segment declares the record-level action (add, update, delete) and the STF segment immediately follows, optionally trailed by PRA and ORG segments that elaborate on the same person.

Field-by-field reference

Source: HAPI HL7v2 v2.5.1 javadocs (STF) 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.

SeqNameData TypeLengthReqRepeatTable #Description
STF-1Primary Key Value - STFceRMaster file primary key identifying this staff record
STF-2Staff Identifier ListcxOYInstitution-assigned identifiers for the staff member
STF-3Staff NamexpnOYFull name of the staff member
STF-4Staff TypeisOYHL70182Category of staff such as physician or nurse
STF-5Administrative SexisOHL70001Administrative sex of the staff member
STF-6Date/Time of BirthtsOBirth date and time of the staff member
STF-7Active/Inactive FlagidOHL70183Indicates whether the staff record is active
STF-8DepartmentceOYDepartment to which the staff member belongs
STF-9Hospital Service - STFceOYHL70069Hospital service associated with the staff member
STF-10PhonextnOYTelephone or other telecommunication contacts
STF-11Office/Home Address/BirthplacexadOYOffice, home, or birthplace addresses
STF-12Institution Activation DatedinOYDate the staff member was activated at an institution
STF-13Institution Inactivation DatedinOYDate the staff member was inactivated at an institution
STF-14Backup Person IDceOYIdentifier of a backup or covering person
STF-15E-Mail AddressstOYElectronic mail address of the staff member
STF-16Preferred Method of ContactceOHL70185Preferred way to reach the staff member
STF-17Marital StatusceOHL70002Marital status of the staff member
STF-18Job TitlestOFree-text job title of the staff member
STF-19Job Code/ClassjccOHL70327Coded job classification of the staff member
STF-20Employment Status CodeceOHL70066Employment status of the staff member
STF-21Additional Insured on AutoidOHL70136Indicates additional insured on auto policy
STF-22Driver's License Number - StaffdlnODriver's license number of the staff member
STF-23Copy Auto InsidOHL70136Indicates a copy of auto insurance is on file
STF-24Auto Ins. ExpiresdtOAuto insurance expiration date
STF-25Date Last DMV ReviewdtODate of the last motor vehicle record review
STF-26Date Next DMV ReviewdtODate of the next scheduled DMV review
STF-27RaceceOHL70005Race of the staff member
STF-28Ethnic GroupceOHL70189Ethnic group of the staff member
STF-29Re-activation Approval IndicatoridOHL70136Indicates approval to re-activate the staff member
STF-30CitizenshipceOYHL70171Citizenship of the staff member
STF-31Death Date and TimetsODate and time of death
STF-32Death IndicatoridOHL70136Indicates whether the staff member is deceased
STF-33Institution Relationship Type CodecweOHL70538Type of relationship to the institution
STF-34Institution Relationship PerioddrODate range of the institution relationship
STF-35Expected Return DatedtOExpected return date of the staff member
STF-36Cost Center CodecweOYHL70539Cost center associated with the staff member
STF-37Generic Classification IndicatoridOHL70136Indicates a generic classification applies
STF-38Inactive Reason CodecweOHL70540Reason the staff member is inactive

Most-used fields

In practice the overwhelming majority of integrations rely on a small subset of STF fields. STF-1 (Primary Key Value) is the stable identifier that ties the staff record to MFE and to any PRA/ORG children, so it is effectively mandatory. STF-2 (Staff Identifier List) carries the operational identifiers an external system actually keys on, such as an NPI or an internal provider number. STF-3 (Staff Name) supplies the human-readable name. STF-4 (Staff Type) and STF-7 (Active/Inactive Flag) drive directory categorization and the activation lifecycle. STF-10 (Phone) and STF-15 (E-Mail Address) round out the contact picture that most provider directories need.

Version differences (2.3 to 2.8.2)

STF was introduced in HL7 v2.3 with a comparatively short field list focused on identifier, name, type, sex, birth date, active flag, department, service, phone, and address. Version 2.3.1 and 2.4 expanded the demographic and credentialing fields (driver's license, DMV review dates, marital status). Version 2.5 and 2.5.1 added the institution relationship fields (STF-33 and STF-34), cost center (STF-36), and the generic classification and inactive reason fields, bringing the segment to the 38-field form documented here. Versions 2.6 through 2.8.2 retained this structure while migrating several coded fields from CE toward CWE and tightening table bindings; no fields were removed, so a 2.5.1 STF parses cleanly under later versions.

Common mistakes

A frequent error is omitting or reusing STF-1, which breaks the linkage between the master file entry and its staff record and can cause downstream systems to create duplicates. Another is conflating STF-2 (the identifier list) with STF-1 (the primary key); they serve different roles and should not be populated with the same value blindly. Integrators also often forget that STF-2, STF-3, STF-4, and the address and phone fields repeat, and they truncate to the first value, dropping additional identifiers or alternate names. Finally, sending demographic fields such as race or ethnic group without the correct table-bound codes produces records that fail validation in stricter engines.

Examples

A minimal valid STF segment with only the primary key, an identifier, name, type, and active flag:

STF|1234^^^HOSP^PRN|987654^^^HOSP^MR|SMITH^JOHN^A|P|||A

A fully populated STF segment exercising most fields:

STF|1234^^^HOSP^PRN|987654^^^NPI~5551212^^^HOSP^PRN|SMITH^JOHN^A^^DR^MD|P~T|M|19700115|A|CARDIOLOGY^Cardiology^L|CAR^Cardiology Service^L|(555)555-0100^PRN^PH~(555)555-0188^WPN^FX|100 MAIN ST^^METROPOLIS^NY^10001^USA^O|20180101000000|||0099^Dr. Adams^L|jsmith@hospital.example|TEL^Telephone^HL70185|M^Married^HL70002|Attending Physician|123^Physician^L^^^L|F^Full Time^HL70066|N|D1234567^NY^20281231|N|20281231|20250101|20260101|2106-3^White^HL70005|N^Non-Hispanic^HL70189|N|USA^United States^HL70171|||N||20300101|CC100^Cardiology Cost Center^L|N|

Annotated breakdown of the key fields:

STF|1234^^^HOSP^PRN|987654^^^NPI|SMITH^JOHN^A|P|M|19700115|A
    |                |              |            |  |  |        |
    |                |              |            |  |  |        +--> STF-7  Active/Inactive Flag (A = active)
    |                |              |            |  |  +-----------> STF-6  Date/Time of Birth
    |                |              |            |  +--------------> STF-5  Administrative Sex
    |                |              |            +-----------------> STF-4  Staff Type (P = physician)
    |                |              +------------------------------> STF-3  Staff Name
    |                +---------------------------------------------> STF-2  Staff Identifier List
    +------------------------------------------------------------> STF-1  Primary Key Value - STF

In-context excerpt inside an MFN^M02 message, adding a new staff record:

MSH|^~&|HRSYS|HOSP|DIRSVC|HOSP|20260610091500||MFN^M02^MFN_M02|MSG00001|P|2.5.1
MFI|PRA^Practitioner Master File^HL70175|HOSP|UPD|20260610091500||AL
MFE|MAD|PKEY001|20260610091500|1234^^^HOSP^PRN|CM
STF|1234^^^HOSP^PRN|987654^^^NPI|SMITH^JOHN^A|P|M|19700115|A
PRA|1234^^^HOSP^PRN|GRP01^Cardiology Group^L|FACPHY|Y|207RC0000X^Cardiology^NUCC

A second in-context excerpt updating an existing staff record's contact details:

MSH|^~&|HRSYS|HOSP|DIRSVC|HOSP|20260610093000||MFN^M02^MFN_M02|MSG00002|P|2.5.1
MFI|PRA^Practitioner Master File^HL70175|HOSP|UPD|20260610093000||AL
MFE|MUP|PKEY002|20260610093000|1234^^^HOSP^PRN|CM
STF|1234^^^HOSP^PRN|987654^^^NPI|SMITH^JOHN^A|P|||A|||(555)555-0199^PRN^PH||||jsmith.new@hospital.example

FHIR mapping

No segment-level ConceptMap is published in the v2-to-FHIR IG for STF. Conceptually the staff member described by an STF segment corresponds to a FHIR Practitioner resource: STF-1 and STF-2 map to Practitioner.identifier, STF-3 to Practitioner.name, STF-5 to Practitioner.gender, STF-6 to Practitioner.birthDate, and the phone, email, and address fields to Practitioner.telecom and Practitioner.address. Because no formal ConceptMap exists at the segment level, implementers must define these mappings locally.

Engine considerations

Most interface engines treat STF as a standalone segment that can appear at most once per MFE group, so engines should enforce that cardinality when validating staff master files. Repeating fields (STF-2, STF-3, STF-4, STF-8, STF-9, STF-10, STF-11, and others) must be parsed as arrays; flattening them to a single occurrence silently discards data. Engines that downcast coded fields from CWE to CE between versions should preserve the original code, text, and coding system components. Because STF carries demographic and license data, engines often need to apply de-identification or filtering rules before forwarding the segment to less-trusted destinations.

How Vorro parses and produces STF

Vorro parses STF by first reading STF-1 as the record key and indexing it against the parent MFE action code so that adds, updates, and deletes are routed correctly. Repeating identifier, name, and contact fields are expanded into normalized collections, and coded fields are resolved against the configured HL7 tables with the original components retained. When producing STF, Vorro emits STF-1 as the stable primary key, populates STF-2 from the source system's identifier set, and writes name, type, and active-flag fields from the normalized staff model, leaving optional fields empty rather than sending placeholder values. PRA and ORG segments produced for the same person reuse the STF-1 key to preserve linkage.

Sources

← Back to HL7 v2 Guide

Ready to Integrate This Into Your Workflow?

Talk to a Vorro expert about implementing HL7 v2 in your specific environment.

Browse HL7 v2 Guides
HL7 STF Segment: Staff Identification | Vorro Academy | Vorro