On a warm summer evening in July, John Smith, a successful executive at the ABC Inc., returned from his week-long negotiating sessions with his overseas customers. The negotiations were tiring and long, and John felt both physically and mentally exhausted. He had not been able to convince his customers to renew the contract. This was when he began to experience severe abdominal pain and dizziness. Immediately, John turned on his laptop computer, attached himself to the vital signs devices to the PCMIA slot of the laptop, punched in the URL to hook up to his Field Nursing Station (FNS) - a World-Wide-Web interactive nursing station assigned to him whenever he is on travel. The computer at the nursing station immediately beeped to alert the advice nurse about John’s connecting to the health information network and displayed the incoming vital signs data. The computer loaded John’s medical file, validated and verified his incoming biodata, and detected that he is dehydrated and suffered from shortness of breath. The FNS also found John to have typical symptoms of depression and so advised the nurse. The FNS computer also analyzed John’s biodata and concluded that advice must be secured from a cardiologist and psychiatrist as well. It asked for permission from the nurse to contact these remote specialists immediately. The nurse reevaluated the data and concurred with the computer. Upon the permission from the nurse, the nursing station computer connected to these specialists at the remote sites. The computers at the specialists’ sites examined the data and interacted with the physicians, and at one instance, acted as an educated facilitator/negotiator for the cardiologist and psychiatrist as their two initial treatment plans were different. Once, consensus on a treatment plan was reached, the computer relayed the negotiated recommendations to the nurse. These recommendations included advising John to take Ecocyn¹ tablets, plenty of fluids, and rest and log back to the nursing station in two hours. The nurse once again reviewed the recommendations and approved them. The computer initiated a teleconferencing session between the advising nurse and John, and the nurse communicated the ordered prescription to him personally. She also informed John that arrangements have been made for him to pick-up the medication at the nearest pharmacy. The entire operation last approximately 25 minutes.

The above scenario sure must sound futuristic. But the technology for implementing such a sequence of events is already beginning to evolve. The ever expanding global network, availability of inter-platform connectivity software, progress in design and development of multi-media-based decision and negotiation systems are all making telemedicine closer to reality.

This scenario also reflects the trends of a healthcare system that promises to be:

1. managed, to control the exorbitant cost of healthcare
2. proactive with emphasis on prevention
3. self-administered with individuals having direct access to advanced medical technologies that allow them to regularly monitor the vital health signs
4. minimally invasive with less reliance on surgical intervention, and
5. global with healthcare providers operating worldwide and their patients sometimes geographically apart.

As such, the scenario also illustrates the concept of using computer technology as non-human teleworkers. Indeed, as the networked organization reaches the new frontiers of workplace (e.g., telemedicine, flexible organization, Internet commerce), some form of organizational intelligence will be required to allow the competitive organization to stay abreast of the fast changing environment.

For some time, and in theory, distributed systems have been regarded as the next generation of intelligent systems which promises to provide support to management in solving complex organizational problems. More recently, research in enterprise and distributed computing has accelerated as a result of the tremendous progress achieved in the area of networking and telecommunications. The renewed interest in this area of research does, however, depart from the traditional paradigm that relies on tightly closed and homogenous system architectures.

Organizations are now exploring the use of Internet-based client-server architecture allowing their large and interdependent functional units to migrate into independent and domain specific platforms, yet capable of interfacing with each other. Recent deployment of the global banking systems and the explosive growth of Web-based electronic commerce are examples of widely-publicized success stories [2].

These systems can be seen as a new generation of global management information systems. They are lacking, however, in decision support and embedded distributed intelligence. In addition, due to the lack of cost-effective information infrastructure, current knowledge based systems are still characterized by the inability to interleave seamlessly with multiple platforms that require interoperability.

In this paper, we describe a cost-effective framework that enables both human and non-human teleworkers to collaborate in such a network setting. The proposed framework can be seen an innovative approach to embed non-human teleworkers in a distributed and flexible organization.

For the purpose of this paper, telemedicine refers to the delivery of healthcare using computers and telecommunication technology for diagnosis and treatment [1]. Whenever appropriate, diagnosis and treatment during the course of patient interaction can be done remotely. Primary functional areas of telemedicine include, but are not limited to [5]:

