This document provides an overview of the Sunrise XA Monitored Device Interface. It describes the workflow of how device data is collected and integrated into Sunrise XA. Key components include the DataCaptor software, MonDev translators, and configuration workbooks for mapping device channels and locations. The document also addresses troubleshooting, purging data, and common questions.

1. SXA 3.5 Sunrise XA Monitored Device Interface Technical Airlift –Washington Conference Room Presented by Monisha Ghuman

2. Agenda Sunrise XA Monitored Device Interface Brief Overview /Process Flow Sunrise XA Capsule and Elink Brief Overview Elink User defined Queues MonDev Translators Sunrise XA HL7 Device Interface Configuration GUI SXA 3.5 Configuration /Mapping Workbooks Configuring Observation Parameter to Use Device Interface Data Troubleshooting the Sunrise XA Device Interface Purging Data Alarms References Key Contacts FAQ

3. Sunrise XA Monitored Device Interface Brief Overview /Workflow Description of the flow of data through the system: Devices gather physiological data from patients. Capsule Technologies ’Data Captor interfaces to Monitor device and does its own data polling (time period is configurable). Data Portal is the part of the DataCaptor system that sends data through a socket to the MonDev engine in a standard (HL7) format. MonDev validates messages using location identifier PV1-3 to match the active patient visit in the database and channel identifier to match the XA flowsheet parameter and after the mapping is done successfully the data gets stored into the temporary location called “unvalidated database”. A Sunrise XA user pulls the data into a flowsheet by double click time column header and verifies it.

4. Monitored Devices Workflow eLink Translator (MonDevDB.exe) eLink Translator (MonDevClient.exe) XA DB eLink Queue (MonitorInbound) HL7 Messages sent via TCP/IP with Devices Data from Devices TCP/IP Translator Listening on specified Port and IP Address for Inbound message Queued Reads Reads HL7 message for PID, PV1, OBR, OBX segments retrieving appropriate fields End User pulls the data from DB via Flowsheets 30 minutes prior to or after the time column Store Device Stats

5. Capsule and Elink Brief Overview DataCaptor is a data acquisition and distribution software that enables to collect data from all types of medical devices and use it in the clinical applications with various ancillary systems. DataCaptor is a software-only data acquisition tool that runs on Windows NT4 SP6, 2000 SP3, XP SP1 and Server 2003 systems, and sends data to clinical applications. DataCaptor collects all variable data from bedside medical devices through any type of communication hardware or through a direct connection to a bedside computer. DataCaptor retrieves and delivers real-time data from more than 250 different medical devices . Capsule Installation link : http://www.capsuletech.com/pgs/products/dc44download.htm# Elink Sunrise e-Link handles all Business and Data Access Logic for Monitored Devices. MonDevClient Translator MonDevDB Translator MonDev TestSrvr Translator Elink User-Defined Queues-The following user-defined queues must also be created and registered before running the interface. MonitorGarbageQueue MonitorGarbageFormatQueue MonitorInboundQueue SXAInboundTestDataQueue For specific instructions on creating and registering user-defined queues, consult the eLink User Guide.

6. Elink User-Defined Queues Error Handling Logic The conditions when the record gets inserted into Garbage Queue: If no MSH segment exists, then the translator outputs the record to garbage queue. If the message control ID is duplicated, outputs to garbage queue. If MSH-9 does not exist or it exists but it is not a supported message type, outputs to garbage queue. If MSH-11 Processing ID does not exist or it exists but it is not supported, outputs to garbage queue. If one of the segments of PID, PV1, OBR, OBX is missing, outputs to garbage queue . The conditions when the record gets inserted into Garbage Format Queue: If MSH-10 or MSH-12 or PID-3 or PV1-3 or OBR-7 or OBX-3 or OBX-3.1 or OBX-3.2 or OBX-5, or OBX-6, OBX-7 missing, outputs to garbage format queue. If OBX-5 is empty, discards the OBX result. In another word, the OBX result will not be updated to the database. The conditions when the record gets inserted into Monitor Inbound Queue Required queue for storing well-formed HL7 messages (those messages beginning with 0B and ending in a 1C0D, with each segment ending in a 0D) to be processed by MonDevDB translator and sent on to SunriseXA.

