Columbia University's Informatics for Diabetes Education and Telemedicine (IDEATel) Project

Abstract

The Columbia University Informatics for Diabetes Education and Telemedicine IDEATel) project is a four-year demonstration project funded by the Centers for Medicare and Medicaid Services with the overall goal of evaluating the feasibility, acceptability, effectiveness, and cost-effectiveness of telemedicine. The focal point of the intervention is the home telemedicine unit (HTU), which provides four functions: synchronous videoconferencing over standard telephone lines, electronic transmission for fingerstick glucose and blood pressure readings, secure Web-based messaging and clinical data review, and access to Web-based educational materials. The HTU must be usable by elderly patients with no prior computer experience. Providing these functions through the HTU requires tight integration of six components: the HTU itself, case management software, a clinical information system, Web-based educational material, data security, and networking and telecommunications. These six components were integrated through a variety of interfaces, providing a system that works well for patients and providers. With more than 400 HTUs installed, IDEATel has demonstrated the feasibility of large-scale home telemedicine.

The Columbia University Informatics for Diabetes Education and Telemedicine (IDEATel) project is a four-year demonstration project funded by the Centers for Medicare and Medicaid Services (CMS; formerly Health Care Financing Administration) with the overall goal of evaluating the feasibility, acceptability, effectiveness, and cost-effectiveness of telemedicine.¹ The project is enrolling 1,500 patients who have diabetes and are Medicare beneficiaries, half of whom will receive telemedicine case management in a randomized design. No previous study has attempted to deploy home telemedicine on such a large scale or integrate it so tightly into existing clinical information systems and the practice of care. This paper discusses the implementation of the technology intervention.

Previous home-based telemedicine and informatics interventions in disease management have focused separately on three technical approaches. First, synchronous videoconferencing has been used for patient education, monitoring, and motivation.^2,3 Second, remote monitoring has been used to capture disease-specific measurements electronically, such as blood glucose levels and vital signs.^4–8 Third, with the emergence of the World Wide Web, Web sites have been developed to provide disease-specific education, and e-mail has been used increasingly between patients and providers.⁹ The limited data that exist support the value of each of these technology approaches.¹⁰

The technical intervention evolved during lengthy discussions between the technology team and the clinical team. The companion paper¹ (see p. 49 of this issue) describes the clinical background and evaluation component of the project in detail. In brief, optimal management of diabetes requires that patients be educated about their disease and treatment, that they be motivated, and that the process be monitored regularly so that treatment can be adjusted. Diabetes education can be provided both by interactive videoconferencing and by Web-based instructional materials.

Monitoring can involve interactive discussions with caregivers about quality of life, and text-based electronic communication, such as e-mail, as well as the electronic transmission of glucose results. The volume of measurement data generated can easily overwhelm the ability of a human being to accurately detect trends. For that reason, electronic monitoring is often supplemented by the use of decision-support tools that detect and report worrisome values.¹¹

Motivation is in some ways the most problematic. It is clear from earlier studies that patients can be motivated by video interactions with caregivers.¹² Our own earlier experience indicated that electronic monitoring itself can be highly motivational. Simply knowing that someone is watching the numbers can motivate patients to collect the measurements regularly.¹¹

The target population is described in the companion paper.¹ In short, participants have diabetes mellitus, are 55 years of age or older, are not institutionalized, live in a federally designated medically underserved area or health professional shortage area, and are eligible for Medicare Part B. The urban component enrolls patients in New York City. The population of these areas is predominantly African American or Hispanic, with the majority of the Hispanic population having come originally from the Dominican Republic. In the urban component the intervention is, therefore, conducted in both English and Spanish.

The rural component enrolls participants across the entire geographic span of upstate New York, an area nearly 800 miles in breadth. The medically underserved census tracts are interspersed throughout this area. The patients in these groups are predominantly non-Hispanic white.

Design Objectives

In the planning phase of the project, it became clear that videoconferencing, remote monitoring, and Web-based tools are potentially synergistic rather than competing approaches and that the technology intervention should support all three. Furthermore, since no prior study has combined all three modalities, there was little data to suggest which modalities patients would prefer, given the opportunity to choose. In addition to providing these three modalities, the technical implementation needed to satisfy a number of other requirements:

