OR-Eye, one of several new solutions developed by the Ohio State University (OSU) Medical Center, allows authorized users to securely and remotely monitor, record, and replay vital signs data that is generated in operating rooms and intensive care units. Based on a loosely coupled, service-oriented architecture, the solution extracts data from a proprietary monitor network and uses implementations of Web service protocol specifications that are provided by Web Services Enhancements 2.0 for Microsoft .NET to securely and efficiently expose that information for access by smart client applications. Through OR-Eye and its other solutions, OSU Medical Center will realize improved quality of clinical data, broader access to that data, improved correlation of vital signs and medications, and greater operational efficiency—all of which will improve the center’s ability to deliver on its threefold mission of patient care, education, and research.

Part of one of the most comprehensive health sciences campuses in the United States, the Ohio State University (OSU) Medical Center includes a College of Medicine and Public Health, five hospitals, two research institutes, and more than 30 community-based primary and specialty care facilities. Its three-part mission of patient care, education, and research dates back to 1847, when a donation from Lyne Starling, a prominent attorney in Columbus, Ohio, helped to establish the first teaching hospital in the United States. University Hospital—the center’s flagship patient care facility—and OSU’s James Cancer Hospital are consistently named as among America’s Best Hospitals by U.S. News & World Report.

OSU Medical Center has a long history of using technology to improve the quality of patient care, education, and research. For the last four years, the center has been recognized as one of the "Most Wired" hospitals and health care systems in the nation for its use of wireless and Internet technologies by Hospitals & Health Networks, the journal of the American Hospital Association. A wireless network spans all major OSU Medical Center facilities, where it supports everything from bedside care and record keeping to the secure transmission of patient records and medical images. Virtual private network (VPN) technology provides physicians and other authorized caregivers with secure remote access to many of the center’s systems.

In early 2003, Dr. Michael Howie, Chair of the Department of Anesthesiology at OSU Medical Center, approached Dr. Furrukh Khan of the Department of Electrical and Computer Engineering with a vision. He wanted to explore how technology could be used to help improve the day-to-day operations of the center’s 50-plus operating rooms (ORs).

One area that Howie wanted to improve was operational efficiency. Maximizing the use of limited, expensive resources like operating rooms and the highly skilled medical professionals that work in them requires an extensive amount of coordination. Today, the coordination required to keep patients moving smoothly from phase to phase is done manually—and requires an extensive amount of proactive communication to keep all parties informed as to the status of each patient. A central OR desk is at the center of all that activity.

Even a simple outpatient surgery procedure begins several hours before the start of a scheduled operation when, after admission, the patient goes to an ambulatory surgery unit (ASU) where a surgery consent form is signed and checks are made to verify that the patient is ready for surgery. Next, the patient goes to a preoperative holding area where an anesthesia evaluation is performed, an anesthesia consent form is signed, intravenous lines are placed, and the patient is sedated. Then comes surgery, which can involve anywhere from 5 to 10 people: surgeons, surgical assistants, anesthesiologists, residents, and nurses.

After surgery, most patients go to a post-anesthesia care unit (more critical cases go to a surgical intensive care unit). From there, patients go back to the ASU before leaving the hospital. Inpatient procedures are similar except that the process begins and ends on the hospital floor instead of the ASU. A single operation generates at least 18 phone calls as a patient progresses through each staging area and the nurses in each area keep other areas informed about the patient’s state of readiness, the estimated time a surgery will end, when the OR will be ready for the next patient, and so on. Constant status updates are required because delays can happen for many reasons, including unsigned consent forms, transport delays, last-minute lab tests, last-minute visits with relatives, or a patient changing his or her mind about having surgery.

"To keep things running smoothly, the OR desk needs to know where each patient is at all times," says Howie. "If grocery stores and superstores can know how many tubes of toothpaste are on their shelves at all times, then I should be able to know more about the status and location of a patient."

Another area where Howie saw room for improvement was in how a patient’s vital signs are recorded during surgery—specifically, finding a way to collect more data with less effort. During a typical surgery, a monitor connected to the patient displays from 8 to 15 different vital signs: invasive and noninvasive pressure, pulse oximetry, cardiac output, and so on. For open-heart surgery, the number of vital signs monitored is much greater.

Today, the anesthesiologist records this data manually, entering that information by hand into a paper-based anesthesia record at five-minute intervals. Limited by the amount of effort it takes to manually record data, that level of granularity is often insufficient when trying to reconstruct what happened during an operation, as is regularly done for educational purposes and to improve the quality of patient care. The need for granular vital signs data is even more important in clinical trials, for which the data-gathering process often requires the full attention of one or more research nurses.