7. MonDev Translators The MonDevClient is a TCP/IP client translator that receives HL7 messages from Capsule Technologies DataCaptor and inputs the messages into the Monitor Inbound Queue. The MonDevDB translator is a timer translator that reads HL7 messages from the MonitorInbound Queue. It checks the integrity of the HL7 messages and then transfers the patient observation data into the unvalidated database observation table. The MonDevTestSrvr translator is a TCP/IP server used only for testing. This would not be part of the production interface. This translator reads the SXAInboundTestData queue after the MonDevClient translator connects and opens the socket.

8. HL7 Fields Used by Monitored Device Interface Patient Location Fields PID-3 (Patient ID): Patient’s medical record number, used for associating results with the patient’s device database. PV1-3 (Assigned Patient Location): Patient’s bed mapping location, used for associating results with patient’s device database. Alternative to PID-3, if present. Observation Fields OBR-7 (Observation Date and Time): Device Date and Time for results ,used for linking results to a specific time column on the flowsheet. OBX-3.1 (Observation Identifier, parameter code): Device EMFC or parameter code, used to map the channel to the SunriseXA internal device database parameter label. OBX-3.2 (Observation Identifier, parameter label): Device parameter label, used to map the channel to the SunriseXA internal device database parameter label. OBX-5 (Observation Value): Device results stored into the SunriseXA internal device database. Note: Device channel numbers can be long and confusing. To configure the Device Interface to use names that are easier to read, use OBX-3.2 when mapping channels. OBX-6 (Units): Units, if present, stored with results into the SunriseXA device database. OBX-7 (References Range): Reference range, if present, stored with results into the SunriseXA device database.

9. HL7 Fields Used by Monitored Device Interface Sample Data MSH|^~\&|INST-MCAR|EnConcert|SCM|SCM|||ORU^R01|HP1012910670670815|P|2.3||||||8859/1 PID|||103-23-12||JEANNE ALLEN||||||||||||||||||||||||| PV1||I|^^CCU 8&8&1||||||||||||||||||||||||||||||||||||||||||||||||| OBR|||||||20020205070430|||||||||||||||||||||||||||||||||||| OBX|1|NM|92^RR^SDN|0|16|||||||||||| OBX|2|NM|44^PULSE^SDN|0|80|||||||||||| OBX|3|NM|188^SpO2^SDN|0|93|||||||||||| OBX|4|NM|40^HR^SDN|0|122|||||||||||| OBX|5|NM| 65 ^ ABP S ^SDN|0| 64 |||||||||||| OBX|6|NM| 66 ^ABP D^SDN|0| 60 |||||||||||| OBX|7|NM|67^ABP M^SDN|0|61|||||||||||| OBX|8|NM|71^CVP M^SDN|0|8|||||||||||| OBX|9|NM|512^PERF^SDN|64|2.4|||||||||||| OBX|10|ST|144^ECTOP^SDN|64| |||||||||||| OBX|11|ST|140^RHYTHM^SDN|64|SINUS TACHY |||||||||||| OBX|12|ST|136^VPB^SDN|64|PVC 0 |||||||||||| OBX-3.1-Channel Number- - Device EMFC or parameter code OBX-3.5- Observation Value seen on the SXA flowsheets OBX-3.2- Device Parameter label

10. Messages and Segments supported by the Interface Message supported by the HL7 device interface: Inbound messages: ORU^R01Result Message Segments Supported by the Interface: MSH PID PV1 OBR OBX

11. SunriseXA HL7 Device Interface Configuration GUI Before installing and configuring the SunriseXA HL7 Device Interface configuration tool, it is important to install Sunrise eLink. For specific instructions on installing Sunrise eLink, please consult the Sunrise eLink Installation Guide. » Note: This tool only applies to the translator MonDevDB. It is actually the GUI tool for modifying the INI file associated with the translator MonDevDB. This tool is just for testing purposes.