• The technology needed to be usable by elderly diabetic patients who have no computer experience and may not even be literate (objective 1).

• The technology needed to be stable and robust. Many of the study patients live in remote rural locations. Therefore, service calls are prohibitively expensive and needed to be minimized (objective 2).

• To maximize comparability between the intervention and control groups, the technology had to be deployed in patients' homes as soon as possible after intake evaluation and randomization (objective 3).

• The intervention needed to be integrated with the existing care of the patient. This implied that the electronic record needed to support information about the patient's diabetes as well as other diseases. It also implied that close communication be provided between project case managers and the patient's primary care physician (objective 4).

• The project needed to support the best practices in clinical data security, including both existing CMS and impending requirements of the Health Insurance Portability and Accountability Act (HIPAA). The project was given no waivers regarding data security and privacy (objective 5).

• The intervention, although composed of multiple individual systems, should function as a cohesive whole (objective 6).

• To meet the project timetable, the systems needed to be developed and implemented as fast as possible (objective 7).

System Description

From the outset, it was clear that no existing system met all the required criteria. Conversely, the aggressive timetable (objective 7) precluded both building a system from scratch and sufficiently modifying an existing system. The only viable option was to combine multiple vendor and internally developed systems.

Supporting all the functional requirements of the intervention requires the tight integration of six technical components (Figure 1▶): the home telemedicine unit (HTU); the case management software that provides disease-specific longitudinal data displays for individual patients, summary data displays across patient panels for case managers and physicians, and secure messaging among patients and providers; a clinical information system that provides comprehensive patient-specific clinical data to providers and patients and that includes data-driven alerting capabilities; Web access for patients to view educational materials about diabetes and related health issues and to review and enter their own data; data security; and networking and telecommunications. These six components were integrated through a variety of interfaces.

Figure 1 .

Functional overview. The arrangement of the components relates roughly to their relationship. At the top level, the patients interact directly with the home telemedicine unit (HTU). Through the HTU, they access the case management system and Web resources. The clinical information system provides unique patient identifiers used by the other systems. It also provides the long-term repository for clinical data and supplemental data used by the case managers and physicians. The security and telecommunication components interact to support the function of all three layers.

Home Telemedicine Unit (HTU)

The focal point of the intervention is a home telemedicine unit (HTU) (American Telecare Inc. [ATI], Eden Prairie, Minnesota) (Figure 2▶), consisting of a specially modified computer with modem connection to an existing telephone line. The HTU provides four critical functions: videoconferencing, medical data acquisition through an electronic device interface, secure Web-based access to clinical data and messaging, and Web-based access to tailored educational materials.

Figure 2 .

Home telemedicine unit (HTU). The HTU is based on a conventional PC. It is installed with peripherals and a cart in the patient's home. The glucose meter is the SureStep (Lifescan, Milpitas, California). The blood pressure meter is supplied by A&D Medical (Milpitas, California).

Seamless integration of these functions was a significant challenge. In addition, the HTU must be usable by elderly patients who have little or no computer experience. Many of the subjects live in rural areas with no broadband availability, so the HTU needs to operate using conventional analog telephone lines, so-called plain old telephone service (POTS).

A wide variety of hardware and software possibilities were evaluated; no option was ideal for all four required functions. The selected HTU is a PC-based special-purpose device that represents the best compromise and operates over standard telephone connections, thus reducing cost and increasing potential for dissemination. The HTU uses the H.324 videoconferencing standard to transmit video signals at 8frames/sec over POTS connections. This video quality is significantly better than H.323 over a dial-up IP connection and is adequate for face-to-face interactions and such functions as diabetes education and medication instruction. Studies have shown that even lower quality videoconferencing (less than 2frames/sec) is acceptable to patients.¹²

The software on the workstations of the nurse case managers (American Telecare, Inc.) automates videoconferencing connections, logs video visits, and allows nurse case managers to archive still images for future comparisons.