Although monitors in each operating room route vital signs data over an isolated network, the format for that data is non-standards based and can be read only by another monitor from the same vendor. In the medical center, this limits access to that information to other ORs—the only place that monitors from the same vendor are used. Carlos del Río, an Anesthesia Engineer, had figured out how to tap into the network and decode vital signs values, but the method for aggregating, storing, and exposing that data to enhance patient care, education, and research still remained to be found.

In addition to capturing vital signs data for later analysis, Howie wanted to be able to correlate medications that are given in the OR with the effects that they have—as determined by a patient’s vital signs.

Currently, medications given during surgery are noted by hand on the anesthesiology record—an inefficient method of data capture compared with the computerized systems used outside the OR. Dealing with complications during an operation may force the anesthesiologist to forego writing down medications as they are delivered and reconstruct the actions from memory at a later point in the operation. After surgery, a copy of the anesthesia record becomes part of the patient record, with four additional copies routed to various departments for billing purposes (pharmacy, anesthesia department, and so on.)

"Current systems and processes for capturing what goes on in the operating room—and in the areas that support it—do not work well together,"says Howie. "We often dissect a case in detail to determine if we did things the best way, but the granularity in vital signs data and the lack of correlation between medication and vital signs makes this more difficult than it should be. A good deal of manual analysis and correlation needs to happen before we can get an accurate picture of what happened and start the discussions on how we can do better."

High-Level System Requirements In helping to develop a solution, Howie wanted to avoid the pitfalls that had been faced in the past. "Several times, the medical center has had consultants come in to interview us and then hand us a large bill and a report that tells us what we already know," he says. "Past attempts to get stand-alone systems to work together have been largely unsuccessful. The resulting solutions have been tightly coupled and thus extremely fragile, presenting significant challenges when they broke."

After digesting Howie’s vision, Khan and his team of graduate students outlined some high-level requirements for the solution:

• Extensibility. All solution components had to be loosely coupled so that future data sources could be added easily and the methods for accessing data would not be limited. The solution had to pull together data from—and facilitate communication between—many isolated islands of data and functionality, much in the same way that the various functions in a hospital each have their own systems and processes yet still must communicate to coordinate activities and share data. In addition, the solution had to be extensible enough to serve Children’s Hospital, whose faculty members are the pediatric faculty of OSU Medical Center. And while it is a separate organization from OSU Medical Center, Children’s Hospital regularly hosts medical residents and has its OR schedules prepared by the center’s staff.
• Security. To meet healthcare industry requirements for the confidentiality of patient data, all information passed between the distributed solution components would need to be encrypted. Based on lessons learned in a recently completed project, Khan’s team wanted to avoid the complexity of coding complex security mechanisms by hand. They also wanted to avoid mixing security code with business logic, which had made the previous solution inflexible and hard to change.
• Scalability and availability. The solution had to be cost-effective yet scalable enough to support the entire OSU Medical Center, including the new Ohio State Richard M. Ross Heart Hospital that will open in the fall of 2004. And the solution would need to be robust and self-healing, so that someone unplugging a monitor or disconnecting another system would not disrupt solution performance or stability.
• Standards based.The solution had to work together with other systems. In addition, it would need to be able to support healthcare industry standards like Health Level Seven (HL7).

OR-Eye, the first of several solutions to be delivered through a collaborative effort between the OSU Colleges of Medicine and Engineering, allows authorized users to securely and remotely monitor, record, and replay vital signs data that is generated in OSU Medical Center operating rooms and intensive care units. Developed by 10 graduate students in Dr. Khan’s Electrical Engineering Applied Software Engineering (EASE) group using Microsoft® .NET technologies, OR-Eye consists of two parts:

• Service-oriented architecture that extracts vital signs data from the proprietary network and securely and efficiently exposes that information for access by the rest of the medical center. Implemented as a federation of Web services (discrete application components that can be programmatically accessed using industry-standard Web protocols like XML, SOAP, and WSDL), the loosely coupled service-oriented architecture allows for the easy addition of new data sources and functionality, and provides access to that data and functionality to a range of new and existing systems. Web Services Enhancements (WSE) version 2.0 for Microsoft .NET—an add-on to the Microsoft .NET Framework that implements Web service protocol specifications like WS-Security, WS-Trust, WS-Policy, and WS-SecureConversation—was used to help secure confidential patient data as it passes between distributed solution components.
• Smart client application (see Figure 1) that uses secure Web services to communicate with the service-oriented architecture. By taking advantage of the processing power of the desktop, the OR-Eye smart client provides a graphical user interface that allows the user to intuitively view, record, and replay vital signs data on a desktop PC, laptop, or Tablet PC. The EASE team also developed a mobile version of the OR-Eye client that runs on a Pocket PC. Both versions of the smart client allow the user to access the system from anywhere on the center’s wireless network—or from remote locations using the center’s VPN.