• Teleradiology
• Telecardiology,
• Teledentistry,
• Teledermatology, and
• Teleopathology.

As a new mode of organizational connectivity, telemedicine can be seen as a special form of "virtual hospital" in which the patient can benefit from a medical team that is put together from various centers of excellence that are geographically dispersed. When the patient logs in with a medical complaint, at the intervention of the advice nurse, each of the medical team members assigned to a patient can be contacted instantaneously. The patient can also be connected, whenever the needs call for, to other specialists throughout the Internet-based network of medical care. This would typically happen if the patient’s problems go beyond the expertise of the currently assigned medical teams.

Benefits of telemedicine include:

• flexible organization infrastructure,
• greater access to healthcare,
• improved quality of healthcare due to quick availability of the best facilities regardless of geographical boundaries, and
• reduced costs of healthcare thanks to economies of scale.

Software agents are the result of a paradigm shift in developing application software. Software is no longer regarded as a tool. Rather, it is considered as an autonomous assistant to the users - hence the word Personal Assistant in the software engineering literature. In other words, the traditional approach to software development is a reactive one in that the computer is programmed to react to the user’s instruction. Instead, the software agent approach is a pro-active one, in that the user specifies what he/she wants the computer to accomplish, and the latter performs tasks on behalf of the users the way it does best. By analogy, a software agent mimics the role of an intelligent, dedicated and competent personal assistant (e.g., secretary of a busy executive, or medical assistant of an engaged physician). An intelligent software agent should be able to perform the following tasks:

• Search and retrieve information,
• Manage information overload,
• Perform repetitive office activity,
• Assist in mundane personal activity, and
• Refer to domain expert.

Table 1. Negotiation Agent as Explorer of Goals, Preferences, Solutions and Actors Spaces

To accomplish these tasks, it should possess the following general characteristics [3]:

• Independence,
• Learning,
• Cooperation,
• Reasoning, and
• Intelligence.

In a networked organization, software agents can be seen as teleworkers as they are agents assigned with specific tasks and sent to the "field" to interact with other agents or customers. An agent could perform its role as a:

• Front-end agent directly interacting with the customers (e.g., the FNS in the working scenario interacting with John Smith),
• Back-end agent supporting the task of a human teleworker (e.g., the expert system module supporting the work of the physician-specialist), and
• Mobile agent that intervenes whenever and wherever it is called for (e.g., the Negotiation Manager as the group decision and negotiation agent).
• Stationary agent: that typically involves large-scale legacy systems located at major corporate centers, and whose mission and operational uniqueness justifies its local architecture.

4. Problem-Solving and Negotiation in Telemedicine

Problem solving can be modeled as a sequence of four functional processes: (i) problem definition, (ii) analysis, (iii) solution-finding, and (iv) negotiation. Adapted to healthcare the four processes can be translated into (i) medical examination, (ii) diagnosis (Dx), (iii) treatment (Tx) recommendation, and (iv) treatment plan/ prognosis.

The participants in the decision chain include the patient, the advice nurse, and any number of medical specialists depending on the health problem being addressed. The use of qualified experts within an organization has proven to be an effective means for problem solving. Based on the assumption that "two heads are better than one", researchers (e.g., [7]) recommend that opinions from more than one expert, whenever possible, should be considered. An accord among medical experts in a severe case can often be the result of an intense, laborious and evolutionary negotiation process. During this process, involved parties are confronted with goal, judgment and outcome conflict. As such, negotiation may be characterized as "a process of potentially opportunistic interaction by which two or more parties, with some apparent conflict, seek to do better through jointly decided action than they could otherwise" [4]. Research in negotiation has often focused on the quantitative and/or qualitative mechanics of seeking a consensus or a compromise outcome that would be acceptable to all. The traditional modeling approach treats a negotiation problem as a well structured problem and assumes a dynamic search for consensus within the context of the problem until a solution can be found. Such an approach presumes, however, that negotiation is a well-confined process. In fact, we argue that, more often than not, negotiation accord is the result of multiple, intense, and evolutionary negotiation processes, punctuated by streams of working agreements and disagreements. For each of these processes, a variety of process-dependent problem-solving methods can be used (e.g., [8]).