Intervention subjects are also provided with a glucose meter and automated blood pressure meter interfaced with the HTU. Data are collected through the RS-232 data ports of FDA-cleared glucose and blood pressure meters. Each subject is provided with an ISP (Internet service provider) account (discussed under “Telecommunications”). To transmit data, the HTU connects through the ISP and opens an encrypted secure socket layer (SSL) connection to an ATI data server at Columbia-Presbyterian Medical Center (CPMC). On the ATI server, the data are validated, formatted into HL7 standard messages, and forwarded to an interface engine. The interface engine routes copies of the messages to the case management system and the clinical data repository for storage and automated monitoring (e.g., for out-of-range values).

For Web access, the HTU uses standard PC Web-browser software, which provides greatly increased capabilities (such as streaming video) compared with currently available hardware-based browsers (such as WebTV). The HTUs are preconfigured before installation so that patients need to click only one button to connect to the Web, thereby gaining access to several types of Web-based information resources.

A critical design criterion for the HTU was ease of use (objective 1). This is facilitated through use of a custom four-button launch pad (Figure 3▶). The button functions are redundantly coded using color, icons, and bilingual text labels. The pad allows patients to operate the majority of the HTU functions without a mouse or keyboard. The four launch pad functions are “answer video call,” “send data from glucose and blood pressure meters,” “connect to Web site,” and “reboot computer.”

Figure 3 .

Patient launch pad. To simplify operation of the home telemedicine unit (HTU), a customized mouse pad was developed. The buttons are programmable function keys that allow patients to answer video calls or electronically transmit glucose and blood pressure readings with a single push of a button. Pressing the “Web” button will dial the Internet service provider and connect to the project Web site. The patient can then enter a password to view results. The “Restart” button allows the user to either reboot or shut down the system entirely.

Although PC-based, the HTU is designed to minimize failures due to user error (objective 2). The HTU has no user-adjusted settings, no floppy drive, and no CD-ROM drive. Other than the certificate used for patient identification and security, the HTU has no local data storage. If a unit fails, it is replaced by a new unit. This design also facilitates rapid deployment (objective 3). Gentiva Health Services (Overland Park, Kansas) installs and maintains the HTUs. Home care nurses rather than computer technicians perform installation and training, because the ability to communicate effectively with older patients is critical. Patients' existing phone lines are used. In most cases, a simple splitter is used to connect the HTU and the patient's telephone to the same jack. If the existing wiring is not in the right location or does not include an RJ-11 jack, Verizon performs interior wiring under a special program approved by the New York Public Service Commission. Some patients' homes still have two-prong ungrounded, unpolarized electrical outlets, while computers all have three-prong plugs. (Standard three-prong adapters presume polarized outlets and cannot be safely used with such old-style outlets.) In these homes, the HTU is connected to a Ground Fault Circuit Interrupt (Technology Research Corporation; Clearwater, Florida) specifically designed for use with two-prong unpolarized circuits.

The nurse case managers' central stations use the same H.324 software as the HTU. Because these stations are typically in noisy environments, the camera-based microphone is replaced by a directional array microphone (GN-Netcom, Nashua, New Hampshire). This eliminates background noise without the need to use a headset microphone. In addition, a document camera with video-source switching allows the case manager to send training images to the patients. Because the image from the document camera is absolutely steady, a surprisingly clear and detailed image can be transmitted over the H.324 connection. Because the nurse case managers initiate the video calls and the ISP provides local service, participants do not incur long-distance charges. Participants contact nurse case managers by telephoning an 800 number or through the secure messaging system.

Case Management Software

The nurse case managers receive training in diabetes management, following the diabetes guidelines of the Veterans Hospital Administration,¹³ and in the use of computer-based case management tools. The Web-based diabetes case management tools are a customized implementation of the CommuniHealth product (Siemens Health Services, Malvern, Pennsylvania). The case management software supports disease-specific data displays, workflow management, and out-of-range alerting. Patients are able to access a Web-based data display to review their own glucose, glycosylated hemoglobin, and blood pressure levels, their treatment plan, and other aspects of their own clinical data (e.g., weight, diet, and lipid levels). Simplified graphical longitudinal displays are available for these clinical parameters. The nurse case managers are able to view a summary display that shows recent data, alerts, and messages for all their patients at once; they are also able to set and monitor behavioral goals tailored to each patient. Patients receive individualized computer alerts based on parameters set by the nurse case managers.

