Definition: This segment provides additional information about the software product(s) used as a Sending Application. The primary purpose of this segment is for diagnostic use. There MAY be additional uses per site-specific agreements.
Implementers are encouraged to use message profile identifiers (as found in 2.14.9.21, "MSH-21 Message Profile Identifier (EI) 01598") to control the behavior of the receiving application rather than relying on application or version information in the SFT segment.
For example, if software product A has versions 9 and 10 deployed in different Enterprise locations, the fact that they use different message types, segments, or fields SHOULD be reflected via their message profiles (see section 2B, "Conformance Using Message Profiles"). If there is an upgrade from version 10 to 10.1, this would be reflected in the SFT segment, but changes to the message contents SHOULD be reflected via a new/different conformance profile.
Use Case: An external application has been customized to communicate with a centralized patient drug history system. However, due to certain, known characteristics of the external software package, the centralized system must modify its behavior in order to process transactions correctly. In one example, the external application could have multiple versions in production. As such, the centralized application will need to know the name of the Software Vendor Organization, the Software Release Number, the Software Product Name, and the Software Binary ID so that it can correctly identify the software submitting the transaction and modify its behavior appropriately.
While preparing a transaction for submission to a centralized system the sending application specifies its Software Install Date and its configuration settings (Software Product Information). While processing the transaction, the centralized system encounters an error. Upon examination of the error, install date and configuration of the software that sent the message, helpdesk staff are able to determine the sending application has not been updated to reflect recent application changes.
Use Case: In circumstances where a message is manipulated or modified by multiple systems, a repetition of this segment MAY be appended by each system.
Example:
MSH
[{ SFT }]
...
| Seq# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
|---|---|---|---|---|---|---|---|---|---|
SFT
|
|||||||||
1
|
Software Vendor Organization | XON | R | [1..1] | 01834 | ||||
|
2
|
Software Certified Version or Release Number | ST | R | [1..1] | 01835 | 15 | # | ||
|
3
|
Software Product Name | ST | R | [1..1] | 01836 | 20 | # | ||
|
4
|
Software Binary ID | ST | R | [1..1] | 01837 | 20 | # | ||
|
5
|
Software Product Information | TX | O | [0..1] | 01838 | ||||
6
|
Software Install Date | DTM | O | [0..1] | 01839 | ||||
Definition: Organization identification information for the software vendor that created this transaction. The purpose of this field, along with the remaining fields in this segment, is to provide a more complete picture of applications that are sending HL7 messages. The Software Vendor Organization field would allow the identification of the vendor who is responsible for maintaining the application.
Definition: Latest software version number of the sending system that has been compliance tested and accepted. Software Certified Version or Release Number helps to provide a complete picture of the application that is sending/receiving HL7 messages. Versions are important in identifying a specific 'release' of an application. In some situations, the receiving application validates the Software Certified Version or Release Number against a list of "certified" versions/releases of the particular software to determine if the sending application adheres to specific business rules required by the receiving application.
Alternatively, the software MAY perform different processing depending on the version of the sending software
Definition: The name of the software product that submitted the transaction. A key component in the identification of an application is its Software Product Name. This is a key piece of information in identifying an application.
Definition: Issued by a vendor for each unique software version instance to distinguish between like versions of the same software e.g., a checksum.
Software Binary Ids are issued for each unique software version instance. As such, this information helps to differentiate between differing versions of the same software. Identical Primary IDs indicate that the software is identical at the binary level (configuration settings mmightdiffer).
Definition: Software identification information that can be supplied by a software vendor with their transaction. Might include configuration settings, etc.
This field would contain any additional information an application provides with the transaction it has submitted. This information could be used for diagnostic purposes and provides greater flexibility in identifying a piece of software. Possibilities include setup or configuration parameter information.
This field SHOULD NOT be sent unless performing diagnostics.
Definition: Date the submitting software was installed at the sending site.
A Software Install Date on its own can often provide key information about the behavior of the application, and is necessary to provide a complete picture of the sending application.
®© HL7.org 2019+. HL7 v2+ generated on March 23, 2022
Links:
Version History
|
Propose a change
|
License
The Demo site for our new HL7 Version 2+ (plus) Standard