A mobile negotiating agent’s tasks consist of:

• continuously search for conflicting problems across the organization, and
• intervene, whenever and wherever necessary, to bring about a consensual solution.

This process seeks to promote (i) problem adaptation through information-sharing and concession-making; and (ii) problem restructuring or reframing. In this sense, when satisfactory solutions are not forthcoming, problem restructuring is a key approach - i.e., expanding the solution set, challenging and revising the goals and preferences of involved parties, and, if needed, changing the composition of the decision making team. Table 1 describes the three programmed functions of the Negotiation agent.

Technically, the mobile negotiation agent can be programmed as a process-driven software agent whose mission is to help conflicting agents explore new goals, new preferences, new solutions, or new agents in the search for a consensual outcome (see Table 1).

A generic architecture of the software agent, adapted from Poggi [6] is depicted in Figure 1. For the telemedicine context, and as described later in more details, the user (e.g., patient, nurse, physician) interact with their agents via the User-Agent Interface. The interface role is to pass the agent’s data in the user’s format. The agent uses its embedded procedures (Agent’s processing engine) and its data (Agent’s Repository) to perform tasks and exchange information via the electronic mailbox. Agents are seamlessly connected together both horizontally and vertically.

Horizontal links permit medical systems at the same operational levels to work together (i.e., interchange of information between nursing systems, between knowledge-based systems belonging to the same medical specialty). Vertical links allow all echelons of care be seamlessly connected to ensure adequate treatment (i.e., patient system ® nursing system ® general practitioner system ® specialist system).

Figure 1. The Structure of a Software Agent

Figures 2 and 3 respectively show a typical telemedicine workflow and the proposed Internet-based telemedicine system architecture. Human teleworkers include patients, advice nurse, doctors on-duty and specialists. Software agents are composed of: (i) the Exam Manager, (ii) Dx/Tx Manager, (iii) the Session Manager, (iv) the Specialty Problem Solver, and (v) the Negotiation Manager.

A treatment scenario begins with data about the problem being gathered by the Exam Manager at the patient site. It is passed on to the Dx/Tx Manager at the site where the field provider/advice nurse is located. The Dx/Tx Manager analyzes the patient data received over the Internet and, using a knowledge and cost-based approach, identifies which Specialty Problem Solvers should participate in generating treatment recommendations. The Session Manager at the field provider site then initiates communications with their counterparts belonging to these Specialty Problem Solvers. The Solvers execute the problem, independently or interactively with a human specialist, and arrive at recommendations. The Negotiation Manager receives their recommendations and applies its own algorithms to reach an overall consensus solution. The solution is then communicated back to the Dx/Tx Manager which is then presented to the field provider through a human interface.

The functions shown in the model (Figure 3) are further explained below.

Figure 2. Telemedicine workflow model

Figure 3. System View of Internet-based Telemedicine Support Process

Examination: The problem-solving process begins with data collection from the patient user who has a health problem to be solved. Subjective data such as patient’s description of symptoms and feelings as well as objective data like vital sign measurements are collected. The gathered data is sent to the advice nurse who is alerted as soon as the patient information is received. To implement this, in the operational context of the Internet, an input form may be used in conjunction with a net browser such as Netscape. This pre-designed form has all the questions/parameters related to the problem description. The data obtained is verified and validated. It is then forwarded electronically, either by e-mail or file transfer protocol to the diagnosis phase of the model. It is also possible to gather data directly through sensors/health monitoring equipment and transmit them over the Internet.

Diagnosis: Once the patient data is received, the advice nurse analyzes them towards finding a recommended course of action to be prescribed. The diagnosis phase consists of examining the problem details as received from the examination phase and select the appropriate medical specialists who are qualified to further evaluate the problem towards generating an overall solution. It is also possible in simple cases for the advice nurse to make a decision without further consultation with any other specialists. In the Internet context, these specialists are intelligent systems implemented at various nodes on the net and can be connected using their URLs. Although theoretically, the more the number consulted intelligent systems the better. In practice, there are several limiting factors, like the cost of using an expert, the severity and urgency of the problem, and so on. Thus, it is important to find an optimum strategy on a case by case basis.

