POSTER SESSION. Wireless Cardiology Decision Support System. Proceedings Paper. Slide Presentation. Dr. Saji Salam SSI Technologies Chennai, India

Transcription

1 Proceedings Paper Slide Presentation Handouts Case Study POSTER SESSION Wireless Cardiology Decision Support System 16 Dr. Saji Salam SSI Technologies Chennai, India Anand Subramanian Software Solutions Integrated Chennai, India Dr. Anita Thampy Healthtoall.com Chennai, India COPYRIGHT 2001 BY THE HEALTHCARE INFORMATION AND MANAGEMENT SYSTEMS SOCIETY. 1

2 INTRODUCTION Mobile access to information has become the key to success in many business sectors where right information at the right time is crucial for decision-making. A sector that would benefit substantially from the benefits of mobile communication is healthcare, where timely access to clinical information is more than crucial. Physicians stand to gain immensely from the technology, given the nature of their work and the associated mobility. Immense pressures are mounting on physicians and healthcare organizations to control cost and provide quality care. Reimbursement is being constantly reduced; performance is being dissected while the demand for quality improvements continue. The pressures on revenue generation force physicians to stretch their time to accommodate more patients in the office and in the hospitals. Regulatory and other administrative work adds to the pressure on time. Physicians working in specialties such as cardiology have to respond in real-time to salvage a case. It is crucial that the attending cardiologist is alerted of an emergency without delay so that she can take instantaneous action. Current communication mechanisms include an assortment of phone calls, faxes, paging services etc. Often the attending cardiologist may not be available at a reachable distance to provide care. Many a time trying to reach the attending cardiologist on the phone consumes precious time. Time would then be spent on explaining the case to the cardiologist, which takes time as well. This paper describes how wireless technology could be used to provide to provide cardiology decision support on a WAP enabled mobile phone. The wireless cardiology decision support system (WCDSS) addresses these issues and provides a viable solution to make alert the cardiologist in real time and provide information on the condition of a patient. THE WIRELESS CARDIOLOGY DECISION SUPPORT SYSTEM (WCDSS) The WCDSS is a real time WAP enabled push technology, which listens in on the hospital s cardiology monitoring workstation. When a patient has cardiac emergency an alert message, which comprises the patient s name, and the immediate cardiac complication is sent to the cardiologist. (the user) The mobile phone will display the three options in the menu. More Information The cardiologist can then obtain clinical information of the patient available on the hospital database using his WAP enabled phone. Thus the cardiologist can obtain more information about the patient from the medical record. Treatment options/ Custom treatment plan This will display on the micro browser, a list of predefined treatment protocols for the emergency conditions. The cardiologist can then choose one from the displayed list of protocols by selecting the options using the keypad. If the cardiologist wishes to opt for a plan other than the standard protocols available, there is provision for a custom treatment plan. The user can type in custom treatment plan on the browser if required. The system design is based on the Push Message Specification of WAP. WIRELESS APPLICATION PROTOCOL The Wireless Application Protocol (WAP) standard specifies the basics prerequisites for wireless communication on a browser. The application protocol is a layered communication protocol that is embedded in each WAP-enabled user agent. A WAP application consists of a server application and a client application that the gateway downloads from the application server to the user agent for execution. WAP defines a standard application environment (Wireless application Environment) for the user agent. The browser has the capability to handle content described in Wireless Markup Language (WML), and also has a built-in script interpreter for running script applications in the user agent. The script applications are written in WMLScript. The browser also contains content formats to interpret data and images and other objects. The WAP communication protocol has the following layers: Session layer consists of services for browsing applications. Transaction layer provides a reliable transaction service over the wireless network HIMSS Proceedings: Posters Poster Session 16 / Page 2