12. SXA 3.5 Configuration/Mapping Workbooks Overview MonDev receives mnemonics for locations and parameters from devices. These mnemonics must be matched to the appropriate SunriseXA values for data to be successfully pulled into flowsheets. DevIntfChannels: This table maps device channels (delivered in OBX 3.1 or OBX 3.2) to a ‘DeviceObject Label’ (‘DeviceObjLabel’ in workbooks) that will be used by SunriseXA to identify the correct observation parameters to receive data.

13. Documentation Workbook (DevIntChannels) OBX||NM| 40 ^HR^SDN|0|101 (Channel 40 would be mapped to DeviceObjLabel U_HR)

14. Documentation Workbook( DevIntfMonChannelMapList) This table maps Device Object Labels to SunriseXA observation channels and descriptions. This table is facility based, each facility could have a unique description for the same in-coming message. This table is used to PULL out the monitor channel description in the UI. DeviceObjLabel ‘U_HR’ would be mapped to SunriseXA Observation ‘Heart Rate’:

15. DevIntfBedMapList MonDev can use Medical Record Number and/or location to identify patients. Typically, devices do not supply Medical Record Numbers, so location is used by MonDev to find which patient should receive data contained in a particular message. However, devices do not send SunriseXA locations. Typically, a device ID is sent in the location field . This workbook maps device IDs from devices delivered in PV1-3 to SunriseXA patient locations, contained in the Facility, Unit, Room, and Bed fields of the workbook.

16. Documentation Workbook( DevIntfBedMapList) MSH|^~\&|INST-CAR|EnConcert|SCM|SCM|||ORU^R01|HP1012910670670815|P|2.3||||||8859/1 PID|||103-23-12||JEANNE ALLEN||||||||||||||||||||||||| PV1||I |^^CCU 8&8&1 ||||||||||||||||||||||||||||||||||||||||||||||||| OBR|||||||20020205070430|||||||||||||||||||||||||||||||||||| OBX|1|NM|92^RR^SDN|0|16|||||||||||| OBX|2|NM|44^PULSE^SDN|0|80|||||||||||| The patient location CCU881 in HL7 message(PV1-3) would map to the location NGH Unit 1E Room 21 Bed B See Appendix F, “Documentation Workbook Fields” in the SunriseXA Express Load Reference Guide for complete information on the data needed for these worksheets.

17. Setting Observation Parameter Item Options using Add / Modify Observation Item In the Configuration Tools “Observation Catalog” you can configure observation parameter items to use data received via an external device using the Add Observation Item or Modify Observation Item window. When “From Device Interface” check box is selected, you can choose the Monitor Channel Description from the Monitor Channel list. DeviceObjLabel ‘U_HR’ would be mapped to SunriseXA Observation ‘Heart Rate’. Note: This MonChannel description is coming in via the MonChannelDesc column of the SCMDevIntfMonChannelMapList Table.

18. Getting Device Interface Data into a Flowsheet Device interface data is held in the unvalidated database table(SCMDevIntfData) for 48 hours and can be accessed by clicking on a time column during flowsheet charting. All data for individual patients have date, time, and cell values for individual observation parameters. When a select user clicks on a time column header, the system automatically retrieves data from the unvalidated database table closest to the time column, 30 minutes prior to or after the time column, but not beyond the current date and time.

19. Purging Data Configuring Purge Schedules- Data stored in SCMDevIntfData table in the database on the SunriseXA database is stored for 48 hours , after which it is purged. After installing the Device Interfaces, you must configure the purge schedule. Refer SunriseXA Monitored Device Interface Configuration Guide for configuring purge schedules

20. Alarms in MonDev Translators Conditions under which Alarms would be fired from MonDev translators in Production: If MonDevClient.ini or MonDevDB.ini is not at ewebit\ directory, the translator fires alarm writes log messages to eLink log. If MonDevClient.ini or MonDevDB.ini does not have all the required entries in it, the translator fires alarm and writes log messages to eLink log. If MonDevClient translator received CLOSE, the translator fires alarm, writes log messages to eLink log . If a connection could not be made to SXA database at the initialization of the MonDevDB translator, the translator fires an alarm . There is an INI setting which defines the threshold of the times in a row the HL7 messages could be rejected due to database operation failure. If the threshold is reached, the translator fires two alarms, writes log messages to eLink log .