The case management software also includes a secure electronic clinical communications (ECC) messaging system that provides several features not supported in conventional e-mail. First, the system maintains an archive of all messages sent and received as part of the patient's medical record. Second, it maintains an audit trail for all messages so that the nurse case managers know when a patient or physician has read a message. Third, the ECC system provides guaranteed delivery notification, so that the nurse case managers can be electronically alerted if a message is not read. Fourth, messages are stored on the case management server and accessed through an SSL, and are therefore secure across the network. Unlike a conventional e-mail message, no copies are kept on unsecured servers. Last, because the messages are addressed to role names, such as “My Case Manager,” rather than to the names of persons, such as “Nancy Smith”, ECC facilitates cross-coverage.

The electronic messaging system in the case management software also allows nurse case managers to send messages with embedded URLs to direct patients to specific Web resources. Videoconferencing is used for initial diabetes education and for periodic reinforcement, whereas the ECC system is used for the majority of day-to-day communications between nurse case managers and patients.

Interactions among patients can supplement the benefits of interactions with health care providers.¹⁴ For this reason, the case management system also incorporates discussion groups that are moderated by the nurse case managers. The patient-oriented portion of the case management software is maintained in both English and Spanish versions. Patients are automatically routed to the correct site on the basis of a language preference stored in the database. In addition, all case managers in the urban component are bilingual, so that patients may send and receive text messages in English, Spanish, or a mixture of both.

Clinical Information System

Older patients with diabetes often have other chronic illnesses. Thus, in addition to diabetes-related disease management capabilities, providers need access to comprehensive, longitudinal clinical data (objective 4).

Web-based Clinical Information System (WebCIS) Viewer

The need for clinical data is met by the clinical data repository at CPMC¹⁵ and the Web-based repository interface (WebCIS).¹⁶ WebCIS provides an integrated display of both project-based diabetes-specific and general clinical data. The CPMC data repository uses a generic schema¹⁵ that allows the new data types and new sources of coded data required for the project to be incorporated without creating new tables, and the WebCIS displays were appropriately modified to incorporate these new data types. Pointers for images such as snapshots from video visits are stored in the clinical repository.

Medical Entities Dictionary (MED)

The rapid storage and integration of disparate data types in the CPMC data repository are made possible by the use of the Medical Entities Dictionary (MED), a hierarchic knowledge base.¹⁷ New concepts added to the MED for this project include home glucose monitoring, home blood pressure monitoring, diabetes-related preventive care, case management events, and telemedicine visits. After these data elements were defined in the MED, the corresponding data could be stored in the repository immediately.

Decision Support

The project uses computer-based decision support in two ways. First, the case management software supports table-driven decision support. Both default and patient-specific triggers are used. Examples of monitored events include high and low blood glucose levels, failure to enter or upload data, and failure to read clinical messages. Second, we use the Arden-syntax–based event monitor, which is an integral part of the CPMC data repository.¹⁸ Arden syntax medical logic modules process incoming data events, including laboratory results from patients in the project. This capability allows monitoring of events that do not originate in the case management system, such as glycosylated hemoglobin results.

Web-based Resources

The American Diabetes Association (ADA) project Web site includes a collection of low-literacy diabetes information modules in a format tailored to inexperienced computer users, an interactive quiz, and information about the ADA. Subject areas include basic information about type 1 and type 2 diabetes, eating and diabetes, factors affecting blood sugar, checking one's own blood sugar, the care team, changing habits, emotions and diabetes, and standards of care. Each participant's progress is tracked in a database. These materials are kept current with new medical and behavioral knowledge.

The Web resources for patients (the case management site, the ADA educational site, and the IDEATel project site) are all bilingual. Materials in English were translated into Spanish appropriate to the Hispanic patient, largely of Caribbean origin, who live in the target communities, and ensured that the literacy was at the required 7th grade level or lower.

Data Security

