Table Of Contents
Cisco Imatis Mobile Care Solution Architecture
IMATIS Hospital Communication Solutions
RS-232-Based Nurse Call Interconnect
Hospital Services—Building Alarms
Cisco Imatis Mobile Care Solution Architecture
Overview
The Cisco Imatis Mobile Care solution plays a critical part in providing information to caregivers reliably and in real time. To accomplish this, the solution is based on Cisco's Medical-Grade Network Architecture, providing high availability and scalability. It is beyond the scope of this document to discuss the Cisco Medical-Grade Network architecture in detail.
It is however important to point out that achieving a level of availability for such systems requires careful review and planning of the end-to-end network topology as it applies to:
•
Redundancy
•
•
•
•
For information on Cisco's Medical-Grade Network architecture, refer to http://www.cisco.com/go/healthcare. These designs are based on the architectures that can be found at http://www.cisco.com/go/srnd. Information about the architectures that are relevant to Mobile Care can be found in the design guides for Campus, Data Center, Secure Mobility, and Voice over WLAN. The placement of the Wireless LAN Controller (WLC) as recommended should be either part of the distribution layer or service module. It is not recommended to place the WLC directly to the Data Center core switching fabric. In many deployments, a service module is created to host components that provide network services such as Content Switching Modules (CSM), FireWall Service Modules (FWSM), and Application Control Engine (ACE) modules.
Figure 3-1 provides a high level overview of the network used to validate this design architecture.
Figure 3-1 High-Level Overview of Network Used to Validate Design Architecture
Deployment Model
The deployment of Cisco Imatis Mobile Care is based on the Campus design. Each floor of a hospital should follow the access designs aggregating traffic up to the distribution and core components of the campus network. The application servers, such as the Cisco Unified Communications Manager and IMATIS server, should be placed in the server farm of the data center. For the deployment of the 7921G phone, strict adherence to site surveys for wireless deployment should be followed. See the section for prerequisites for wireless voice deployment for details. To achieve the most optimal voice coverage, follow the design recommendations found in the voice over wireless LAN design guide.
IMATIS Overview
IMATIS Hospital Communication Solutions
The IMATIS platform connects together and manages a series of different input sources. Examples include alarms from medical equipment, patients' emergency pull cords, and alerts from ancillary clinical systems. The message event originating devices span a wide range of device types, from medical equipment, mechanical signal senders such as emergency pull cords, postal tube systems, and other technical systems, to clinical IT systems and telephony equipment. In addition, the system manages logical alarms, such as if a nurse leaves a department and that department is understaffed (based on predefined assumptions). Using rules which process in real time, an alarm for cardiac arrest triggers an alarm on the units the cardiac arrest team are currently using. The cardiac arrest team can be defined as the personnel nearest to the patient based on the system's location parameters. The solution can do more than just pass alarms and messages. Using IMATIS Hospital Communication System, which uses Web Services (.NET and MS-BizTalk), the patients' journals can be retrieved from the medical applications on the doctor's or nurse's PC or PDA. The system also manages patient terminals on which patients can choose entertainment or control technical systems in their room, such as light and temperature.
A core of Web Services has been produced that make it possible for the portals on the various units to retrieve the information needed. Using the message server IMATIS, PCs and Cisco IP telephones can be used for voice, dictation, e-mail, SMS, and other message exchanges, and alarms and remote control if they are equipped with these functions. For example, an alarm from a patient monitoring device can be routed to the nearest doctor and in a form suited to the doctor's unit, as an alert to an IP telephone, or as a spoken message to a telephone without a display.
The messaging server:
1.
2.
3.
In addition, message routing takes place both as a wired and wireless function using standardised protocols and interfaces and is routed from call devices in rooms (phones, work stations (PCs), and patient signal units) and information systems (e-mail, SMS, IM, etc.) to the message recipient via wireless phones and wireless message receiving devices (PCs, PDAs, etc.) or as e-mail.
The system can be integrated with all described message routers and receivers using standard network technology (TCP/IP) and network-based standards such as XML, SMTP, SMNP, and OPC, including network connectors (gateways) to non-IP based standards such as SMS, ESPA 4.4.4, and potential free I/O signals, etc.
The patient signal unit itself collects and transfers various alarms from patients and nurses for calling assistance to bed rooms, toilets, examination and treatment rooms, and specialised rooms. Calls and alarms are routed to the specified ward and, via the messaging server, to the dedicated nurse. The patient signal unit also allows the public and patients to call for assistance from individual rooms, such as handicap toilets (HC) in public areas. Alarms from these rooms are routed to the duty centre and security guards via the messaging server.
The system is installed as a distributed solution with positioning of redundant servers. An overview of the IMATIS Hospital Communication System, together with the patient signal system, is shown in Figure 3-2.
Figure 3-2 Overview of IMATIS Hospital Communication System with Patient Signal System
The main elements of the message router solution are:
•
•
•
•
•
•
•
•
•
•
•
The main elements in the patient signal solution are:
•
•
•
•
•
•
Services Flow
IMATIS Mobile Nurse Call
The IMATIS Nurse Call service is provided through integration with nurse call systems vendors, such as BEST in Sweden ( http://best.se/index.htm). Imatis creates adapters to interface with nurse call systems using protocols like OPC or the protocol used by the nurse call vendor. The alarms created by the nurse call system are collected by the IMATIS server and delivered to the clinicians and nurses according to the defined business rules.
A high-level architectural diagram is shown in Figure 3-3.
1.
2.
3.
4.
5.
6.
7.
Figure 3-3 High-Level Architecture—Nurse Call
Interfacing to the nurse call system can be accomplished through two primary methods. The most common method is the use of an RS-232 serial connection between the IMATIS server and the nurse call system. The second method, if supported by the nurse call vendor, is an IP connection where the nurse call system sends XML formatted messages directly to the IMATIS server over an IP-based network.
RS-232-Based Nurse Call Interconnect
The maximum distance for RS-232 is both dependent on the capacitance of the cabling used and the speed of the serial transmission. The RS-232 specification specifies that the cable length must not exceed 50 feet or a cable length who capacitance does not exceed 2500 pF. Using Category 5 cabling, it may be possible in some circumstances to reach 150 foot at 9600 baud. The use of Cat 5 cabling however is implementation-dependant and such results may not be possible in all cases.
Since most nurse call systems use 9600 baud connections, the typical installation using non-specialized cabling, the 50 foot rule of thumb should be used. Since the IMATIS server is critical to the clinical workflow, both its availability and reliability must be considered. As such, it is strongly recommended that you install the IMATIS server in the hospital data center. Since the location of the data center is typically greater then 50 feet from the installed nurse call system, a method of converting RS-232 to IP must be employed. It is possible to extend RS-232 signal from remote nurse call systems by using an RS-232 to IP converter or by using the Cisco IOS feature BSTUN (Block Serial Tunneling).
IMATIS Order Entry Alerts
The IMATIS Order Entry Alerts solution provides care givers with real time alerts about the availability of clinical results specific to a patient under their care. The source of the alerting information can be any ancillary system that supports standard HL7-based results reporting. The ancillary system can originate the HL7 transaction directly to the IMATIS server or an HL7 interface engine can replicate a message and forward a copy to the IMATIS system.
Despite the mechanism used to deliver the message to the IMATIS server, a number of rules can be applied to the event and trigger the notification of the results to the appropriate care provider.
Figure 3-4 highlights the flow of the message content between the ancillary system and the care providers.
1.
2.
3.
Figure 3-4 Message Content Flow
Communication between the ancillary system and the IMATIS server is IP/TCP based and can occur on any TCP port as configured on the IMATIS and ancillary HL7-based system.
Once the message is received by the IMATIS server, it is examined to determine if action must be taken against the message. If such an event requires notification to third parties, the message is sent to the BizTalk server where it is examined further to determine the parties to which the message should be sent. One of the critical business rules decides what type of data is passed onto the clinician. Due to patient sensitive data, a business rule decides if the results is sent along with the alert or if only the indication that a result is ready is sent to the clinician. Once this is determined, the IMATIS server forwards the message to he intended devices currently assigned to the care providers.
The screens shown here are seen by the clinician when a stat alert is received on their Cisco 7921G phone.
Figure 3-5 shows a normal lab result is ready for a patient and displays the test results.
Figure 3-5 Result Ready and Results Shown
Figure 3-6 shows a normal lab result is ready for review by the clinician, but the results are not shown.
Figure 3-6 Result Ready and Results Not Shown
Figure 3-7 shows an urgent lab result is ready for a patient and displays the test results.
Figure 3-7 Urgent Result Ready and Results Shown
Figure 3-8 shows an urgent lab result is ready for review by the clinician, but the results are not shown.
Figure 3-8 Urgent Result Ready and Results Not Shown
IMATIS Medical Team Assembly
IMATIS enables the ability to request a summon of a predefined team. This predefined team would enroll for a specific functional role as defined by the team. A example of a team may be the cardiac team that consists of a doctor and a nurse or it may be all nurses on floor 15. These rules are defined in the IMATIS server. These members enrolled in this group then receive alerts that belong to the team.
The request for this medical team can be achieved via several methods:
•
•
•
Figure 3-9 demonstrates the workflow for summons of a medical team.
1.
2.
3.
4.
Figure 3-9 IMATIS Medical Team Assembly
IMATIS Hospital Orderly
IMATIS provides greater efficiencies for the orderly staff in a hospital. Through the combination of Web applications enabled by IMATIS and the Cisco Unified Communications system to provide updated requests to orderly staff, the mobile staff can receive updated work requests in real time. Accomplished through an IMATIS interface, the work staff in a hospital can make a specific request for an orderly to perform a task. This task request is then sent to the hospital dispatcher to assign the request to a specific individual. The receiver of the message has the option to accept, miss, or dismiss the request. By accepting the task, thee system acknowledges the dispatcher once the task is completed. To dismiss a request, such as when the orderly staff may be busy with an activity, the request is then rerouted back to the dispatcher for reassignment. In the miss scenario, the request may not be able to be serviced due to the inability to service the request, for example when a wheelchair transport being requested is not available at the specified location.
Figure 3-10 demonstrates the workflow of an orderly request.
1.
2.
3.
4.
Figure 3-10 IMATIS Hospital Orderly
Text Paging (SMS)
Due to coverage issues of GSM phones inside a hospital or improved integration with hospital directory systems, a hospital my want to have a localized message system to facilitate communication from one individual to another individual inside a hospital facility. This can be enabled through the text message application enabled by IMATIS and delivered through the Cisco Unified Communications system. A few screens seen by the user are shown below.
Figure 3-11 shows the window to create the text message from a Cisco phone.
Figure 3-11 Window for Creating Text Message on Cisco Phone
Figure 3-12 shows the user receiving a message.
Figure 3-12 User Receiving Message
Figure 3-13 shows the options to answer the message, which are to answer with a predefined answer, call the originator back, or send them back a user-defined text message.
Figure 3-13 Options to Answer Message
Figure 3-14 shows the inbox for a text message for a particular user.
Figure 3-14 User Text Message Inbox
Hospital Services—Building Alarms
Integrating building alarm systems such as fire and security is critically important. Up until now, there has not been a focus on bringing such life-critical alerts directly to the clinician. Interfacing to such systems is similar in design to that of an RS-232-based nurse call system. Using the IMATIS server, it is possible to trigger on messages, and forward to groups of phones, both hard-wired XML-enabled Cisco phones as well as wireless 7921G phones. The integration to these systems uses the protocol European Selective Paging Association (ESPA) 4.4.4.
Fire Systems
Connectivity to most fire alarm systems is accomplished via an RS-232 serial interface or in some cases with older equipment a 20 mA (Milli-Amp) current loop. These outputs from the fire alarm system were typically connected to a line printer which was used as a notification mechanism for responding fire personnel.
The output includes the following information:
•
•
•
•
Using this information, the IMATIS server can forward alerts to the most appropriate staff. The message can be both building/floor dependant. Figure 3-15 shows two screenshot samples as seen by the facilities manager receiving the message.
Figure 3-15 Sample Screenshots for Received Messages
Security Systems
Similar to fire alarm systems, most security system control panels provide a serial interface to which alerts or system programming can be performed. Likewise, many card access systems also provide a mechanism to provide activity monitoring information via a standard RS-232 serial interface. The event monitoring data sent from a security system can be forwarded to the IMATIS server through either a direct connection or extended via IP through the use of an RS-232 to IP device.
A typical alarm message would include:
•
•
•
•
•
•
Once these messages are received by the IMATIS server, they can easily be acted upon based on the configured business rules. Figure 3-16 is a sample screen shot of a security alarm being received.
Figure 3-16 Sample Screen Shot of Security Alarm Being Received
