Clin Doc Device Interfaces Technical Airlift

1,377 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,377
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 01/12/10
  • 01/12/10
  • 01/12/10 -. DataCaptor is a software that pings these monitor devices and polls the data from these devices, translates the data into HL7 format and then this data is sent to MonDev Engine thru a socket or a TCP/IP connection. - Monitor Device Interface is a process that allows observations from the devices like heart rate monitor etc which are connected to data captor .Data captor polls the data from these monitor devices ,translates the data into standard Hl7 format and sends this data thru a socket to the MonDev engine . So data captor acts as a middleware between medical device and our Elink Monitor Device engine . -MonDev does all the data validations in terms of the required segments and fields ,in terms formatting errors, in terms of mappings using location identifier PV1-3 to match the active patient visit in the DB and mappings using channel identifier to match the observation data with the XA Flowsheet parameter and then when a message is matched the observation data is stored in the XA unvalidated database . Once it gets into the database the user is able to pull the data on the flowsheets by a double click time column header within a window of +/- 30mins i.e. 30 minutes prior to or after the time column but not beyond the current date and time
  • 01/12/10 -Devices send the data -Data Captor polls the data from the devices, translates the data into HL7 format and sends the data thru the TCP/IP connection to the Elink MonDevClient translator -MonDevClient translator outputs the data to the Monitor inbound Q -MonDevDB translator reads the data from the Monitor Inbound Q ,validates the data using the location identifier PV1-3 and channel identifier and once the data is mapped successfully it gets stored into the temp location called unvalidated database -The user can go into the application ,flowsheet tab and pull the data with a double click time column header
  • 01/12/10 -Data Captor is a software that collects data from around 250 bed side medical devices and then that data could be used in the clinical applications used by different ancillaries -Monitor Inbound Q –Messages in this Q pass the QA check in terms all the mappings and formatting. These are well formatted messages
  • 01/12/10 -Its imp to remember over here that Monitor Garbage Format Q records the formatting errors but these message do get forwarded to XA.This Q just flags the warnings that there some errors in the message -Monitor Garbage Q –This Q records all the critical errors in the message and these are never forwarded to XA -Monitor Inbound Queue- -All the messages that pass the QA check in terms of formatting, location mappings, channels mappings get forwarded to Monitor Inbound Queue
  • 01/12/10 -MonDevClient Translator-It receives the messages from datacaptor and writes the messages to Monitor Inbound Q
  • 01/12/10
  • 01/12/10
  • 01/12/10
  • 01/12/10 This GUI tools is used to modify INI file. .Do not have to manually go to the INI file to make a change in terms of the Database connections etc.
  • 01/12/10
  • 01/12/10
  • 01/12/10 This table is facility based. Each facility in the hospital can define a unique description for the same in-coming message
  • 01/12/10 Some hospitals use MRN which is the PID-3 to identify the patient whereas some hospitals might use PV1-3 to identify the patients. Typically, devices do not supply Medical Record Numbers so PV1-3 is used to identify which patient should receive data contained in a message.
  • 01/12/10
  • 01/12/10 Demo the Config Tools
  • 01/12/10
  • 01/12/10
  • 01/12/10
  • 01/12/10 -Verify if the data is populating into the table “SCMDEVINTFDATA” table. If data is not accumulating in this table, check the MonDevDB translator. -If PV1-3 is used for mapping purposes then its very imp to remember that the patient has to be in that location at the time of the observation. If not the stored proc will fail and the data will never be seen on the flowsheet
  • 01/12/10
  • 01/12/10
  • 01/12/10 1.For Example if data captor is configured to pull the data every sec then data captor pings the device every sec to spit out the data to it. Right now data captor is configured to ping the device every 2 secs and during that time it appears that we are receiving 3 records . If we want pulse rate every fifteen minutes, we can tell DataCaptor to give us the highest value during that time, or the average, or a few other options .
  • 01/12/10 -We will take the data 15 secs prior and not after as it is clinically more correct to take data in the past than in the future. -Demo the channels number column of the documentation workbook and show that RR which is OBX-3.2 WOULD BE thrown in ,in the channel number column if mapping is done based on OBX-3.2 and not OBX-3.1.
  • 01/12/10
  • Clin Doc Device Interfaces Technical Airlift

    1. 1. SXA 3.5 Sunrise XA Monitored Device Interface Technical Airlift –Washington Conference Room Presented by Monisha Ghuman
    2. 2. Agenda <ul><li>Sunrise XA Monitored Device Interface Brief Overview /Process Flow </li></ul><ul><li>Sunrise XA Capsule and Elink Brief Overview </li></ul><ul><li>Elink User defined Queues </li></ul><ul><li>MonDev Translators </li></ul><ul><li>Sunrise XA HL7 Device Interface Configuration GUI </li></ul><ul><li>SXA 3.5 Configuration /Mapping Workbooks </li></ul><ul><li>Configuring Observation Parameter to Use Device Interface Data </li></ul><ul><li>Troubleshooting the Sunrise XA Device Interface </li></ul><ul><li>Purging Data </li></ul><ul><li>Alarms </li></ul><ul><li>References </li></ul><ul><li>Key Contacts </li></ul><ul><li>FAQ </li></ul>
    3. 3. Sunrise XA Monitored Device Interface Brief Overview /Workflow <ul><li>Description of the flow of data through the system: </li></ul><ul><li>Devices gather physiological data from patients. </li></ul><ul><li>Capsule Technologies ’Data Captor interfaces to Monitor device and does its own data polling (time period is configurable). </li></ul><ul><li>Data Portal is the part of the DataCaptor system that sends data through a socket to the </li></ul><ul><li>MonDev engine in a standard (HL7) format. </li></ul><ul><li>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”. </li></ul><ul><li>A Sunrise XA user pulls the data into a flowsheet by double click time column header and verifies it. </li></ul>
    4. 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. 5. Capsule and Elink Brief Overview <ul><ul><li>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. </li></ul></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>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 . </li></ul></ul><ul><ul><li>Capsule Installation link : </li></ul></ul><ul><ul><li>http://www.capsuletech.com/pgs/products/dc44download.htm# </li></ul></ul><ul><ul><li>Elink </li></ul></ul><ul><ul><li>Sunrise e-Link handles all Business and Data Access Logic for Monitored Devices. </li></ul></ul><ul><ul><li>MonDevClient Translator </li></ul></ul><ul><ul><li>MonDevDB Translator </li></ul></ul><ul><ul><li>MonDev TestSrvr Translator </li></ul></ul><ul><ul><li>Elink User-Defined Queues-The following user-defined queues must also be created and registered before running the interface. </li></ul></ul><ul><ul><li>MonitorGarbageQueue </li></ul></ul><ul><ul><li>MonitorGarbageFormatQueue </li></ul></ul><ul><ul><li>MonitorInboundQueue </li></ul></ul><ul><ul><li>SXAInboundTestDataQueue </li></ul></ul><ul><ul><li>For specific instructions on creating and registering user-defined queues, consult the eLink User Guide. </li></ul></ul>
    6. 6. Elink User-Defined Queues Error Handling Logic <ul><li>The conditions when the record gets inserted into Garbage Queue: </li></ul><ul><li>If no MSH segment exists, then the translator outputs the record to garbage queue. </li></ul><ul><li>If the message control ID is duplicated, outputs to garbage queue. </li></ul><ul><li>If MSH-9 does not exist or it exists but it is not a supported message type, outputs to garbage queue. </li></ul><ul><li>If MSH-11 Processing ID does not exist or it exists but it is not supported, outputs to garbage queue. </li></ul><ul><li>If one of the segments of PID, PV1, OBR, OBX is missing, outputs to garbage queue . </li></ul><ul><li>The conditions when the record gets inserted into Garbage Format Queue: </li></ul><ul><li>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. </li></ul><ul><li>If OBX-5 is empty, discards the OBX result. In another word, the OBX result will not be updated to the database. </li></ul><ul><li>The conditions when the record gets inserted into Monitor Inbound Queue </li></ul><ul><li>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. </li></ul>
    7. 7. MonDev Translators <ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
    8. 8. HL7 Fields Used by Monitored Device Interface <ul><li>Patient Location Fields </li></ul><ul><li>PID-3 (Patient ID): Patient’s medical record number, used for associating </li></ul><ul><li>results with the patient’s device database. </li></ul><ul><li>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. </li></ul><ul><li>Observation Fields </li></ul><ul><li>OBR-7 (Observation Date and Time): Device Date and Time for results ,used for linking results to a specific time column on the flowsheet. </li></ul><ul><li>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. </li></ul><ul><li>OBX-3.2 (Observation Identifier, parameter label): Device parameter label, used to map the channel to the SunriseXA internal device database parameter label. </li></ul><ul><li>OBX-5 (Observation Value): Device results stored into the SunriseXA internal device database. </li></ul><ul><li>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. </li></ul><ul><li>OBX-6 (Units): Units, if present, stored with results into the SunriseXA device database. </li></ul><ul><li>OBX-7 (References Range): Reference range, if present, stored with results </li></ul><ul><li>into the SunriseXA device database. </li></ul><ul><li> </li></ul>
    9. 9. HL7 Fields Used by Monitored Device Interface Sample Data <ul><li>MSH|^~&|INST-MCAR|EnConcert|SCM|SCM|||ORU^R01|HP1012910670670815|P|2.3||||||8859/1 </li></ul><ul><li>PID|||103-23-12||JEANNE ALLEN||||||||||||||||||||||||| </li></ul><ul><li>PV1||I|^^CCU 8&8&1||||||||||||||||||||||||||||||||||||||||||||||||| </li></ul><ul><li>OBR|||||||20020205070430|||||||||||||||||||||||||||||||||||| </li></ul><ul><li>OBX|1|NM|92^RR^SDN|0|16|||||||||||| </li></ul><ul><li>OBX|2|NM|44^PULSE^SDN|0|80|||||||||||| </li></ul><ul><li>OBX|3|NM|188^SpO2^SDN|0|93|||||||||||| </li></ul><ul><li>OBX|4|NM|40^HR^SDN|0|122|||||||||||| </li></ul><ul><li>OBX|5|NM| 65 ^ ABP S ^SDN|0| 64 |||||||||||| </li></ul><ul><li>OBX|6|NM| 66 ^ABP D^SDN|0| 60 |||||||||||| </li></ul><ul><li>OBX|7|NM|67^ABP M^SDN|0|61|||||||||||| </li></ul><ul><li>OBX|8|NM|71^CVP M^SDN|0|8|||||||||||| </li></ul><ul><li>OBX|9|NM|512^PERF^SDN|64|2.4|||||||||||| </li></ul><ul><li>OBX|10|ST|144^ECTOP^SDN|64| |||||||||||| </li></ul><ul><li>OBX|11|ST|140^RHYTHM^SDN|64|SINUS TACHY |||||||||||| </li></ul><ul><li>OBX|12|ST|136^VPB^SDN|64|PVC 0 |||||||||||| </li></ul>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. 10. Messages and Segments supported by the Interface <ul><li>Message supported by the HL7 device interface: </li></ul><ul><li>Inbound messages: ORU^R01Result Message </li></ul><ul><li>Segments Supported by the Interface: </li></ul><ul><li>MSH </li></ul><ul><li>PID </li></ul><ul><li>PV1 </li></ul><ul><li>OBR </li></ul><ul><li>OBX </li></ul>
    11. 11. SunriseXA HL7 Device Interface Configuration GUI <ul><li>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. </li></ul><ul><li>» 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. </li></ul>
    12. 12. SXA 3.5 Configuration/Mapping Workbooks <ul><li>Overview </li></ul><ul><li>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. </li></ul><ul><li>DevIntfChannels: </li></ul><ul><li>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. </li></ul>
    13. 13. Documentation Workbook (DevIntChannels) OBX||NM| 40 ^HR^SDN|0|101 (Channel 40 would be mapped to DeviceObjLabel U_HR)
    14. 14. Documentation Workbook( DevIntfMonChannelMapList) <ul><li>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. </li></ul>DeviceObjLabel ‘U_HR’ would be mapped to SunriseXA Observation ‘Heart Rate’:
    15. 15. DevIntfBedMapList <ul><li>MonDev can use Medical Record Number and/or location to identify patients. </li></ul><ul><li>Typically, devices do not supply Medical Record Numbers, so location is used </li></ul><ul><li>by MonDev to find which patient should receive data contained in a particular </li></ul><ul><li>message. However, devices do not send SunriseXA locations. Typically, a </li></ul><ul><li>device ID is sent in the location field . This workbook maps device IDs from </li></ul><ul><li>devices delivered in PV1-3 to SunriseXA patient locations, contained in the </li></ul><ul><li>Facility, Unit, Room, and Bed fields of the workbook. </li></ul>
    16. 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. 17. Setting Observation Parameter Item Options using Add / Modify Observation Item <ul><li>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. </li></ul><ul><li>When “From Device Interface” check box is selected, you can choose the Monitor Channel Description from the Monitor Channel list. </li></ul>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. 18. Getting Device Interface Data into a Flowsheet <ul><li>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. </li></ul>
    19. 19. Purging Data <ul><li>Configuring Purge Schedules- </li></ul><ul><li>Data stored in SCMDevIntfData table in the database on the </li></ul><ul><li>SunriseXA database is stored for 48 hours , after which it is purged. After </li></ul><ul><li>installing the Device Interfaces, you must configure the purge schedule. </li></ul><ul><li>Refer SunriseXA Monitored Device Interface Configuration Guide for configuring purge schedules </li></ul>
    20. 20. Alarms in MonDev Translators <ul><li>Conditions under which Alarms would be fired from MonDev translators in Production: </li></ul><ul><li>If MonDevClient.ini or MonDevDB.ini is not at ewebit directory, the translator fires alarm writes log messages to eLink log. </li></ul><ul><li>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. </li></ul><ul><li>If MonDevClient translator received CLOSE, the translator fires alarm, writes log messages to eLink log . </li></ul><ul><li>If a connection could not be made to SXA database at the initialization of the MonDevDB translator, the translator fires an alarm . </li></ul><ul><li>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 . </li></ul>
    21. 21. Troubleshooting <ul><li>Checking Data Flow </li></ul><ul><li>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 . </li></ul><ul><li>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. </li></ul><ul><li>MonDevClient- Verify if the messages are accumulating in the MonitorInbound queue, if not verify DataCaptor is connecting and sending messages. </li></ul><ul><li>Checking SunriseXA Configuration </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>Make sure only one patient was assigned to the location in the SXA application at the time of the observation. </li></ul><ul><li>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. </li></ul>
    22. 22. References <ul><li>Sunrise eLink Installation Guide </li></ul><ul><li>Sunrise eLink User Guide </li></ul><ul><li>SunriseXA Clinical Documentation Configuration Guide - Appendix A </li></ul><ul><li>Configuring Device Interfaces </li></ul><ul><li>SunriseXA HL7 Mapping Interface Reference Guide </li></ul><ul><li>HL7 Standard version 2.3 </li></ul><ul><li>SunriseXA User Guide </li></ul><ul><li>SunriseXA Installation Guide </li></ul><ul><li>SunriseXA 2003 r1 Installation Guide - Appendix C, Configuring Device Interfaces </li></ul>
    23. 23. Key Contacts <ul><li>Capsule (Data Captor): </li></ul><ul><li>Contact Scott Elliot </li></ul><ul><li>Work Phone:(520)907-6057 </li></ul><ul><li>Sunrise e-link: </li></ul><ul><li>Contact Bill Duffin </li></ul><ul><li>Work Phone:(678)256-4544 </li></ul><ul><li>Cell Phone: (678)852-4687 </li></ul><ul><li>Flowsheets: </li></ul><ul><li>Contact Charles Cooley </li></ul><ul><li>Work Phone:(360)-853-9421 </li></ul><ul><li>Cell Phone: (360)-7708443 </li></ul><ul><li>Ordering Monitored Care Device: </li></ul><ul><li>Call Eclipsys Customer support to order the software. Documentation for the Monitored Device Interface can be found on SOLAsphere . Call 1-888-GET-HELP . </li></ul>
    24. 24. FAQ <ul><li>1. Is there any way to know if the patient is hooked up to the monitor device or not ? </li></ul><ul><li>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.) </li></ul><ul><li>2. Does Data Captor polls the data continuously from the monitor devices or is it time configurable? </li></ul><ul><li>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. </li></ul><ul><li>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 ? </li></ul><ul><li>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: </li></ul><ul><li>If the data is getting into the unvalidated database at the same time e.g. </li></ul><ul><li>  Recordedat                                    DevIntVal1  DeviceObjlabel </li></ul><ul><li>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 </li></ul><ul><li>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. </li></ul>
    25. 25. FAQ <ul><li>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.? </li></ul><ul><li>We take the value that precedes the time column. </li></ul><ul><li>For example: </li></ul><ul><li>If the time column is (hh, mm, ss) 09:01:00 </li></ul><ul><li>  And there is data 15 seconds prior to this  09:00:45 </li></ul><ul><li>And there is also data 15 seconds after this: 09:01:15 </li></ul><ul><li>  We will take the data from 09:00:45 </li></ul><ul><li>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? </li></ul><ul><li>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. </li></ul><ul><li>Looking at the data below : </li></ul><ul><li>OBR|||||||20020205070430|||||||||||||||||||||||||||||||||||| </li></ul><ul><li>OBX|1|NM| 92900000005678 ^ RR ^ SDN|0|16|||||||||||| </li></ul><ul><li>OBX|2|NM| 445555555555 ^ PULSE ^SDN|0|80|||||||||||| </li></ul>
    26. 26. Q & A Well its time to pick m y brain!!!!

    ×