The granularity with which vital signs data is collected can be adjusted by changing an entry in a configuration file. After a user logs on to the system, the smart client presents the user with a browse screen (left side of the user interface) that lets them select an operating room and view the monitors that are connected in that room. Upon selecting a monitor, the user can choose to view live data, record that information, or replay an earlier-recorded session.

Vital signs are displayed both in graphical forms and as numerical values, with the design of the display closely matching the monitors that are used in the ORs. Another panel (top of screen) provides the user with a graphical timeline that makes it easy to rapidly move forward and backward when viewing data. A "privacy mode" that can be activated with a single mouse click hides any patient-identifying data.

OR-Eye entered the pilot phase in May 2004 and now is in use by selected anesthesiologists and second-year and third-year residents. The pilot will expand to more users throughout the summer and will become a de facto part of the infrastructure for the new heart hospital when it opens in the fall. The system will be retrofitted to other OSU Medical Center hospitals as time and resources allow.

OR-Med, another solution that plugs into the OR-Eye service-oriented architecture, is also in the pilot phase. Through the OR-Med smart client, anesthesiologists can enter the medications that they give to a patient, with that information stored in the same location that OR-Eye stores vital signs information—a Microsoft SQL Server? 2000 database. That information then can be viewed with the OR-Eye smart client, with "medication markers" appearing on the OR-Eye graphical timeline—a capability that allows doctors, students, and researchers as appropriate to visually correlate the administration of a medication with the effect that it has on a patient’s vital signs. (In Figure 1, the blue marker on the timeline is a medication marker.)

"The timeline concept is extremely powerful, especially when combined with an open system that lets us easily plug in new data sources," says Dr. Howie. "For the first time, we have an intuitive and painless way to correlate the medications that are given to a patient in the operating room and the effects that they have on vital signs. It will be an extremely valuable tool for patient care, education, and research. Not only does it allow us to easily re-create what happened during a given procedure, but we can mine that data across many procedures to gain new insights into how we can improve the quality of patient care."

In the future, the service-oriented architecture will extend OR-Med to integrate with the center’s pharmacy systems. At that point, an anesthesiologist in the operating room will be able to enter a medication and intended dosage, and have that data immediately sent to the pharmacy where it can be checked for drug interactions, patient allergies, and other potential complications. Results will be displayed on the OR-Med smart client, providing the anesthesiologist with additional real-time information that can be used to help ensure patient safety.

In building the OR-Med smart client, the EASE team took advantage of forms created with the Microsoft Office InfoPath? 2003 information-gathering program, providing a prebuilt interface with which users can view and enter data. Based on XML, as is the rest of the system, InfoPath 2003 helped the team provide rich, intuitive forms that are prepopulated with patient information, minimizing the time required for data entry.

A third solution that the EASE team is working on is OR-Track, which will use radio frequency identification (RFID) tags attached to a patient’s wristband and RFID readers throughout the hospital to track patients as they proceed through the surgical process. By the end of summer 2004, the team plans to have all software written and a small-scale model built using three short-range RFID readers donated by Texas Instruments. Larger, more powerful RFID readers will be needed for a full-scale implementation, which will require some 200 such devices to cover the entire OR complex, at a cost of approximately U.S.$2,000 per device.

Like OR-Eye and OR-Med, OR-Track plugs into the service-oriented architecture and uses its centralized data store. As a patient moves from room to room, changes in the patient’s status will be displayed graphically on a flat panel TV screen mounted near the OR desk. Changes in a patient’s location will cause prepopulated InfoPath forms to appear on PCs in the appropriate areas for nurses to complete or modify.

For example, in the OR, a form can be presented with a button to click when anesthesia is administered, when the surgeon approaches a patient, when the first incision is made, when the surgery is completed, when the operating room is ready for the next patient, and so on—with real-time visibility into that information provided throughout the medical center.

Like medication events, patient events and status changes captured by OR-Track can be recorded, replayed, and viewed on the OR-Eye timeline along with medication and vital signs data, enabling users to easily see the movement of a patient and correlate that information with other data collected by the system.