Balancing ease of use with data security (objectives 1 and 5) is always problematic. Different data security solutions were needed for the varied project user groups, which include elderly patients in their homes, nurse case mangers, physicians, and researchers. The project supports multiple computer systems and a variety of user interactions, including data entry, data review, patient education, videoconferencing, and electronic monitoring. The project design for data security required compliance with Internet and other health care data privacy requirements of HIPAA,¹⁹ the need for data at the point of care, and the need for the system to be used by technically unsophisticated patients. The project security policy is based on the well-known components of authentication, authorization, access control, auditing, transport security (encryption), and physical security.

Authentication

The security approaches for the various access and data paths are summarized in Figure 4▶ and Table 1▶. Each numbered connection shown in Figure 4▶ is referred to in the text with angle brackets <1>. Patients and clinicians access clinical data through Web-based interfaces <4,6,7,9–13>. These all use conventional userID/password plus one of four additional methods. First, clinician access from within CPMC is based on access from trusted computers <12>. Second, mobile clinicians use a time-based hardware token system of SecurID (RSA Security, Bedford, Massachusetts) <6,7,11–13>. Third, for patients, a Public Key Infrastructure (PKI) (Crosshair Technologies, Scarsdale, New York) solution was employed. Project staff configure the patient certificate in the HTU prior to home installation. Thus, the patient need only access the Web site from his or her own HTU and have the correct password <9,10> (objective 1). Fourth, access to the evaluation database requires use of a password-protected virtual private network (VPN) from a trusted computer.

Figure 4 .

Summary of data access paths. Various users access project data on numerous systems. Encryption methods for each path are shown in Table 1▶. Back-end servers not accessed directly by users are not shown. See Table 1▶ for list of abbreviations.

Table 1 .

Authentication and Transport Security

		Authentication				Transport Security
Connection Number	Description	Type of Access	UserID/Password	PKI Certificate	SecurID Token	SSL Encryption	VPN	Symm. Key Encr. by Application	Ded. Land Line	Intranet Only
1	HHAR to eval. server	Data	X				X
2	CPMC to eval. server	Data	X							X
3	SUNY to eva.l server	Data	X				X		X
4	CM supervisor to CM server	Web	X	X
5	CM data upload	Data		X		X
6	CM to CM server	Web	X		X	X
7	CM to WebCIS	Web	X		*	X
8	Pt. data upload	Data		X		X
9	Pt. to CM server	Web	X	X		X
10	Pt. to ADA edu. server	Web	X	X		X
11	Non-CPMC MD to CM server	Web	X		X	X
12	CPMC MD to CM server	Web	X		*	X
13	CPMC MD to WebCIS	Web	X		*	X
14	CM to pt. video telephone	Video							X
15	CM server to security server	Sec						X		X
16	ADA edu. server to security	Sec						X

Note: Connection numbers refer to the data paths shown in Figure 4▶. For each connection, security methods are indicated by an X. For example, path 6 uses userID/password and SecurID for authentication, and SSL for transport security. An asterisk indicates that a password and SecurID are required for access from outside the CPMC intranet. Abbreviations: PKI indicates Public Key Infrastructure; SSL, Secure Sockets Layer; VPN, virtual private network; Symm. Key Encr., symmetric key encryption; HHAR, Hebrew Home for the Aged at Riverdale, Bronx, New York; eval. server, evaluation database server; CPMC, Columbia-Presbyterian Medical Center; SUNY, State University of New York; CM, case manager; Pt, patient; MD, physician; ADA, American Diabetes Association; edu., educational.

Authorization

The multi-institutional nature of the project complicates any authorization scheme. Eight distinct categories of patient–provider relationships were identified. Further discussions with providers allowed these to be simplified to four authorization levels. Physicians at CPMC continue to have full access to all data in WebCIS. These physicians have, in addition, access to project data in the case management system for their own patients. Non-CPMC physicians have access only to project-specific data for their own patients in the case management system.

Nurse case managers at CPMC have access to non-sensitive data for all patients in WebCIS, as is standard for CPMC nursing staff. Joslin-based staff have access to non-sensitive data for project patients only in WebCIS. Both groups of nurse case managers have access to individual lists of project patients in the case management system.

Access Control