3 Wireless Transaction Layer Security is the security protocol based upon the industry-standard Transport Layer Security (TLS) protocol. Datagram layer provides a datagram service and bearer adaptation Figure 1 illustrates the WAP architecture 1 Figure 1: WAP Programming Model The WAP uses a similar programming model as the web. The server side WAP application is located in the company s web or application server. Since the browsing protocol used in the web is HTTP, a conversion between WSP and HTTP is needed. For this purpose the WAP specification defines the WAP gateway. The gateway is responsible for providing the necessary protocol conversions. In addition to protocol level conversion the gateway is also responsible for the content and WSP header encoding/decoding. Some gateways might also support HTML to WML conversion. WAP Content Types WML is intended for use in specifying content and user interface for devices that have small display, limited user input facilities, narrowband network connection, and/or limited memory and computational resources. WML is specified as an Extensible Markup Language (XML) document type. WML documents are structured as a collection of cards. Cards are grouped together into decks. A deck is the smallest unit of WML that a web server can send to a user agent. When a user agent receives a deck, it typically activates the first card in the deck, though it can be directed to any particular card in the deck. 2 Logically, a user navigates through a set of WML cards. The user navigates to a card, reviews its contents, may enter requested information, and may make choices, and then moves on to another card. Instructions embedded within cards may invoke services on origin servers as needed by the particular interaction. WMLScript is a lightweight procedural scripting language based on ECMA script. 3 It enhances the standard browsing and presentation facilities of WML. WMLScript is compiled into byte code before it is being sent to the client. WMLScript is usually used in conjunction with WML, but can also be used as a standalone tool. WAP PUSH The Push Message Framework is a term used to describe all of the protocols, service interfaces, and software entities, which together provide the capability of pushing data to user agents in a WAP client device in an asynchronous manner that is, without the end user specifically requesting to receive this data. The architecture consists of a distributed client/server application, with a server residing in the push proxy gateway (PPG) or a push initiator (PI), and a client residing in the mobile 2001 HIMSS Proceedings: Posters Poster Session 16 / Page 3

4 device. The push initiator typically first sends the message by using the Push Access Protocol (PAP) to the Push Proxy Gateway (PPG) through the wired network and the PPG sends the message by using the Push OTA (Over the Air) Protocol over the wireless network. 4 Figure 2 illustrates the Push Framework. Figure 2: WAP Push Architecture WML content is not usually pushed direct to a client user agent because its reception and display could interfere with the user s browser activities. A Push message can contain one of two content types: Service Indication (SI) and Service Loading (SL). The Service Indication (SI) content type provides the means to send an alert message to a client asynchronously (without the client requesting it). When this descriptive message is displayed to the user, the user can choose to load some WML content (specified by a URI that accompanied the push message). The Service Loading (SL) content type provides the means to transmit to the mobile client device a URI, which the client device then pulls from an origin server without the knowledge of the mobile client user. When the WML content is retrieved, it is passed to the user agent, which then executes it. As this WML the WML user agent, the user, interprets content may become aware of this activity at this point. Because the user may be busy with other activities, this service loading mechanism also provides the push application developer with the option to set the level of intrusiveness. SYSTEM DESIGN The system consists of the following elements. EKG database As soon as a patient has a cardiac emergency, Electrocardiogram (EKG) changes generated from a centralized EKG monitoring system, are captured in the Central Patient Monitoring Work station. This database will contain demographic information on the patient, the immediate complication and the attending cardiologist s mobile phone number. Please refer to Figure 3. WCDSS Interface Manager The WCDSS Interface Manager will run in a loop and check for new reports in the database periodically. The WCDSS Interface Manager is a standalone applet. Once a new report is detected the WCDSS Interface Manager does a copy of the report in the WCDSS database. The WCDSS database The WCDSS database contains the following information 1. Alert reports The alert report consists of the following, the name of the patient, the immediate complication and the attending cardiologist s mobile phone number. 2. Information regarding cardiologists The database will maintain a list of the cardiologists and their patients. Unique identifiers (mobile telephone numbers) assigned to the cardiologists will also be available HIMSS Proceedings: Posters Poster Session 16 / Page 4

5 Figure 3: WCDSS Architecture 3. Preferences of cardiologist Preferences of the cardiologist such as whether they require SIC/SLC message, preferred alternate cardiologist, and other preferences can be provided as part of additional functionality. 4. Treatment Protocols Treatment Protocols for various cardiac emergencies as are stored in this database. The Patient database The patient database contains the medical record of the patient. The record will have the entire clinical information on the patient as on date. The physician can have access to the patient database using a WAP enabled phone. The Alert Message Servlet This servlet will be used to generate the WML deck showing the alert message. The alert message deck will have the following- patient, patient Name, complication and links for Treatment Options and More Details decks. It retrieves the complication details from the database and generates a WML page containing the complication, which is then returned to the Doctor via the WAP gateway. The Treatment Options servlet This servlet will be called when the doctor chooses the Treatment Options link in the WML deck showing the alert message. The treatment options servlet will be used to generate a WML deck showing the list of standard options that the Doctor can choose and also an input field in which the doctor can add any custom advice. The deck should also contain a link to submit this information to the WCDSS web server. The moreinfo servlet This servlet will be called when the doctor chooses the moreinfo link in the WML deck. The moreinfo servlet will establish a connection to the hospital database and obtain the details of the patient. With the records obtained from the database, the servlet will generate a WML deck containing the details about the patient. The details should be comprehensive. The deck should be split into a number of cards. Each card should not have more than four lines HIMSS Proceedings: Posters Poster Session 16 / Page 5