To the service-oriented architecture that supports OR-Eye, OR-Med, and OR-Track, the collection of data is based on the concept of actions—for example, there are vital signs actions, medication actions, and patient location actions, each of which is generated by a different Web service that sends that information to a common Web service for storage (called the Action Bucket in Figure 2). The system’s open architecture will allow for the flexible addition of new actions in the future, such as a radiology action or a lab test action.

A record is a sequence of actions strung together. For example, a complete anesthesiology record for a patient can be reconstructed by extracting all vital signs actions and medication actions for that patient from the common data store. Other types of records are generated in the same manner—for instance, a complete patient record can be generated by extracting all actions for a patient from the data store. Similarly, an OR record that shows all activity for a given operating room can be assembled by querying the data store for all actions associated with that room, or a monitor record can be generated by querying the data store for all actions associated with a monitor.

This model maps extremely well to a loosely coupled, service-oriented architecture based on Web services. In the case of OR-Eye, one Web service collects information from the proprietary monitor network and sends that information to another Web service that exposes the centralized data store. The OR-Eye smart client interfaces with the system through a third Web service, without having to be concerned about how that Web service interacts with the other Web services in the federation to provide the requested data.

Additional Web services serve a similar function for OR-Track and OR-Med, with each Web service capturing a single type of action and sending that data as an XML message (using SOAP) to the data store Web service. Altogether, the service-oriented architecture includes some 13 Web services, which all communicate with each other and with the smart clients that some of them support using advanced security mechanisms to help protect confidential patient data.

All solution components were developed using the Microsoft Visual Studio® .NET 2003 development system and run on the Microsoft .NET Framework, an integral component of the Windows® operating system that provides a programming model and runtime for Web services, Web applications, and smart client applications. In building the system, the development team had to protect confidential patient data as the loosely coupled system components communicate with each other. In addition, the developers wanted to avoid having to implement those security mechanisms by hand. They also wanted to avoid combining security code and business logic, which would have made the solution less flexible and more difficult to maintain or enhance.

The developers achieved all those goals using Web Services Enhancements version 2.0 for Microsoft .NET, a supported add-on for Visual Studio .NET and the .NET Framework that gave them prebuilt support for evolving Web service protocol specifications. Features of WSE 2.0 that the developers used include support for:

• WS-Security, which describes standards for how SOAP headers can carry or refer to various types of security tokens—used to help ensure message integrity and confidentiality through electronic signatures and encryption.
• WS-Trust, which describes a standard model for establishing trust relationships, including standards for requesting and exchanging security tokens with a trust service.
• WS-SecureConversation, which makes use of WS-Security and WS-Trust, and describes standards for establishing mutually authenticated security contexts that enable long-running, secure, and efficient conversations between the senders and receivers of SOAP messages.
• WS-Policy, which describes standards for how senders and receivers of SOAP messages can declaratively specify their policy requirements. WS-SecurityPolicy, part of the WS-Policy specification, was used by the team to specify security requirements for solution components in a way that helped them separate business logic from security and avoid coding those security mechanisms by hand.

"Microsoft offered an implementation of the Web service protocol specifications required to make the project a success," says Khan. "By using WSE 2.0, we were able to focus on the solution’s business logic instead of writing security code. WS-Policy allowed us to simply install digital certificates, extend prebuilt classes to handle passwords, and write a few hundred lines of configuration and policy XML that describes how the Web services are to use them. Another big enabler was WS-SecureConversation, which gave us the security that was required without sacrificing performance."

The Pocket PC smart client runs on the Microsoft .NET Compact Framework, for which no WSE 2.0 equivalent is currently available. To overcome this, the EASE team developed its own security implementation that works with WS-Security and WS-SecureConversation, which they did by wrapping existing Microsoft Windows Mobile 2003 cryptographic libraries with managed C# code that runs under the .NET Compact Framework on the mobile device. Those application components communicate with a software "bridge" that is part of the service-oriented architecture, which in turn uses WSE 2.0 to communicate with the target Web services. To those target Web services, messages from the mobile smart client appear no different from those that originate from a WSE-enabled system.

Over the next few months, the development team will continue to enhance OR-Eye and OR-Med, and begin building the scale model and writing the necessary code for OR-Track. Khan also plans to look at how to make the system fully HL7 compliant—that is, to automatically support the HL7 protocols that many healthcare systems use to communicate with each other.

