| In the era of rising health-care costs, the City General Hospital provides extended care for its patients in their homes. The hospital employs a fleet of visiting nurses called the "Roving Nightingales." The nurses provide ongoing home care for some patients, as well as pre- and post-operative care for other patients. Over the course of a day, nurses visit a number of patients, record vital signs and other measurements, perform home tests, and collect samples for laboratory tests. The nurses also record a summary of their visual observation of the patients. Sometimes, if a patient is not doing too well, a nurse may decide that the patient needs to come in to the hospital-affiliated clinic to see a doctor. The hospital hosts a Complete eCare application that manages information flow and synchronization between the roving nightingales, doctors, and laboratories, as shown in Figure 3-3. In a real-life scenario, other entities like health insurance agents and pharmacies may need to be incorporated in the Complete eCare application. Those entities are ignored in this application for simplicity. Figure 3-3. The setting for the Complete eCare application coordinating information exchange between different employees of the hospital and outside entities like independent laboratories. 
Application Setting The Complete eCare application is the nerve center for the information flow and synchronization required for this scenario. Like the Web calendar, the various Client parts of this application run on various devices, such as a PDA, a laptop, an office PC, and a special purpose medical tablet device. Unlike the Web calendar application, however, the programmers that implement the Client parts used by the doctors and the visiting nurses also implement the Server part of the application. The information systems group of the hospital likely employs them. The Client part that runs in the laboratory office may be implemented by another independent organization. Thelma, a typical roving nightingale, uses both a PDA and a laptop. She typically starts the day by synchronizing her daily schedule information with the Server calendar. She visits patients according to the schedule but synchronizes the schedule regularly to obtain schedule changes. When she visits a patient, she finds it convenient to record observations and home-test results quickly on her handheld PDA and synchronize the PDA with the Server's "daily visits" datastore. She finds the laptop more convenient for typing in visit summaries. At the end of the day, she usually synchronizes her daily visit records from the Server onto her laptop. The records already contain the information entered on the PDA throughout the day. She types in summaries for each visit and synchronizes the laptop to complete the records for the daily visits. Upon completion of the record, the laptop application also synchronizes the same record with the "patient chart" datastore. The patient chart datastore contains information in addition to records of the nurse visits. For certain patients that need to see a doctor, Thelma can mark certain records "red." When such red records are synchronized with the Server, the Server application schedules an appointment with a relevant doctor. Thelma can also collect samples (mailed separately to the lab) and order lab tests from her PDA. When the PDA is synchronized, the Server application updates the local "daily lab orders" datastore with the ordered test. Jacob, a doctor in the hospital, uses a lightweight, touch-screen, multimedia-enabled, and wireless-LAN-capable tablet device. The device is his single-point portal for all the information that he needs to perform his job. He can access and make changes to his schedule, access and update patient charts, access lab results (including digitized x-ray images and CT scans), and order lab tests. John, an office assistant in a small medical laboratory, uses a basic office PC. The PC is not normally connected to the network. Typically, the Client application on the PC dials in and synchronizes with the hospital Server in the morning to obtain the lab orders for the day. The orders are processed, lab tests are performed, and the results of completed lab tests are synchronized with the hospital Server at the end of the day. The data format of the lab orders and results conform to an XML-based standard called "LabML."[2] [2] For the time being, LabML is imaginary. It is reasonable, however, to expect the emergence of domain-specific standard XML formats in the near future.
The Server part of the Complete eCare application runs on server-class networked machines. The application manages many datastores, including schedules for nurses and doctors, lab orders and results, daily visit records for nurses, and patient charts. The Server supports the HTTP and WSP transport protocols over many underlying communication protocols including wide-area wireline and wireless, as well as local-area wireless. Application Logic Most of the application intelligence resides with the Server application. For illustrative purposes, the Server application may be guided by the following rules: The Server application may enter appointments, perhaps following a call into the office from a patient. If there are conflicts between appointments entered by the application and those entered by the doctor or the nurse, the appointments entered by the doctor or the nurse take precedence. If the nurse and the doctor have ordered the same lab test for a particular patient in the span of a week, the second test order is discarded, and the doctor or the nurse is notified by email. Ordinary entries from the visiting nurse are synchronized with the daily visit datastore. Entries marked "red" are also synchronized with the patient chart datastore. When an entry marked "red" is received, the Server application also schedules an appointment for the patient to visit the doctor at the hospital clinic and alerts the office assistant to notify the patient about the appointment.
Usage Instances The following illustrates a few usage scenarios where SyncML is used to synchronize different data between a variety of devices using diverse network protocols. Thelma visits her first patient Thelma turns on her WAP-enabled PDA in the morning. She had manually entered a morning appointment on her schedule the previous evening. Upon synchronization, the Server application discovers a conflict with a previously scheduled appointment and resolves the conflict in favor of the appointment entered by Thelma. The conflict, however, is flagged during synchronization and the conflicting record is returned to the PDA. The PDA application brings the conflict to Thelma's attention and she enters a new appointment in the afternoon to visit the originally scheduled patient. Thelma visits the first patient. She records vital signs and performs a few quick tests, and then enters the observations and results in the local PDA. The patient appeared fine and there was no need to order any lab tests or to schedule a doctor's visit. She synchronizes her PDA to quickly upload the visit records to the Server. She does this to ensure that the records are not lost in case the PDA is lost, stolen, or broken. At the end of the day, Thelma synchronizes her laptop application with the Server daily visit datastore. Her laptop application obtains the daily updates previously synchronized from the PDA. She fills the descriptive visit summary in the empty summary field and resynchronizes the laptop to complete this visit record and other similar records. Thelma's lab order application is upgraded The "LabML" standards committee had introduced a new field called "priority" in the lab order data format. The priority field is intended for use by the requester to express priorities of high, medium, or low. A laboratory can now better schedule its lab tests according to the expressed priorities of the orders. Over the last few weeks, the Complete eCare application programmers have updated the Client and Server applications to expose this new field in the Client GUI and make necessary changes in the data formats. Now the updated applications are ready for deployment. The SyncML Device Management Protocol (see Chapter 9) is ideal for configuring and managing software on diverse client devices. When Thelma synchronizes her PDA after visiting the first patient, the Client information technology (IT) management application on Thelma's PDA uses the Device Management Protocol to obtain the latest updates to the Lab Order application code from the hospital Server. It installs the application code and enables Thelma to take advantage of this new feature immediately. When Thelma connects her laptop to the Server in the evening, the Client IT management application on the laptop similarly obtains the latest updates to the Lab Order application code from the Server. Thelma's second patient is not doing too well Thelma visits her second patient of the day and finds that he is not doing too well. The patient is under post-operative in-home care and his recovery is not progressing as expected. She records all the measurements and marks the daily visit update "red"; she also orders a high priority blood test on her PDA application, and then synchronizes her PDA. The Client application synchronizes the daily visit update with not only the Server daily visit datastore, but also the Server patient chart datastore, since the entry is marked "red," The Server application schedules a next-day afternoon appointment with the appropriate clinic doctor. The Server application also synchronizes the lab order with the Server lab order datastore. Meanwhile, just before lunch, Thelma ships the blood sample in a protective envelope for next-day morning delivery to the lab. The doctor, in the middle of his morning rounds, synchronizes his wireless tablet calendar with the Server calendar. He notices the new appointment (during his clinic office hours) with the patient. He opens his local patient chart datastore and synchronizes it with the Server. The synchronization updates the local patient datastore with the latest patient chart from the Server datastore for this patient. The doctor reviews the chart briefly over lunch the next day in preparation for the afternoon visit. The lab results are ready in time In order to differentiate from the competition, the laboratory has instituted a policy that results for high priority lab tests will be synchronized with the hospital every two hours. John synchronizes the laboratory office PC with the hospital lab order datastore at 5 PM and picks up the high priority lab order that Thelma entered. The corresponding blood sample arrives the next morning. The sample, being high priority, is tested quickly. The results are ready by 1 PM. John synchronizes the results for this high-priority order in the 2 PM batch and the results appear in the Server lab results datastore. The doctor had noticed the outstanding lab order during his lunch review of the patient charts. Just before the patient visit at 3 PM, he synchronizes the lab results datastore on his tablet with the Server datastore and obtains the results. He is now fully informed before the patient visit and is able to make the best medical decision for the patient. The Benefits of SyncML The use of SyncML in enterprise applications is beneficial from the point of view of the employees, the platform vendors, and the enterprise IT personnel, such as application programmers and system managers. The employee perspective Some of the biggest benefits from the employee standpoint are flexibility, empowerment, and usability. Since enterprise applications are usually richer in function and semantics, it is conceivable that certain parts of the application are best performed on certain devices. In Thelma's case, she finds it convenient to record brief results of observations and home-tests in her PDA as she is performing them. This way she does not have to take them down on paper and later re-enter them. On the other hand, entering lines of text for the visit summary is usually difficult to do on a PDA-type device. Thelma finds it convenient to record her subjective summary later in the day on her laptop. SyncML allows synchronization from diverse devices, allowing the flexibility that Thelma desires. SyncML allows applications to detect and resolve conflicts but enables communication of conflicts in a standard way in its Synchronization Protocol. Policies such as "Client resolves the conflict" can be implemented with relative ease by applications. Thelma is notified and allowed to resolve scheduling conflicts herself directly from her PDA, thereby feeling more empowered as an employee to manage her daily schedule. Thelma is also not worried about managing applications on her mobile devices. SyncML Device Management is used to seamlessly upgrade applications on her device in a timely fashion. This increases overall usability from her perspective and makes her a more effective roving nightingale. The platform vendor perspective In the previous Web calendar example, independent individuals make the buying decisions for the server platform and the client platform. In contrast, in the enterprise case the client and server platforms are bought by the same entity, namely the enterprise management, perhaps advised by the enterprise IT group. Without synchronization standards, it is possible that a dominant server vendor will also drag in client platforms that it owns, or its partners own, by closely coupling the platforms together technically. The reverse is also true. From a technical perspective, a synchronization standard such as SyncML allows server and client platform buying decisions to be relatively independent of each other. For example, when an enterprise buys a server platform, maybe the very best server platform, the owners of that platform cannot drag in its clients by claiming that one must buy these clients to communicate with this wonderful server. The world has converged largely on the TCP/IP communication protocol, and therefore any client implementing the TCP/IP protocol should be able to communicate with any server that does. This allows the clients to freely compete on the client side of the business. SyncML takes this argument to the next level, from the communication layer to the data exchange layer. By adopting a standard data synchronization protocol, the clients and servers can freely compete on the merits of their individual implementations and not use one leverage point to establish another. The enterprise IT perspective SyncML is enormously beneficial from the enterprise IT perspective. First, it reduces the cost of developing mobile enterprise applications. Both Client and Server application programmers can depend on the underlying SyncML stack. Assuming some form of a common SyncML toolkit that allows generation, processing, and communication of SyncML packages over a variety of transports, the application programmers can freely focus on the application logic and user interface issues. The SyncML toolkit can either be developed by the enterprise IT team or bought from a tool vendor, or can actually be included with the platform, as SyncML becomes more commonplace. Once there, the toolkit can be used in common by various applications. Therefore, although it is likely that enterprise applications will use proprietary data formats between Client and Server parts and will likely not be targeted to interoperate with applications developed by other entities, the use of SyncML as an underlying synchronization mechanism will reduce overall application development time. Enterprise applications also need to synchronize with other enterprise applications. For example, the Complete eCare application includes synchronization with a Client in an independent laboratory. In order to really interoperate with applications developed across enterprises, standard data formats and their semantics need to be defined and used by SyncML. The imaginary LabML standard data format is key to interoperability between the hospital and the laboratory. Using a standard synchronization protocol, such as SyncML, and a standard data format, such as LabML, the hospital is able to interoperate with various independent laboratories. Thus, using SyncML, applications within an enterprise are well positioned to interoperate with applications outside the enterprise as standard data formats emerge. Managing client devices is a key element of the overall IT cost in many enterprises. The software components of various devices, including application software, change from time to time. It is difficult to "roll out" the new versions of the software components in a consistent manner. This problem, however, is similar to data synchronization, where the "data" is the binary code for the software component. The IT management applications can use the SyncML Device Management Protocol (which uses the Representation Protocol) to keep device software and applications consistent. In the above example, Thelma's PDA gets updated with the new application code in a timely fashion, enabling a chain of events that result in better overall patient care. Chapter 9 covers SyncML Device Management in more detail. |
