(Radiographics. 2000;20:1137-1150.)
© RSNA, 2000
Teleradiology as a Foundation for an Enterprise-wide Health Care Delivery System1
John David N. Dionisio, PhD,
Ricky K. Taira, PhD,
Usha Sinha, PhD,
David B. Johnson, MS,
Benjamin Y. Dai, MS,
Gregory H. Tashima, BS,
Stephen Blythe, DO,
Richard Johnson, MD and
Hooshang Kangarloo, MD
1 From the Departments of Radiological Sciences (J.D.N.D., U.S., B.Y.D., G.H.T., H.K.), Computer Science (D.B.J.), and Family Medicine (R.J.), University of California, Los Angeles, 924 Westwood Blvd, Suite 420, Los Angeles, CA 90024; the Department of Radiology, Children's Hospital and Regional Medical Center, University of Washington, Seattle (R.K.T.); and the Harris Family Medical Center, Melbourne, Fla (S.B.). Recipient of a Certificate of Merit award for an infoRAD exhibit at the 1998 RSNA scientific assembly. Received March 1, 1999; revision requested April 28; final revision received October 11; accepted October 21. Supported by grant RO1 CA 39063 from the National Cancer Institute. Address correspondence to J.D.N.D. (e-mail: dondi@itmedicine.net).
 |