"Just like WS-SecurityPolicy lets us focus on business logic, with security largely taken care of automatically, we would like to declaratively make all of the communications within our system compliant with HL7 protocols—without having to spend a significant amount of time learning the details of HL7 data exchange standards and writing the code to support those standards by hand," says Khan. "We prefer to concentrate on the business logic and let the infrastructure take care of things like security, reliability, and HL7."

The Ohio State University Medical Center will realize several powerful capabilities through its new solution set: an ability to collect more granular data, improved access to that data, better visibility into a patient’s location and status, and an ability to easily correlate information from disparate data sources. In turn, those capabilities will improve the medical center’s effectiveness and efficiency in meeting its three-part mission of patient care, education, and research.

"The genius of the solution lies in its simplicity," says Dr. Howie. "By connecting isolated islands of information in a loosely coupled manner, we’re able to realize a solution that is both extremely useful and infinitely extensible. I can think of dozens of ways that we can extend our new solution, with each delivering some new capability that will make us more effective on a daily basis."

By automating the capture of vital signs data, OR-Eye will provide caregivers, students, and researchers with better, more granular data—without adding to the workload of operating room personnel or being limited by the amount of data that can be recorded on a paper anesthesia record. When combined with the capabilities provided by OR-Med, the ability to correlate that granular information with the administration of medications will yield several benefits:

• Improved patient care. With more granular data, anesthesiologists will be able to better re-create what happened in an operating room and use that information to determine how to improve the quality of patient care. "Every week, we hold a clinical management conference where we dissect a case in detail to see if we could have done better," says Howie. "With the data readily available and viewable, we’ll be able to go straight to the discussion—and with more information than we’ve had in the past. The system will also provide new capabilities during surgery—such as the ability to ask an expert in a remote location to pull up a patient’s vital signs and provide an opinion, without that person having to travel to the operating room and physically view the monitor."
• More realistic training. The anesthesia department participates in a multi-million dollar simulation model (mannequin) that can be programmed to cover 18 common anesthesia scenarios, such as preparing a patient for surgery after an automobile accident. Having granular data from real-world operations will allow the center to increase the realism with which the mannequin functions, leading to better training for future caregivers.
• Better research. By storing vital signs and medication data in one place and automating the process of gathering that information, the center can rapidly and cost-effectively build a vast pool of data that can be analyzed to uncover hidden patterns. Modern data mining tools will allow researchers to easily pose "what-if" scenarios and immediately have their questions answered, accelerating the pace of research and leading to new insights that will improve the quality of care. Dr. Khan has close ties with the bioinformatics group at the medical center and plans to work with that group to drive the research program forward.
• More research dollars.The capabilities provided by the center’s new solution will help to set it apart from other institutions that are competing for the same research opportunities and funding. "We’ll be able to gather the amount of data generated by clinical trials on a daily basis—without the traditional expense," says Howie. "Not only will that capability improve our ability to do research, but it will help attract more clinical trials and the salary recovery funds that come with them."

Having an electronic record of the medications that are administered during surgery (OR-Med) and the flow of patients through the operating room complex (OR-Track) will provide significant opportunities to improve operational efficiency by eliminating manual processes.

Some of those areas include:

• More efficient billing. Today, multiple copies of an anesthesia record are created and routed to various departments, which manually key the information into different systems for billing purposes. With that same information captured electronically and stored in an open system, the medical center will be able to expose that data to other systems to further automate the billing process and eliminate the need for manual data entry.
• Improved auditing. Every morning, an anesthesiologist faculty member or resident visits the pharmacy and, after a series of inventory steps, obtains the pre-approved pharmaceutical supplies that he or she may need that day based on the type of patients to be treated—drugs that must be accounted for at the end of the day. Today, that process involves the transfer of information by hand from anesthesiology records to a drug usage form, which is presented to the pharmacist when unused drugs are returned at the end of the day. The pharmacist then cross-checks that data against anesthesiology records to ensure that all drugs are accurately accounted for. With the same data stored electronically and exposed for access throughout the medical center by authorized personnel, the process can be greatly streamlined.
• Better use of resources. A modern operating room costs $2,000 to $2,500 per hour to staff and operate. By providing improved visibility into the flow of patients and the areas where delays occur, the center can improve the utilization of those expensive and limited resources. For example, if OR-Track shows that transport delays are a problem, the center can add more transport staff or get faster elevators. "The operating room is one of the economic engines of the hospital," says Howie. "If we can reduce the time that each operating room is empty by as few as 15 minutes per day, the savings will be huge. Improved throughput also will reduce the amount of overtime that people need to work, leading to additional savings and a better quality of life. I predict a 30 to 35 percent gain in operational efficiency when all systems are fully operational."

