SFT identifies the software that created the message. It names the vendor organization, the certified version or release, the product name, the binary build id, optional free-text product information, and the install date. SFT appears directly after MSH and before the rest of the message body. It was introduced in HL7 v2.5 so that receivers — and especially certification and conformance programs — can record exactly which sending product and version produced each message. SFT is optional and may repeat, so a single message can declare a chain of software (for example an application plus the interface engine that relayed it).
Purpose
SFT tells the receiver which software vendor, product, version, and build originated the message. It exists for provenance, troubleshooting, and certification: when behavior differs across senders, SFT pins the exact product and release responsible. Because it repeats, each SFT instance can describe a distinct piece of software in the sending chain.
Used in
SFT is optional and repeating, and may appear immediately after MSH (and before UAC, EVN, or the first message-specific segment) in most v2.5+ message types — ADT, ORM, ORU, MDM, SIU, DFT, and others. See the messages index for the full list. Messages built against pre-2.5 profiles do not carry SFT at all.
Field-by-field reference
Source: official HL7 v2-to-FHIR IG. R = required (cardinality min ≥ 1). Repeat = field may repeat. Length pending authoritative v2.5.1 data.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| SFT-1 | Software Vendor Organization | XON | — | R | — | — | The organization that produces or distributes the sending software. |
| SFT-2 | Software Certified Version or Release Number | ST | — | R | — | — | The certified version or release of the product that created the message. |
| SFT-3 | Software Product Name | ST | — | R | — | — | The name of the software product. |
| SFT-4 | Software Binary ID | ST | — | R | — | — | A binary/build identifier that distinguishes builds sharing the same SFT-2 version. |
| SFT-5 | Software Product Information | TX | — | O | — | — | Free-text product information, configuration notes, or arguments. |
| SFT-6 | Software Install Date | DTM | — | O | — | — | When the sending software was installed (YYYYMMDD[HHMMSS][+/-ZZZZ]). |
Most-used fields
SFT-1 Software Vendor Organization and SFT-3 Software Product Name together answer the first triage question: whose software, which product. SFT-2 Software Certified Version or Release Number is what conformance and certification programs key on — it is the human-readable release.
SFT-4 Software Binary ID disambiguates builds that report the same SFT-2 value; two systems both claiming version 5.4 can differ by binary id when one carries a hotfix. SFT-6 Software Install Date is useful when a regression correlates with a specific deployment window.
Version differences (2.3 to 2.8.2)
- 2.3 / 2.4: SFT does not exist. Software provenance, if sent at all, was buried in MSH-3 (Sending Application) or local Z-segments.
- 2.5: SFT introduced as an optional, repeating segment positioned immediately after MSH, with all six fields (SFT-1 through SFT-6) defined.
- 2.5.1: SFT carried forward unchanged.
- 2.7 / 2.8.x: SFT remains stable; the UAC (User Authentication Credential) segment may follow SFT in the same header area. Receivers built for 2.3/2.4 simply ignore the unknown SFT segment.
Common mistakes
- Emitting SFT on a 2.3/2.4 interface whose receiver was never built to skip it, causing the parser to flag an unexpected segment.
- Placing SFT before MSH or somewhere other than the header area — SFT must follow MSH.
- Treating SFT-2 as a build id; SFT-2 is the certified release, SFT-4 is the binary/build id. Conflating them defeats hotfix tracking.
- Omitting required SFT-1 to SFT-4 when SFT is present — the segment's first four fields are mandatory once you choose to send it.
Examples
Minimal valid SFT (required fields only):
SFT|Acme Health Systems|5.4.1|InterfaceEngine|BUILD-20260101
Fully-populated SFT:
SFT|Acme Health Systems^^^^^^XX^^^VENDOR-001|5.4.1|InterfaceEngine|BUILD-20260101.3|Profile=ADT;Mode=Production|20260101
Annotated breakdown of the minimal example:
SFT ← segment ID
Acme Health Systems ← SFT-1 Software Vendor Organization
5.4.1 ← SFT-2 Software Certified Version or Release Number
InterfaceEngine ← SFT-3 Software Product Name
BUILD-20260101 ← SFT-4 Software Binary ID
← SFT-5 empty (Software Product Information)
← SFT-6 empty (Software Install Date)
In-context inside an ADT^A01 (admit), SFT after MSH:
MSH|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609120000||ADT^A01^ADT_A01|MSG00001|P|2.5.1
SFT|Acme Health Systems|5.4.1|InterfaceEngine|BUILD-20260101|Profile=ADT|20260101
EVN|A01|20260609120000
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
PV1|1|I|ICU^101^A|||||||MED
In-context inside an ORU^R01 (result), with two repeating SFT segments after MSH:
MSH|^~&|LAB|HOSP_B|EHR|HOSP_A|20260609131500||ORU^R01^ORU_R01|CTRL-9931|P|2.5.1
SFT|Beacon Diagnostics|8.2|LabConnect|LC-20251201|Source application|20251201
SFT|Acme Health Systems|5.4.1|InterfaceEngine|BUILD-20260101|Relaying engine|20260101
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
OBR|1||ORD123|CBC^Complete Blood Count^L
OBX|1|NM|718-7^Hemoglobin^LN||13.5|g/dL|13.0-17.0|N|||F
FHIR mapping
Target resource: Device (primary). A second official ConceptMap maps SFT to MessageHeader.source for the source-software view. Official ConceptMap: ConceptMap-segment-sft-to-device (JSON); see also ConceptMap-segment-sft-to-messageheader.
| SFT field | FHIR target |
|---|---|
| SFT-1 Software Vendor Organization | Device.manufacturer (string; or extension referencing an Organization) |
| SFT-2 Software Certified Version or Release Number | Device.version.value |
| SFT-3 Software Product Name | Device.deviceName.name / Device.deviceName.type |
| SFT-4 Software Binary ID | Device.modelNumber |
| SFT-5 Software Product Information | Device.note.text |
| SFT-6 Software Install Date | Device.version.extension (installDate URL with valueDateTime) |
All six SFT fields are mapped in the SFT-to-Device ConceptMap; none are dropped, though SFT-1 (Organization reference) and SFT-6 (install date) use extensions rather than first-class Device elements.
Engine considerations
- SFT is optional and repeating: handle zero, one, or many instances. Each repeat is a distinct piece of software in the sending chain, not a continuation of the previous one.
- Position matters: SFT belongs in the header area immediately after MSH (and before UAC/EVN). A misplaced SFT trips strict segment-order validators.
- Version gating: only emit SFT when the negotiated MSH-12 version is 2.5 or later, or when the receiver is known to tolerate it. Pre-2.5 receivers may reject an unexpected segment.
- Failure mode: senders that hard-code SFT-2 across builds make hotfix correlation impossible; populate SFT-4 (Binary ID) to distinguish builds.
How Vorro parses and produces SFT
Vorro reads each SFT repetition after MSH and records the vendor, product, version, and binary id as message provenance, attaching them to the parsed message for audit and troubleshooting. On the produce side, Vorro stamps SFT only when the channel's negotiated version is 2.5+, populates SFT-1 through SFT-4 from channel configuration, and sets SFT-6 to the deployed build's install date so downstream receivers can correlate behavior to a specific Vorro release.
Related pages
- MSH — the message header that SFT immediately follows.
- UAC — the user authentication credential segment that may follow SFT in the header area.
- ADT messages — a common message family where SFT appears after MSH.
