HL7 STF Staff Identification
HL7 field reference STF 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 |
|---|---|---|---|---|---|
| STF.1 | Primary Key Value - STF | No | No | CE | 9999 |
| STF.2 | Staff Identifier List | No | Yes | CX | |
| STF.3 | Staff Name | No | Yes | XPN | |
| STF.4 | Staff Type | No | Yes | IS | 0182 |
| STF.5 | Administrative Sex | No | No | IS | 0001 |
| STF.6 | Date/Time of Birth | No | No | TS | |
| STF.7 | Active/Inactive Flag | No | No | ID | 0183 |
| STF.8 | Department | No | Yes | CE | 0184 |
| STF.9 | Hospital Service - STF | No | Yes | CE | 0069 |
| STF.10 | Phone | No | Yes | XTN | |
| STF.11 | Office/Home Address/Birthplace | No | Yes | XAD | |
| STF.12 | Institution Activation Date | No | Yes | DIN | 0537 |
| STF.13 | Institution Inactivation Date | No | Yes | DIN | 0537 |
| STF.14 | Backup Person ID | No | Yes | CE | |
| STF.15 | E-Mail Address | No | Yes | ST | |
| STF.16 | Preferred Method of Contact | No | No | CE | 0185 |
| STF.17 | Marital Status | No | No | CE | 0002 |
| STF.18 | Job Title | No | No | ST | |
| STF.19 | Job Code/Class | No | No | JCC | 0327 |
| STF.20 | Employment Status Code | No | No | CE | 0066 |
| STF.21 | Additional Insured on Auto | No | No | ID | 0136 |
| STF.22 | Driver's License Number - Staff | No | No | DLN | |
| STF.23 | Copy Auto Ins | No | No | ID | 0136 |
| STF.24 | Auto Ins. Expires | No | No | DT | |
| STF.25 | Date Last DMV Review | No | No | DT | |
| STF.26 | Date Next DMV Review | No | No | DT | |
| STF.27 | Race | No | No | CE | 0005 |
| STF.28 | Ethnic Group | No | No | CE | 0189 |
| STF.29 | Re-activation Approval Indicator | No | No | ID | 0136 |
| STF.30 | Citizenship | No | Yes | CE | 0171 |
| STF.31 | Death Date and Time | No | No | TS | |
| STF.32 | Death Indicator | No | No | ID | 0136 |
| STF.33 | Institution Relationship Type Code | No | No | CWE | 0538 |
| STF.34 | Institution Relationship Period | No | No | DR | |
| STF.35 | Expected Return Date | No | No | DT | |
| STF.36 | Cost Center Code | No | Yes | CWE | 0539 |
| STF.37 | Generic Classification Indicator | No | No | ID | 0136 |
| STF.38 | Inactive Reason Code | No | No | CWE | 0540 |
STF identifies a staff member and carries demographic, contact, credential, and employment detail.
The standard describes STF this way: The Technical Steward for the STF segment is PA and Personnel Management. The STF segment can identify any personnel referenced by information systems. These can be providers, staff, system users, and referring agents. In a network environment, this segment can be used to define personnel to other applications, for example, order entry clerks, insurance verification clerks, admission clerks, as well as provider demographics. When using the STF and PRA segments in the Staff/Practitioner Master File message, MFE-4-primary key value is used to link all the segments pertaining to the same master file entry. Therefore, in the MFE segment, MFE-4-primary key value must be filled in. Other segments may follow the STF segment to provide data for a particular type of staff member. The PRA segment (practitioner) is one such. It may optionally follow the STF segment in order to add practitioner-specific data. Other segments may be defined as needed.
Master-file segments update reference data rather than describing a single patient event. They define locations, staff, providers, test catalogs, charge items, inventory items, languages, certificates, and other shared records.
Because many downstream messages depend on this data, small changes here can have large effects. Use stable identifiers, effective dates, action codes, and clear ownership rules instead of treating a master-file feed like a loose spreadsheet export.
The v2.5.1 structures show STF in MFN_M02 - Master file - staff practitioner, PMU_B01 - Add personnel record, PMU_B03 - Delete personnel re cord, and PMU_B04 - Active practicing person, and 3 other message structures. That tells you where it can appear, but the implementation guide still decides which optional fields are meaningful.
For practical interface work, read the generated field panel for datatype, required, repeatable, and table details, then use the notes below to decide what the field should mean in the receiving workflow.
STF-1 carries a measured, counted, priced, or dosed value. A number without the expected unit, currency, or companion qualifier is much easier to misread than an empty field.
The generated panel links this to HL7 table 9999; many real interfaces narrow that list further, so follow the receiver's implementation guide.
STF-2 identifies the Staff Identifier List for this master-file record. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
If there are several identifiers, use repetitions deliberately and make each repeat self-explanatory rather than relying on position alone.
STF-3 identifies a person, provider, staff member, or contact involved in this master-file record. Use the structured name or provider datatype instead of flattening everything into display text.
When more than one person is sent, repeats should carry role or identifier context so the receiver can tell who did what.
STF-4 qualifies the master-file record rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
Use the agreed value set, starting from HL7 table 0182. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
STF-5 belongs to the medication/treatment workflow. Be explicit about whether the value describes the original order, encoded order, dispense event, scheduled give, or actual administration.
The generated panel links this to HL7 table 0001; many real interfaces narrow that list further, so follow the receiver's implementation guide.
STF-6 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
STF-7 carries Active/Inactive Flag for this master-file record. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0183; many real interfaces narrow that list further, so follow the receiver's implementation guide.
STF-8 places the master-file record in an organization, facility, department, room, bed, or location group. Keep physical location, owning department, and receiving facility separate when the datatype allows it.
The generated panel links this to HL7 table 0184; many real interfaces narrow that list further, so follow the receiver's implementation guide.
STF-9 carries Hospital Service - STF for this master-file record. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0069; many real interfaces narrow that list further, so follow the receiver's implementation guide.
STF-10 carries contact details. Use the datatype components for use code, equipment type, address type, country, and other qualifiers rather than squeezing everything into one formatted string.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
STF-11 carries contact details. Use the datatype components for use code, equipment type, address type, country, and other qualifiers rather than squeezing everything into one formatted string.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
STF-12 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
The generated panel links this to HL7 table 0537; many real interfaces narrow that list further, so follow the receiver's implementation guide.
STF-13 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
The generated panel links this to HL7 table 0537; many real interfaces narrow that list further, so follow the receiver's implementation guide.
STF-14 identifies the Backup Person ID for this master-file record. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
If there are several identifiers, use repetitions deliberately and make each repeat self-explanatory rather than relying on position alone.
STF-15 carries contact details. Use the datatype components for use code, equipment type, address type, country, and other qualifiers rather than squeezing everything into one formatted string.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
STF-16 qualifies the master-file record rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
Use the agreed value set, starting from HL7 table 0185. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
STF-17 tells the receiver the state of this master-file record. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0002 or the narrower table in the local profile.
STF-18 carries Job Title for this master-file record. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
STF-19 qualifies the master-file record rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
Use the agreed value set, starting from HL7 table 0327. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
STF-20 tells the receiver the state of this master-file record. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0066 or the narrower table in the local profile.
STF-21 carries Additional Insured on Auto for this master-file record. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0136; many real interfaces narrow that list further, so follow the receiver's implementation guide.
STF-22 identifies the Driver's License Number - Staff for this master-file record. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
STF-23 carries Copy Auto Ins for this master-file record. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0136; many real interfaces narrow that list further, so follow the receiver's implementation guide.
STF-24 carries Auto Ins. Expires for this master-file record. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
STF-25 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
STF-26 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
STF-27 carries Race for this master-file record. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0005; many real interfaces narrow that list further, so follow the receiver's implementation guide.
STF-28 carries Ethnic Group for this master-file record. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0189; many real interfaces narrow that list further, so follow the receiver's implementation guide.
STF-29 tells the receiver the state of this master-file record. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0136 or the narrower table in the local profile.
STF-30 carries Citizenship for this master-file record. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0171; many real interfaces narrow that list further, so follow the receiver's implementation guide.
STF-31 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
STF-32 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
The generated panel links this to HL7 table 0136; many real interfaces narrow that list further, so follow the receiver's implementation guide.
STF-33 identifies the Institution Relationship Type Code for this master-file record. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
The generated panel links this to HL7 table 0538; many real interfaces narrow that list further, so follow the receiver's implementation guide.
STF-34 identifies an organization, clinic, facility, department, or company involved in this master-file record. Keep the organization identifier and display name separate when the datatype supports it.
STF-35 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
STF-36 identifies the Cost Center Code for this master-file record. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
If there are several identifiers, use repetitions deliberately and make each repeat self-explanatory rather than relying on position alone.
STF-37 tells the receiver the state of this master-file record. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0136 or the narrower table in the local profile.
STF-38 identifies the Inactive Reason Code for this master-file record. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
The generated panel links this to HL7 table 0540; many real interfaces narrow that list further, so follow the receiver's implementation guide.
Related links
- MFI - Master File Identification
- MFE - Master File Entry
- MFA - Master File Acknowledgment
- LOC - Location Identification
- PRA - Practitioner Detail
- OM1 - General Segment
- CDM - Charge Description Master
- MFN_M02 - Master file - staff practitioner
- PMU_B01 - Add personnel record
- PMU_B03 - Delete personnel re cord