The Microsoft Windows Server? 2003 operating system (which includes the .NET Framework), SQL Server 2000, Visual Studio .NET, and Web Services Enhancements 2.0 gave the EASE team a single platform and tool set for developing all solution components: server, desktop, and mobile. By providing prebuilt support for emerging Web service protocol specifications, WSE 2.0 helped the EASE team focus on the solution’s business logic instead of security, delivering more useful functionality in less time and building an application that will be easier to maintain and extend.

"In our last project, 75 percent of the code we wrote was security related," says Sriram Seshadri, a doctoral student in the Electrical and Computer Engineering Department and development lead for the project. "With Microsoft .NET and WSE 2.0, 1 or 2 percent of the code is security related. Moreover, we were able to design and build the system in a way that was best suited to our functional requirements—instead of being forced to implement it in a certain way because of security constraints. We simply set up the security framework and coded the business logic within it—WSE 2.0 took care of the rest."

By building the multiple solutions on a single, service-oriented architecture that supports advanced Web service standards, the medical center has ensured that it can continue to innovate without getting bogged down in the technical details. Instead, it can remain focused on providing new capabilities that will benefit both the medical center and the diverse communities of physicians, patients, researchers, and students that it serves.

"Web services are a great fit for the hospital environment," says del Río, whose work decoding the non-standards based vital signs data was the origin of the project. "A service-oriented architecture based on Web services maps well to the way that a hospital works, with each department providing its own services yet all having to work together. The Web services in our system are modeled after the departments in the hospital, each implementing its role in a way that hides the complexity behind that functionality from the rest of the system. The only real difference is that instead of passing paper forms between departments, we pass structured XML documents between Web services."

"The possibilities for our system are endless, especially with technologies that let us focus on what needs to be done instead of how to do it," adds Khan. "I’m really impressed with how much my students have been able to deliver in such a short amount of time and the ease with which they’ve been able to do so. Web services are the way that software will be written in the future, especially when you consider the capabilities and benefits provided by rapidly evolving standards for Web service security, policy, and so on. It’s vital that we teach students about these things."

All testing and piloting of the system is done in the actual operating rooms, surgical intensive care units, and other related areas of the Ohio State University Medical Center. The people testing and piloting the solution are anesthesiologists, surgeons, managers, interns, and nurses. The EASE team has full clearance to work in the OR complex alongside the medical professionals, and to access and manipulate data within the center.

Before beginning the project, Dr. Howie and Dr. Khan assembled a cross-functional team that consists of personnel from Ohio State’s College of Engineering and College of Medicine. Those from the College of Engineering are all members of Khan’s EASE team, which focuses on mission-critical distributed computing and security. Project team members from the College of Medicine include Howie, Chairman of the Department of Anesthesiology; Dr. Nicholas Teteris, Director of Operating Rooms, and a number of anesthesiologists, operating room nurses, and OR equipment managers.

The EASE team members did not know what type of solution to build at the start of the project, because they knew nothing about the operating room environment and its systems and workflows. Before designing a solution, they spent summer 2003 in the OR complex, observing and documenting how it operated.

They saw that the complex’s rhythm is dictated by anesthesiologists, who prepare the OR schedules and whose roles begin well before the first incision and continue past the last stitch. They noted the procedures and workflows, which are designed to optimize the use of ORs, and documented the complexities and dependencies of the "parallel patient processing" used to maximize OR utilization. They also wrote manuals for existing systems and documented the use and flow of forms as they pass through the process.

During all those activities, the EASE team worked side by side with medical center staff, ensuring that the ultimate solution would be seen by the caregivers as their system instead of something handed to them by outsiders.

"Until we looked at the operating room complex from a service perspective, we didn’t know what to improve," says Khan. "After experiencing the environment and documenting what we saw, we came up with all sorts of ways to improve the quality of healthcare for patients, the quality of education for students, the quality of data for researchers, and the quality of life for caregivers."

Solution development began in September 2003 and took approximately six months, with most team members working on the project for roughly 20 hours per week. The Web services were developed by a team of two, the OR-Eye desktop client by another two people, and the mobile client by a single student. Other team members assisted with testing, documentation, and so on.

Development of all new code was done using the Visual Studio .NET 2003 development system and the C# programming language. Component Object Model (COM) interoperability, a feature of the .NET Framework, was used to integrate the C++ dynamic-link library (DLL) that del Río had written before the start of the project to extract data from the proprietary monitor network.