Treatment (Tx) Recommendation: Once the problem-related data is passed along to the selected medical consultants, each of them arrive at their own individual solutions based on their knowledge and experience. It is assumed that unless the problem fits in such perfect unison with the individual knowledge bases, the physicians are more likely to arrive at alternative solutions to the problem at hand than otherwise. On the Internet, it involves setting up sessions and exchange of data packets with the expert systems stored at the various sites using their URLs, a platform independent language (e.g., Java), and file transfer protocol utilities.

Tx Plan/Prognosis: As seen in the previous phase, it is more likely for the consulted experts to arrive at different solutions than otherwise. When this occurs, it becomes necessary for the experts to negotiate among themselves until a consensus patient treatment strategy can be found. There is an abundance of methods from which to draw an appropriate negotiation algorithm that would fit a given problem during a problem solving session [x]. On the Internet, it would necessitate having these algorithms on the net at the different net sites, and the ability of software agents to detect and pass the individual expert conclusions to these sites. In practice, Java applets with wrapped code can help in invoking knowledge bases located at the various nodes on the Internet and data transfer protocols (using ASCII or byte data format) can move data files dynamically between the specialists sites and the negotiating site.

If a consensus has been reached through negotiation towards resolving how the patient is to be treated, the final step involves implementing this consensus prescription. The agreed solution is communicated to the advice nurse for action and follow up with the patient. However, if the negotiation phase could generate only different recommendations, then the advice nurse may review them and choose one oneself and arrive at her own prescription, or may seek further assistance from the Negotiation Manager.

The implementation addresses the scenario that presented in the beginning section of this paper. It demonstrates how a telemedicine application can be built using the workflow, agent models and the system view discussed in earlier sections. Again, in telemedicine, the objective is to provide expert medical advice to patients through a nurse intermediary by remotely contacting the physicians. In the previous section, we simply refer to intelligent systems in a very generic form. They can be of any form including knowledge based systems, case based reasoning, data extraction and mining tools, and/or complex computational algorithms. In this prototype implementation, intelligent systems refer to expert systems. Figure 4 maps the generic telemedicine support process into the corresponding implementation agents as applied to John Smith’s case. These are further described below.

Figure 4. A System View as Applied to John’s Case

Exam Manager: The patient inputs, both manual and sensory, are input into the Exam Manager through an intelligent front-end. This involves at a minimum a personal computer with Internet connection and a web browser software. The browser provides access to the homepage of the website which houses the Medical Management Software. The homepage is made up of a series of html files which collects the problem parameters interactively from the patient. In this manner the problem data is directly stored at the homepage site. An alternative method is to collect the data at user site itself and use an ASCII file transfer subsequently.

Dx/Tx Manager: This component is housed at the field provider computer site. The goal is to interpret the problem characteristics as obtained from the user and select a relevant combination of expert systems on the Internet that will independently work towards generating solution recommendations. This is done with the help of a meta-knowledge base. It is a repository of all the medical software available and their URLs. In addition, knowledge about which particular Specialty Problem Solver applications are to be invoked during a consultation session matching the problem characteristics are also stored in the form of If-Then rules. For example, consider a patient who has shortness of breath and depression. The matching rules are shown below.

Once the selection of the Specialty applications has been made using the above rules, the Dx/Tx Manager determines from the meta-knowledge base their URLs and invokes them.

This is achieved with the use of the meta-knowledge base. In this instance, a second level of If-Then rules are stored with the conditional part of the rule having the Specialty Problem Solver names and the conclusion part of the rule pointing to the corresponding html file that should be used by the browser. A separate rule is used for each combination of Solvers. Similarly, a distinct html file is also used for each rule with applet codes to execute the corresponding Solver applications. For example, for the above problem which requires calling Cardiologist and Psychiatrist, if the corresponding html file to be run were html_Card_Psych, then the rule is represented as shown.

A sample of applet codes inside the html_Card_Psych file referred earlier is highlighted below..

.<html>

The applets are batch file wrapped so that DOS/Windows based applications can be executed at the connected Internet site when the applets are run. Thus, when the first applet is executed, it enables the CSUN site and runs a DOS based application using VP-Expert, a commercial-of-the-shelf rule-based expert system.