WebCIS supports access controls by patient, patient-list, patient-class, and data type. Within WebCIS, patients can be flagged as “VIP,” which is typically done for celebrities and employees of CPMC. Access to data on the entire class of VIP patients can be restricted. Access control in the case management software is based on enumerated patient lists and provides “all-or-none” access to a given patient's data. However, in view of the disease-specific nature of the data in the case management system, this was deemed to be adequate.

Auditing

Audit logs of computer access to clinical data at CPMC have been maintained for more than a decade.²⁰ Recorded information includes user, IP address, patient, data type, access type, and date and time of access. Audit trails are periodically monitored for inappropriate access. Access to data on VIP patients receives additional scrutiny. Whenever a user is about to view data on a VIP patient, the user is informed of the special status and required to document the reason for the access. To facilitate auditing, all patients added to the WebCIS repository specifically for the study were flagged as VIP.

As part of the project enrollment process, all patients not already in WebCIS are assigned a CPMC medical record number. Use of the VIP flag represents a compromise between allowing access to these patients' data in case of emergency and discouraging inappropriate access not related to the project.

Transport Security (Encryption)

Current CMS regulations require that all data that travel over the public Internet be encrypted. Web-based access to project data and upload of data from the HTU employ 128-bit SSL. Access to the project evaluation data server uses 168-bit VPN encryption <1–3>. Since the video call is over a dedicated line, the tradeoff between performance and security did not support encryption. Connections from the Web servers to the security policy server use symmetric encryption internal to the security application. Server-to-server data connections within the CPMC Intranet are not encrypted.

Physical Security

All servers containing clinical and evaluation data are housed in the main CPMC computer facility. This site is staffed 24 hours per day and is physically secured with biometric access controlled locks. To reduce tampering with HTUs, the units have neither floppy nor CD-ROM drives and are configured to prevent installation of unauthorized software.

Networking and Telecommunications

The project has diverse communication requirements, and it requires a heterogeneous network design. We chose communication infrastructure options that are widely available, and avoided proprietary solutions wherever possible. The network architecture is shown in Figure 5▶.

Figure 5 .

Network architecture: overview of the telecommunication and network infrastructure for the project. Paths carrying only data are shown as solid lines. Paths carrying video or video and data are shown as dashed lines.

Wide-area Network (WAN)

Syracuse and CPMC are linked redundantly by a 1.5MB T1 connection. The clinical information system, case management, and HTU management software all run on servers located at CPMC. Caregivers at CPMC access the systems across the CPMC local-area network (LAN). Caregivers at Syracuse are connected to their local LAN, bridged to CPMC through the VPN. The evaluation staff at Hebrew Home for the Aged are connected via a 168-bit VPN over a 144Kb IDSL connection. Staff involved in enrollment and evaluation data collection at the rural hospitals access the CPMC network via routed ISDN.

HTU Connectivity

Home telemedicine visits involve H.324 videoconferencing over analog POTS lines. Even though the HTU is designed to use the patient's existing telephone line, this did not make the unit completely “plug-and-play.” For some patients, the existing telephone jack is not located near the desired place for the HTU or does not support the newer RJ-11 connectors, and a new telephone jack is required. For the small percentage of the patients who still have party lines, the New York State Public Service Commission has allowed the regional telecommunication carrier, Verizon, to convert the service to a single-user line at no charge for the two years that the patient has the HTU.

Internet Access

For data uploads from the HTU and for patient Web access, we use a customized ISP access solution provided by Verizon (New York, New York). The project provides local ISP access to all of the patients. These accounts are paid directly by the project and are preconfigured into the hardware before the patient receives the HTU. To simplify the configuration, the ISP provides a special 1-500 number that is automatically converted into a local number by the local telecommunication carrier. In cases where the local carrier does not support the 1-500 routing, a toll-free long-distance number is used. Participating non-CPMC physicians access data using standard Web-browsers over any conventional Internet connection.

Video conferencing

In addition to patient care, videoconferencing is used for project management. H.320/384 conferencing is used for major project team meetings. H.320/120 conferencing is used for interactions with the enrollment and data collection staff in the rural recruitment sites.