"The C# programming language and the .NET Framework provide a lot of the functionality that I used to wish I had," says del Río. "They let me get more done and write better-structured code. It’s very helpful that I can program and debug any solution component—client, server, or mobile—using a single, integrated development tool and programming framework. And the tools that ship with WSE 2.0, which function as add-ins to Visual Studio .NET, let us create the XML policy files that drive the system without having to write them by hand."

The OR-Eye and OR-Med desktop smart clients are based on Windows Forms, the classes in the .NET Framework for writing Windows-based applications. All code behind the Windows Forms controls is written in C#. Graphical elements were created in vector-graphics form using Adobe Illustrator and later converted to bitmaps.

To provide a rich interface for data entry without having to develop that functionality by hand, the EASE team took advantage of InfoPath forms by using the InfoPath 2003 Toolkit for Visual Studio .NET. To make InfoPath work with WSE 2.0–based security, the team built a bridge DLL that runs as managed code on the client. To prepopulate a form, as may be required after receiving patient data from a call to the pharmacy service (today implemented as a dummy service), the smart client first writes the data received from the pharmacy service to a local XML file. It then invokes the InfoPath form, which, upon loading, reads the XML file and uses its data to populate the fields in the form.

Data entered into the form by the user is checked and validated by the XML schema. Upon the user clicking Update or Submit, the bridge DLL (written in managed C# code) extracts the XML from the modified InfoPath form, formats it into a SOAP message, and uses WSE to securely send that message to the appropriate Web service for processing—for example, to the pharmacy Web service for additional safety checks to be made or to the medication recorder Web service for storage.

"With InfoPath, we can let Microsoft handle the user interface while we focus on business logic," says Khan. "Users benefit because they get a rich data entry interface with which they’re already familiar, and we benefit because we can avoid having to code or maintain that user interface and can remain focused on the data. Hospitals have lots of paper forms, and InfoPath lets us mimic the look and feel of those forms with a minimal amount of work."

The Mobile OR-Eye smart client is based on Windows Forms and the .NET Compact Framework. It runs on Windows Mobile 2003 software on a Hewlett-Packard iPAQ 5555 mobile device, which is configured with an Intel XScale 400-MHz processor, 128 megabytes (MB) of SDRAM, 48 MB of Flash ROM, and integrated Bluetooth and 802.11b wireless connectivity.

To overcome the lack of a WSE 2.0 equivalent for the .NET Compact Framework, the team implemented a WSE 2.0–based bridge Web service that runs as part of the service-oriented architecture and acts on behalf of the mobile smart client. Communication between the Pocket PC and the bridge is based on the previously described C# security libraries that the EASE team wrote for the .NET Compact Framework.

"A nice thing about developing on the .NET Compact Framework is that we were able to use the same development system and programming model for all solution components: mobile, desktop, and server," says Seshadri. "In addition, we were able to reuse a good deal of the C# code that we had written for the desktop client. Most of the work in developing the mobile smart client came from having to redesign the user interface for a lower-resolution display."

The 13 Web services at the heart of the solution’s service-oriented architecture currently reside on a single server, although their loosely coupled nature will let the team scale the solution out to any number of servers with only minimal configuration changes. The "listener" that monitors the proprietary monitor network resides on a second server and feeds information to the primary server using a Web service interface. Flat files from an external system used to maintain operating room schedules are sent by File Transfer Protocol (FTP) to the service-oriented architecture, where they are converted to structured XML files and exposed to the rest of the system through the OR Schedule Web service.

All Web services hide their state from each other, which results in a very loosely coupled system. Loose coupling is further enhanced by using message queues that are based on the Message Queuing (also known as MSMQ) service provided by the Windows operating system. A Windows Service extracts data from the monitor network and puts that information in a message queue. There is a maximum of one queue per monitor, and the queues are created only if some part of the system needs the data. A Web service pulls that data from the queues and stores it in the system’s SQL Server 2000 database. Each of the smart clients has its own Web service interface in the service-oriented architecture, which in turn calls other Web services to perform the required actions.

The system uses software-based leases to make itself self-healing with respect to network and connection failures. If a client were to unexpectedly shut down or a monitor to become disconnected, the corresponding lease eventually times out and the system reclaims the appropriate resources.

Security policies for interaction between Web services—and between the desktop smart client and Web services—are driven by WS-Policy. The policy assertions, which are contained in XML configuration files, state that the Web services will accept only SOAP messages that are encrypted and signed by a Secure Context Token that is issued by the Secure Token Service specified in the policy file. The EASE team used the Secure Token Service that is included with WSE 2.0, which uses a trust model called Issue Security Token. Appropriate SOAP headers conforming to WS-Security are automatically generated by WSE 2.0 as a result of the use of WS-Policy, WS-Trust, and WS-SecureConversation.

Within the service-oriented architecture, Web services initiate secure conversation with one another by using an X.509 v3 certificate to request a security token from the Secure Token Service. A 1024-bit certificate key and the RSA/SHA1 algorithm are used to sign the request for the security token. The request for the security token also contains a randomly generated 128-bit symmetric key, which is encrypted using the Secure Token Service’s X.509 v3 certificate and the RSAES-PKCS1-v1_5 algorithm.

The response from the Secure Token Service—more precisely, the proof token part of the Secure Context Token that is returned—is encrypted using the symmetric key that was provided by the requesting Web service and the AES128 algorithm, and is signed using the Secure Token Service’s X.509 v3 certificate and the SHA1 algorithm. After secure conversation is established, SOAP messages that pass between system components are signed and encrypted using two 128-bit keys, which are derived from the Secure Context Token using the P_SHA1 algorithm. They are encrypted using one of the derived keys and the AES128-CBC algorithm, and are signed using the other derived key and the SHA1 algorithm.

The smart client initiates secure conversation with a Web service in a similar manner, except that it uses a Username Token to request a security token from the Secure Token Service, and uses a symmetric key generated from the Username Token to sign the request. Like with the Web services, the smart client’s request for a security token also contains a randomly generated symmetric key that is encrypted using the Secure Token Service’s X.509 v3 certificate and the RSAES-PKCS1-v1_5 algorithm.

"The security mechanisms that the system uses are very complex, but we didn’t have to concern ourselves with any of that detail," says Khan. "All we had to do was write the policy assertions and WSE 2.0 took care of the rest."

The project team was headed by Professor Furrukh Khan, Director of Technology, Center for Applied Software Technology, who holds positions in the Department of Electrical and Computer Engineering and the Department of Computer Science and Engineering in the OSU College of Engineering, as well as the Department of Anesthesiology in the OSU College of Medicine. The graduate students who participated in the project are Shaharyar Khan, Sankaraganesh Manikantan, Shantanu Bharadwaj, Sriram Seshadri, Chris Weber, Sudhir Subramanian, Jilani Sarmad Syed, Ingrid Wijaya, and Agustina Siswandari.

Project team members from Ohio State’s College of Medicine and Medical Center include: Dr. Michael Howie, Professor, Chair of the Department of Anesthesiology; Dr. Nicholas Teteris, Professor, Director of Operating Rooms; Dr. Luis Lopez, Professor, Director of Anesthesia; Dr. Sergio Bergese, Faculty, Anesthesia; Carlos L. del Río, Anesthesia Engineer; Lynda R. Petty, RN, Director of Perioperative Services; Diane Nagel, RN, Nurse Manager, Perioperative Services; and John O'Brien, Quality Control and Materials Manager.

Microsoft .NET is software that connects people, information, systems, and devices through the use of Web services. Web services are a combination of protocols that enable computers to work together by exchanging messages. Web services are based on the standard protocols of XML, SOAP, and WSDL, which allow them to interoperate across platforms and programming languages. .NET is integrated across Microsoft products and services, providing the ability to quickly build, deploy, manage, and use connected, secure solutions with Web services. These solutions provide agile business integration and the promise of information anytime, anywhere, on any device.

For more information about Microsoft .NET and Web services, please visit these Web sites:

www.microsoft.com/net msdn.microsoft.com/webservice

For more information about Microsoft products and services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada Information Centre at (877) 568-2495. Customers who are deaf or hard-of-hearing can reach Microsoft text telephone (TTY/TDD) services at (800) 892-5234 in the United States or (905) 568-9641 in Canada. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information using the World Wide Web, go to:
www.microsoft.com

For more information about the Ohio State University Medical Center, visit the Web site at:
www.medicalcenter.osu.edu

For more information about the OSU Medical Center Department of Anesthesiology, visit the Web site at:
anesthesiology.osu.edu

For more information about the OSU Department of Electrical and Computer Engineering, visit the Web site at:
www.ece.osu.edu

For more information about the OSU Department of Computer Science and Engineering, visit the Web site at:
www.cse.ohio-state.edu

---

Was This Information Useful?