21. Troubleshooting Checking Data Flow Unvalidated results table- Verify if the data is populating into the table “SCMDEVINTFDATA” .If data is not accumulating in this table, check the MonDevDB translator . MonDevDB- Verify if there are rejected records in the MonitorInbound queue, if there are check the eLink log to see what problems were encountered while these records were being processed. MonDevClient- Verify if the messages are accumulating in the MonitorInbound queue, if not verify DataCaptor is connecting and sending messages. Checking SunriseXA Configuration If the device sends Medical Record Numbers (PID-3), make sure that these MRN’s exist in SunriseXA and are assigned to the correct patient. If the device sends a device ID in PV1-3, make sure that there is an entry in the bed map (DevIntfBedMapList) for that device. Make sure only one patient was assigned to the location in the SXA application at the time of the observation. If the device sends both PID-3 and PV1-3, make sure that the patient was in that location at the time of the observation.

22. References Sunrise eLink Installation Guide Sunrise eLink User Guide SunriseXA Clinical Documentation Configuration Guide - Appendix A Configuring Device Interfaces SunriseXA HL7 Mapping Interface Reference Guide HL7 Standard version 2.3 SunriseXA User Guide SunriseXA Installation Guide SunriseXA 2003 r1 Installation Guide - Appendix C, Configuring Device Interfaces

23. Key Contacts Capsule (Data Captor): Contact Scott Elliot Work Phone:(520)907-6057 Sunrise e-link: Contact Bill Duffin Work Phone:(678)256-4544 Cell Phone: (678)852-4687 Flowsheets: Contact Charles Cooley Work Phone:(360)-853-9421 Cell Phone: (360)-7708443 Ordering Monitored Care Device: Call Eclipsys Customer support to order the software. Documentation for the Monitored Device Interface can be found on SOLAsphere . Call 1-888-GET-HELP .

24. FAQ 1. Is there any way to know if the patient is hooked up to the monitor device or not ? Most of monitor devices have no way of knowing whether a patient is actually hooked up to the device or not and will continually spit out data (some are configurable as to how often while others are not.) 2. Does Data Captor polls the data continuously from the monitor devices or is it time configurable? It's Data captor's job to do its own polling and the time period is definitely configurable . The users need to tell DataCaptor which parameters to pass through, and how often. 3. If data captor is continuously polling data every sec from the monitor device then what data the user actually sees on the flowsheet as the time columns are added based on minutes and not seconds ? The data that is actually pulled on the flowsheet on a particular time column would be the closest occurrence to that newly added time column and not the most recent occurrence . For Example: If the data is getting into the unvalidated database at the same time e.g. Recordedat DevIntVal1 DeviceObjlabel 2004-04-21 09:45:31.000 100 U_HR 2004-04-21 09:45:32.000 105 U_HR 2004-04-21 09:45:35.000 98 U_HR The data that would be pulled on the flowsheet for the time column added on 2004-04-21 at 09:45 for the observation Heart Rate would be “100” as this is the closest occurrence to the time column added.

25. FAQ 4. The system will find the data closest to a time column, 30 minutes before or after the time column date/time. What happens in the case of a tie.? We take the value that precedes the time column. For example: If the time column is (hh, mm, ss) 09:01:00 And there is data 15 seconds prior to this 09:00:45 And there is also data 15 seconds after this: 09:01:15 We will take the data from 09:00:45 5.If the OBX-3.1 (Channel Numbers) are too long then how would the user map the channels.? Can the user use OBX3.2 instead of OBX3.1? Yes, if the device channel numbers are too long and confusing the user have the option to configure the Device Interface to use names that are easier to read and use OBX-3.2 instead of OBX3.1 when mapping channels. Looking at the data below : OBR|||||||20020205070430|||||||||||||||||||||||||||||||||||| OBX|1|NM| 92900000005678 ^ RR ^ SDN|0|16|||||||||||| OBX|2|NM| 445555555555 ^ PULSE ^SDN|0|80||||||||||||

26. Q & A Well its time to pick m y brain!!!!