Interfaces

A critical factor in allowing the various systems to function as a unified whole (objective 6) is the use of multiple standards-based interfaces. The Health Level Seven (HL7) messaging standard^21–23 was used wherever possible and for all exchanges of clinical data between the vendor systems (Figure 6▶ and Table 2▶).

Figure 6 .

Data server interfaces. Multiple data interfaces integrate various project systems and tie the systems into the Columbia-Presbyterian Medical Center clinical information systems. Details are shown in Table 2▶.

Table 2 .

Summary of Data Interfaces

Interface	Type	Auto-upload Glucose	Auto-upload Blood Pressure	Video Visit Log	Video Snap-shots	Manual-entry Glucose	Manual-entry Blood Pressure	Manual-entry HbA1c	Alerts	Messages	Patient ID Info.	Lab. HbA1c	Routine Lab. Results
A	Mixed	X	X	X	X
B	HL7										X
C	Image				X
D	HL7					X	X	X	X	X	X
E	HL7	X	X
F	HL7											X	X
G	Mixed	X	X	X		X	X	X	X	X		X	X

Note: Interface letters refer to Figure 6▶. All numeric data are transported among vendor systems with HL7 interfaces. Images are transferred by use of FTP on a secured connection. Abbreviations: HbA_1c indicates glycosylated hemoglobin; info., information; lab., laboratory.

To simplify management and improve reliability, data interfaces were routed through the CPMC DataGate interface engine (SeeBeyond, Monrovia, California). In addition to translation, the interface engine provides caching, so that downtime of one interface does not affect other interfaces. Other standards tailored to a specific need, such as Lightweight Directory Access Protocol (LDAP), were used in some synchronous interfaces, such as user authentication.

Status Report

The IDEATel architecture has been able to satisfy the sometimes competing design objectives. The project has successfully implemented this technical approach in less than one year in a physically extended and sociologically diverse user environment. Fifteen months after the start of the project, more than 230 HTUs had been installed, making IDEATel the largest home telemedicine project to date in this country. New units are being installed at a rate of roughly three per day, and full implementation is expected by month 24 of the project.

Discussion

Although implementation is still ongoing and formal evaluations have not been completed, a number of anecdotal observations and lessons can be gleaned from the experience. The first goal of IDEATel was to determine whether the concept of large-scale home telemedicine for the management of elderly patients was even feasible. The project is roughly six times larger than any previous home telemedicine implementation. Given the scale of the project, it was not certain at the outset whether a home telemedicine project of this scale and complexity could be fielded.

The project also demonstrates that the selection of people and the interaction among them are as critical to the success of such projects as the selection of the technology. Rapid installation of the HTU depends on a series of accurate handoffs involving the evaluation staff, the implementation staff, the telecommunication vendor, and the HTU vendor. While workflow software can facilitate these interactions, it is unlikely to eliminate the human component.

Another lesson has been the value of clearly defined interfaces between the various components. Clearly separated areas of responsibility allowed the various vendor teams to develop in parallel. They also allowed the IDEATel staff to focus on the areas of overlap or intersection. In some cases, two vendors could both support a particular function. Clarifying which system would be the “primary” required both careful analysis and careful management of the vendor relations.

The value of interface engines in such multi-vendor projects cannot be overstated. The interface engine interposed IDEATel staff between the various vendors. The greatest value occurred when data transfers failed. Because the interface engine monitored the various feeds and kept copies of the messages, the cause of the failure could be rapidly determined and corrected. This virtually eliminated “finger-pointing” between the various vendors.

The final observation is that urban and rural telemedicine populations are different in ways that are not easy to predict. For example, because the HTU often shares a single POTS line with the patient's phone, it behaves like any extension phone—it rings whenever the main phone rings. A small group of patients find this annoying.

The IDEATel technical implementation is admittedly complex. The complexity of the system integration tasks reflects the scope of the project, the requirement for robust data security, and the need to integrate new technologies, applications, and user types with operational hardware, software, and data security schema. The IDEATel project is designed to answer a number of basic questions about telemedicine. The first of those was whether such a large-scale implementation was even possible. We can say with confidence that the answer is yes.