6 HOW DOES THE SYSTEM WORK? The push initiator program monitors the WCDSS database continuously. The push initiator program runs in a loop to monitor the changes in the WCDSS database. If there is a change, it generates a notification message based on the custom preferences saved in the WCDSS database. The push initiator program then opens a connection with push proxy gateway and transmits the message either in SI or SL (text form) to the push proxy gateway. The push proxy gateway does the job of converting the SI or SL message into SIC or SLC binary form and transmits (pushes) the message to the cardiologist s user agent. If the message is of type SLC then the user agent pulls the alert deck from the web server without the Cardiologist s intervention and displays the alert message. If the message is of type SIC, the user agent notifies the Cardiologist that there is an incoming alert message. An alert message deck is ready and, if the Cardiologist accepts, will ask the phone s browser to pull the deck from the WCDSS web server via the WAP Gateway. The alert message is then displayed on the micro browser. The user agent in the WAP device reads the message and in order to pull the alert deck, it contacts the gateway using WSP; the gateway then contacts the WCDSS web server-using HTTP. The alert deck as such is not Pushed to the WAP device but only an instruction of type SI or SL to Pull the alert deck is transmitted (Pushed). The alert deck is actually constructed in the WCDSS web server. The WCDSS web server constructs the alert deck through the servlet. The servlet, which we ll call gencomplication, will generate the formatted page in response to a standard HTTP request to the WCDSS web server. It will expect the patientid to be provided as a request parameter in the form of a query string in the URL with the parameter variable name pateintid, for example: PateintID= This servlet then searches the WCDSS database for the emergency condition of this patient. The servlet opens a connection to the WCDSS database using JDBC and gets the relevant data. The servlet generates the dynamic WML deck. This WML deck is then sent to the gateway-using HTTP. The gateway then sends this deck to the user agent in the WAP device using WSP. The cardiologist views the alert deck containing the erratic condition of the patient and can either chose to view the Treatment Options deck or the More Information deck. The More Information page has to be dynamically constructed by the moreinfo servlet. This servlet has to read the information about the patient from the hospital s patient database and construct a WML deck split into multiple cards for optimal end user comfort. The servlet achieves this by using JDBC to establish the connection with hospital s patient database and reads the medical records the patient. In the More Information deck the clinical information about the patient stored in the medical record in the hospital database can be viewed card by card. This is achieved by having a link for More Information in each card. In a scenario wherein the hospital has to make an emergency contact with a cardiologist who has no prior knowledge about the patient, this feature would be of good use. The cardiologist could be made aware of the patient s precise details without any manual help. Also another link for the cardiologist to navigate to the Treatment Options deck is provided. In the Treatment Options deck, a list of standard treatment options is given along with two input fields. One input field is to obtain the choice (a number) of the treatment option. The other input field is to obtain any custom advice entered by the cardiologist. The cardiologist can then chose the standard treatment option and can also add any custom advice. Here care is to be taken to minimize text entry and so the listing of standard treatment options is necessary and should be comprehensive. Once the Treatment Option is chosen and entered by the cardiologist the choice and advice are submitted to the web server where the Treatment Options Servlet establishes the database connection and inserts data in the WCDSS database as well as the hospital database. DESIGN CONSTRAINTS Push Proxy Gateway The major constraint in implementing the system is that a Push Proxy gateway is not commercially available at the time of design of this application. Navigation Scrolling using the keypad is a cumbersome process. Scrolling is to be avoided as much as possible. Therefore the deck has to contain as many cards as possible HIMSS Proceedings: Posters Poster Session 16 / Page 6

7 Keying in data In case the cardiologist wishes to key in custom treatment plan using the keypad, it would consume precious time. Therefore in treatment options deck all treatment options must be listed. For each option a number should be assigned. The doctor has to just enter a number in the input field. AUTHOR BIOGRAPHY Dr. Saji Salam is a healthcare analyst based in Chennai, India. He currently chairs HL7 India. He can be contacted at salamsaji@yahoo.com REFERENCES 1 Wireless Application Protocol Architecture Specification WAP Forum, On-line at 2 Wireless Markup Language Specification WAP Forum, On-line at 3 WMLScript Language Specification WAP Forum, On-line at 4 Push Message Framework HIMSS Proceedings: Posters Poster Session 16 / Page 7