Abstract
|
|---|
An effective, integrated telemedicine system has been developed that allows (a) teleconsultation between local primary health care providers (primary care physicians and general radiologists) and remote imaging subspecialists and (b) active patient participation related to his or her medical condition and patient education. The initial stage of system development was a traditional teleradiology consultation service between general radiologists and specialists; this established system was expanded to include primary care physicians and patients. The system was developed by using a well-defined process model, resulting in three integrated modules: a patient module, a primary health care provider module, and a specialist module. A middle agent layer enables tailoring and customization of the modules for each specific user type. Implementation by using Java and the Common Object Request Broker Architecture standard facilitates platform independence and interoperability. The system supports (a) teleconsultation between a local primary health care provider and an imaging subspecialist regardless of geographic location and (b) patient education and online scheduling. The developed system can potentially form a foundation for an enterprise-wide health care delivery system. In such a system, the role of radiologist specialists is enhanced from that of a diagnostician to the management of a patient's process of care.
Index Terms: Computers, diagnostic aid • Computers, educational aid • Teleradiology
|
Introduction
|
|---|
Teleradiology can allow improved patient care by making specialists available to generalists regardless of their geographic locations. By integrating information access for patients, primary health care providers (primary care physicians [PCPs] and general radiologists), and specialists in an existing teleradiology system, the role of PCPs can be changed from a resource controller (gatekeeper) to a more effective triage officer (gateway). Similarly, the role of radiologist specialists can be enhanced from providing interpretations for diagnostic studies to providing advice on patient care and work-up.
This article describes an integrated telemedicine system that provides patient education, online scheduling, and teleconsultation between primary health care providers and imaging specialists and is developed by augmenting an already existing teleradiology consultation service. The system, which is designed around a well-defined process model of patient, generalist (eg, PCPs and general radiologists), and specialist interaction, will not only improve the speed and accuracy of diagnosis but also improve the quality of care and reduce health care costs by facilitating appropriate patient care and work-up. Specific topics discussed are background and motivation; previous work; the teleconsultation process; the patient, primary health care provider, and specialist modules; integration methods; system architecture; implementation and preliminary results; and remaining issues.
|
Background and Motivation
|
|---|
Escalating health care costs have been the major reason for the implementation of a variety of cost control mechanisms, particularly the primary care gatekeeper concept. Under these circumstances, quality of care has decreased, at least for patients with serious illnesses and for the poor and elderly (1). Under the gatekeeper scenario, neither PCPs nor their patients have appropriate authority in the decision-making process. Surveys dealing with satisfaction with this process indicate the importance of physician and patient involvement in medical decision making (2,3).
The majority of patient care is increasingly provided by local PCPs. In an overwhelming majority of cases (80%–90%), the PCP is confident about a specific patient's care. In a small percentage of "difficult cases" (approximately 10%), consultation with appropriate specialists is valuable for correct diagnosis and treatment.
A traditional teleradiology consultation service that provides specialist consultation to general radiologists can be expanded into an integrated enterprise-wide system by incorporating active patient and PCP participation. The natural first step for developing an effective telemedicine-based diagnostic consultation service for difficult cases is the selection of specialists who are familiar with imaging. Because of their considerable knowledge and their working relationships with other medical providers, imaging specialists can function not only as diagnostic consultants but also as effective triage officers for other subspecialty services. For example, a musculoskeletal radiologist can consult for a patient with a complicated musculoskeletal complaint as well as perform triage for sports medicine, orthopedics, rheumatology, and other specialties when necessary.
|
Previous Work
|
|---|
Traditional teleradiology infrastructures can potentially provide any local community with specialist consultation from national experts (4). We have implemented a large-scale teleradiology service with a dedicated T1 line for a high-traffic environment (Fig 1) and have used a dial-up Integrated Services Digital Network (ISDN) service for international and lower-volume transmissions (5).
This traditional teleradiology system can be expanded to closely integrate patient, primary health care provider, and imaging specialist interaction. Such an expanded teleradiology environment can provide teleconsultation services to PCPs in managing difficult cases. These services include the selection of an appropriate imaging procedure, the specific protocol to be used, and sequences of imaging work-up. Such an integrated system will encourage active participation by the patient.
A system with these characteristics—active participation by a patient, consultation between imaging specialists and generalists, and imaging procedures or protocols that are selected particularly for individual patients—paves the way toward the practice of individually tailored medicine (ITM). With ITM, patients can get tailored care and procedures based on their individual needs. This article describes the initial design and implementation of a system that integrates a radiologist's role as a consultant to primary health care providers with the active participation and education of patients.
|
Teleconsultation Process
|
|---|
A patient undergoes the individually tailored process of medical care (ie, ITM) by using the health care delivery system described in this article (Fig 2). The process extends an established teleradiology consultation service between generalist radiologists and specialists (Fig 1) (4) to include PCPs and patients.
View larger version (59K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 2. Consultation process between PCPs and specialists, which includes initial patient participation in the home page, education, and online scheduling (upper part of diagram); PCP examination of data and request for consultation (left side of diagram); and specialist interaction (right side of diagram).
|
|
The process of care distinguishes clearly between diagnosis and therapy components, with an emphasis on diagnosis because this component is almost always performed first, particularly in complicated cases that require imaging. Thus, consultation in the ITM process of care focuses on specialists who are familiar with imaging, a focus that naturally translates into radiologic specialists oriented to organ system or patient age. Nonradiologic specialists, such as cardiologists who are familiar with imaging and obstetricians who are familiar with obstetric ultrasonography (US), will also be able to participate in the imaging-based consultation phase. These "first-line" imaging consultants can, in turn, obtain further consultation from other, nonimaging colleagues in a multispecialty approach.
The process can be grouped into three main phases: patient interaction, PCP or generalist interaction, and specialist interaction (Fig 2). Patients can interact with the system by using a patient module. This module includes medical history, general medical education, and online scheduling functions. When a patient visits his or her primary health care provider, the primary health care provider can log in to the primary health care provider (PCP) module to look at the patient's medical data, including initial assessment. Finally, when the PCP requires a consultation about the current patient, the patient's information can be sent to a specialist radiologist, who can look at this information in his or her customized specialist module to provide consultation regarding the work-up. When imaging is performed, the existing teleradiology consultation process (Fig 1) is followed. The succeeding sections discuss the three interrelated modules—patient, primary health care provider, and specialist—in detail.
|
Patient Module
|
|---|
The patient module consists of three components: (a) a "home page" containing the patient's reminders, medical history, and other information; (b) a library of online educational resources; and (c) a scheduler linked to the patient's local primary care and imaging facilities. The patient may interact freely with his or her home page and educational resources. If an office visit with the patient's PCP is desired, then an appointment can be made with the online scheduler. In addition to standard information such as appointment date and time, the scheduler also collects information about a chief complaint and, by means of an interactive questionnaire consisting of on-screen forms, provides for structured entry of information related to the initial assessment of that chief complaint.
The patient home page is designed to be a starting point for the patient's health-related activities. It provides a dynamic summary of his or her medical information, including scheduling reminders, a visual index of current and past concerns, a medical history, and other health-related items (Fig 3). With the home page, the patient can get an interactive, up-to-the-moment snapshot of his or her health status (6).
View larger version (103K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 3. Patient home page for a fictitious patient. The patient's picture, demographic data, and reminders appear in the upper left part of the screen. A brief history, entered in a structured format, is displayed in the lower part of the screen. Details of the "Library" and "Schedule" tabs are shown in Figures 4 and 5, respectively. AIDS = acquired immunodeficiency syndrome, Meds = medications, Std = standard.
|
|
With the library of educational resources, a patient can select a body region that is of interest to him or her by using an image map (Fig 4a) or a textual list. The library provides three types of educational resources: (a) A general education resource is an interactive tutorial on topics such as brain attack, heart attack, or a specific organ system. (b) Designed with appropriate physician input, risk assessment resources "interview" a patient to estimate his or her risk for a particular condition. (c) Pain and symptom guides educate the patient about specific symptoms, indicating when certain symptoms are severe enough to warrant an appointment with the patient's physician.
View larger version (82K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 4a. Library of educational resources. (a) With body map navigation of resources, the patient selects the area of interest by clicking on a specific anatomic site (eg, the head). When such an area is selected, three resource lists become available to the patient: general education, risk assessment, and pain and symptom guides. (b) A resource (eg, osteoporosis risk assessment) appears after it is selected from a resource list and opened by the patient.
|
|
View larger version (90K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 4b. Library of educational resources. (a) With body map navigation of resources, the patient selects the area of interest by clicking on a specific anatomic site (eg, the head). When such an area is selected, three resource lists become available to the patient: general education, risk assessment, and pain and symptom guides. (b) A resource (eg, osteoporosis risk assessment) appears after it is selected from a resource list and opened by the patient.
|
|
The library's medical content is based on recommendations by scientific societies and the medical literature under the supervision of a medical expert within a particular field. These experts are also responsible for updating the content, with our research group providing technical support and performing the actual programming and code management. For instance, the osteoporosis risk assessment resource (Fig 4b) was developed and is maintained by a family physician who specializes in nutrition (7). A set of cardiac resources developed for the system is maintained by two cardiology groups from the University of California, Los Angeles, and Vanderbilt University.
With the patient scheduler, patients can make appointments with their physicians directly from their client computers. The scheduler can gather initial assessment data based on the patient's chief complaint (Fig 5). This information is kept along with the appointment data (ie, date, time, physician) for later use by the patient's PCP or the consulting radiologist.
View larger version (112K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 5. Initial assessment phase of the appointment scheduling process. After an inquiry into the patient's chief complaint, the initial assessment provides a series of online questions specific to that complaint. When the initial assessment is completed, the patient can select the date and time of the visit.
|
|
|
Primary Health Care Provider Module
|
|---|
During an actual office visit, the PCP or any other primary health care provider can log in to the system. The PCP module initially displays a work list of patients waiting to be seen. The PCP can then select a patient and bring up that patient's medical record, chief complaint, and initial assessment data (Fig 6a).
View larger version (98K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 6a. Consultation request and real-time talk windows. (a) In the PCP module, the consultation modes available to the PCP (talk, e-mail, or submit) appear in the lower right part of the screen. (b) In the consultant module, real-time discussion in the form of a "chat room" is displayed in the lower right part of the screen. Initial assessment data (lower left part of each screen) and the medical history and patient demographics (top part of each screen) are identical in both modules.
|
|
View larger version (90K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 6b. Consultation request and real-time talk windows. (a) In the PCP module, the consultation modes available to the PCP (talk, e-mail, or submit) appear in the lower right part of the screen. (b) In the consultant module, real-time discussion in the form of a "chat room" is displayed in the lower right part of the screen. Initial assessment data (lower left part of each screen) and the medical history and patient demographics (top part of each screen) are identical in both modules.
|
|
The user interface of the PCP module is similar to that of the patient module in terms of displaying patient data. However, the PCP module differs from the patient module in the following ways: (a) A work list shows the patients who are currently waiting to see the PCP. (b) An appointments section displays the PCP's schedule in a calendar format. (c) A messages section displays messages received by the PCP through the network. Initially, these messages consist primarily of consultation responses by specialists. (d) A reference section provides pointers to online resources such as Medline, the World Wide Web, and other medical literature. In terms of information availability, the PCP has access to the medical information of multiple patients, while each patient has access to only his or her own medical information.
As specified in the process model (Fig 2), a PCP may request a consultation if necessary. Appropriate specialists are chosen on the basis of organ system and chief complaint. Three options are provided: real-time talk, which is similar to Internet chat systems; conventional e-mail; and in-system submission of the consultation request (Fig 6a). In all cases, the current patient's information is sent to the specialist through the network (to ensure patient confidentiality, security measures such as encryption are used). The patient's information will be visible to the consulting radiologist when he or she logs into the specialist module.
|
Specialist Module
|
|---|
The specialist module is nearly identical to the PCP module, except that a specialist's work list consists of pending consultation requests that can then be opened and worked on, instead of
incoming or waiting patients. These consultation requests—which are generated when a PCP selects the in-system submission option (Fig 6a)—present the user with the same information as in the PCP module. Space is provided for entering the specialist's response.
If a specialist is logged into the system when a PCP decides to request a consultation, the real-time talk option on the PCP module will be enabled (Fig 6b). Whether the consultation is requested in real time, by e-mail, or by submission, the final result is the same: the consultant, after examining the patient's information, supplies the PCP with a tailored work-up or protocol for diagnosing that patient's condition.
|
Integration Methods
|
|---|
The integration methods for the patient, PCP, and specialist modules consisted of three phases: process modeling, data modeling, and technical specification. The process modeling phase resulted in the flowchart shown in Figure 2, as well as a number of more detailed flowcharts that elaborate on the main steps in Figure 2. The final set of process models provided the system's designers with an overall view of the entire system's operation. Particular attention was paid to who was involved in which process step to determine how the three modules interacted with each other.
Data modeling followed the process modeling phase. Whereas process modeling showed how the patient, PCP, and specialist modules integrated in terms of steps taken over time, data modeling showed how the three modules integrated in terms of the information they required or generated. A hybrid entity-relationship and object-oriented notation was used to specify the information involved in the system (8) (Fig 7).
View larger version (36K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 7. Data model for patient information, which was generated during the data modeling phase of system integration. The patient, PCP, and consultant modules use this common model when retrieving, storing, or displaying patient information. id = identification.
|
|
The technical specification for integrating the three user modules had to satisfy a number of requirements. Hardware independence was a goal; in addition, the nature of the existing teleradiology operation dictated that intermodule communication over a network had to be straightforward.
To accomplish hardware independence with the greatest possible efficiency, the Java programming language was chosen for ease of development and porting (9). The language has a number of compelling characteristics: an elegant, object-oriented model; built-in networking libraries; and a flexible graphical user interface library. In addition, compiled Java code is binary compatible with any platform that supports Java; thus, no porting or recompiling is required to run Java applications on different hardware and operating system platforms.
These Java features have been used extensively in the development and integration of the three user modules. The patient, PCP, and specialist modules are represented as sets of Java classes that communicate through a common database. User interface consistency is achieved by sharing user interface components across the three modules; for example, all three modules share an identical calendar display for making appointments or browsing schedules. Owing to this component approach, refinements, updates, or "bug fixes" are automatically and simultaneously reflected in all three modules. Java's platform independence is used every day because development takes place on multiple platforms (Linux, Mac OS [Apple Computer, Cupertino, Calif], Solaris [Sun Microsystems, Mountain View, Calif], Windows 95/98/NT [Microsoft, Redmond, Wash]) but results in a single build that can be run on each of these platforms by means of a direct file copy of the compiled system.
The system's architecture specifies a number of client and server modules that communicate with each other over a network. The Common Object Request Broker Architecture (CORBA) standard was chosen to facilitate this communication for two primary reasons (10). First, it is platform independent; modules on different hardware or operating system platforms can communicate transparently with each other by using CORBA. Second, it is language independent; although most of the system is implemented by using Java, many components, particularly older, legacy modules, do not use Java but older programming languages such as C or C++ (11,12). Creating CORBA "wrappers" around these modules permits them to communicate over the network with newer, Java-based modules.
CORBA integration is accomplished by specifying an interface or protocol that encapsulates the specific functionality of each module. The modules include not only the client-level patient, PCP, and specialist modules but also server-level components such as database or image servers (Fig 8).
View larger version (69K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 8. Technical aspect of the system's integration methods. Java and CORBA are used by the system to integrate its multiple modules. The modules shown may represent anything ranging from user-level patient, PCP, or specialist clients to agent or server processes.
|
|
Interfaces are specified on the basis of the process and data models created during the first two phases of system integration. For example, the patient module requires a set of scheduling functions for viewing current appointments, creating a new appointment, or changing an existing appointment. These functions are captured as commands within the interface and are "published" through CORBA over the network. These published commands can then be used (or "called") by other modules to accomplish their corresponding functions.
|
System Architecture
|
|---|
The system's operating model consists of three layers: the currently running clients (ie, the patient, PCP, and specialist modules), their corresponding agents (13), and the underlying servers within the system's domain. The interaction between any two of these modules, whether client-to-agent or agent-to-server, is discussed in the previous section and shown in Figure 8.
The architecture of the overall system is as follows: Most of the system's components are encapsulated within a network domain; client machines, running either the patient, PCP, or specialist module, log in by contacting a designated gateway host (Fig 9). A gateway manager running on that host verifies the login and requests an appropriate client agent from the agent server. The newly spawned agent, running on another machine within the domain, then handles all further interaction between the client and the system.
View larger version (61K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 9. Overall system architecture, including components not visible to users. Components communicate by using the integration methods shown in Figure 8. Users interact only with their respective clients; clients interact only with their respective agents, which in turn exist only while the clients are logged in. The dynamic nature of these agents facilitates the customizability of the system.
|
|
Two of an agent's most significant functions are database server interaction and user interface coordination. The agent for a patient, PCP, or specialist client module handles all direct activity with the system's database server. The agent also communicates with a user interface server, which directs the user interface elements (eg, displays, panels, logos, and other graphics) displayed by the modules.
Customization is accomplished because an agent has access to a user's information in the database and performs all operations from the perspective of that user. For example, if the patient module requests the user's appointment schedule, the module issues a "get appointment schedule" request to the agent instead of a database query such as "retrieve events of type = appointment for patient id = 12672." Clients see no other part of the system except for their designated agents, which have no other function than to interact with their specific, assigned user. In effect, the agents mediate the general information at the server level into information that is specific to their assigned clients (14). Agents are terminated when their assigned client logs out of the system.
|
Implementation and Preliminary Results
|
|---|
The following components of the overall system have been implemented and are undergoing testing: (a) system back-end and architecture (ie, database, agent, and user interface servers and gateway and agent hosts); (b) data modeling and loading of a patient's encounter timeline (Fig 7); and (c) agent software for patients, PCPs, consultants, and system administrators.
For the patient module, the following subcomponents have been implemented: (a) the patient home page, which shows patient demographics, medical history, and upcoming appointments;
(b) osteoporosis and cardiac content areas in the patient library; and (c) patient scheduling.
For the PCP module, the following subcomponents have been implemented: (a) the PCP work list, which includes individual display of a patient's medical history and current chief complaint; and (b) a consultation mechanism for asking a specialist, either online or offline, about a given patient in the PCP's work list.
For the specialist module, the following subcomponents have been implemented: (a) the specialist work list, which includes individual display of a patient's medical history and current chief complaint; and (b) an online chat mechanism for communicating with a given patient's PCP.
Patient scheduling is currently running in parallel with the existing scheduling system, while the other subcomponents of the patient, PCP, and consultant modules are in nondeployed, laboratory testing stages. The system is built on the Java 1.1.x specification, CORBA 2.0, and the GemStone/J object-oriented database (GemStone Systems, Beaverton, Ore) (15). These implementation choices have fulfilled expectations thus far, and our experience with using these young technologies has been documented (16).
The Harris Family Medical Center and University Center Imaging in Melbourne, Fla, is the initial deployment site for the system. The facility was designed from the ground up to accommodate the integrated system: Network wiring, workstation locations, and a main computer room are intrinsic parts of the physical plant. Key portions of the three modules have been tested with users as well, and preliminary data from this evaluation are favorable.
The patient scheduler, as a core operational component of the overall system, has reached the user testing phase. The evaluation consisted of initial training, hands-on activity, and a modified Questionnaire for User Interaction Satisfaction (17). The results of the questionnaire were very favorable and have been taken by the development group for the next iteration of the scheduler (18).
An osteoporosis risk assessment panel was designed and implemented as one of the educational resources available through the patient module. This panel has been deployed over the Internet as a stand-alone Web site and has resulted in 600 hits per month (7). On the basis of the initial online assessment, patients who are considered at high risk for osteoporosis are referred to their PCPs. All of these patients required an osteoporosis work-up, including imaging (computed tomography [CT] or dual x-ray absorptiometry).
Cardiac cases constitute an area of process evaluation. The ITM process of care has been implemented for cardiac cases at the Harris Family Medical Center and University Center Imaging. The facility sees an average of 20 cardiac cases per month, all of which undergo ITM consultation. Of these cases, around 58% are genuine cardiac abnormalities, with 13% resulting in a change of diagnosis due to the consultation. Cardiologists participating in the process have stated that these changes in diagnosis (as well as the confirmation or corroboration of the diagnosis in the other 87% of cases) represent a significant improvement in the quality of care of these patients. Support software and content for these patients—similar to the already implemented osteoporosis risk assessment module—are currently in the prototype stage.
Initial experience with electronic patient-physician communication currently includes e-mail contact between patients and their PCPs. One of the four physicians at the Harris Family Medical Center and University Center Imaging is testing such e-mail communication with patients. An overwhelming majority of the patients (90%) have indicated their desire for this kind of communication. This result is somewhat unusual and may reflect the nature of the patient population, the majority of which consists of technically knowledgeable engineers. Within 1 year of operation, 225 patients were registered as part of the physician's address book, communicating regularly with that PCP via e-mail.
Focused interview sessions with target users have been conducted on the types of hardware preferred for hosting each module (patient, generalist, or specialist). According to these interviews, PCPs are satisfied with familiar, standard personal computers. Radiologists required a different type of workstation; for magnetic resonance (MR) and CT studies, they required a high-end digital 12-bit viewing station. For US and nuclear medicine studies, a frame grabber system (ie, video to a standard monitor) was acceptable. A commercial product that uses a Web browser for image viewing was also tested. Although this product did fulfill the promise of securely delivering studies to a Web browser over the Internet, much of its functionality was closed and proprietary, thus preventing integration of this product with the prototype system described in this article.
Another evaluation has been performed on variations in how local generalists and remote specialists manage a patient's process of care. This evaluation found an approximately 15%–20% difference between the opinions of local generalists and those of specialists, with the specialist consultations having a beneficial effect on follow-up and patient care. These consultations are provided to local generalists, who in turn incorporate the specialist's opinion into their own reports.
|
Remaining Issues
|
|---|
The existing traditional teleradiology consultation service has resulted in increased use of CT and MR imaging (4). The effect of a fully developed teleconsultation system between PCPs and imaging specialists, as well as active participation by patients in their health care, will most likely affect utilization of health care services, which needs to be measured and evaluated.
The appropriate selection of specialists is a looming issue. The current implementation uses
a straightforward mapping of organ system and patient age. However, as the number and complexity of potential cases increase and specialties become more focused and specific, more sophisticated physician profiling including machine learning techniques will become necessary.
Widespread consultation by electronic means has many potential implications, particularly in the context of the broad appeal of the Internet. Initial explorations concern direct patient interaction with physicians and should later cover generalist-specialist consultations of the type discussed in this article (19,20).
Security issues remain, on many levels (21,22). Network security is currently accomplished by physically separating the system from the Internet at large. This approach has the disadvantage of limiting the client machines to those within the system's intranet (including direct dial-up connections). For broader deployment over the Internet, commercial implementations of firewalls, tunneling, and virtual private networks are being explored.
Patient privacy issues, which are currently handled by a conventional identification and password mechanism, will be addressed further as commercial technologies such as smart cards, fingerprint decoders, and other embedded devices (eg, Java rings, buttons) mature. The general approach to security and privacy is to monitor commercial developments and apply them to the system over time.
Issues of network reliability and fault tolerance may arise as use of the system increases. Commercially available network management software (Net Manager [Sun Microsystems]) is currently linked to a hospital paging system to alert administrators of network problems. Additional measures will be required as the system scales up in terms of number of users and amount of data.
As the client-agent-server approach matures, the existing traditional teleradiology consultation service will be revamped and fully integrated into the architecture. This step requires a transitional plan so that it will not compromise the existing teleradiology clinical operation.
|
Conclusions
|
|---|
A well-defined process of care is critical to the proper design and implementation of any technologic framework in support of that process. The integrated patient, local primary health care provider, and remote specialist modules described in this article are designed around such a process, by means of which national specialists can be made available to patients regardless of their geographic location. A middle agent layer enables tailoring and customization of the modules for each specific user type. Implementation by using Java and CORBA facilitates platform independence and interoperability.
The resulting system can potentially form a foundation for an enterprise-wide health care delivery system. In such a system, the role of radiologist specialists is enhanced from that of a diagnostician to the management of a patient's process of care. The integration of the system enables both national and international experts to function in this capacity. Local general radiologists and PCPs form a team of primary health care providers that uses imaging to objectify subjective clinical findings.
The initial stage of system development was a traditional teleradiology system that needed to function in a busy clinical environment. The system also had to be evaluated for acceptance by generalists and specialists. The turnaround time for consultation results, the type of viewing station needed, and changes in use all had to be addressed (4). The patient module was developed in-house and tested in a laboratory environment for user satisfaction. Thus far, one educational resource has been implemented in an actual clinical environment (osteoporosis risk assessment) to obtain user input (7). Electronic patient-physician interaction has been limited to e-mail, with favorable results thus far. The hardware-independent, online scheduling system has been developed and tested in the laboratory environment and is gradually being integrated with the remainder of the system.
According to initial input from users, including local generalists, patients, and remote specialists, the system is highly satisfactory. Patients welcome the electronic availability of appropriate educational material and interaction with their PCPs.
When development and integration of such a system follow a systematic process model, the system can be operational in a busy, real-world clinical environment while new developments are being integrated. Hardware independence and scalability are important requirements for allowing further expansion of such a system.
|
Footnotes
|
|---|
Abbreviations: CORBA = Common Object Request Broker Architecture,
ITM = individually tailored medicine,
PCP = primary care physician
|
References
|
|---|
-
Ware JE, Jr, Bayliss MS, Rogers WH, Kosinski M, Tarlov AR. Differences in 4-year health outcomes for elderly and poor, chronically ill patients treated in HMO and fee-for-service systems: results from the Medical Outcomes Study. JAMA 1996; 276:1039-1047.
-
Holmes-Rovner M, Kroll J, Schmitt N, et al. Patient satisfaction with health care decisions: the Satisfaction with Decision scale. Med Decis Making 1996; 16:58-64.[Abstract/Free Full Text]
-
Dolan JG. A method for evaluating health care providers' decision making: the Provider Decision Process Assessment Instrument. Med Decis Making 1999; 19:38-41.[Abstract/Free Full Text]
-
Kangarloo H, Ho BKT, Lufkin RB, et al. Effect of conversion from a fee-for-service plan to a capitation reimbursement system on a circumscribed outpatient radiology practice of 20,000 persons. Radiology 1996; 201:79-84.[Abstract/Free Full Text]
-
Ho BKT, Taira RK, Steckel RJ, Kangarloo H. Technical considerations in planning a distributed teleradiology system. Telemed J 1995; 1:53-65.[Medline]
-
Tang PC, Newcomb C. Informing patients: a guide for providing patient health information. J Am Med Inform Assoc 1998; 5:563-570.[Abstract/Free Full Text]
-
Blythe S. Are you at risk for osteoporosis?; Available at: http://www.drblythe.com/weightloss/osteotop.htm..
-
Dionisio JDN, Cardenas AF. A unified data model for representing multimedia, timeline, and simulation data. IEEE Trans Knowledge Data Eng 1998; 10:746-767.
-
Javasoft home page; Available at: http://javasoft.com..
-
Object Management Group home page.; Available at: http://www.omg.org..
-
Kilman DG, Forslund DW. An international collaboratory based on virtual patient records. Communications of the ACM 1997; 40:110-117.
-
Morgan B. Building distributed applications with Java and CORBA. Dr. Dobb's Journal April 1998; 94-105.
-
Maes P. Agents that reduce work and information overload. Communications of the ACM 1994; 37:30-40.
-
Wiederhold G. Mediators in the architecture of future information systems. IEEE Computer Magazine March 1992; 38-49.
-
GemStone/J programming guide Beaverton, Ore: GemStone Systems, March 1998.
-
Dionisio JDN, Sinha U, Dai B, Johnson DB, Taira RK. Initial experiences with building a health care infrastructure based on Java and object-oriented database technology. Proc AMIA Annu Fall Symp 1999; 515-519.
-
Shneiderman B. Designing the user interface 3rd ed. Reading, Mass: Addison-Wesley, 1998; 136-143.
-
Dai BY, Sinha U, Dionisio JDN, Tashima GH, Valdez J, Kangarloo H. Individually tailored time management: a process model–based scheduler infrastructure integrated with a patient medical record (abstr). AJR Am J Roentgenol 1999; 172(suppl):92.
-
Borowitz SM, Wyatt JC. The origin, content, and workload of e-mail consultations. JAMA 1998; 280:1321-1324.[Abstract/Free Full Text]
-
Spielberg AR. On call and online: sociohistorical, legal, and ethical implications of e-mail for the patient-physician relationship. JAMA 1998; 280:1353-1359.[Abstract/Free Full Text]
-
Barber B, Garwood D, Skerman P. Security in hospital information systems. Int J Biomed Computing 1995; 39:133-138.
-
Furnell SM, Gaunt PN, Pangalos G, Sanders PW, Warren MJ. A generic methodology for health care data security. Med Inform 1994; 19:229-245.
Top
Abstract
Introduction