Specialty Problem Solver: These solvers are the independent specialized applications that are called upon to run by the remote Dx/Tx Manager. They can be located anywhere on the Internet and hence can be using any type of application software and can be running on totally different software platforms. They contain the standard production rule based knowledge bases (other knowledge representations are possible as well) in their respective domains of expertise and can assign confidence scores for the conclusions. They use the original problem data transferred to them by the software agent through a ASCII data transfer protocol. After individual inferencing, their recommendations are also stored in ASCII data files at their respective sites for other Specialty Problem Solvers and the Negotiation Manager agent to screen from time to time while finding an overall solution/consensus.

Negotiation Manager: The purpose of this component is to evaluate the various recommendations arrived at independently by the Specialty Solvers in the Internet and find a consensus solution if needed. While different methods are possible to accomplish, this research study uses a knowledge based approach. Hence, rules are stored to take into account the various possible combinations of outcomes from the Specialty Solvers and what the relative final recommendations should be. Since confidence scores are assigned when generating recommendations, one way to arrive at a conclusion is to determine which recommendation was identified the most by all the experts and with the highest confidence. The following rule demonstrates the method:

where CS represents the confidence score on a scale of 0 to 100, 0 representing the lowest confidence and 100 the highest.

Both Exam Manager and Negotiating Manager components use software agents in their functions. The Exam Manager employs two kinds of agents. The first kind is run at pre-specified time intervals and scans patient databases for potential problems using key word searches. Example keywords are weight cholesterol, insulin count and so on. If the agent finds on examination of a patient’s record that the weight, has changed over 10% since last read, the agent might send out an advice to the assigned physician. The second type of agent scans for the incoming patient form inputs and as soon as one is spotted advises the field provider of it in order to capture immediate attention.

The Negotiation agent uses agents that can detect as soon as the Dx/Tx Manager initiates an interaction session on the Internet. Other agents employed the Negotiator act as a liaison among the Specialty Problem Solvers by exchanging emails of their recommendations so as to assist in faster consensus generation.

The most obvious benefit of the proposed system is that seamless data collection can be cost-effectively achieved with relatively low investment of the Internet global infrastructure. The latter ensures adequate interoperable communication support to support medical systems connectivity.

With a client-server architecture in which each medical station (e.g., nurse station, doctor’s station, hospital’s station) augmented with its software agents, and supported my mobile agents, medical models (i.e., models for diagnosis and treatment) and related data are maintained at the user’s sites. The decentralization and ownership of systems (i.e., medical units) are expected to help secure accurate and reliable data.

From a system design perspective, the proposed framework also introduces a flexible concept supporting highly dynamic organization that uses agents as a task-oriented team of:

• human versus non-human teleworkers, and
• software agents as support and/or replacement of human teleworkers.

Most important, from a telework perspective, the design of the proposed architecture seeks to minimize medical footprint, allowing better use of medical resources, while providing continuity of care. Indeed, the possibility to provide anytime-anywhere healthcare would make the patient feel at home as he/she is always in touch first with his/her primary care provider.

The experience on the project so far has proved that the concept of providing medical service from a remote location is a feasible one. Ultimately, telemedicine will become an integral part of patient healthcare activities. The steady expansion of the Internet and availability of platform independent software make the prospect of achieving telemedicine implementations faster and more cost-effective as well.

Technology and software are now available in developing knowledge-based systems to implement the Dx/Tx and Specialty Problem Solver components proposed in our telemedicine architecture. However, the future is not without challenges. The current technology is still not sufficiently powerful to allow easy and quick creation of the applet calls from the html files Also, the wrapper mechanism to launch local applications at local nodes is primitive at best. Improvements in future versions of the Java development environment and network browsers are expected to address these issues and provide more user transparent code-ability. Last but not least, additional programming tools are needed is in implementing software agents. In order to make the Internet sessions more dynamic and proactive in problem solving, more mobile agents are also required. Several approaches are being explored in developing algorithms that can accomplish their implementation.

The authors would like to thank Dalila Carey, RN, Theresa Bui, D.C., Lt Doris Nevded, USN, MSC, for their inputs on the use of telemedicine and the preparation of the case scenario used in this paper.