Infinity Gateway Suite Protocol Handbook SW Vf9n Ifu 3703522 en
Infinity Gateway Suite Protocol Handbook SW Vf9n Ifu 3703522 en
General Information
Trademarks
Open-source software
Dräger devices that use software may use open-source software, depending on their setup. Open-source
software may be subject to different terms of license. Additional information regarding the open-source
software used in this device is available at the following web page:
www.draeger.com/opensource
The term "user group" describes the personnel responsible who have been assigned by the operating or-
ganization to perform a particular task on a product.
User groups
Clinical users
This user group operates the product in accordance with the intended use.
Users have medical specialist knowledge in the application of the product.
Service personnel
This user group installs the product and performs the service activities.
Service personnel have specialist knowledge in software systems and applications. Service personnel
also have experience in the servicing of medical devices.
Where product specific knowledge or tools are required, the service activities must be carried out by spe-
cialized service personnel. The specialized service personnel was trained by Dräger for these service ac-
tivities on this product.
Operating characteristics
Classification
Symbols
The following table lists the Infinity Gateway symbols. Additional information about the symbols is avail-
able on the following web page: www.draeger.com/md-symbols
Symbol Description
Read accompanying IFU for specific safety information.
Rx only Caution: Federal law restricts this device to sale by or on the order of a
physician
Manufacturer
Date of manufacture
Symbol Description
Complies with applicable EU regulations and directives
Quantity
Lot/batch number
Medical device
Importer
Importer
Revision index
Safety
Serious adverse events with this product must be reported to Dräger and the responsible authorities.
WARNING
Strictly follow these instructions for use. Any use of the software requires a full understanding
and strict observation of all portions of these instructions. The software is only to be used for the
purpose specified under "Intended use" on page 9 and in conjunction with appropriate patient
monitoring. Observe all WARNING and CAUTION statements as rendered throughout this
manual, and all statements on device labels.
Definitions
Certain paragraphs within these instructions are highlighted as WARNING, CAUTION or NOTE as follows:
WARNING
A WARNING statement provides important information about a potentially hazardous situation
which, if not avoided, could result in death or serious injury.
CAUTION
A CAUTION statement provides important information about a potentially hazardous situation which, if
not avoided, may result in minor or moderate injury to the user or patient or in damage to the equipment
or other property.
NOTE
A NOTE provides additional information intended to avoid inconvenience during operation.
Dräger provides patient monitoring, therapy, and IT products that may exchange information both with
each other and other non-Dräger devices in the clinical environment over information technology networks
(IT networks). Each data interface is an IT network in terms of the relevant communications standard (e.g.
printer interface, ISB interface, etc.).
Transmission of patient and device data across the IT network enables patient data and equipment data
to be monitored, stored, transferred, printed, or shared through the use of direct wired and wireless tech-
nologies, facilitating the following operations:
– Waveform and parameter data display
– Alarm notification
– Network recordings and printing
– Remote control (for example, alarm management)
– Patient archive data review (trends, events, charting information)
– Service access (device and component status data; log file access)
Connecting Dräger devices to a shared IT network with other devices, or subsequent changes to the
shared IT network, can lead to previously unidentified risks for patients, users, and third parties. These
risks must be identified, analyzed, evaluated, and controlled before placing the medical device into the IT
network. Before a device can be in service on the Infinity Network, a valid and unique IP address must be
entered.
Security recommendations
CAUTION
Dräger recommends that all documents opened for viewing from the hospital LAN are from a secure
source.
Intended purpose
Intended use
The Infinity Gateway software applications are intended to provide clinicians with the capability of viewing
patient data remotely via the Infinity network and for data exchange of select clinical and administrative
information between the Infinity network and the hospital network.
Indications
The Infinity Gateway software applications are intended to provide clinicians with the capability of viewing
patient data remotely via the Infinity network and for data exchange of select clinical and administrative
information between the Infinity network and the hospital network.
Contraindications
There are no known contraindications for the Infinity Gateway software applications.
Environments of use
The Infinity Gateway software applications are intended for use in a healthcare environment.
Patient population
The Infinity Gateway software applications are applicable to all patient populations.
Intended application
The intended application of the Infinity Gateway software applications is data exchange between the Infin-
ity network and the hospital network. This device is an active, reusable, and non-implantable medical
device. It does not come into direct contact with the patient’s body.
Table of Contents
General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Safety. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intended purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
HL7 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
PatientWatch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Preface
A customized version of the Protocol Handbook accompanies each copy of the Infinity Gateway server
software to convey the following:
High-level information about the software development capabilities of the server.
Information about interfacing the SERVER within a hospital environment using specific protocols.
Specific information with regards to data fields, values, and formats.
CAUTION
Updates to this information will be issued and packaged with each subsequent release of this product.
It is strongly recommended that you read the accompanying document each time you receive an
updated version of the software so that you will be aware of any changes in the product or the associated
documentation.
This document does not contain installation instructions. To install software or any of its optional
applications, or other related components, consult the Installation Guide and/or hard copy instructions
included with the installation media of the server.
Questions about the Protocol Handbook Documentation
If you have questions relating to this document, please contact your local field service representative.
The Infinity Gateway Server facilitates the exchange of important clinical information between the Infin-
ity/SDC protocol and your existing hospital and patient care systems. The Infinity Gateway Server is
designed to provide developers with maximum flexibility by using common healthcare protocols and data
format standards for managing communications between multiple disparate systems. Select one or more
Infinity Gateway Developer’s Tools and Interface Options to create a seamless flow of information tailored
to support your unique clinical work flow.
Infinity Gateway Developer’s Tools and Interface Options are licensed, or “unlocked”, by using option
passwords. An option password is the electronic proof of purchase for the appropriate Infinity Gateway
software. During the setup procedure, you will be asked for an option password, which will trigger the
“unlocking” of the appropriate Infinity Gateway Developer’s Tools and Interface Options.
WARNING
The Infinity Gateway Suite and Interface Options are information transfer technology. They are
intended to make information from the Infinity and SDC Networks available to third party
applications. The Gateway Suite and Interface Options are not intended as a replacement for the
primary alarm notification system and/or clinical decision making systems. The delivery of pages
cannot be guaranteed or verified.
CAUTION
The use of an anti-virus program is strongly recommended for the Infinity Gateway Server and all client
PCs. Dräger has tested compatibility of the Infinity Gateway Suite with Trend Micro Deep Security Agent.
Prior to installing any Microsoft Hot Fixes and Microsoft product Service Packs, please contact your local
Dräger Service Representative to ensure compatibility with Dräger IT products.
This setting on the Server specifies how to interpret the patient identifier entered on patient monitors.
This identifier is referred to throughout this document as the primary identifier. The alternate identifier
(i.e. whichever of these two is not configured as the primary) is never used by the patient monitor, but it
may be used by HL7 interfaces.
The Infinity Gateway File Access Developer’s Tool is a utility for accessing patient directory information
and monitoring data (parameters and alarms) from Infinity patient monitors and exporting that data in a
UTF-16 text format. The File Access Developer’s Tool does not support devices that are only on the SDC
Network.
The File Access Developer’s Tool creates the following data files:
"Patient Directory" on page 21 file containing a list of current patients, additional system demographic
data detailed in Section 4.1, and the corresponding "Vital Signs Files" on page 22 file name.
"Vital Signs Files" on page 22 file containing the latest parameter and alarm data.
The Patient Directory and Vital Signs files are UTF-16 files with variable size fields, and field delimiters
that allow simple methods of file navigation and parsing. The Infinity Gateway server setup program allows
you to specify the directory in which these files are created and the frequency at which they will be updated
(between 15 and 6,000 seconds).
Patient Directory
The Patient Directory file lists the patients whose information is currently being acquired by the Infinity
Gateway server.The Patient Directory will be updated dynamically whenever a change occurs in the Infin-
ity monitors. A typical Patient Directory is as follows:
##################################################################################
#
# Patient Directory (patient monitors currently being monitored by Infinity Gateway Vital Signs Server)
#
# Patient Directory Entry:
#
# Patient Name|Patient ID|Bed Label|Care Unit|File Name|IP Address|Multicast IP Address|Device
Type|Device Status
#
##################################################################################
Eugene Gray|502334|Bed01|CU2|00218100|191.1.2.181|224.0.2.181|SC9000B|Monitoring
Dennis Grunewald|250440|Bed01|CU3|00316500|191.1.3.165|224.0.3.165|SC9000|Monitoring
Cynthia Haber|520201|V3-8|V3|00309000|191.1.3.90|224.0.3.90|SC9000|Monitoring
Terrence Huxley|582822|TELAPOL|CU5|00515600|191.1.5.156|224.0.5.156|SC7000|Monitoring
Martin Inonu|522877|Bed01|CU1|00118300|191.1.1.183|224.0.1.183|SC7000|Monitoring
[End List]
Each Patient Directory file line contains the following information for each patient:
Field Description
Patient Name The patient name as it is entered on the Infinity monitor.
Patient ID The identifier as it is entered on the Infinity monitor.
Bed Label Identifies monitor or telemetry transmitter for the patient.
Care Unit Identifies care unit for the patient.
File Name Name of the Vital Signs file that contains monitoring data for patient.
IP Address IP Address of the Infinity monitor or Infinity CentralStation.
Multicast Address Multicast IP address on which patient data is broadcast. This address is
unique for a patient monitor or telemetry patients.
Device Type Model of source monitor.
Device Status Current status of the monitor: Monitoring, Standby, Discharged
NOTE
Future Infinity Gateway File Access Developer’s Option revisions may include additional information in
the Patient Directory file, which will always be added to the end of the record. The file format displays one
line per patient. The lines for individual patients contains nine data fields each separated by a delimiter,
or the “|” character. Lines beginning with a ‘#’ character are comment lines. The end of the Patient
Directory file is marked by an “[End List]” line.
The Vital Signs file is created for each patient listed in the Patient Directory file. Each Vital Signs file con-
tains the last reading of the parameter and alarm data for a patient. The Vital Signs file has three main
sections:
Patient Directory
Current Alarm
Patient Vital Signs
CVP|15|2009/11/18 20:20:06|06009|8591-0|19012|NONE|||mmHg|mm(hg)|3872|1
RA|15|2009/11/18 20:20:06|08009|8400-4|18996|SER|||mmHg|mm(hg)|3872|1
ART S|167|2009/11/18 20:20:06|03008|8480-6|18961|SER|||mmHg|mm(hg)|3872|1
ART D|69|2009/11/18 20:20:06|03007|8462-4|18962|NONE|||mmHg|mm(hg)|3872|1
ART M|106|2009/11/18 20:20:06|03009|8478-0|18963|NONE|||mmHg|mm(hg)|3872|1
mib MVe|0.3|2009/11/18 20:20:06|36039||20812|NONE|||L/min|L/min|3072|1
mib TVe|15|2009/11/18 20:20:06|36040|||NONE|||ml|mL|1714|1
mib RRv|20|2009/11/18 20:20:06|36006|9279-1|20514|NONE|||1/min|/min|2784|3
mib PIP|60|2009/11/18 20:20:06|36036||20885|NONE|||cmH2O|cm_h2O|3904|1
mib PEEP|0|2009/11/18 20:20:06|36037||20732|NONE|||cmH2O|cm_h2O|3904|1
mib MAP|20|2009/11/18 20:20:06|36038||20720|NONE|||cmH2O|cm_h2O|3904|1
iO2|35|2009/11/18 20:20:06|38044|3150-0|21124|NONE|||%|%|544|2[End Vital Signs]
The information on each line is separated into a number of fields by a delimited, or the “|” character, in
each of the three sections. Lines beginning with a ‘#’ character are comment lines. The end of the Vital
Signs file is marked by an “[End Vital Signs]” line.
NOTE
Calculated parameters and ventilator settings are now available from certain patient monitors, but are
only output by the patient monitor once per minute, so they will not appear in the output file immediately
on startup of the Gateway.
Patient Directory
The single line in this section contains the same information listed in the patient’s line in the Patient Direc-
tory file.
Current Alarm
The Current Alarm section contains a single line of a patient’s current alarm state and grade. In the event
there is an alarm, the alarm timestamp and alarm message will appear.
Field Description
State Current alarm state, representing the most serious alarm state across all param-
eters currently monitored for a patient. Possible values are listed in Appendix D:
Alarm States.
Grade Current alarm grade, representing the most serious alarm grade across all the
parameters currently being monitored for the patient. Possible values are listed
in Appendix E: Alarm Grades.
Message Text describing the alarm condition.
Timestamp Timestamp identifying when the alarm condition was detected, in the format:
YYYY/MM/DD HH:MM:SS.
The Patient Vital Signs section contains a series of parameter records listed below:
Fields Description
Label Infinity parameter label. Possible labels are listed in Appendix A: Parameters.
Value Infinity parameter value. Some parameters can take on non-numeric values.
Possible non-numeric parameter values are listed in Appendix C: Special Dis-
play Values.
Time Timestamp identifying when the parameter value was reported. The format for
the timestamp is YYYY/MM/DD HH:MM:SS.
Dräger Code Numeric code used to identify the parameter. Possible codes are listed in
Appendix A: Parameters.
HL7/LOINC Code Code used to identify the parameter in the HL7/LOINC standard. Possible
codes are listed in Appendix A: Parameters.
MIB/CEN Code Code used to identify the parameter in the MIB/CEN standard. Possible codes
are listed in Appendix A: Parameters.
Dräger Status Corresponds to the parameter’s alarm grade. Possible values are listed in
Appendix E: Alarm Grades.
HL7/LOINC Sta- Unused
tus
MIB/CEN Status Unused
Dräger Units Units of measure as defined on the INFINITY Network. Possible values are listed
in Appendix B: Units of Measure.
HL7/LOINC Units Units of measure as defined by the HL7/LOINC standard. Possible values are
listed in Appendix B: Units of Measure.
MIB/CEN Units Units of measure as defined by the MIB/CEN standard. Possible values are
listed in Appendix B: Units of Measure.
Instance Additional identifier used to distinguish parameters in the HL7/LOINC stan-
dard.
The WinAccess API Developer’s Tool provides access to an API (Application Programming Interface), a
powerful tool used to integrate data from the Infinity and SDC networks with custom applications. The
WinAccess API is designed for experienced developers with an understanding of API programming. This
section is intended to provide a high-level introduction to the use of the API only.
The WinAccess API is implemented as a Windows DLL (Dynamic Link Library), and makes the data
available through a set of functions callable from C or C++ programs. Access to the functionality is also
provided for non-Windows custom applications via a socket connection.
CAUTION
It is the responsibility of the customer to validate the functionality of any custom application developed
with WinAccess API Developer’s tool.
CAUTION
Custom applications that use WinAccess API should be developed such that all Gateway structures are
treated with 1-byte alignment.
CAUTION
Infinity Gateway supports filtering of alarms by alarm grade only. Filtering via other fields such as alarm
messages (strings) is not supported and must not be used.
A custom application can use the WinAccess API functions to obtain patient data from the Infinity Gateway
server. This application can request the WinAccess API to make a connection to a patient record. If the
connection is successful, the WinAccess API returns a connection ID that is unique on the Gateway server
for as long as the application is running and the connection is active. The application then uses this
connection ID to request other specific data for the patient, such as parameter values, alarm information,
waveform samples, trended data and demographic data. It can also use this connection ID to modify
demographic data at the monitor under certain limited circumstances.
CAUTION
Each connection should be used by only one thread.
The application can open multiple connections at once. Each Infinity or SDC connection counts as “client”
for purposes of controlling the number of simultaneous client connections at the Infinity Gateway server.
If a device is disconnected from the network (for example, during a “Pick and Go”, when the patient is
transported to another location), the connection ID for that patient will no longer be valid. The WinAccess
API does not provide asynchronous notification to the application that the connection has been lost. The
application should use the WinAccess API to check periodically with the Infinity Gateway server to test
which devices are still available.
In addition, the WinAccess API can also be configured to create 12-Lead Rest ECG output files for use by
a custom application. Please refer to Appendix H: 12-Lead ECG Output Format for more details.
NOTE
Further details about the functions, structures, and constants used in the DLL are not described this
document. However, extensive comments in the WvAPI.h file and the WvAPI.DLL file are provided.
These files can be found on the Infinity Gateway Server distribution CD, in the folder called “WinAccess
Option”.
CAUTION
Each version of the Infinity Gateway comes with a new version of the WvAPI DLL. Custom applications
accessing a given gateway must use a compatible version of the DLL to do so, and hence may need to
be re-compiled in order to support a new version of software.
As of VF5, WinAccess has built in the capability to access functionality via a socket connection. A new
service, InfExp, is now installed on the server. Whenever the “make available via TCP/IP” option is
enabled (only supports Infinity), this service listens to a well known port for a connection from the custom
application. It accepts messages from the custom application and translates that into a function call into
the WvAPI DLL. When the function call returns, a response message is sent back to the custom
application. By default, the Gateway server listens on port 9101 for this connection, but the port is
configurable in the “Configure WinAccess” dialog.
The InfExp service can also be configured to accept and send messages in different byte-orders. If the
“Byte swap” option is enabled (default), then the service will expect that all incoming messages be in the
Big Endian order and will output all messages using that order. If the “Byte swap” option is not enabled,
then the service will expect that all incoming messages be in the Little Endian order.
The InfExp service can only support devices on the Infinity network, it does not support any devices that
are only present on the SDC network.
NOTE
Big Endian byte order means that the high-order byte of the number is stored in memory at the lowest
address, and the low-order byte at the highest address. This byte order is used by Motorola processors
and is the natural byte order of any network.
Little Endian byte order means that the low-order byte of the number is stored in memory at the lowest
address. This byte order is used by Intel processors.
Software developer resources to facilitate the use of the WinAccess API are provided in the Infinity
Gateway Software Developer’s Kit (SDK).
The SDK includes:
API DLL (WvAPI.dll, WvAPI.h, and WvAPI.lib)
WvSvc.dll, IGAcsMsg.dll and Wvresources_**.dll (Strings for each language supported), - other dlls
used by the WvAPI.dll
WvAPITest, a test program that exercises all the functions in the WvAPI.dll
RemTst, a DLL that can be used for testing the socket interface.
Source code for the WvAPITest program and the RemTst DLL(these are complete Microsoft Visual
C++ projects).
The SDK can be found on Infinity Gateway Server distribution CD, in a folder called “WinAccess Option”.
CAUTION
As of VF6, WinAccess has been updated to support Unicode (UTF-16) strings, while still supporting
ANSI strings for backwards compatibility. The h-file is setup to export methods and structures in Unicode
format whenever the _UNICODE define is declared, and to export methods and structures in ANSI
format whenever the _UNICODE define is not declared.
When any of the remote configurations are built and run, instead of using the WvAPI.DLL directly, it uses
the RemTst.DLL. This DLL in turn translates the function calls into socket messages which it sends to the
InfExp service. This setup allows the user to test the socket interface of WinAccess. There is one caveat,
however, this setup will only work if run on the same PC that the InfExp service is running on. This is due
to the fact that the local host address is hardwired into the source code of RemTst, i.e. “127.0.0.1”.
By default, RemTst is configured to build a DLL which WILL swap bytes and which will use port 9101 to
communicate with InfExp. These settings correspond to the default settings for InfExp.
To change this behavior, follow these instructions:
1 Open the developer studio project for RemTst.
2 Select menu Project\settings.
3 Select the C/C++ tab.
4 Select the “General” category from the pick list.
5 In the preprocessor definitions box, note that there are two entries, as follows:
USE_PORT=9101
DO_SWAP=1
6 If you want the software to use a port other than 9101 to communicate with InfExp, change the 9101
to the port that you want to use.
7 If you want the software to NOT do byte swapping, i.e. send messages in Little Endian order, then
change the DO_SWAP value to 0.
8 After making the changes, rebuild the DLL.
NOTE
In order for the Remote versions of WvAPITest to work with the Infinity Export Server (InfExp), the settings
for USE_PORT and DO_SWAP in the RemTst DLL must match the settings on InfExp that are set in the
“Configure WinAccess” dialog of the Infinity Gateway Setup. Also, unless the customer manually changes
the IP address in the code, the Remote version of WvAPITest will only work properly when run on the
same PC that InfExp is running on.
Functions
NOTE
Unless otherwise specified all function calls are valid for Infinity and SDC devices.
Many of the above methods actually have 2 implementations: one that supports ANSI strings and one that
supports Unicode strings. For example, there are two WvListBeds methods supported in the DLL:
WvListBeds_W (supports wide characters or Unicode) and WvListBeds_A (supports single byte ANSI
characters). For compatibility, the definition of WvListBeds is actually mapped to one of those two
methods. The method that WvListBeds is mapped to is driven by whether or not the _UNICODE symbol
is defined or not, If it is defined then WvListBeds represents WvListBeds_W; if the _UNICODE symbol is
not defined, then WvListBeds is equivalent to WvListBeds_A.
The same is true with the structures that are defined in WvAPI.h. For example, WV_BED_LIST can
represent either the WV_BED_LIST_A structure or the WV_BED_LIST_W; again, the decision is made
strictly based on the presence or absence of the _UNICODE define.
Usage Guidelines
The following usage guidelines apply whether the interface is being used in ANSI or UNICODE mode.
The WvAPI DLL will not work properly if the instructions below are not followed.
NOTE
The interface file WvAPI.h, which is distributed in the WinAccess Option folder on the Infinity Gateway
CD, contains detailed usage guidelines for each method.
Call WvStart before calling any of the functions to WvAPI DLL. If not, the WV_NOT_INITIALIZED error
return code will appear.
Call WvStop before exiting from any application that uses WvAPI DLL. Not calling WvStop will cause
memory leaks by leaving a process resident in memory.
Track open connections to all applications using WvAPI DLL. There is no asynchronous notification
when a connection is lost, and the connection ID for that connection will no longer be valid.
All the API functions return WV_SUCCESS, if successful, or another return code if not successful.
The following is the correct calling sequence for using the DLL functions when retrieving
waveform, parameter, and trend data:
1 WvStart
2 WvListBeds (repeat periodically to get updated list)
3 Repeat for all the beds you are interested in:
WvConnect (if not already connected). At this point, a variety of functions can be performed:
To get alarm data: WvGetHighestGradeAlarm
To get Ventilator Alarm data: WvGetHighestGradeVentAlarm
To get parameter data: WvListParameters
Repeat for all the parameters you are interested in:
- WvDescribeParameter
- WvGetParameterValue
To get waveform data:
- WvListAvailableWaveforms
- WvSetFilter (set filter according to the waveforms needed)
- Repeat for all the waveforms you are interested in:
- WvDescribeWaveform
- WvGetWaveformSamples
The following is the correct calling sequence for using the DLL functions when connecting to a
bed to retrieve trends only:
1 WvStart
2 WvListBeds (repeat periodically to get updated list)
3 Repeat for all the beds you are interested in:
WvTrendConnect (if not already connected). At this point only the request for trends is available:
WVGetAvailableTrends (optional if not all trends are desired)
- For hour resolution trend Data: WvGetTrendData
- For minute resolution trend data: WvGetTrendMinData
4 WvDisconnect
Note: This should only be called once data no longer needs to be collected from a bedside monitor. It
is recommended that the connection remain open while collecting data continuously from a bedside.
5 WvStop
The WinAccess API Developer’s Tool can be utilized to create 12-Lead Rest ECG output files data from
the Infinity CentralStation to a custom application. The location of the file, called 12Lead.ekg, is user
configured. The 12Lead.ekg file format is defined in Appendix H: 12-Lead ECG Output Format.
HL7 Interfaces
In the following section “HL7 server” refers to the Infinity Gateway server on which the HL7 service is
installed.
All Infinity HL7 interfaces utilize HL7 Version 2.3, unless otherwise noted, implemented on TCP/IP
connection-oriented sockets, using MLLP as the lower layer message blocking protocol, although some
of the interfaces also accept other versions. All interfaces configured for Unicode also use an extension
of MLLP that uses double byte characters. Refer to the individual interface for more details.
For the purposes of this document, a message consists of an MSH (message segment header) followed
by one or more other segments, depending on the interface being implemented. Only one MSH segment
is contained in each message.
WARNING
The Gateway data access options are information transfer technology. They are intended to make
information from the network available to third party applications. The Gateway data access
options are not intended to be used for alarm monitoring functions.
WARNING
Risk from unauthorized SDC devices.
Other SDC devices in the same IT network can communicate with the device. Access by means
of unauthorized devices must be prevented.
Establish alternative options (e.g., MAC address filters).
WARNING
When data is used from devices that are not certified by Dräger, this data is considered to be for
informational purposes only. Do not use this data as the sole basis for diagnostic or therapeutic
decisions. Do not use this data for patient monitoring or device monitoring.
HL7 sockets
Two systems are always involved in an HL7 interface. One system is the master and initiates the
connection. The other system is the slave and accepts the connection. Each Infinity interface specifies
whether the Dräger HL7 Server will be the master or slave of the connection. Typically for unsolicited
interfaces, the master is the source of the data being transferred. For a solicited interface, the slave is the
source of the data.
A connection is opened by specifying the IP address of the Dräger HL7 Server and the port number for
which the interface is configured. There is no restriction on the port to be used. However, the port number
must be supported by the PC platform software and cannot be used by another application. Port 2150 is
reserved by the HL7 server for internal use and is not configurable. Whenever possible, the software
should be configured using the default port settings:
In all Infinity HL7 interfaces, the master sends a message to the slave. After acting upon the message, the
slave responds with an acknowledgment on the same socket. If the acknowledgment code used is AE,
the master resends the message, using the same message control ID for the message. If the message
control ID in the MSA segment of the acknowledgment message does not match the message control ID
of the sent message, the acknowledgment is not recognized as a valid response for that message.
Dräger HL7 interfaces can support either 8-bit characters from the ISO 8859-1 character set or 16-bit
characters from the Unicode (UTF-16) character set. On every supported HL7 interface, there is a setting
(called Messages are in Unicode) which is used to configure which character set to use on that interface.
By default, the character set for each interface is ISO 8859-1.
When the Messages are in Unicode setting is enabled, all messages received on the interface in question
are interpreted as double-byte Unicode UTF-16 strings, including the MLLP blocking characters. When
the setting is disabled, all messages received on the interface are interpreted as single-byte ISO 8859-1
character strings, including the MLLP blocking characters.
CAUTION
– Given the disparity of character length between these two character sets, it is imperative that both
sides of the interface be configured to use the same character set, otherwise, no communication will
ever be successfully established.
– On a Unicode interface, all characters are treated as double byte characters including the ones
defined in MLLP.
ISO 8859-1
The characters defined in this coding scheme consist of the (7-bit) ASCII character set as well as the
following character codes:
Unicode (UTF-16)
Although the Gateway supports the entire Unicode character set, the patient monitors only support the
characters that are relevant to the current language setting, so at a given site, the use of characters within
the Unicode set should be limited to those characters that apply to the language that is currently being
used at the patient monitors.
The Dräger implementation of HL7 includes an escape character definition required in every MSH
segment. Although the repeat character is recognized, the HL7 Server only uses the first instance of a
field or component, except where noted.
MLLP is a very simple protocol, consisting of a single character indicating the start of a message, and two
characters indicating the end of the message. A message is always started with the VT character, code
0x0B. A message is always ended with the ASCII FS character, code 0x1C, followed by a carriage return.
A carriage return character is also used to terminate a segment.
NOTE
Depending on whether the messages are in Unicode setting, each character may be either one (setting
off) or two (setting on) bytes in length.
Escape Sequences
Dräger HL7 interfaces support and implement the following escape sequences:
Database Usage
HL7 makes use of several database tables for different interfaces/features, as follows:
Interface/Feature Description Tables Consumer of
Data via HL7
Unsolicited ADT Patient demographic t_adt ICS and certain
data patient monitors
t_allergies
t_diagnosis
t_doctor
t_insurance
t_nok
t_picklist
Vitals Signs Patient parameter data *Refer to Parame-
ters Feature
t_acceptableunits
t_itemconversions
t_picklist
t_units
ADT configuration ADT mapping tables for t_Picklist Gateway
race, religion,
nationality, primary
language and ethnicity
HL7 Lab Import/ Parameter Priority and t_lab_group Gateway and
ASTM Lab Import Grouping patient monitors
t_lab_param
Calculator mapping
HL7 accesses the databases using ADO. These databases are stored in SQL Server 2017 Standard data-
bases, however SQL Server 2017 Express, SQL Server 2019 Express, and SQL Server 2019 Standard
are also supported.
Interface Customization
All of the Dräger interfaces allow customization by manipulating fields in incoming and outgoing
messages. For more details, please refer to the on-line help of the HL7Sim application.
The HL7/ASTM Interface Option enables the export of vital signs data in an unsolicited Observation
Results message (ORU).One ORU message is sent for each patient at a fixed configurable update rate.
If the “HL7 Vital Signs Interface - High Speed” locked option is enabled, the interval range is 5 - 6000
seconds. If the “HL7 Vital Signs Interface - Standard” locked option is enabled, the allowed interval range
is 60 - 6000 seconds.
Upon receipt of an ORU message, the receiving system should acknowledge receipt with an ACK
message. Refer to "Dräger HL7 Overview" on page 35 for details on HL7 interfaces.
For the Unsolicited Vital Signs Export interface, Dräger initiates the connection.
NOTE
The solicited and unsolicited Vitals Interfaces are mutually exclusive.
ORU messages follow the format below. The curved brackets ‘{and}’ indicate segments which may be
repeated.
Segments Description
MSH MSH Segment - Message Header
PID PID Segment - Patient Identification
PV1 PV1 Segment - Patient Visit
OBR OBR Segment - Observation Request
{OBX} OBX Segment - Observation/Result
See ACK – Acknowledgment for a description of the acknowledgment message expected from the
receiving application. If no acknowledgment is received within the Response Timeout configured in the
HL7 Vital Signs Interface Configuration screen, the message will be retransmitted up to Retry Count times.
NOTE
All items with an asterisk * are only sent out when the “ADT Data in Message” option is enabled for unso-
licited vitals, and data is found for the patient.Otherwise the fields are <not used>.
Patient Identifiers
Depending on the configuration of the primary identifier, the Patient ID field that appears in the Patient
Admit screen of Infinity patient monitors and at the Infinity CentralStation, is interpreted as either a Medical
Record number or a Patient Account number (i.e. visit number).
If the "ADT Data in Message" option is enabled and then a search of the ADT records will be performed
to find a record that contains the primary identifier. If the record is found and it contains a secondary ID
and/or the corresponding assigning authority then this information will be used in the message. Otherwise
the assigning authority and secondary ID fields will be blank. Field 3 and field 18 of the outgoing
message’s PID segment will be populated as follows:
Patient Name
Patient Name is in the format “Last^First^Middle”. For proper parsing, users of an Infinity patient monitor
should be instructed to enter the Patient Name in the “<Last>,<First> <Middle>” format. If no Patient Name
is entered on the Admit screen, this field will contain “UNKNOWN”.
NOTE
All items with an asterisk * are only sent out when the “ADT Data in Message” option is enabled for unso-
licited vitals and data is found for the patient. Otherwise the fields are <not used>.
Observation Identifier
Uniquely identifies the parameter being reported, in the format:
<identifier1^^local^<<identifier2>&<instance >>^^<coding system >
MIB/CEN codes are only sent when there is no LOINC code that denotes the parameter. Refer to
Appendix A: Parameters for a list of parameters available on the Infinity Network, including LOINC and
MIB/CEN codes.
Observation Value
The parameter value as reported by the device. The format of this field varies according to the Value Type
field.
ACK – Acknowledgment
See ORU - Unsolicited Observation Report for a description of the ORU message being acknowledged.
Acknowledgment Codes
Value Description
AA Original mode: Application Accept
AE Original mode: Application Error
AR Original mode: Application Reject
CA Enhanced mode: Commit Accept
CE Enhanced mode: Commit Error
CR Enhanced mode: Commit Reject
MSH|^~\&|Infinity||NUR||200212021207||ORU^R01|02110212073000458038|P|2.3
PID|||999-99-9999^AN||Smith^John^L|||||||||||||999-99-9999
PV1|||CU1^^BED1||||^^^|||||||||||||||||||||||||||||||||||||
OBR|||||||20021202120235
OBX||SN|STIII^^local^10123-8&1^^LOINC||=^0.01|mv^^ISO+|||||R|||20021202120235
OBX||SN|STaVR^^local^10120-4&1^^LOINC||=^0.01|mv^^ISO+|||||R|||20021202120235
OBX||SN|STaVF^^local^10118-8&1^^LOINC||=^0.01|mv^^ISO+|||||R|||20021202120235
OBX||SN|STaVL^^local^10119-6&1^^LOINC||=^0.01|mv^^ISO+|||||R|||20021202120235
OBX||SN|STV^^local^14692&1^^MIB/CEN||=^0.01|mv^^ISO+|||||R|||20021202120235
OBX||ST|PPR^^local^8893-0&1^^LOINC|| |mm(hg)^^ISO+|||||R|||20021202120235
OBX||SN|PA D^^local^8385-7&1^^LOINC||=^1.8|kpa^^ISO+|||||R|||20021202120235
OBX||SN|PA S^^local^8440-0&1^^LOINC||=^4.4|kpa^^ISO+|||||R|||20021202120235
OBX||SN|PA M^^local^8414-5&1^^LOINC||=^2.8|kpa^^ISO+|||||R|||20021202120235
OBX||ST|PWP^^local^8587-8&1^^LOINC|| |kpa^^ISO+|||||R|||20021202120235
OBX||SN|CVP^^local^8591-0&1^^LOINC||=^2.0|kpa^^ISO+|||||R|||20021202120235
OBX||SN|RA^^local^8400-4&1^^LOINC||=^2.0|kpa^^ISO+|||||R|||20021202120235
OBX||SN|EEG1 Med^^local^22912&1^^MIB/CEN||=^10.0|hz^^ISO+|||||R|||20021202120235
OBX||SN|EEG1 SEF^^local^22920&1^^MIB/CEN||=^12.5|hz^^ISO+|||||R|||20021202120235
OBX||SN|EEG1 BSR^^local^&1^^MIB/CEN||=^30|%^^ISO+|||||R|||20021202120235
OBX||SN|EEG1 Power^^local^22968&1^^MIB/CEN||=^67|dB^^ISO+|||||R|||20021202120235
OBX||SN|EEG1 Beta^^local^23000&1^^MIB/CEN||=^30|%^^ISO+|||||R|||20021202120235
OBX||SN|EEG1 Alpha^^local^22996&1^^MIB/CEN||=^20|%^^ISO+|||||R|||20021202120235
OBX||SN|EEG1 Theta^^local^23008&1^^MIB/CEN||=^25|%^^ISO+|||||R|||20021202120235
OBX||SN|EEG1 Delta^^local^23004&1^^MIB/CEN||=^25|%^^ISO+|||||R|||20021202120235
OBX||SN|etCO2*^^local^20824&2^^MIB/CEN||=^5.0|%^^ISO+|||||R|||20021202120235
OBX||SN|iCO2*^^local^20644&2^^MIB/CEN||=^0.0|%^^ISO+|||||R|||20021202120235
OBX||SN|RRc*^^local^9279-1&4^^LOINC||=^20|/min^^ISO+|||||R|||20021202120235
OBX||SN|etO2^^local^20844&2^^MIB/CEN||=^33|%^^ISO+|||||R|||20021202120235
OBX||SN|iO2^^local^3150-0&2^^LOINC||=^35|%^^ISO+|||||R|||20021202120235
OBX||SN|etN2O^^local^21036&2^^MIB/CEN||=^58|%^^ISO+|||||R|||20021202120235
OBX||SN|iN2O^^local^21120&2^^MIB/CEN||=^60|%^^ISO+|||||R|||20021202120235
OBX||SN|etHAL^^local^21020&2^^MIB/CEN||=^0.9|%^^ISO+|||||R|||20021202120235
OBX||SN|iHAL^^local^21104&2^^MIB/CEN||=^1.1|%^^ISO+|||||R|||20021202120235
OBX||SN|et ISO^^local^21028&2^^MIB/CEN||=^1.3|%^^ISO+|||||R|||20021202120235
OBX||SN|i ISO^^local^21112&2^^MIB/CEN||=^1.5|%^^ISO+|||||R|||20021202120235
OBX||SN|etENF^^local^21016&2^^MIB/CEN||=^1.8|%^^ISO+|||||R|||20021202120235
OBX||SN|iENF^^local^21100&2^^MIB/CEN||=^2.0|%^^ISO+|||||R|||20021202120235
OBX||SN|etSEV^^local^21024&2^^MIB/CEN||=^1.9|%^^ISO+|||||R|||20021202120235
OBX||ST|NBP S^^local^8508-4&1^^LOINC|| |kpa^^ISO+|||||R|||20021202120235
Sample Acknowledgment
MSH|^~\&|NUR||Infinity||200212021207||ACK^R01|99011716090716963683|P|2.3
MSA|AA|02110212073000458038|
The HL7/ASTM Interface Option enables the export of vital signs data in an unsolicited Observation
Results message (ORU) supporting HL7 version V2.6. The data is sent using IEEE nomenclature. Some
messages may not contain all data or too much data to be considered compliant with the IHE PCD DEC
profile. The interface can be configured to be IHE PCD DEC compliant. One ORU message is sent for
each patient at a fixed configurable update rate.
If the “HL7 Vital Signs Interface - High Speed” locked option is enabled, the interval range is 5 - 6000
seconds. If the “HL7 Vital Signs Interface - Standard” locked option is enabled, the interval range allowed
is 60 - 6000 seconds.
Upon receipt of an ORU message, the receiving system should acknowledge receipt with an ACK
message. Refer to Dräger HL7 Overview for details on HL7 interfaces.
For the Unsolicited Vital Signs Export interface, Dräger initiates the connection.
ORU messages follow the format below. The curved brackets ‘{‘ and ‘}’ indicate segments which may be
repeated.
Segments Description
MSH MSH Segment – Message Header
PID PID Segment - Patient Identification
PV1 PV1 Segment - Patient Visit
OBR OBR Segment - Observation Request
{OBX} OBX Segment - Observation/Result
See ACK – Acknowledgment for a description of the acknowledgment message expected from the
receiving application. If no acknowledgment is received within the Response Timeout configured in the
HL7 Vital Signs Interface Configuration screen, the message will be retransmitted up to Retry Count times.
HL7 Dräger
HL7
Seq
Item #
Description Req Type Len Contents Req Len
HL7 Dräger
HL7
Seq
Item #
Description Req Type Len Contents Req Len
NOTE
All items with an asterisk * are only sent out when the “ADT Data in Message” option is enabled for unso-
licited vitals, and data is found for the patient.Otherwise the fields are <not used>.
NOTE
All items with an asterisk * are only sent out when the “ADT Data in Message" option is enabled, and
data is found for the patient. Otherwise the fields are <not used>.
Observation Value
The parameter value as reported by the device. The format of this field varies according to the Value Type
field.
ACK - Acknowledgment
After receipt of an ORU message, the HL7 server will send an acknowledgment:
Segment Description
MSH MSH Segment – Message Header
MSA MSA Segment – Message Acknowledgment
See ORU - Unsolicited Observation Report for a description of the ORU message being acknowledged.
Acknowledgment Codes
Value Description
AA Original mode: Application Accept
AE Original mode: Application Error
AR Original mode: Application Reject
CA Enhanced mode: Commit Accept
CE Enhanced mode: Commit Error
CR Enhanced mode: Commit Reject
OBX|10|NM|131902^MDC_ECG_AMPL_ST_AVR^MDC^STaVR^^local|2.1.1.131902001|0.0|266418^M
DC_DIM_MILLI_-
VOLT^MDC^mv^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://www.draeger.com/^DNS
OBX|11|NM|131903^MDC_ECG_AMPL_ST_AVL^MDC^STaVL^^local|2.1.1.131903001|0.0|266418^MD
C_DIM_MILLI_VOLT^MDC^mv^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://www.drae-
ger.com/^DNS
OBX|12|NM|131904^MDC_ECG_AMPL_ST_AVF^MDC^STaVF^^local|2.1.1.131904001|0.0|266418^M
DC_DIM_MILLI_-
VOLT^MDC^mv^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://www.draeger.com/^DNS
OBX|13|NM|192805^MDC_ECG_AMPL_ST_CVM^MDC^STCVM^^local|2.1.1.192805001|0.0|266418^
MDC_DIM_MILLI_-
VOLT^MDC^mv^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://www.draeger.com/^DNS
OBX|14|NM|192806^MDC_ECG_AMPL_ST_VM^MDC^STVM^^local|2.1.1.192806001|0.0|266418^MD
C_DIM_MILLI_VOLT^MDC^mv^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://www.drae-
ger.com/^DNS
OBX|15|NM|147842^MDC_ECG_CARD_BEAT_RATE^MDC^HR^^local|2.1.2.147842001|86.0|264864^
MDC_DIM_BEAT_PER_MIN^MDC^/min^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://w
ww.draeger.com/^DNS
OBX|16|NM|148066^MDC_ECG_V_P_C_RATE^MDC^PVC/min^^local|2.1.2.148066001|0.0|264864^M
DC_DIM_BEAT_PER_MIN^MDC^/min^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://www
.draeger.com/^DNS
OBX|17|ST|148496^MDC_ECG_ARRHY^MDC^ARR^^local|2.1.2.148496001|
|262656^MDC_DIM_DIM-
LESS^MDC^^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://www.draeger.com/^DNS
OBX|18|NM|149530^MDC_PULS_OXIM_PULS_RATE^MDC^PLS^^local|2.13.1.149530001|86.0|26486
4^MDC_DIM_BEAT_PER_MIN^MDC^/min^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://
www.draeger.com/^DNS
OBX|19|NM|150456^MDC_PULS_OXIM_SAT_O2^MDC^SpO2^^local|2.13.1.150456001|97.0|262688^
MDC_DIM_PERCENT^MDC^%^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://www.drae-
ger.com/^DNS
OBX|20|NM|150488^MDC_BLD_PERF_INDEX^MDC^PI^^local|2.13.1.150488001|3.52|262688^MDC_
DIM_PERCENT^MDC^%^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://www.drae-
ger.com/^DNS
OBX|21|ST|150301^MDC_PRESS_CUFF_SYS^MDC^NBP S^^local|2.16.1.150301001|
|266016^MDC_DIM_MMHG^MDC^mm(hg)^^ISO+|||||R|||20180923145607||||0060E9EEBC^IACS^http://
www.draeger.com/^DNS
OBX|22|ST|150302^MDC_PRESS_CUFF_DIA^MDC^NBP D^^local|2.16.1.150302001|
|266016^MDC_DIM_MMHG^MDC^mm(hg)^^ISO+|||||R|||20180923145607||||0060E9EEBC^IACS^http://
www.draeger.com/^DNS
OBX|23|ST|150303^MDC_PRESS_CUFF_MEAN^MDC^NBP M^^local|2.16.1.150303001|
|266016^MDC_DIM_MMHG^MDC^mm(hg)^^ISO+|||||R|||20180923145607||||0060E9EEBC^IACS^http://
www.draeger.com/^DNS
OBX|24|ST|159764^MDC_CONC_HB_ART^MDC^Hgb^^local|2.31.1.159764001|
|264256^MDC_DIM_G_PER_DL^MDC^g/dL^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http:
//www.draeger.com/^DNS
OBX|25|ST|160064^MDC_CONC_PCO2_GEN^MDC^PCO2^^local|2.31.1.160064001|
|266016^MDC_DIM_MMHG^MDC^mm(hg)^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://
www.draeger.com/^DNS
OBX|26|ST|160116^MDC_CONC_PO2_GEN^MDC^PO2^^local|2.31.1.160116001|
|266016^MDC_DIM_MMHG^MDC^mm(hg)^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://
www.draeger.com/^DNS
OBX|27|ST|160132^MDC_CONC_HCT_GEN^MDC^Hct^^local|2.31.1.160132001|
|262688^MDC_DIM_PER-
CENT^MDC^%^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://www.draeger.com/^DNS
OBX|28|NM|192557^MDC_NMT_TEMP^MDC^NMT-
Temp^^local|2.32.1.192557001|20.0|268192^MDC_DIM_DEGC^MDC^cel^^ISO+|||||R|||2018092615043
7||||0060E9EEBC^IACS^http://www.draeger.com/^DNS
OBX|29|ST|192605^MDC_NMT_TOF_RATIO^MDC^TOF-Ratio^^local|2.32.1.192605001|
|262688^MDC_DIM_PER-
CENT^MDC^%^^ISO+|||||R|||20180923145607||||0060E9EEBC^IACS^http://www.draeger.com/^DNS
OBX|30|NM|160280^MDC_PULS_OXIM_CONC_HB_O2_ART_CALC^MDC^SpOC^^local|2.39.1.16028
0001|33.0|268562^MDC_DIM_-
MILLI_L_PER_DL^MDC^mL/dL^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://www.drae-
ger.com/^DNS
OBX|31|NM|160284^MDC_PULS_OXIM_HB_CO_ART^MDC^SpCO^^local|2.39.1.160284001|2.0|2626
88^MDC_DIM_PER-
CENT^MDC^%^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://www.draeger.com/^DNS
OBX|32|NM|160288^MDC_PULS_OXIM_HB_MET_ART^MDC^SpMet^^local|2.39.1.160288001|0.7|262
688^MDC_DIM_PER-
CENT^MDC^%^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://www.draeger.com/^DNS
OBX|33|NM|192790^MDC_PULS_OXIM_PVI^MDC^PVI^^local|2.39.1.192790001|1.0|262688^MDC_DI
M_PERCENT^MDC^%^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://www.drae-
ger.com/^DNS
OBX|34|NM|149530^MDC_PULS_OXIM_PULS_RATE^MDC^PLS*^^local|2.41.1.149530001|50.0|2648
64^MDC_DIM_BEAT_PER_MIN^MDC^/min^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http:/
/www.draeger.com/^DNS
OBX|35|NM|150456^MDC_PULS_OXIM_SAT_O2^MDC^SpO2*^^local|2.41.1.150456001|96.0|262688^
MDC_DIM_PERCENT^MDC^%^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://www.drae-
ger.com/^DNS
OBX|36|NM|150468^MDC_PULS_OXIM_SAT_O2_DIFF^MDC^Delta^^local|2.41.1.150468001|1.0|2626
88^MDC_DIM_PER-
CENT^MDC^%^^ISO+|||||R|||20180926150437||||0060E9EEBC^IACS^http://www.draeger.com/^DNS
Sample Acknowledgment
MSH|^~\&|NUR||Infinity|MEDAT-18|20180926150437||ACK^R01|99011716090716963683|P|2.3
MSA|AA|18092615043700515606|[999-99-9999]Message Delivered
The HL7/ASTM Interface Option for exporting solicited vital signs supports external system requests of
vital signs data from the Infinity and SDC Networks. This option is available only on an Infinity Gateway
server. The request is made in a QRY message. A message can be used to request data from one or
multiple patients. Patients are specified by their location within the Infinity and SDC Networks by a
combination of care unit label and bed label. Upon receipt of this message, the Infinity Gateway server
exports all vital signs data received from the specified patient monitor(s), in an ORF message.
Discrete parameters vital signs, such as non-invasive blood pressure, are sent repeatedly by the device,
even when no new measurement has been taken. By default, these vital signs parameters will
continuously be output to the requesting system. The requesting system can determine whether a vital
signs parameter measurement represents a new measurement by examining the associated timestamp.
An option does exist to filter the repeated output of these discrete parameters vital signs. If this filter is
enabled, the interface will output these parameter measurements only once, however, if the system is
restarted, the parameter vital sign may be transmitted once more.
See Dräger HL7 Overview for details on how Dräger implements HL7 interfaces.
For the Solicited Vital Signs Export interface, the external system (the Clinical Information System or CIS)
initiates the connection.
See ORF – Observational Report for a description of the response message sent by the Infinity Gateway
server.
Seqment Description
MSH MSH Segment - Message Header
MSA MSA Segment - Message Acknowledgment
QRD Acknowledgment Codes
QRF QRF Segment – Query Filter
PID PID Segment - Patient Identification
PV1 PV1 Segment - Patient Visit
OBR OBR Segment - Observation Request
{[OBX]} OBX Segment - Observation/Result
Acknowledgment Codes
Value Description
AA Original mode: Application Accept
Enhanced mode: Application acknowledgment: Accept
AE Original mode: Application Error
Enhanced mode: Application acknowledgment: Error
AR Original mode: Application Reject
Enhanced mode: Application acknowledgment: Reject
The QRD segment in the request (refer to Acknowledgment Codes) is echoed back to the requestor.
Patient Identifiers
Depending on the on the configuration of the primary identifier, the Patient ID field that appears in the
Patient Admit screen of Infinity patient monitors and at the Infinity Central Station, is interpreted as either
a Medical Record number or a Patient Account number (i.e. visit number).
Patient Name
Patient Name entered in the Admit screen of the device in the format “Last^First^Middle”. For proper pars-
ing, users of the device should be instructed to enter the Patient Name in the “<Last>,<First> <Middle>”
format. If no Patient Name is entered on the Admit screen, this field will contain “UNKNOWN”.
HL7 Dräger
Seq Item # Description Req Type Len Contents Req Len
HL7 Dräger
Seq Item # Description Req Type Len Contents Req Len
HL7 Dräger
Seq Item # Description Req Type Len Contents Req Len
Observation Identifier
Uniquely identifies the parameter being reported, in the format:
<identifier1^^local^<<identifier2>&<instance >>^^<coding system >
MIB/CEN codes are only sent when there is no LOINC code that denotes the parameter. Refer to
Appendix A: Parameters for a list of parameters available on the Infinity Network, including LOINC and
MIB/CEN codes.
Observation Value
The parameter value as reported by the Infinity Network. The format of this field varies according to the
Value Type field.
Value Type Observation Value Field Format Comments
ST <value> See Appendix C: Special Dis-
play Values for special value
strings.
SN <comparator>^<value> comparator is “=”
Sample
QRY Messages
MSH|^~\&|Infinity||HIS||199903221322||QRY^R02|99022213222303883455|P|2.3
QRD|19990322160000|R|I|9999999999|||||RES
QRF|MONITOR||||CU50^^Bed2
ORF Message
SH|^~\&|Infinity||Infinity||20170424084700||ORF^R04|17042408470029637450|P|2.3|||AL|NE
MSA|AA|17042408470000053922|[CU50,Bed2]Bed found
QRD|19990322160000|R|I|9999999999|||||RES
QRF|MONITOR||||CU50^^Bed2
PID|||8888^^^^AN||Data^Simulated^Patient|||||||||||||8888
PV1|||CU50^^Bed2
OBR|||||||20170425185117
OBX||SN|HR^^local^8867-4&1^^LOINC||=^84|/min^^ISO+|||||R|||20170425185116
OBX||SN|%PACED^^local^ &1^^LOINC||=^0|%^^ISO+|||||R|||20170425185116
OBX||ST|ARR^^local^ &1^^LOINC|| |^^ISO+|||||R|||20170425185116
OBX||SN|PVC/min^^local^ &1^^LOINC||=^0|/min^^ISO+|||||R|||20170425185116
OBX||SN|STI^^local^10121-2&1^^LOINC||=^0.2|mm^^ISO+|||||R|||20170425185116
OBX||SN|STII^^local^10122-0&1^^LOINC||=^0.3|mm^^ISO+|||||R|||20170425185116
OBX||SN|STIII^^local^10123-8&1^^LOINC||=^0.2|mm^^ISO+|||||R|||20170425185116
The unsolicited ADT interface accepts ADT messages from the transmitting system and maintains a
database of patient admission information. Data imported through this interface is used on Infinity patient
monitors by request. Admission data is requested directly from some models of Dräger patient monitors
or from an Infinity Central Station (ICS) during a patient admission.
The Dräger HL7 server acknowledges the receipt of these messages with an ACK message to the sending
system. When ADT data requests for a particular patient, based on primary identifier, are made from the
Infinity Network, the latest data for that patient is sent to the requesting device.
When data is requested from a Infinity Central Station or a Dräger patient monitor, the Patient ID in the
request is interpreted according to the Interpret Patient ID as setting on the HL7 server. Available values
for this setting are MRN or Patient Account number.
The lower layer protocol used for this interface is Minimal Lower Layer Protocol (MLLP). See Dräger HL7
Overview for details on how Dräger implements HL7 interfaces.
NOTE
The solicited and unsolicited ADT Interfaces are mutually exclusive.
For the Unsolicited ADT interface, the external system (the hospital information system or HIS) initiates
the connection.
NOTE
The Unsolicited ADT interface has been validated with up to 60 transactions per minute and a total of
100,000 patient records.
The following table indicates the data imported, the HL7 segment from which it is extracted, and the screen
where it appears on the destination Infinity monitor or Infinity Central Station (ICS).
100 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Unsolicited ADT Import
ADT data received from the hospital information system (HIS) is stored in a database on the Dräger HL7
SERVER. When a request for data is received from an Infinity device, a database lookup is done based
on information provided by the requesting device. The Patient ID received from the requesting device is
interpreted according to the Interpret Patient ID as setting on the HL7 server.
This Bedside Auto Update option to Unsolicited ADT causes demographic data changes received by the
HL7 server to be forwarded to a patient monitor where the corresponding patient has already been
admitted, if applicable.
This feature is intended only to solve the following problem:
1 The nurse admits a patient to a patient monitor using the “Get From HIS” button on the Infinity Central
Station.
2 Someone at the admissions system notices an error in the demographic data for the patient and
corrects it.
3 The admissions systems automatically sends an update to the HL7 server.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 101
Unsolicited ADT Import
In this situation, if the ADT Auto Update option is not enabled, the patient monitor will never be updated
with the correction unless the nurse manually requests the data from the Admissions System again by
pressing the “Get From HIS” button at the Infinity Central Station.
With this feature enabled, all changes (a patient record must already exist at the HL7 server) received
from the HIS, excluding height and weight, that are normally sent to the patient monitor when the “Get
From HIS” button is pushed, will automatically be sent to the patient monitor where the patient is admitted.
Note that if the primary identifier is entered at more than one patient monitor, the changes will not be sent
to any patient monitor. In the event of a merge where the patient identifier has changes the patient
identifier will be updated at the patient monitor.
Configuration
The unsolicited ADT interface allows the user to define which Event Types the interface will accept, and
the actions to be taken for each configured event. Any Event Type that has not been configured will be
acknowledged, but no action will be taken.
The following table outlines the Event Types and associated actions constituting the default configuration
for the Unsolicited ADT interface.
Admit
If an ADT record exists in the database that corresponds to the Patient Account Number field of the PID
segment of the incoming message, then that record is deleted, and a new record is created.
102 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Unsolicited ADT Import
Discharge
If an ADT record exists in the database for the Patient Account Number in the PID segment, it will be
deleted.
Cancel Discharge
If a discharged patient record exists in the database, mark the patient as admitted and then update the
record with changes from the incoming message.
Change
If an ADT record exists in the database that corresponds to the Patient Account Number field of the PID
segment of the incoming message, then the fields of that record are changed with any relevant data in the
incoming message. This action, however, will never modify the Patient Account Number of the patient. If
no record exists, no action is taken.
If Bedside Auto Update is enabled, the changes (excluding height and weight) will be sent to the patient
monitor where the patient is admitted, if only one exists.
Update
This action is identical to a CHANGE action, however, if the ADT record does not already exist, a new
record will be created.
If Bedside Auto Update is enabled and the ADT record already existed for this patient on the HL7 Server,
then the changes (excluding height and weight) will be sent to the patient monitor where the patient is
admitted, if only one exists.
Merge
If an ADT record exists in the database corresponding to the new identifiers, it will be deleted. If an ADT
record exists in the database corresponding to the “prior” identifiers, that record will be updated with the
new identifiers and data.
If Bedside Auto Update is enabled, and one and only patient monitor exists that contains an identifier that
corresponds to the contents of the old record, then any changes applicable to the monitor, excluding
height and weight, between the old record and the newly modified record are sent to the patient monitor.
Ignore
This action is a do nothing action. The incoming message will be acknowledged, but there will be no effect
whatsoever to the database, patient monitors, or ICS.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 103
Unsolicited ADT Import
ADT messages formats are indicated below. Square brackets, ‘[‘ and ‘]’, indicate optional segments.
Curved brackets, ‘{‘ and ‘}’, indicate segments which may be repeated.
Segment Description
MSH MSH Segment - Message Header
[EVN] EVN Segment - Event Type
PID PID Segment - Patient Identification
{[AL1]} AL1 Segment - Patient Allergy
{[IN1]} IN1 Segment – Patient Insurance
{[DG1]} DG1 Segment – Patient Diagnosis
[NK1] NK1 Segment - Next of Kin
[PV1] PV1 Segment - Patient Visit
[MRG] MRG Segment - Merge Patient Information
{[OBX]} OBX Segment - Observation/Result
104 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Unsolicited ADT Import
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 105
Unsolicited ADT Import
106 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Unsolicited ADT Import
Event Occurred
The date and time that the ADT event took place, in the format:
YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 107
Unsolicited ADT Import
108 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Unsolicited ADT Import
Religion
This field contains a code, up to 10 characters long, that indicates the religion of the patient. Refer to
ADTConfig for the default configuration of this field.
Patient Identifier
Depending on the HL7 configuration screen, the Patient ID field that appears in the Patient Admit screen
of the device is interpreted as either a Medical Record number, retrieved from PID segment Seq#3, or a
Patient Account number (i.e. visit number), retrieved from Seq#18 of the PID segment.
The format of either field is:
<ID>^<check digit>^<check digit scheme>^<assigning authority>^<identifier type>^<assigning facility>
The ID component and assigning authority are used for the MRN (seq#3), but only the ID component is
used in the Patient Account number (seq#18).
NOTE
Draeger device can support only an ID of up to 12 characters long.
The Assigning Authority component can only be up to 10 characters long.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 109
Unsolicited ADT Import
Patient Name
Contains the patient name to be entered in the Admit screen of the device upon the request of the ADT
data. The format is:
<Last>^<First>^<Middle>
When the device requests ADT data, the Patient Name will appear in the following format on the Patient
Admit screen: <Last Name>,<First Name> <Middle Initial/Name>
with a comma between the last and first name, and a single space between the first and middle names.
The name is truncated to 26 characters. If this field contains the string “UNKNOWN”, a blank will appear
on the Admit screen for this patient.
Date/Time of Birth
The format is:
YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]
The date portion of this field will be entered in the Birth Date field of the Patient Admit Screen on the device
when ADT data is requested.
Sex
Contains a single character denoting the sex of the patient. The results of this field will be entered in the
Sex field of the ECG Report Setup Screen, if one exists, when requested during Admit by the device.
In Field On Device
F Female
M Male
All other Unknown
Race
Contains a string denoting the race of the patient. On the device the results of this field will be entered in
the Race field of the ECG Report Setup Screen, if one exists, when requested during Admit. When a
message is received from the HIS, the HIS code is compared to the list of acceptable values, and then
translated into an internal Infinity numeric code, which is then used to communicate with all of the devices.
Infinity codes 1-7 have a fixed interpretation on the device. The HIS codes, however can be configured.
Additional entries may also be added; however, any new entries will be reflected on the Infinity patient
monitors as “Unknown”. The utility used to configure these entries is ADTConfig.exe.
In Field Infinity On Device
(HIS code) Code
2106-3 2 Caucasian
2028-9 3 Asian
2054-5 4 Black or African
American
110 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Unsolicited ADT Import
Patient Address
This field contains the mailing address of the patient. Although HL7 supports repetition of this field, Dräger
does not, and only the first instance with address type of M (mailing) will be used. If no address is marked
as mailing, and there is an address that is unmarked for type, then it will be used.
<street1>^<street2>^<city>^<state/province>^<postal code>^<country>^<address type>
The component lengths supported are as follows:
Component Max Length
street1 40
street2 40
city 25
state/province 25
postal code 10
country 15
address type 1
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 111
Unsolicited ADT Import
Marital Status
The following table denotes the acceptable HIS codes that can be accepted along with their associated
meaning. Unlike many of the other codes accepted on this interface, this list is not configurable.
In Field On Device
A Separated
B Unmarried
C Common law
D Divorced
E Legally Separated
G Living together
I Interlocutory
M Married
N Annulled
O Other
P Domestic partner
R Registered
domestic partner
S Single
T Unreported
W Widowed
All Other Unknown
Ethnic Group
This field contains a code, up to 4 characters long, that indicates the patient’s ethnic group. The default
configuration is detailed in the table below.
HIS Code Ethnic Group
H Hispanic or Latino
N Not Hispanic or Latino
All other Unknown
112 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Unsolicited ADT Import
Nationality
This field contains a code, up to 4 characters long, that indicates the nationality of the patient. Refer to
ADTConfig for the default configuration of this field.
NOTE
All allergies must be included in every message, otherwise the associated allergy that is not included will
be deleted from the patient record.
Allergy Types
The following table lists the allergy types accepted by HL7:
Code Description
DA Drug Allergy
FA Food Allergy
MA Miscellaneous Allergy
MC Miscellaneous Contraindication
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 113
Unsolicited ADT Import
Allergies
This field has the format <Allergy Code>^<Allergy Description>
The Allergy Code portion of this field must match the HIS code from the pre-configured list of available
Allergy codes. The Allergy code is limited to 4 characters.
The Allergy Description portion of this field is optional and is limited to 40 characters. If the description is
provided, it supersedes the description provided in the default allergy table.
NOTE
All IN1 segments must be included in every message, otherwise the associated insurance information
that is not included will be deleted from the patient record.
114 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Unsolicited ADT Import
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 115
Unsolicited ADT Import
116 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Unsolicited ADT Import
Address
Repetition is not supported for this field, and only the first instance will be used.
<street1>^<street2>^<city>^<state/province>^<postal code>^<country>
The component lengths supported are as follows:
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 117
Unsolicited ADT Import
Name of Insured
Contains the name of the primary insured person, The format is:
<Last Name>^<First Name>^<Middle name>
The maximum component lengths are as follows. If a component exceeds the maximum length, it will be
truncated.
NOTE
All DG1 segments must be included in every message, otherwise the associated diagnosis information
that is not included will be deleted from the patient record.
Diagnosis
This field is of the format:
<ID>^<Text>
Where
ID - contains the code that identifies the diagnosis (up to 8 characters)
Text - description of the diagnosis (up to 42 characters)
Name
Contains the name of the next of kin/associated party. The format is: <Last Name>^<First Name>
The maximum component lengths are as follows. If a component exceeds the maximum length, it is
truncated.
Component Max Length
Last 30
First 20
118 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Unsolicited ADT Import
Address
This field contains the mailing address of the next of kin/associated party. Although HL7 supports
repetition of this field, Dräger does not, and only the first instance is used.
<street1>^<street2>^<city>^<state/province>^<postal code>^<country>
The component lengths supported are as follows:
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 119
Unsolicited ADT Import
120 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Unsolicited ADT Import
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 121
Unsolicited ADT Import
122 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Unsolicited ADT Import
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 123
Unsolicited ADT Import
124 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Unsolicited ADT Import
Patient Location
This field contains the location of the patient. It is in the format:
<Care Unit>^<Room>^<Bed>
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 125
Unsolicited ADT Import
Attending Doctor
Contains the attending physician information in the format:
<not used>^<last>^<first>^<middle>^<suffix>^<prefix>^<degree>
The data from this field will appear in the Physician field of the Patient Admit Screen of the device if ADT
data is requested for the device. In this instance, the format will be:
<last>,<first> <middle>
With a comma between the last and first name, and a single space between the first and middle names.
The name is truncated to 12 characters.
Admitting Doctor
Contains the admitting physician information in the format:
<not used>^<last>^<first>^<middle>^<suffix>^<prefix>^<degree>
Refer to Attending Doctor for details on field lengths and display formats.
Consulting Doctor
Contains the consulting physician information in the format:
<not used>^<last>^<first>^<middle>^<suffix>^<prefix>^<degree>
Refer to Attending Doctor for details on field lengths and display formats.
Referring Doctor
Contains the referring physician information in the format:
<not used>^<last>^<first>^<middle>^<suffix>^<prefix>^<degree>
Refer to Attending Doctor for details on field lengths and display formats.
Admit Date/Time
Contains the admission date in the format:
YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]
The date portion of this field will be entered in the Admit Date field of the Patient Admit screen on the
device.
126 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Unsolicited ADT Import
Discharge Date
Contains the date that the patient was discharged. It is in the format:
YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 127
Unsolicited ADT Import
Prior Internal ID
If this MRG segment is contained in a message type (based on event type) that is configured for the Merge
action, and the first component of this field is populated, it is interpreted as a request to change the MRN
(Medical Record number) of the patient from the contents of this field to that contained in the Internal ID
field of the PID segment.
If this segment is contained in a message type (based on event type) that is not configured for the “Merge”
action, then this field is ignored.
128 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Unsolicited ADT Import
HL7 Dräger
HL7
Seq
Item #
Description Req Type Len Contents Req Len
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 129
Unsolicited ADT Import
Observation Identifier
Uniquely identifies the parameter being reported, in the format:
<identifier1 >^<description>^<coding system>^<identifier2>^<description>^<coding system >
identifier1 label for the parameter
description parameter description
identifier2 an alternate label for the parameter
coding system name of the coding system
The ADT Interface supports only “height” and “weight” for the identifier1 component. Other identifiers are
not used.
Units
Uniquely identifies the units in which the parameter is being reported, in the format:
<identifier1 >^<description>^<coding system>^<identifier2>^<description>^<coding system >
identifier1 unit identifier
description unit description
identifier2 an alternate label for the unit
coding system name of the coding system
The ADT interface uses the primary identifier, identifier1, and only supports the “iso+” coding system. All
other components are not used. ASA does not have any units. The following units are supported for patient
height and weight:
Supported Height Units Supported Weight Units
Unit Description Unit Description
cm centimeters kg kilograms
m meters g grams
in inches lb pounds
ft feet oz ounces
ACK – Acknowledgment
After reception of an ADT message, an acknowledgment of the following form will be sent:
Segment Description
MSH MSH Segment - Message Header
MSA MSA Segment - Message Acknowledgment
See ADT – Admit, Discharge, and Transfer for a description of the ADT message being acknowledged.
130 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Unsolicited ADT Import
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 131
Unsolicited ADT Import
132 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Unsolicited ADT Import
Acknowledgment Codes
Value Description
AA Original mode: Application Accept
Enhanced mode: Application acknowledgment: Accept
AE Original mode: Application Error
Enhanced mode: Application acknowledgment: Error
AR Original mode: Application Reject
Enhanced mode: Application acknowledgment: Reject
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 133
Unsolicited ADT Import
ADT Message
MSH|^~\&|HIS||Infinity||199903291650||ADT|99022916500500050122|P|2.3
EVN|A01
PID|||222-22-2222||Smith^Jane||1990062659|F||A|||||||B|2002
PV1|||CCU1^201^B||||^Dixon^Glen|||||||||||||||||||||||||||||||||||||20001130
OBX||NM|height^^^^^||68|in^^ISO+|||||R|||20001126
OBX||SN|weight^^^^^||=^135|lb^^ISO+|||||R|||20001126
ACK Message
MSH|^~\&|Infinity||HIS||200105011304||ACK^R01|01040113043900414846|P|2.3
MSA|AA|99022916500500050122|[2002]ADT: Admit successful.
134 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
IHE Unsolicited ADT
The IHE unsolicited ADT interface accepts ADT messages from the transmitting system and maintains a
database of patient admission information. Data imported through this interface is used on devices by
request. Admission data is requested directly from some models of Dräger patient monitors or from an
Infinity Central Station (ICS) during a patient admission.
The Dräger HL7 server acknowledges the receipt of these messages with an ACK message to the sending
system. When ADT data requests for a particular patient, based on patient identifier, are made from the
Infinity Network, the latest data for that patient is sent to the requesting device.
When data is requested from a Infinity Central Station or a Dräger patient monitor, the patient identifier in
the request is interpreted according to the Interpret Patient ID as setting on the HL7 server. Available
values for this setting are MRN or Patient Account number.
The lower layer protocol used for this interface is Minimal Lower Layer Protocol (MLLP). See Dräger HL7
Overview for details on HL7 interfaces.
NOTE
The IHE Unsolicited and unsolicited ADT Interfaces are mutually exclusive.
For the IHE Unsolicited ADT interface, the external system (the hospital information system or HIS)
initiates the connection.
The following table indicates the data imported, the HL7 segment from which it is extracted, and the screen
where it appears on the destination Infinity monitor or Infinity Central Station (ICS).
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 135
IHE Unsolicited ADT
ADT data received from the hospital information system (HIS) is stored in a database on the Dräger HL7
SERVER. When a request for data is received from an Infinity device, a database lookup is done based
on Patient identifier provided by the requesting device. The patient identifier received from the requesting
device is interpreted according to the Interpret Patient ID as setting on the HL7 server.
136 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
IHE Unsolicited ADT
This Bedside Auto Update option on the IHE Unsolicited ADT interface causes demographic data changes
received by the HL7 server to be forwarded to a patient monitor where the corresponding patient has
already been admitted, if applicable.
This feature is intended only to solve the following problem:
1 The nurse admits a patient to a patient monitor using the “Get From HIS” button on the Infinity Central
Station.
2 Someone at the admissions system notices an error in the demographic data for the patient and
corrects it.
3 The admissions systems automatically sends an update to the HL7 server.
In this situation, if the ADT Auto Update option is not enabled, the patient monitor will never be updated
with the correction unless the nurse manually requests the data from the Admissions System again by
pressing the “Get From HIS” button at the Infinity Central Station. With this feature enabled, all changes
(a patient record must already exist at the HL7 server) received from the HIS, excluding height and weight,
that are normally sent to the patient monitor when the “Get From HIS” button is pushed, will automatically
be sent to the patient monitor where the patient is admitted. Note that if the primary patient identifier is
entered at more than one patient monitor, the changes will not be sent to any patient monitor.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 137
IHE Unsolicited ADT
138 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
IHE Unsolicited ADT
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 139
IHE Unsolicited ADT
140 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
IHE Unsolicited ADT
Event Occurred
The date and time that the ADT event took place, in the format:
YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 141
IHE Unsolicited ADT
142 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
IHE Unsolicited ADT
Patient Identifier
Depending on the Infinity Network Users setting in the HL7 configuration screen, the Patient ID field that
appears in the Patient Admit screen of the device is interpreted as either a Medical Record number or a
Patient Account number (i.e., visit number). The Identifiers in the identifier list will override any identifiers
present in seq 4, seq 18, or seq 19.
The format of either field is:
<ID>^<check digit>^<check digit scheme>^<assigning authority>^<identifier type>^<assigning facility>
The following identifiers are accepted by HL7:
– MR - MRN
– AN - Account/Visit Number
– SS - Social Security Number
– PI - Alternate Patient Identifier
NOTE
Infinity and SDC devices can support only an ID of up to 12 characters long.
The Assigning Authority component can only be up to 10 characters long.
Patient Name
Contains the patient name to be entered in the Admit screen of the device upon the request. The format is:
<Last>^<First>^<Middle>
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 143
IHE Unsolicited ADT
When the device requests ADT data, the Patient Name will appear in the following format on the Patient
Admit screen: <Last Name>,<First Name> <Middle Initial/Name>
with a comma between the last and first name, and a single space between the first and middle names.
The name is truncated to 26 characters. If this field contains the string “UNKNOWN”, a blank will appear
on the Admit screen for this patient.
Date/Time of Birth
The format is:
YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]
The date portion of this field will be entered in the Birth Date field of the Patient Admit Screen on the device
when ADT data is requested.
Sex
Contains a single character denoting the sex of the patient. The results of this field will be entered in the
Sex field of the ECG Report Setup Screen, if one exists, when requested during Admit by the device.
In Field On Device
F Female
M Male
All other Unknown
Race
Contains a string denoting the race of the patient. On the device the results of this field will be entered in
the Race field of the ECG Report Setup Screen, if one exists, when requested during Admit. When a
message is received from the HIS, the HIS code is compared to the list of acceptable values, and then
translated into an internal Infinity numeric code, which is then used to communicate with all of the devices.
Infinity codes 1-7 have a fixed interpretation on the device. The HIS codes, however can be configured.
Additional entries may also be added; however, any new entries will be reflected on the devices as
“Unknown”. The utility used to configure these entries is ADTConfig.exe.
144 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
IHE Unsolicited ADT
Patient Address
This field contains the mailing address of the patient. Although HL7 supports repetition of this field, Dräger
does not, and only the first instance with address type of M (mailing) will be used. If no address is marked
as mailing, and there is an address that is unmarked for type, then it will be used.
<street1>^<street2>^<city>^<state/province>^<postal code>^<country>
The component lengths supported are as follows:
Component Max Length
street1 40
street2 40
city 25
state/province 25
postal code 10
country 15
address type 1
Marital Status
The following table denotes the acceptable HIS codes that can be accepted along with their associated
meaning. Unlike many of the other codes accepted on this interface, this list is not configurable.
In Field On Device
A Separated
B Unmarried
C Common law
D Divorced
E Legally Separated
G Living together
I Interlocutory
M Married
N Annulled
O Other
P Domestic partner
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 145
IHE Unsolicited ADT
In Field On Device
R Registered domestic partner
S Single
T Unreported
W Widowed
All Other Unknown
Ethnic Group
This field contains a code, up to 4 characters long, that indicates the patient’s ethnic group. The default
configuration is detailed in the table below.
HIS Code Ethnic Group
H Hispanic or Latino
N Not Hispanic or Latino
All other Unknown
NOTE
All allergies must be included in every message, otherwise the associated allergy that is not included will
be deleted from the patient record.
146 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
IHE Unsolicited ADT
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 147
IHE Unsolicited ADT
Allergy Types
The following table lists the allergy types accepted by HL7:
Code Description
DA Drug Allergy
FA Food Allergy
MA Miscellaneous Allergy
MC Miscellaneous Contraindication
Allergies
This field has the format <Allergy Code>^<Allergy Description>
The Allergy Code portion of this field must match the HIS code from the pre-configured list of available
Allergy codes. The Allergy code is limited to 4 characters.
The Allergy Description portion of this field is optional and is limited to 40 characters. If the description is
provided, it supercedes the description provided in the default allergy table.
NOTE
All IN1 segments must be included in every message, otherwise the associated insurance information
that is not included will be deleted from the patient record.
148 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
IHE Unsolicited ADT
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 149
IHE Unsolicited ADT
150 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
IHE Unsolicited ADT
Address
Repetition is not supported for this field, and only the first instance will be used.
<street1>^<street2>^<city>^<state/province>^<postal code>^<country>
The component lengths supported are as follows:
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 151
IHE Unsolicited ADT
Name of Insured
Contains the name of the primary insured person, The format is:
<Last Name>^<First Name>^<Middle name>
The maximum component lengths are as follows. If a component exceeds the maximum length, it will be
truncated.
Component Max Length
Last 30
First 20
Middle 20
NOTE
All DG1 segments must be included in every message, otherwise the associated diagnosis information
that is not included will be deleted from the patient record.
152 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
IHE Unsolicited ADT
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 153
IHE Unsolicited ADT
Diagnosis
This field is of the format:
<ID>^<Text>
Where
ID - contains the code that identifies the diagnosis (up to 8 characters)
Text - description of the diagnosis (up to 42 characters)
154 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
IHE Unsolicited ADT
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 155
IHE Unsolicited ADT
156 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
IHE Unsolicited ADT
Name
Contains the name of the next of kin/associated party. The format is: <Last Name>^<First Name>
The maximum component lengths are as follows. If a component exceeds the maximum length, it will be
truncated.
Component Max Length
Last 30
First 20
Address
This field contains the mailing address of the next of kin/associated party. Although HL7 supports
repetition of this field, Dräger does not, and only the first instance will be used.
<street1>^<street2>^<city>^<state/province>^<postal code>^<country>
The component lengths supported are as follows:
Component Max Length
street1 40
street2 40
city 25
state/province 25
postal code 10
country 15
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 157
IHE Unsolicited ADT
158 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
IHE Unsolicited ADT
If IHE non
Compliant:
"^Last
Name^First
Name ^Middle
Name ^Suf-
fix^Pre-
fix^Degree"
18 00148 Patient Type O IS 2 <not used>
19 00149 Visit Number O CX 20 <not used>
20 00150 Financial Class O CM 50 <not used>
21 00151 Charge Price Indica- O IS 2 <not used>
tor
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 159
IHE Unsolicited ADT
160 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
IHE Unsolicited ADT
Patient Location
This field contains the location of the patient (destination location in a ADT – Admit, Discharge, and
Transfer). It is in the format:
<Care Unit>^<Room>^<Bed>
Admit Date/Time
Contains the admission date in the format:
YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]
The date portion of this field will be entered in the Admit Date field of the Patient Admit screen on the
device.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 161
IHE Unsolicited ADT
162 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
IHE Unsolicited ADT
HL7 Dräger
HL7
Seq
Item #
Description Req Type Len Contents Req Len
Observation Identifier
Uniquely identifies the parameter being reported, in the format:
<identifier1 >^<description>^<coding system>^<identifier2>^<description>^<coding system >
identifier1 label for the parameter
description parameter description
identifier2 an alternate label for the parameter
coding system name of the coding system
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 163
IHE Unsolicited ADT
The IHE ADT interface supports only the LOINC codes for Height ("8303-0"), and Weight ("3142-7").
Other identifiers are not used.
Units
Uniquely identifies the units in which the parameter is being reported, in the format:
<identifier1 >^<description>^<coding system>^<identifier2>^<description>^<coding system >
identifier1 unit identifier
description unit description
identifier2 an alternate label for the unit
coding system name of the coding system
The ADT interface uses the primary identifier, identifier1, and only supports the “iso+” coding system. All
other components are not used. The following units are supported for patient height and weight:
ACK – Acknowledgment
After reception of an ADT message, an acknowledgment of the following form will be sent:
Seqment Description
MSH MSH Segment - Message Header
MSA MSA Segment - Message Acknowledgment
See ADT – Admit, Discharge, and Transfer for a description of the ADT message being acknowledged.
164 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
IHE Unsolicited ADT
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 165
IHE Unsolicited ADT
166 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
IHE Unsolicited ADT
Acknowledgment Codes
Value Description
AA Original mode: Application Accept
IHE mode: Application acknowledgment: Accept
AE Original mode: Application Error
IHE mode: Application acknowledgment: Error
AR Original mode: Application Reject
IHE mode: Application acknowledgment: Reject
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 167
IHE Unsolicited ADT
168 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Solicited ADT Import
The HL7 Access option can be used for the import of ADT data. The ADT system responds by transmitting
the latest data for that patient to the HL7 server. This data is then forwarded to the requesting device. The
responding system has 27 seconds to respond to an ADT Query message.
Refer to Dräger HL7 Overview for details on HL7 interfaces.
NOTE
The solicited and unsolicited ADT Interfaces are mutually exclusive.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 169
Solicited ADT Import
See ADR – Query Response for a description of the response message expected from the responding
application.
MSH Segment - Message Header Query
HL7 Dräger
HL7
Seq Item #
Description Req Type Len Contents Req Len
1 00001 Field Separator R ST 1 “|” R 1
2 00002 Encoding R ST 4 “^~\&” R 4
Characters
3 00003 Sending O HD 180 “INFINITY” O 16
Application
4 00004 Sending Facility O HD 180 <not used>
5 00005 Receiving O HD 180 “NUR” O
Application
6 00006 Receiving O HD 180 <not used>
Facility
7 00007 Date/Time of O TS 26 YYYYMMDDhh O 12
Message mmss
8 00008 Security O ST 40 <not used>
9 00009 Message Type R CM 7 “QRY^A19” R 7
10 00010 Message Control R ST 20 A number or R 20
ID other identifier
uniquely identi-
fying the mes-
sage. The
responding
system echoes
this ID back to
the sending
system in the
Message
Acknowledg-
ment segment
(MSA).
11 00011 Processing ID R PT 3 “P” R 3
170 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Solicited ADT Import
HL7 Dräger
HL7
Seq Item #
Description Req Type Len Contents Req Len
12 00012 Version ID R ID 8 “2.3” R 8
13 00013 Sequence O NM 15 <not used>
Number
14 00014 Continuation O ST 180 <not used>
Pointer
15 00015 Accept O ID 2 "AL" R 2
acknowledgment
Type
16 00016 Application O ID 2 "NE" R 2
acknowledgment
17 00017 Country Code O ID 2 <not used>
18 00692 Character Set O ID 6 <not used>
19 00693 Principal O CE 60 <not used>
Language Of
Message
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 171
Solicited ADT Import
172 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Solicited ADT Import
Upon receiving a QRY message, the following message will be sent by the responding system. Square
brackets, ‘[‘ and ‘]’ indicate optional segments. Curved brackets ‘{‘ and ‘}’ indicate segments that can be
repeated.
Seqment Description
MSH MSH Segment - Message Header
MSA MSA Segment - Message Acknowledgment
QRD QRD Segment - Original Type Query Definition
PID PID Segment - Patient Identification
[PV1] PV1 Segment - Patient Visit
[{OBX}] OBX Segment - Observation/Result
Refer to QRY – Patient Query for a description of the QRY message being responded to.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 173
Solicited ADT Import
174 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Solicited ADT Import
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 175
Solicited ADT Import
176 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Solicited ADT Import
Acknowledgment Codes
Value Description
AA Original mode: Application Accept
Enhanced mode: Application acknowledgment: Accept
AE Original mode: Application Error
Enhanced mode: Application acknowledgment: Error
AR Original mode: Application Reject
Enhanced mode: Application acknowledgment: Reject
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 177
Solicited ADT Import
178 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Solicited ADT Import
Patient Identifier
Depending on the in the HL7 configuration screen, the Patient ID field that appears in the Patient Admit
screen of devices is interpreted as either a Medical Record number, retrieved from PID segment Seq#3,
or a Patient Account number (i.e. visit number), retrieved from Seq#18 of the PID segment.
The format of either field is:
<ID>^<Text digit>^<check digit scheme>^<assigning authority>^<identifier type>^<assigning facility>
The ID component and assigning authority are used for the MRN (seq#3), but only the ID component is
used in the Patient Account number (seq#18).
CAUTION
Infinity and SDC devices can support only an ID of up to 12 characters long.
The Assigning Authority component can only be up to 10 characters long.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 179
Solicited ADT Import
Patient Name
Contains the patient name to be entered in the Admit screen of the device upon request. The format is:
<Last>^<First>^<Middle>
When the device requests ADT data, the patient name will appear in the following format on the Patient
Admit screen: <Last Name>,<First Name> <Middle Initial/Name>
with a comma between the last and first name, and a single space between the first and middle names.
The name is truncated to 26 characters. If this field contains the string “UNKNOWN”, a blank will appear
on the Admit screen for this patient.
Date of Birth
The format is:
YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]
The date portion of this field will be entered in the Birth Date field of the Patient Admit screen on the device
when ADT data is requested.
Sex
Contains a single character denoting the sex of the patient. The results of this field will be entered in the
Sex field of the ECG Report Setup screen, if one exists, when requested during admit by the device.
In Field On Device
F Female
M Male
All other Unknown
Race
Contains a string denoting the race of the patient. The results of this field will be entered in the Race field
of the ECG Report Setup Screen, if one exists, when requested during admit.
In Field On Device
(HIS code)
2106-3 Caucasian
2028-9 Asian
2054-5 Black or African
American
2131-1 Other
1002-5 American Indian or
Alaska Native
2076-8 Native Hawaiian or
Other Pacific
Islander
All others Unknown
180 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Solicited ADT Import
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 181
Solicited ADT Import
182 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Solicited ADT Import
Attending Doctor
Contains the attending physician information in the format:
<not used>^<last>^<first>^<middle>^<suffix>^<prefix>^<degree>
The data from this field will appear in the Physician field of the Patient Admit Screen of the device if ADT
data is requested for the device. In this instance, the format will be:
<last>,<first> <middle>
With a comma between the last and first name, and a single space between the first and middle names.
The name is truncated to twelve characters.
Admit Date
Contains the admission date in the format: YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]
The date portion of this field will be entered in the Admit Date field of the Patient Admit screen on the
device that ADT is requested from.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 183
Solicited ADT Import
184 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Solicited ADT Import
Observation Identifier
Uniquely identifies the parameter being reported, in the format:
<identifier1 >^<description>^<coding system>^<identifier2 >^<description>^<coding system >
identifier1 label for the parameter
description parameter description
identifier2 an alternate label for the parameter
coding system name of the coding system
The ADT Interface supports only “height,” and “weight,” for the identifier1 component. Other identifiers are
not used.
Observation Value
The Observation Value field contains the parameter value. The format of this field varies according to the
Value Type field as follows:
Value Type Observation Value Field Format
NM <value>
SN <comparator>^<value>
For values of type SN, the comparator must be equal to “=” or blank; otherwise the data will not be
imported into the HL7 server.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 185
Solicited ADT Import
Units
The Units field uniquely identifies the units in which the parameter is being reported, in the format:
<identifier1 >^<description>^<coding system>^<identifier2 >^<description>^<coding system >
identifier1 unit identifier
description unit description
identifier2 an alternate identifier for the unit
coding system name of the coding system
The ADT interface uses the primary identifier, identifier1, and only supports the “iso+” coding system. All
other components are not used.
The following units are supported for patient height and weight:
186 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Solicited ADT Import
Sample
QRY Message
MSH|^~\&|Infinity||NUR||200301152306||QRY^A19|03001523064500052645|P|2.3
QRD|200301152306|R|I|4500052655|||1^RD|1001|APA|
ADR Message
MSH|^~\&|HIS||Infinity||199903291650||ADR^A19|99022916500500050122|P|2.3
MSA|AA|03001523064500052645|Patient found
QRD|19990322160000|R|I|4500052655|||1^RD|1001|APA
PID|||1001||Smith^Wally^L.||194204301420|M||W|||978 907-7333||||Ch|1001
PV1|||CCU1^200^A||||021-55-1366^Munster^F.^S|||||||||||||||||||||||||||||||||||||199804300430
OBX||NM|height^^^^^||182.9|cm^^ISO+|||||R|||19990329165005
OBX||SN|weight^^^^^||=^29.3|kg^^ISO+|||||R|||19990329165005
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 187
This page has been left blank intentionally.
188 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Lab Import
Lab Import
In the Lab Import interface, the HL7 server will accept laboratory data in an Unsolicited Observation
Results message (ORU). It will acknowledge receipt of an ORU message with an ACK message. It will
then attempt to find a patient monitor on the Infinity network with the corresponding identifier. If one, and
only one such patient monitor is found, and the monitor is a Modular monitor, then the data is forwarded
to the patient monitor.
CAUTION
– Lab data transmitted to all patient monitors is in ANSI characters. If the incoming lab data contains
Unicode (non-ANSI characters), then a character mapping must be configured or all characters in
the non-ANSI range will get removed from the message.
– Lab data is not supported on SDC-only devices.
By default, the identifier used to locate the patient on the Infinity network is the primary identifier in the
incoming message. If, however, the external system (LIS) does not have this identifier available, the
alternate identifier can be provided instead, provided that the Unsolicited ADT interface is also enabled,
and the “Allow patient to be identified by Alternate Identifier” option is enabled on this interface.
For the Lab Import interface, the external system (the Laboratory Information System or LIS) initiates the
connection. Refer to Dräger HL7 Overview for details on HL7 interfaces.
Although the incoming message format is different, the functionality of the HL7 Lab Import and the ASTM
Lab import are virtually identical.
HL7/ASTM provides a mechanism by which the customer can organize incoming lab data and control how
the data is represented on the destination device (i.e. or patient monitor). The user can:
Define any number of parameter groups and the associated group label to be used when displaying
them.
Define each parameter that can be expected to be received from the central laboratory, assign a group
to each parameter and a priority within the group for the parameter.
This setup information is stored in the Lab Import database. When a message is received by the HL7
service, the data is reorganized according to this configuration. Groups with lower numbered priorities
appear nearest to the top of the message. Parameters are placed into the group to which they have been
assigned, with lower numbered priorities appearing first. Grouping labels are also embedded before the
data is forwarded to the destination device. If a defined group has no associated parameters in the
message, then the group label is not included in the message.
If none of the parameters received are defined as part of a group then no reorganization occurs. If,
however, at least one parameter is defined as part of a group, the message is reformatted with grouping
information. Note that any parameter received that is not defined as being a member of a group will
automatically be assigned to the group “Other”, which has the highest numbered priority and therefore
goes at the bottom of the message.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 189
Lab Import
NOTE
To configure the databases for importing HL7 laboratory data, a device ID of “HL7” is used.
Please refer to the on-line help for the HL7 setup program for more details on how to perform the
configuration.
Alert message
When lab data is received on a patient monitor, a message is displayed in the message area indicating
that new lab data has been received. Once the newly received lab data has been reviewed, this message
is cleared from the message area.
The group labels and order of appearance of parameters on the screen is defined by the group and priority
settings in the Lab Import database setup.
The date and time that is displayed on the screen is the date and time associated with the first OBX-14
that appears in the reorganized message, if that field is populated. In this case the Time Label used is
“Test Time” (or a translation if English is not being used).
If no date/time appears in OBX-14 of the first parameter, then the time displayed will be the time that the
message arrived at the patient monitor, and the Time Label will be “Arrival Time” (or a translation).
Hemo/Oxy/Vent Calculator
Under certain conditions, the patient monitor will also allow the user to import parameter data received into
the Hemo/Oxy/Vent Calculator, if this option is enabled at the monitor. In order to import the data, HL7 also
needs additional configuration information that maps the parameter labels to be received from the central
laboratory into known parameters at the patient monitor. This calculator mapping is also performed in the
HL7 setup application.
Parameters that can be imported into the calculator are:
SaO2
190 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Lab Import
PAO2
PACO2
HgB
pH
HCO3
HCT
SVO2
PVO2
Note that the patient monitor also requires that the parameter be a recent measurement. Please refer to
the instructions for use for the specific patient monitor for more details.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 191
Lab Import
The Lab Import interface will accept ORU messages. Square brackets [and] indicate optional segments.
Curved brackets {and} indicate segments that may be repeated.
Segment Description
MSH MSH Segment - Message Header
{
PID PID Segment - Patient Identification
[PV1] PV1 Segment – Patient Visit
[ORC] ORC Segment – Common Order
[OBR] OBR Segment - Observation Request
[
{
OBX OBX Segment - Observation/Result
}
]
}
192 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Lab Import
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 193
Lab Import
194 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Lab Import
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 195
Lab Import
196 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Lab Import
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 197
Lab Import
Observation Date/Time
If any of the OBX segments that follow the OBR do not contain a timestamp in OBX-14, then this field is
used by as the time of that associated parameter.
198 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Lab Import
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 199
Lab Import
Observation Value
Contains the parameter value to be displayed on the Infinity monitor. The format of this field varies
according to the Value Type field, as follows:
Value Observation Value Field Format
ST <value>
NM <value>
SN <comparator>^<value>
For SN value types, the comparator must be equal to “=” or blank; otherwise the data will not be imported
into the INFINITY Network.
ACK - Acknowledgment
After receipt of an ORU message, the HL7 server will send an acknowledgment:
Segment Description
MSH MSH Segment - Message Header
MSA MSA Segment – Message Acknowledgment
See ORU - Unsolicited Observation Report for a description of the ORU message being acknowledged.
200 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Lab Import
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 201
Lab Import
Acknowledgment Codes
Value Description
AA Original mode: Application Accept
Enhanced mode: Application acknowledgment: Accept
AE Original mode: Application Error
Enhanced mode: Application acknowledgment: Error
AR Original mode: Application Reject
Enhanced mode: Application acknowledgment: Reject
202 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Lab Import
Sample
ACK Message
MSH|^~\&|Infinity||LIS||20050426113509||ACK^R01|99022518340103894120|P|2.3
MSA|AA|17042411075600136436|[9009]Message Delivered
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 203
This page has been left blank intentionally.
204 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Lab Export
Lab Export
Using the Lab Export Interface, MIB Blood Gas results can be exported from an MIB-compliant device
connected to an Infinity monitor via a serial link. This data will be transmitted by the HL7 server in an Unso-
licited Observation Results message (ORU). Upon receipt of an ORU message, the receiving system
should acknowledge receipt with an ACK message. MIB Blood Gas results can be exported from Infinity
Modular monitors. See Dräger HL7 Overview or details on how Dräger implements HL7 interfaces.
For the Lab Export interface, Dräger initiates the connection.
NOTE
The Lab Export interface is not available for SDC-only devices.
The Lab Export interface will generate ORU messages listed below. Square brackets, [and], indicate
optional segments. Curved brackets, {‘ and ‘} indicate segments which may be repeated.
Segment Description
MSH MSH Segment - Message Header
PID PID Segment - Patient Identification
OBR OBR Segment - Observation Request
[{OBX}] OBX Segment - Observation/Result
See ACK - Acknowledgment for a description of the acknowledgment expected by the HL7 server.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 205
Lab Export
206 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Lab Export
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 207
Lab Export
208 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Lab Export
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 209
Lab Export
210 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Lab Export
Observation Value
The parameter value as reported by the point-of-care laboratory device. The format of this field varies
according to the Value Type field.
Value Type Observation Value Field Format Comments
ST <value>
SN <comparator>^<value> comparator is “=”
ACK - Acknowledgment
See Section ORU - Unsolicited Observation Report for a description of the ORU message being acknowl-
edged.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 211
Lab Export
212 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Lab Export
Acknowledgment Codes
Value Description
AA Original mode: Application Accept
Enhanced mode: Application acknowledgment: Accept
AE Original mode: Application Error
Enhanced mode: Application acknowledgment: Error
AR Original mode: Application Reject
Enhanced mode: Application acknowledgment: Reject
If an acknowledgment code of AE is received from the destination device, the HL7 server will attempt to
retransmit the message as many times as this interface is configured in the HL7 setup program.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 213
Lab Export
Sample
ORU Message
MSH|^~\&|Infinity||NUR||200011201019||ORU^R01||P|2.3
PID|||999-99-9999||UNKNOWN^^||||||||||||999-99-9999
OBR|1||||||20001120101911
OBX||ST|pH^^^^^||7.35|^^|||||R
OBX||ST|PO2^^^^^||10.4|mmHg|||||R
OBX||ST|Hct^^^^^||31.5|%|||||R
ACK Message
MSH|^~\&|Infinity||MEDAT-18||199903251834||ACK^R01|99022518340103894120|P|2.3
MSA|AA|17042411161900020570|[999-99-9999]Message Delivered
214 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Alarm Communication Management Interface
The HL7/ASTM Interface Option enables the export of alarm data in an unsolicited Observation Results
message (ORU) using HL7 version V2.6. The data is sent using IHE compliant nomenclatures. The
interface can be configured to be IHE PC D ACM compliant, or by default may contain additional or omitted
data causing it to be non-compliant. One ORU message is sent for each alarm update.
Upon receipt of an ORU message, the receiving system should acknowledge receipt with an ACK
message. Refer to Dräger HL7 Overview for details on HL7 interfaces.
For the Alarm Communication Management interface, Dräger initiates the connection.
The measured value of a parameter in an HL7 ACM profile may be a value sampled immediately before
or after occurrence of the alarm, and may not match the value that actually generated the alarm.
NOTE
The Alarm Communication Management interface is only available for SDC devices.
ORU messages follow the format below. The curved brackets {‘ and ‘} indicate segments which may be
repeated.
Segments Description
MSH MSH Segment – Message Header
PID PID Segment - Patient Identification
PV1 PV1 Segment - Patient Visit
OBR OBR Segment - Observation Request
{OBX} OBX Segment - Observation/Result
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 215
Alarm Communication Management Interface
HL7 Dräger
HL7
Seq Item
# Le
Description Req Type Len Contents Req n
216 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Alarm Communication Management Interface
HL7 Dräger
HL7
Seq Item
# Le
Description Req Type Len Contents Req n
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 217
Alarm Communication Management Interface
218 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Alarm Communication Management Interface
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 219
Alarm Communication Management Interface
Name
The patient name will be in the following format: <Last> ^>First> ^<Middle> ^^^^<Type>.
If at least the last name is known then the Type will be “L”. If the name is not know then the Type will be “U”.
NOTE
All items with an asterisk * are only sent out when the “ADT Data in Message” option is enabled for ACM,
and data is found for the patient. Otherwise the fields are <not used>.
220 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Alarm Communication Management Interface
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 221
Alarm Communication Management Interface
Doctor’s Name
If the interface is configured to be IHE compliant then this field is not used. If the interface is not configured to be IHE
compliant then the format will be as follows: ^<Last Name>^<First Name>^<Middle Name>^<Suffix>^<Prefix>^
<Degree>.
222 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Alarm Communication Management Interface
For the Alarm Management interface there are up to 7 OBX segments sent.
The following OBX segments are sent:
OBX 1: MDS information
Seq HL7 HL7 Dräger
Item # Description Req Type Len Contents Req Len
1 00001 Set ID – R SI 4 “1” R 4
OBX
2 00002 Value Type C ID 3 “ST” R 2
3 00003 Observation R CWE 705 <CF_Code10>^<R R 20
Identifier eference ID>^MDC
4 00004 Observation R ST 20 "1.0.0.0" R 20
Sub-
5 00005 Observation C Varies 99999 <not used> R
Value
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 223
Alarm Communication Management Interface
224 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Alarm Communication Management Interface
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 225
Alarm Communication Management Interface
226 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Alarm Communication Management Interface
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 227
Alarm Communication Management Interface
228 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Alarm Communication Management Interface
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 229
Alarm Communication Management Interface
230 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Alarm Communication Management Interface
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 231
Alarm Communication Management Interface
232 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Alarm Communication Management Interface
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 233
Alarm Communication Management Interface
234 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Alarm Communication Management Interface
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 235
Alarm Communication Management Interface
236 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Alarm Communication Management Interface
ACK – Acknowledgment
See ORU - Unsolicited Observation Report for a description of the ACM message being acknowledged.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 237
Alarm Communication Management Interface
238 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Alarm Communication Management Interface
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 239
Alarm Communication Management Interface
Acknowledgment Codes
Value Description
AA Original mode: Application Accept
AE Original mode: Application Error
AR Original mode: Application Reject
CA Enhanced mode: Commit Accept
CE Enhanced mode: Commit Error
CR Enhanced mode: Commit Reject
NAME=ACK
MSG:#
MSH|^~\&|NUR|DRAEGER|INFO_SRC_DRAEGER^0030E60000000001^EUI-64|Drae-
ger|20170125135441-
0500||ACK^R40^ACK|18092115514903462867|P|2.6|||AL|NE||8859/1|EN^ENGLISH^ISO639||IHE_PC-
D_ACM_001^IHE PCD^1.3.6.1.4.1.19376.1.6.4.4^ISO
MSA|CA|18092115514900035708|
240 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Alarm Communication Management Interface
NAME=ORU(3/11/2019 14:33:29)
MSG:
MSH|^~\&|INFO_SRC_DRAEGER^0030E60000000001^EUI-64|Draeger|NUR|REC-
FAC|20190311143329-
0500||ORU^R40^ORU_R40|19031114332900039875|P|2.6|||AL|NE||8859/1|en^English^ISO639||IHE_P
CD_ACM_001^IHE PCD^1.3.6.1.4.1.19376.1.6.4.4^ISO
PID|||111-11-
1111^^^Auth1^MR~1001^^^^AN||Smith^Wally^L.^^^^L|Joosse\S\K\S\Judy^^^^^^L|19420430142000|M^
Male||U^Unknown|Smith13 Beer St.^#123Wally^Beersteinville^VA^12345-6785^USA^M||||spa^Span-
ish|M^Married|JEW^Jewish||012-34-5678|||N^Not Hispanic or Latino||||||USA^United States
PV1|||CU2^^GOWDA23^BGS1||||^Munster^Florence^S^II^Mr.^M.D.|^Kaite^William^M^Mr^II^MD|^Kuma
r^Sri^L^Mr^III^MBBS||||||||^Carr^Mary^Jones^II^Mrs.^M.D.
OBR|1||1^356fdbd9-b939-47c7-acf2-151bc323819819667220190311143329^0030E60000000001^EUI-
64|196616^MDC_EVT_ALARM^MDC|||20190311143329-0500
OBX|1|ST|69837^MDC_DEV_METER_PHYSIO_MUL-
TI_PARAM_MDS^MDC|1.0.0.0|||||||F|||||||0060E9EEBC^IACS^http://www.draeger.com/^DNS
OBX|2|ST|196672^MDC_EVT_LO_LT_LIM^MDC|1.1.2.147842.1.2|HR < low
limit||||||F|||||||0060E9EEBC^IACS^http://www.draeger.com/^DNS
OBX|3|NM|147842^MDC_ECG_CARD_BEAT_RATE^MDC|1.1.2.147842.1.3|89.000000|264864^MDC_
DIM_BEAT_PER_MIN^MDC|||||F|||||||0060E9EEBC^IACS^http://www.draeger.com/^DNS
OBX|4|ST|68481^MDC_AT-
TR_EVENT_PHASE^MDC|1.1.2.147842.1.4|start||||||F|||||||0060E9EEBC^IACS^http://www.drae-
ger.com/^DNS
OBX|5|ST|68482^MDC_AT-
TR_ALARM_STATE^MDC|1.1.2.147842.1.5|active||||||F|||||||0060E9EEBC^IACS^http://www.drae-
ger.com/^DNS
OBX|6|ST|68483^MDC_ATTR_ALARM_INACTIVATION_STATE^MDC|1.1.2.147842.1.6|enabled||||||F||||
|||0060E9EEBC^IACS^http://www.draeger.com/^DNS
OBX|7|ST|68484^MDC_ATTR_ALARM_PRIOR-
ITY^MDC|1.1.2.147842.1.7|PM||||||F|||||||0060E9EEBC^IACS^http://www.draeger.com/^DNS
OBX|8|ST|68485^MDC_ATTR_ALERT_-
TYPE^MDC|1.1.2.147842.1.8|SP||||||F|||||||0060E9EEBC^IACS^http://www.draeger.com/^DNS
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 241
This page has been left blank intentionally.
242 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
ASTM Stat Lab Interface Option
The ASTM Stat Lab interface allows the HL7 server to accept laboratory data using a serial
communication link from a “stat” laboratory device and transmit the data to Infinity Modular monitors.
If the Lab Interface option is enabled then upon receipt of the ASTM message, it will then attempt to find
a patient monitor on the network with the corresponding ID. If one, and only one such patient monitor is
found, and the monitor is a Modular monitor, then the data is forwarded to the patient monitor. On the
modular monitor, laboratory data is displayed in the Blood Chemistry screen, and may be imported into
the Calculator. Please refer to the instructions for use of the appropriate Infinity patient monitor for more
details.
In the HL7/ASTM setup program, the user configures the stat labs that data is to be accepted from. On
each of these device configurations, the “LAB ID” setting controls which field the identifier is extracted from
in the message. Refer to the ASTM (Practice Assigned Patient ID/Laboratory Assigned Patient ID) section
for more details.
The identifier extracted from the ASTM message is interpreted as being either an MRN or a Patient
Account number according to the global uses setting defined in the HL7 setup program.
The ASTM Stat Lab Interface Option conforms to the ASTM 1381-91 and ASTM 1394-91 protocols with
the following exceptions:
Hexadecimal data escape sequences are not supported
Local (manufacturer defined) escape sequences are not supported
Start and end highlighting escape sequences will be ignored
NOTE
- Refer to Message Structure for details on the individual records used by the Infinity devices.
- Lab data cannot be transmitted to SDC-only devices.
HL7/ASTM provides a mechanism by which the customer can organize incoming lab data and control how
the data is represented on the destination device (i.e. or patient monitor). The user can:
Define any number of parameter groups and the associated group label to be used when displaying
them.
Define each parameter that can be expected to be received from the central laboratory, assign a group
to each parameter and a priority within the group for the parameter.
This setup information is stored in the Parameter Grouping/Priority database. When a message by HL7,
the data is reorganized according to this configuration. Groups with lower numbered priorities appear
nearest to the top of the message. Parameters are placed into the group to which they have been
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 243
ASTM Stat Lab Interface Option
assigned, with lower numbered priorities appearing first. Grouping labels are also embedded before the
data is forwarded to the destination device. If a defined group has no associated parameters in the
message, then the group label is not included in the message.
If none of the parameters received are defined as part of a group then no reorganization occurs. If,
however, at least one parameter is defined as part of a group, the message is reformatted with grouping
information. Note that any parameter received that is not defined as being a member of a group will
automatically be assigned to the group “Other”, which has the highest numbered priority and therefore
goes at the bottom of the message.
See Sender Name or ID and Universal Test ID sections for more details on configuring databases for a
particular ASTM device.
Please refer to the on-line help for the HL7 setup program for more details on how to perform the
configuration.
Notification message
When lab data is received on a patient monitor, a message is displayed in the message area indicating
that new lab data has been received. Once the newly received lab data has been reviewed, this message
is cleared from the message area.
The patient monitor lab data review screen is of the following format:
<Time Label> <Date and time>
244 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
ASTM Stat Lab Interface Option
Hemo/Oxy/Vent Calculator
Under certain conditions, the patient monitor will also allow the user to import parameter data received into
the Hemo/Oxy/Vent Calculator, if this option is enabled at the monitor. In order to import the data, the
HL7/ASTM server also needs additional configuration information that maps the parameter labels to be
received from the central laboratory into known parameters at the patient monitor. This calculator mapping
is also performed in the HL7 setup application.
Parameters that can be imported into the calculator are:
SaO2
PAO2
PACO2
HgB
pH
HCO3
HCT
SVO2
PVO2
NOTE
The patient monitor also requires that the parameter be a recent measurement. Please refer to the
instructions for use for the specific patient monitor for more details.
Unlike the patient monitor, maintains a time stamp for each individual result received. The time stamp for
an individual parameter may be extracted from the following 3 fields in the following priority order:
Field 12 of the result (‘R’) record relating to the parameter
Field 8 of the order (“O”) record preceding the parameter
Field 14 of the header (“H”) record
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 245
ASTM Stat Lab Interface Option
Message Structure
The message accepted from the external system must conform to ASTM 1381-91 for the data link layer.
Each record must be transmitted in one or more frames and the record must be terminated with a <CR>.
If more than one record is contained in a frame, then a record cannot end on the frame boundary.
Continuation frames are only allowed after full-length frames.
In the ASTM interface, there is no acknowledgment message, but rather each frame transmitted is
acknowledged.
The following structure shows the contents of the message after all records have been extracted from the
frame(s) in which they were transmitted. Sections of the message that appear within {and} brackets may
be repeated. Records shown within [and] brackets are optional. Additional unused records may appear in
the message, but are ignored.
Record Description
H Message Header
Record
{
P Patient Information
Record
[C] Comment Record
[O] Order Record
{
R Result Record
}
}
L Terminator Record
246 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
ASTM Stat Lab Interface Option
Sender Name or ID
This field contains the name of the device sending the laboratory data. The first word of this field is used
by the HL7 Server, as a Device Identifier, for database table lookups, which determine how to:
map parameters which are to be imported into the calculator (Calculator Mapping Database Table)
group and order parameters on the Blood Chemistry screen of the Infinity monitor (Parameter
Grouping/Priority Database Table)
If this field is not populated, or if no corresponding entry appears in the database tables mentioned above,
then no parameters will be imported into the calculator, and the parameters will appear on the patient
monitor in the order they appear in the message.
Date/Time of Message
This field contains the data and time the message was sent, in the format: YYYYMMDDhhmmss
This field may also contain a time zone indicator, not used by the HL7/ASTM server. Refer to Lab data
display and Parameter time stamp sections for more details on how the time stamps are used on the
destination device.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 247
ASTM Stat Lab Interface Option
248 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
ASTM Stat Lab Interface Option
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 249
ASTM Stat Lab Interface Option
Order Record
250 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
ASTM Stat Lab Interface Option
Date/Time of Message
This field contains the data and time the group of parameters to follow were collected, in the format:
YYYYMMDDhhmmss
This field may also contain a time zone indicator, not used by the HL7/ASTM server. Refer to Lab data
display and Parameter time stamp sections for more details on how the time stamps are used on the
destination device.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 251
ASTM Stat Lab Interface Option
Result Record
Universal Test ID
This field uniquely identifies the laboratory test being reported, according to the ASTM protocol. The
format is:
<universal identifier >^< test name>^< test ID type >^< local code>^...
universal identifier: currently unused component
test name: test or battery name
252 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
ASTM Stat Lab Interface Option
Reference Range
Contains the parameter value to be displayed on in the Labs Review tab. The reference ranges of the
following formats are accepted:
1 lower limit – upper limit
2 >lower limit
3 <upper limit
Abnormal Flag
This field indicates the normalcy status of the result, and is used by Innovian only. The field can be
repeated to combine the following Abnormal values. Only flags that appear in the following table are
flagged within Innovian as abnormal. Innovian’s flag turns the beaker on the lab message red and
parameter value red.
Value Description
L Below low normal
H Above high normal
LL Below lower panic limits
HH Above upper panic limits
< Below absolute low-off instrument scale
> Above absolute high-off instrument
scale
A Abnormal
AA Very abnormal
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 253
ASTM Stat Lab Interface Option
Comment Record
Date/Time of Message
This field contains the data and time the test was started, in the format: YYYYMMDDhhmmss
This field may also contain a time zone indicator, not used by the HL7/ASTM server. Refer to Lab data
display and Parameter time stamp sections for more details on how the time stamps are used on the
destination device.
254 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
ASTM Stat Lab Interface Option
Terminator Record
The following sample does not include the control characters and checksum required to transmit this
ASTM message, but does include the frame number. See ASTM 1381-91 for more details.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 255
This page has been left blank intentionally.
256 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
PatientWatch
PatientWatch
NOTE
PatientWatch can be used to view both SDC and Infinity devices, however, certain functionality, such as
trends, is only available on Infinity devices.
WinViewActiveX Control
Methods
NOTE
Not all error codes are used by all methods.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 257
PatientWatch
AddServers()
Purpose: This method adds a list of Gateway servers to the Network Setup list of
servers.
Arguments: ServerList - The names or IP addresses of the gateway server(s) to add,
separated by “&”
Return Value: 0: SUCCESS
1: FAIL – Unknown cause
2: FAIL – Gateway Server not found
9: FAIL – Error finding server because list is empty
Description: This method adds a Gateway Server to the Network Setup list of servers on
the client machine. If the gateway server is already present, it will not be added
again. If any server in the list provided is not valid, an error will occur, but will
not prevent the valid ones from being added. Otherwise a SUCCESS code will
be returned.
258 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
PatientWatch
SelectGSMBedMCAddr()
Purpose: This method allows the Global Session Manager (GSM) user to connect to an
Infinity monitor specified by the Multicast address of the patient admitted to
that bed. This method cannot be used to connect to an SDC-only device.
Arguments: GWServer – The name of the gateway server to log on to
GSMSessionID – The session identification for GSM
GSMServer – The GSM server name
UserName – The user name to be used to log on to the server
BedMCAddr – The multi-cast address that identifies the bed
Return Value: 0: SUCCESS – The user is logged in to the server with a valid GSM session,
and the Infinity monitor specified has been connected.
2: FAIL – Gateway Server not found
3: FAIL – Error logging in to the server
4: FAIL – Error obtaining directory
8: FAIL – Error connecting to bed
11: FAIL – GSM Server not found
12: FAIL – GSM session is invalid
13: FAIL – Error found an empty Address String
Description: This method will allow the user to view a bed at a specified multicast address.
The current bed, if any, will be disconnected. The software will attempt to log
on to the gateway server specified. If log on to the server is not successful, an
error code will be returned. The software will then attempt to locate an Infinity
monitor whose multicast address corresponds to that supplied by the user. If
no Infinity monitor contains the specified multicast address, an error code will
be returned. If the GSM session has expired or is invalid, an error code will be
returned.Otherwise a SUCCESS code will be returned.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 259
PatientWatch
SelectGSMPatient()
Purpose: This method allows the Global Session Manager user to select a device from
a list of available devices using a Patient identifier. This method will work with
both Infinity and SDC devices.
Arguments: GWServer – The name of the gateway server to log on to
GSMSessionID – The GSM session identification string
GSMServer – The name of the GSM servers to connect to verify a valid GSM
session
UserName – The user name to be used to log on to the server
PatientId – The identifier for the patient at the patient monitor
Return Value: 0: SUCCESS
1: FAILURE – unknown cause
2: FAILURE – Server not found
3: FAILURE – Invalid log on
4: FAILURE – Failed to get directory
6: FAILURE – Patient not found in active directory
7: FAILURE – Duplicate patients found
8: FAILURE – Failed to connect to bed
9: FAILURE – Empty Server String
10: FAILURE – Duplicate bed found. Has same patient ID
11: FAILURE – Invalid GSM Server
12: FAILURE – Invalid GSM session or session has timed out
13: FAILURE – Empty address string. Cannot find a valid IP address for Server
Condition None
Description: The current bed, if any, will be disconnected. The software will attempt to log
on to the server specified. If log on to the server is not successful, an error
code will be returned. The software will then attempt to locate an device whose
patient ID corresponds to that supplied by the user. If no device contains the
specified, or more than one device contains it, an error code will be returned.
If the GSM session has expired or is invalid, an error code will be
returned.Otherwise a SUCCESS code will be returned.
260 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
PatientWatch
SelectPatient()
Purpose: This method allows the user to select a device from a list of available Care Units.
This method can be used to select both Infinity and SDC devices.
Arguments: None
Return Value: 0: SUCCESS
1: FAILURE
Condition: None
Description: This method will display a disclaimer on the first invocation within a newly
instantiated ActiveX control. If the user has not yet logged on a server, a log on
dialog will be displayed. The patient selection dialog will then appear.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 261
PatientWatch
SelectServerandBed()
Purpose: This method allows the user to programmatically log on to a server and
connect to a device specified by its Care Unit label and Bed label. If more than
one bed exists with the same labels (as can happen with seamless viewing
wireless beds), the non-wireless bed is selected. This method cannot be used
to connect to an SDC-only device.
Arguments: ServerName – The name or IP address of the server to log on to
UserName – The user name to be used to log on to the server
Password – The password to be used to log on to the server
Domain – The domain name of the user to be used to log on to the server
CareUnit label – The care unit label of the device to be connected
Bed label – The bed label of the patient monitor
Return Value: 0: SUCCESS – The user is logged on to the server, and the Infinity patient
monitor specified has been connected.
2: FAIL – Server not found
3: FAIL – Error logging in to the server
4: FAIL – Error obtaining directory
5: FAIL –Patient monitor specified does not exist on the server
8: FAIL – Error connecting to bed
10: FAIL – Duplicate bed
Description: This method will display a disclaimer, on the first invocation within a newly
instantiated ActiveX control. The software will attempt to log on to the server
specified. If log on is not successful, an error code will be returned. The current
bed, if any, will be disconnected. The software will then attempt to connect to
the specified Infinity monitor on that server. If connection to the Infinity
monitor cannot be made, an error code will be returned. Otherwise a
SUCCESS code will be returned.
262 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
PatientWatch
SelectServerandBedMCAddress()
Purpose: This method allows the user to programmatically log on to a server and
connect to an Infinity monitor specified by the multicast IP address of the
patient monitor. Note that this method does not work with SDC-only devices.
Arguments: ServerName – The name of the server to log on to the server
UserName – The user name to be used to log on to the server
Password –The password to be used to log on to the server
Domain – The domain name to be used to log on to the server
MCAddress – A string containing the multicast IP address of the patient
monitor
Return Value: 0: SUCCESS – The user is logged on to the server, and the Infinity monitor
specified has been connected.
2: FAIL – Server not found
3: FAIL – Error logging in to the server
4: FAIL – Error obtaining directory
5: FAIL – Patient monitor specified does not exist on the server
8: FAIL – Error connecting to bed
Description: This method will display a disclaimer, on the first invocation within a newly
instantiated ActiveX control. The software will attempt to log on to the server
specified. If log on is not successful, an error code will be returned. The current
bed, if any, will be disconnected. The software will then attempt to locate an
Infinity monitor whose patient ID corresponds to that supplied by the user. If
no Infinity monitor contains the specified, or more than one monitor contains
it, an error code will be returned. Otherwise a SUCCESS code will be returned.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 263
PatientWatch
SelectServerandPatientID()
Purpose: This method allows the user to programmatically log on to a server and connect
to an device specified by the of the patient admitted to that bed. This method
cannot be used to connect to an SDC-only device.
Arguments: ServerName –The name of the server to log on to
UserName –The user name to be used to log on to the server
Password – The password to be used to log on to the server
Domain –- The domain name to be used to log on to the server
PatientID – The identifier for the patient at the patient monitor
Return Value: 0: SUCCESS – The user is logged on to the server, and the device specified has
been connected.
2: FAIL – Server not found
3: FAIL – Error logging in to the server
4: FAIL – Error obtaining directory
6: FAIL – Specified does not exist on the server
7: FAIL – More than one patient monitor contains the same
8: FAIL – Error connecting to bed
Description: This method will display a disclaimer, on the first invocation within a newly
instantiated ActiveX control. The software will attempt to log on to the server
specified. If log on is not successful, an error code will be returned. The current
bed, if any, will be disconnected. The software will then attempt to locate whose
patient ID corresponds to that supplied by the user. If no device contains the
specified identifier, or more than one monitor contains it, an error code will be
returned. Otherwise a SUCCESS code will be returned.
264 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
PatientWatch
Properties
DisableAsyncBoxes (BOOL)
When this property is set to TRUE, any message dialogs that would normally pop up asynchronously are
disabled. For example, if the patient monitor that is currently being viewed disappears from the network,
a popup would normally appear; with this option enabled, the popup dialog will no longer be displayed.
SinglePatientMode (BOOL)
When this property is set to TRUE and the web page subsequently invokes one of the methods that
automatically selects a patient, then the control goes into single patient mode. In this mode, the “Select
Patient” and the “Log Off” buttons are disabled.
Note, however, that if the SelectPatient method of the ActiveXcontrol is called, this setting is temporarily
overridden until one of the other patient selection methods are called.
SingleSignonMultiPatientMode
When this property is set to TRUE and the web page subsequently invokes one of the methods that
automatically selects a patient, then the control goes into single sign-on, multi-patient mode. In this mode,
the “Select Patient” button is disabled ONLY WHEN the user is not logged in, thereby forcing the user to
log on through the parent website.
Events
The Infinity PatientWatch ActiveX control will trigger the following events listed below.
Error Event
This event is triggered whenever a serious unrecoverable error is encountered within the ActiveX Control.
Select Event
This event is triggered whenever the mouse is clicked on the ActiveX control. No click event will be
triggered when a mouse click occurs within a dialog box.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 265
PatientWatch
Activity Event
This event is triggered whenever any mouse click or other activity occurs and is available so that the web
page containing the control can reset any active timeouts.
This event is triggered when the ActiveX control is in Multi-patient mode and the user selects a different
patient to view. The event contains the patient ID of the newly selected patient.
Logoff Event
This event is triggered when the user presses the Logoff button. The next time the user attempts to select
a patient, he/she will be prompted for user name and password.
Abort Event
This event is triggered more than 4 copies of the WinViewActiveX control are placed on a page or a
shortcut to a page containing one control is invoked more than 4 times. In the standard WebViewer.asp
page, this event triggers a redirection to a page reporting an error.
Map2Server Control
Map2Server is a server side asp object. This patient–to-server mapping mechanism allows custom web
applications to determine whether a patient, identified by Patient ID or Patient name, is available for
viewing through PatientWatch, and if so, the name of the Infinity Gateway Server through which the view
can be accessed.
It also can provide a global list of patients available on the network, across multiple Infinity Gateway
Servers for a specific user. Finally, it can authenticate a user name, password and domain on one server.
266 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
PatientWatch
Methods
GetErrorNum()
Purpose: This method returns the error number as a result of any other method calls.
Arguments: None
Return Value: 20: SUCCESS
21: FAILURE
22: FAILURE – Duplicate Patient Identification Number is on the network
23: FAILURE – Invalid user name or password
24: FAILURE – No Gateway servers are available
25: FAILURE – No Gateway servers are configured from the Configure
Servers
26: FAILURE – Invalid Patient ID
27: FAILURE – Patient ID not found on the network
28: FAILURE – Server List is not properly configured
29: FAILURE – Server List contains invalid or unavailable Gateway IP address
Description: This method will return a value which in return can be used to get the Error
String. The value returned can be determined by calling GetErrorString().
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 267
PatientWatch
GetErrorString()
GetPatientList()
Purpose: This method returns all the available patient monitors in all of the properly
configured Gateways. The logon method must be called first and return
SUCCESS.
Arguments: None
Return Value: 20: SUCCESS
21: FAILURE – User had not logged on
Description: This method will display in a pick list, all the active patient monitors. Only the
Gateway’s that are configured on the ServerList (Config. Servers) will be
searched. Also, only the patient monitors that the user has permissions for will
be returned.
GetServerForBedMCAddr()
Purpose: This method returns the specific Gateway server that a select patient monitor
with specified multicast address is connected to.
Arguments: Multicast address
Return Value: 20: SUCCESS
21: FAILURE – User has not logged on
22: FAILURE – Duplicate multicast address
24: FAILURE – No servers available for selected multicast address
26: FAILURE – Invalid multicast address
Description: This method is used to connect to a Gateway server that monitors a specific
patient monitor’s multicast address.
268 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
PatientWatch
GetServerForPatient()
Purpose: This method receives and returns the Gateway Server in which this is found.
If this patient is being monitored by more than one Gateway then the first
Gateway on the list is selected.
Arguments:
Return Value: 20: SUCCESS
21: FAILURE – User had not logged on to a Gateway server
22: FAILURE – Duplicate on the network
24: FAILURE – No Servers Available for selected Patient Id
26: FAILURE – Invalid Patient Id
27: FAILURE – Patient Id not found on any servers
Description: This method will return the first available Gateway server that has user
permissions to view a patient monitor with the selected. If the is not found or if
other errors occur this method will fail.
GSMLogon()
Purpose: This method logons on a user with the requirement of a valid GSM(Global
Session Manager) Session string and a valid GSM Server.
Arguments: GSMSession, GSMServer, Username
Return Value: 20: SUCCESS
23: FAILURE – Invalid Logon
24: FAILURE – No Servers Available to that user
25: FAILURE – No Servers have been configured
Description: This method will logon a user using a valid GSM Session and GSM Server. If
either are invalid and error will occur.
Logon()
Purpose: This method will logon a user to the first available Gateway Server on the list.
The logon will occur if the user is on the domain or a local user on the current
Gateway Server.
Arguments: Username, Password, Domain
Return Value: 20: SUCCESS
23: FAILURE – Invalid Logon
24: FAILURE – No Servers Available to that user
25: FAILURE – No Servers have been configured
Description: This method will logon a user using a valid GSM Session and GSM Server, if
either are invalid and error will occur.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 269
PatientWatch
SetServers()
Purpose: This method will add all servers in the list to map2server.
Arguments: Servers
Return Value: 20: SUCCESS
25: FAILURE – No servers have been configured
28: FAILURE – Invalid server list format
29: FAILURE – Invalid Server IP Address
Description: This method will display a disclaimer on the first invocation within a newly
instantiated ActiveX control. If the user has not yet logged on a server, a log
on dialog will be displayed. The patient selection dialog will then appear.
ValidateUser()
Purpose: This method verifies that a user attempting to logon to a Gateway Server is
using a valid user name and password. Also, that the user has valid
permissions.
Arguments: User, Password, Server
Return Value: 0: SUCCESS
1: FAILURE – Invalid user name or password
24: FAILURE – Selected Server is not available
Description: This method verifies that all arguments are valid then validates the user name
and password with the given Gateway server. If any of the arguments are
invalid or if the user doesnot have permissions a failure is returned.
If a default page was chosen upon installation of PatientWatch then either an Index.htm or default.htm file
is created in the top level folder for the Web server. This installed HTML file redirects to the Infinity
Gateway version of PatientWatch.
The PatientWatch file structure contains one main folder, Webviewer. This folder contains:
All the required asp (Active Server Page) include files.
Serverlist.inc, configurable from the Configure PatientWatch Servers (Start->Programs menu) and
upon install. This serverlist.inc file contains a list all available Infinity Gateway Servers.
A sample Sample Parent Page that invoke PatientWatch in different ways.
Two folders, Gateway and Explorer, each containing:
Frameset.asp, the page that should be invoked from any external application. When one patient is to
be displayed on the page.
270 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
PatientWatch
Frameset4.asp, the page that should be invoked from any external application. When four patients are
to be displayed on the page only in Explorer folder.
Webviewer.asp, this main PatientWatch page displays the WinViewActiveX WinViewActiveX Control
and the buttons and tabs.
NOTE
The Gateway folder contains a version of PatientWatch that can be resized dynamically. The Explorer
folder contains a version that cannot and also supports a 2x2 view.
Siemens Global Session Manager is supported but must be obtained from Siemens and installed
separately. This program allows users to move between multiple applications without having to logon to
each one it can also provide a patient context between the applications.
PatientWatch can run with or without GSM. With GSM, PatientWatch is running as a child of a parent page,
either Infinity Explorer or another parent such as NetAccess, Dashboard The parent page sets and
controls the timeout time of the child (PatientWatch) page.
If the GSM timeout expires, a redirection to a logon page provided by the parent will occur. However, if a
session cannot be validated, PatientWatch will be redirected to a log-off page.
GSM timer is reset upon any activity on the PatientWatch. Activity is deemed as pressing any tab or button
on the PatientWatch web page (i.e. not pressing a button within a dialog).
Included in the PatientWatch installation is a sample page that uses our proprietary parent-child
mechanism; this parent-child mechanism is the same one used by our Symphony product and does not
employ GSM. The sample page, TestDSMParentBase.htm, can be used to drive PatientWatch and is
provided so that our customers can model this mechanism on their own custom pages.
Before the page can be used, however, there are some dotnet trust configurations that are required. This
can be accomplished by running the cfgTestDSM.bat batch file included in
C:\inetpub\wwwroot\webviewer. It requires as an argument the name of the web server PC that is hosting
the TestDSMParentBase web page.
Once you start TestDSMParentBase.htm, the first thing that will appear is a logon page where you are
required to enter your user name, password, and domain. Note that the domain field is not required; if left
blank, the server-side control, Map2Server Control, will search for the first domain (starting with the local
server domain) for which the user name is valid. It will then validate the user name and password within
that domain.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 271
PatientWatch
Once the user name, password, and domain are validated successfully, a list of available patients for the
user is retrieved using another method in the Map2Server Control and presented to the user. Note that
only patients that have patient IDs entered will appear in the list.
This page has the following controls:
NOTE
In addition to the web page TestDSMParentBase.htm, this page requires the following support files:
– DraegerEncryption.dll to encode/decode URL parameters
– FetchPatientList.asp – retrieves the patient list from the server-side object Map2Server
– DSMParentBase.js – javascripts that are needed by the page to interface with DraegerEncryption.dll
NOTE
This sample page is provided to assist the customer in modeling their own implementation of invoking the
PatientWatch application from their hospital website. There are many ways to invoke the control and the
customer may choose to implement differently, however, the customer is responsible for the testing of any
custom web pages.
272 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
PatientWatch
URL arguments
PatientWatch can accept a variety of variables on the URL. When using these arguments, it is best to
encrypt them as they include sensitive information such as the identifier of the patient whose information
is to be viewed.
NOTE
This section does NOT address the mechanism that must be used in order to provide encrypted
arguments. Please refer to the source and description of the Sample Parent Page for more details.
In the PatientWatch URL, all the variables are in the form of 'variable=value' and each variable is
separated by an '&'.
Example (by patient ID):
//yourgatewaycomputer.com/Webviewer/Gateway/frameset.asp?Login=youruser&Pwd=yourpassword&
PatID=yourpatientID
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 273
PatientWatch
274 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
PatientWatch
Use of Arguments
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 275
PatientWatch
276 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Appendix A: Parameters
Appendix A: Parameters
CAUTION
The parameter tables map Dräger’s parameter labels and codes to corresponding HL7/LOINC and
MIB/CEN codes, when applicable. Most often, no HL7/LOINC and/or MIB/CEN codes exist which
approximate a description of the supported parameter. Otherwise, a similar, but not exact, HL7/LOINC
or MIB/CEN code is used to approximate a description of the parameter in question.
Review the codes below before use. Potential sources of the parameters are identified as Monitor, Mon-
itor/POD, Monitor/Ext, Monitor/MGM or ANESTH. “Monitor” or “patient monitor” refers to all Infinity mon-
itoring devices and may include Configured (Vista, Gamma/GammaXL), Modular (VistaXL, GammaXXL,
Delta/DeltaXL, Kappa, or KappaXLT) or Infinity Telemetry monitoring devices. ‘Monitor/POD’ refers to
modular monitors using a specific Infinity Pod. ‘Monitor/Ext’ refers to any Modular monitor connected to
a 3rd party device via MIB protocol converter or external Device Connection ‘Monitor/MGM’ refers to the
Scio MultiGas Module which connects to the network via a Modular Monitor. ‘ANESTH’ refers to a Dräger
LSS anesthesia workstation that also connects to the Infinity Network via a modular monitor.
The parameter tables are not intended to specify which parameters are available at a particular customer
site as this will vary depending on the specific patient monitors being used, the versions of software
installed on those patient monitors, the types and versions of pods being used, and the options pur-
chased for the patient monitors.
Reference the patient monitor’s instructions for use or contact a service representative for the necessary
configurations to generate certain parameters.
NOTE
The Parameter table has been moved to an Excel document. The Excel document, “Protocol Handbook
Appendices.xlsx”, which contains the Parameter table can be found in the Infinity Gateway installation
location or on the installation CD.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 277
This page has been left blank intentionally.
278 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Appendix B: Units of Measure
NOTE
The Unit of Measure table has been moved to an Excel document. The Excel document, "Protocol
Handbook Appendices.xlsx", which contains the Unit of Measure table can be found in the Infinity
Gateway installation location or on the installation CD.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 279
This page has been left blank intentionally.
280 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Appendix C: Special Display Values
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 281
Appendix C: Special Display Values
282 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Appendix D: Alarm States
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 283
This page has been left blank intentionally.
284 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Appendix E: Alarm Grades
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 285
This page has been left blank intentionally.
286 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Appendix F: Waveforms
Appendix F: Waveforms
NOTE
The Waveforms table has been moved to an Excel document. The Excel document, “Protocol Handbook
Appendices.xlsx”, which contains the Waveforms table can be found in the Infinity Gateway installation
location or on the installation CD.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 287
This page has been left blank intentionally.
288 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Appendix G: Operation Modes
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 289
This page has been left blank intentionally.
290 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Appendix H: 12-Lead ECG Output Format
NOTE
12 lead ECG output is only supported by Infinity devices.
#ifndef __FORMAT_H__
#define __FORMAT_H__
// data types
typedef unsigned char uchar;
typedef unsigned short ushort;
typedef unsigned long ulong;
// ECG Info
#define LEADCOUNT 15
#define LEADSIZ 5120
#define LEADSAMPLES (LEADCOUNT * LEADSIZ)
#define STMTCOUNT 50
#define STMTLEN 128
#define DESTBUFSIZ 100000
// Lead Definitions
#define LEAD_NOTPRESENT 0
#define LEAD_I 1
#define LEAD_II 2
#define LEAD_III 3
#define LEAD_AVR 4
#define LEAD_AVL 5
#define LEAD_AVF 6
#define LEAD_V1 7
#define LEAD_V2 8
#define LEAD_V3 9
#define LEAD_V4 10
#define LEAD_V5 11
#define LEAD_V6 12
#define LEAD_X 13
#define LEAD_Y 14
#define LEAD_Z 15
#define LEAD_C1 16
#define LEAD_C2 17
#define LEAD_C3 18
#define LEAD_C4 19
#define LEAD_C5 20
#define LEAD_C6 21
#define LEAD_CM5 22
#define LEAD_CC5 23
#define LEAD_V1R 24
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 291
Appendix H: 12-Lead ECG Output Format
#define LEAD_V2R 25
#define LEAD_V3R 26
#define LEAD_V4R 27
#define LEAD_V7 28
#define LEAD_V8 29
#define LEAD_V9 30
#define LEAD_USER1 31
#define LEAD_USER2 32
#define LEAD_USER3 33
// lsb values
#define LSB_1_00 0
#define LSB_2_44 1
#define LSB_2_50 2
#define LSB_4_88 3
#define LSB_5_00 4
// field lengths
#define PID_LEN 16
#define DATE_LEN 8
#define TIME_LEN 6
#define FNAME_LEN 20
#define LNAME_LEN 22
#define NAME_LEN 42
#define ROOM_LEN 8
#define DEPT_LEN 8
#define TECH_LEN 4
292 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Appendix H: 12-Lead ECG Output Format
#define USER_LEN 18
#define MANUF_LEN 8
#define MODEL_LEN 8
#define SERNBR_LEN 16
#define VER_LEN 8
#define REQNBR_LEN 12
// structures
typedef struct
{
char Pid[PID_LEN + 1]; // Patient ID
char AcqDate[DATE_LEN + 1]; // ECG Acquisition Date (MMDDYYYY)
char AcqTime[TIME_LEN + 1]; // ECG Acquisition Time (HHMMSS)
long ECGFormat; // ECG Format (presentation)
long Institution; // Location/Institution
long StatFlag; // Status Flag
char FName[FNAME_LEN + 1]; // Patient First Name
char LName[LNAME_LEN + 1]; // Patient Last Name
long AgeUnits; // Age Units
long AgeValue; // Number of <units> for Age
long Height; // Height
long UnitsHeight; // Imperial/Metric Units for Height
long Weight; // Weight
long UnitsWeight; // Imperial/Metric Units for Weight
long Sex; // Sex (0 = male, 1 = female)
long Race; // Race Code
long Systolic; // Systolic Blood Pressure
long Diastolic; // Diastolic Blood Pressure
char Room[ROOM_LEN + 1]; // Room Number – the Bed Label from the INFINITY monitor
char Dept[DEPT_LEN + 1]; // Department
char Tech[TECH_LEN + 1]; // Technician/Operator
long Drugs; // Drug Code
long Diag; // Diagnosis Code
char ReqDoctor[NAME_LEN + 1]; // Requesting Doctor's Name - last first
char ConfDoctor[NAME_LEN + 1]; // Confirming Doctor's Name - last first
long Confirmed; // Confirmed Flag (0 = unconfirmed, 1 = confirmed)
char ConfDate[DATE_LEN + 1]; // (MMDDYYYY)
char ConfTime[TIME_LEN + 1]; // (HHMMSS)
char ConfEditor[NAME_LEN + 1]; //
char UserA[USER_LEN + 1]; // User Field A
char UserB[USER_LEN + 1]; // User Field B
char ManufID[MANUF_LEN + 1]; // Manufacturer's ID
char CartModel[MODEL_LEN + 1]; // ECG Cart – Model #, the Infinity bed label with an X on the end.
char CartSerNbr[SERNBR_LEN + 1]; // ECG Cart - – Serial #
char CartVersion[VER_LEN + 1]; // ECG Cart - – Analysis Version # - This is the bedside monitor software
version
char ReqNbr[REQNBR_LEN + 1]; // Requisition #
long SampleRate; // Sample Rate (0 = 250, 1 = 500)
long LSBValue; // LSB value (see constant definitions)
long ArtFilter; // Artifact Filter
long BaseFilter; // Baseline Wander Filter
long ACFilter; // AC Filter
long LoPassFilter; // Front End Filter - – Low-pass filter
long HiPassFilter; // Front End Filter - – High-pass filter
long VLeadAmpl; // V-Lead Amplitude
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 293
Appendix H: 12-Lead ECG Output Format
typedef struct
{
char StmtText[STMTCOUNT][STMTLEN]; // Diagnosis Statements – Notes from Bedside
} ECGSTMTS; // 6400 bytes
typedef struct
{
long LeadID[LEADCOUNT]; // identifies each lead and whether present
short Lead[LEADCOUNT][LEADSIZ]; // 12 bit signed ECG data, Intel format
} ECGLEADS; // 153660 bytes
#endif
// end of file
294 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Appendix I: Troubleshooting Gateway M300 Connections
The Infinity Gateway communicates directly with the Infinity OneNet network. This allows trends from
attached and configured beds to be available to the Infinity Gateway. However, due to requirements of
M300 devices related to battery life, these devices must be installed on a separate network, usually on a
separate VLAN. As a result, the subnet may not be available and it may be necessary to configure
additional routing on the server for the Infinity Gateway product to access the separate M300 network.
Four network interfaces and configurations that allow Infinity Gateway to collect trends from an M300 are
as follows:
The first network interface includes the Infinity Gateway server with one NIC for the hospital and one NIC
for the Infinity Gateway. The Infinity Central Station includes one NIC for Infinity Gateway.
In this setup, the M300 VLan is connected to the Infinity Network through a wireless router, and the Infinity
Gateway is configured for both the Infinity and Hospital Networks. The ICS is configured to access the
M300 subnet through a router which can be used in the same manner for Infinity Gateway. To add the
router to the Infinity Gateway, open a command prompt as administrator and enter:
route –p add <M300 subnet> mask <subnet mask> <Router IP>
The command instructs the server to use the router to access the M300 subnet.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 295
Appendix I: Troubleshooting Gateway M300 Connections
The second network interface includes the Infinity Gateway server with one NIC for the hospital and one
NIC for the Infinity Gateway. There is also an Infinity Central Station with one NIC and the M300 with one
NIC.
With dual NICs, this network interface on the ICS directly communicates with the M300 subnet. There is
no stand-alone router device on the Infinity network. However the Infinity Central Station acts as a router
between the Infinity Network and the M300 subnet.
To add the router to the Infinity Gateway, an administrator opens a command prompt and enters the
following:
route –p add <M300 Subnet> mask <subnet mask> <IP of 1st NIC>
For example, the Infinity network’s first NIC has an IP address of 192.168.10.50 with a subnet of /24 or
255.255.255.0, and a second NIC IP address of 192.168.20.50 with a subnet of /24. In this case, all
M300s would have the second NIC IP address as the default Gateway, or 192.168.20.50. The command
to run on the Infinity Gateway is:
route –p add 192.168.20.0 mask 255.255.255.0 192.168.10.50
296 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Appendix I: Troubleshooting Gateway M300 Connections
The third network interface includes the Infinity Gateway server and one NIC, the Infinity Central Station
and one NIC, and the M300 and one NIC.
With dual NICs, a network interface on the ICS is used to communicate with the M300 subnet directly.
Therefore, there is no stand-alone router device on the Infinity network. However, the Infinity Central
Station acts as a router between the Infinity Network and the M300 subnet.
To add the router to the Infinity Gateway, open a command prompt as an administrator and type the
following:
route –p add <M300 Subnet> mask <subnet mask> <IP of 1st NIC>
For example, the Infinity Network’s first NIC has an IP address of 192.168.10.50 with a subnet of /24, or
255.255.255.0. The second NIC has an IP address of 192.168.20.50 and a subnet of /24. In this case, all
M300s would have the second NICs IP address as their default Gateway, or 192.168.20.50. Type the
following on the Infinity Gateway:
route –p add 192.168.20.0 mask 255.255.255.0 192.168.10.50
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 297
Appendix I: Troubleshooting Gateway M300 Connections
The forth network interface includes the Infinity Gateway server with one NIC and the Infinity Central
Station with one NIC. No action is required in this setup since the default router lets you communicate with
the M300 subnet.
To test whether the routing was successful, from the Gateway server open a command prompt and ping
the IP address of an M300. A successful ping indicates that the router was added successfully.
298 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
Appendix J: Relationship table
NOTE
The Relationship table has been moved to an Excel document. The Excel document, "Protocol Handbook
Appendices.xlsx", which contains the Relationship table, can be found in the Infinity Gateway installation
location or on the installation CD.
Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0 299
This page has been left blank intentionally.
300 Instructions for use – Infinity® Gateway Suite – Protocol Handbook – VF9.0
These instructions for use only apply to
Infinity Gateway Suite
Protocol Handbook VF9.0
with the Serial No.:
If no Serial No. has been filled in by Dräger,
these instructions for use are provided for
general information only and are not intended for
use with any specific machine or unit.
Distributed in USA by
3703522 – RI 03 en
© Drägerwerk AG & Co. KGaA
Edition: 4 – 2023-02
(Edition: 1 – 2019-03)