OVERVIEW OF THE IMSA PROJECT , A PATIENT-ORIENTED INFORMATION SYSTEM

This paper proposes an overview of the IMSA application, a patient-oriented medical information system. IMSA stands for Interactive Multimedia System for Auto-medication and aims to provide a health-care Internet tool for the end-user. This system proposes an environment that integrates on-line health information, medical and pharmaceutical databases and a knowledge-based system for medical diagnosis. The implementation process focuses on cognitive science, knowledge representation and human-computer interaction.


INTRODUCTION
The use of the Internet and the World Wide Web in health-care has attracted a lot of attention lately.Consumers are now finding medical information on the Web and changing the balance of power in the practice of medicine.Patients are no longer passive but interact actively during their consultations with physicians.Health-care practitioners are also using the Internet -to keep up in their field, to communicate with patients and to consult with each other.But the internet has not yet achieved the expected fundamental and far-reaching effect on the health-care industry.We think that the reasons for this are cultural and functional.We conducted a study on the functionality of available e-health web sites.The major evaluation criteria of this survey was their efficiency in responding to the user's expectations.Our results showed that most health related web sites do not understand which services and target segments generate value.
The IMSA project provides services in the area of diagnosis.This field has been widely studied in the past and the Mycin expert system (Shortliffe, 1976) is probably the most famous application.Our module concentrates only on a non-exhaustive set of clinical signs and is aimed at being used by patients.IMSA provides several health-care services such as: on-line health information, advice on efficient self-treatment and self-prescription, access to drug databases and a diagnosis module.The cornerstone of the IMSA project is the notion of automedication, which can be defined as the act of treating oneself with or without drugs.This act is becoming more and more popular in most industrial countries and patients, pharmaceutical laboratories and medical institutions are becoming very interested.Health-care organisations consider auto-medication dangerous when overdone and a threat to general practitioners' authorities.Auto-medication is still popular and in France, its growth pace is not governed by legal or political considerations.Even if some magazines, television shows and books are devoted to auto-medication, we do not consider that enough effort is being directed toward this fundamental health-care issue.IMSA aims to provide valuable and trustworthy auto-medication information over the Web.This paper focuses on the implementation of the diagnosis module of IMSA and its fields of activity, which are: cognitive science, knowledge-based systems and human-computer interaction.We will also present an evaluation methodology and its results.

COGNITIVE WORK
The IMSA project belongs to the highly collaborative field of medical informatics.Most of the conceptualisation and implementation is cognition driven and encompasses computer science expertise as well as medical and pharmacological knowledge (Figure 1).The collaborative teams of this project were: • members of the ISIS laboratory in Marne-la-Vallée (France) who specialise in the study and design of information systems and web technologies, • members of the pharmacology department at the Cochin hospital in Paris (France) who are pharmacologists as well as former general practitioners.
Professor J.P. Giroud, chief of the Cochin pharmacology laboratory, is also a renowned author of many automedication books.His latest book (Giroud & Hagège, 1997), written with Dr C. Hagège, has been highly acclaimed by medical organisations and is a French best seller in the field of medicine for the general public.
This book was the cornerstone of our cognitive work because its quality has been validated by health-care professionals and it was intended for the general public.With seven previous editions and more than fifteen years of experience, this guide has reached a maturity that makes it an invaluable source of knowledge in the area of auto-medication.
The book is divided into two parts.The first part deals with symptoms related to auto-medication.These symptoms are listed in alphabetic order and general information is provided, possible outward signs are presented and causes are introduced.This part of the book also explains how to treat the symptom and describes the therapeutic classes related to all the forms of the symptom.Finally a list of OTC (over-the-counter) drugs rated by the authors, is provided.The second part of the book lists all the drugs in alphabetic order, available on the French market (OTC, non-OTC, homeopathic, phytotherapic, etc.).Drugs are described accurately with contra-indications, side-effects, suitable dosages, therapeutic class, etc.It's important to stress that all drugs are rated, based on their active principles and a tolerance/efficiency ratio.
The experience of the authors provides a structural and lexical aspect to this guide.The two-part structure allows the book to be read easily by all kinds of readers -physicians and patients.There are two ways of reading the book: from symptom to a drug or from a drug to a symptom.The first reading pattern promotes hypertextuality.Obviously, hypertext is better suited to a World Wide Web media.
The lexical aspect enables all parts of this book easily to be understood by the general public.All specific medical terms have been translated into simple yet accurate general terms.
The main cognitive work focused on linking a symptom to its therapeutic class(es), leading to a drug recommendation.In order to achieve valuable results, we subdivided the cognitive tasks into different phases (Figure 2): • Stage 1 defines a list of mild clinical signs.This list was constructed from the book with the aid of the physicians' knowledge and ethical considerations.This list's development process involves physicians scanning the auto-medication guide.Their goal is to define a list of symptoms related to auto-medication.• Stage 2 defines a taxonomy of specific forms for the stage 1 symptoms list.For instance, cough was the first symptom studied and its forms are dry or productive.The physicians helped us to determine which forms need the assistance of a doctor and which could be cured with OTC drugs.At this stage the physicians work with the guide and the resultant list from Stage 1.They search for forms of the symptoms that can be automedicated.• Stage 3 emphasises the drugs and their relations to the symptom forms.This stage of development required us to build a relational drug database (RDB).We created this RDB out of the electronic version of the guide.
We "data mined" the drugs from the therapeutic class for a given symptom form to extract valuable

IMSA
Cognitive science information.The major sources of information were the active principles found in the composition of a drug and its contra-indications.
Apart from describing the cognitive stages of the IMSA project, Figure 2 also emphasises the organisation and collaboration between both teams.All teams were more or less involved in each cognitive stage, whether actively or passively.Active teams were involved in the process of providing the results, while passive teams drew upon their experience to check the results.
The cognitive stage was the most demanding in terms of time.A collaboration framework was designed to provide effective results.The two laboratories are geographically distributed and the framework relies on internet technologies (intranet, internet, email, etc.) and meetings (Curé & Levacher & Giroud, 2001a).
Another source of cognitive tasks was the conceptualisation of an auto-medication ontology.The term ontology has several meanings depending on whether it's used in the field of philosophy or artificial intelligence (Guarino, 1998).We consider the concept of an ontology in the context of knowledge sharing.In this field, an ontology refers to the "specification of a conceptualisation" (Gruber,1993).Our auto-medication ontology is a description of the concepts and relations between drugs and mild clinical signs.The concepts describe symptoms and forms of symptoms as well as active principles of drugs and their therapeutic classes.The relations link together drug and symptom concepts and provide efficient support for the diagnosis module.This ontology was designed from the results of Stage 3.
The formalisation of this ontology was not a major concern during the development of IMSA.The concepts and relations are stored in the databases and application modules of the IMSA system and this approach does not allow an effective reuse of ontologies.

KNOWLEDGE REPRESENTATION
The cognitive work helped us to extract valuable information from the physicians' expertise, the auto-medication guide and our pharmaceutical and medical databases.The next step in designing the information system architecture is to take into account this data and the implementation requirements.
The constraints for IMSA were media support, human-computer interaction and maintenance.The media support needs to be free and accessible to a large public.Navigating the system must be intuitive and interactive.We needed the ability to update the databases effectively in a simple and fast way.The updated data must be available as soon as possible for the general public.
Given all these requirements a World Wide Web interface implementation was obvious.Other solutions were considered included CD-ROM, and the French minitel but they could not overcome the constraints.
On the application issue, we had a choice between an expert system's approach or a knowledge-based relational database system.
An expert system is effectively implemented in a logical or symbolic programming language such as Prolog (Van Caneghem,1986) or Lisp (Allen, 1978).These languages are accessible to a web application through Common Gateway Interface (CGI).The main drawback of the classic expert system's approach lies in the data storage and maintenance (Buchanan & Shortliffe, 1984).
We opted to store all the data in a Relational Database Management System (RDBMS) because it provides powerful updating facilities with the Structure Query Language (SQL) and is easy to interface with a web site.
A knowledge-based system is usually described by rules, facts and inference engine components.In IMSA, the inference engine is split into the diagnosis module's web pages.The rules are stored in the database tables and the facts are passed as session variables from page to page.
This approach provides several benefits: • good maintenance facilities through the use of a RDBMS, • ease of implementation and the ability to reuse the knowledge-based system's architecture because the inference engine is divided into distinctive and autonomous pieces, • fluid interaction for the end-user, which is very important for a knowledge-based system aimed at the general public, • effective separation between application, data storage and presentation files.The application code is hosted on the Web server separately from the HTML pages.The presentation is linked to the HTML pages via the use of external cascade style sheet (CSS) files.• Security.The three-tier architecture, with a Web, database and middleware servers, makes the overall framework of the system secure and reliable.
The knowledge representation of the cognitive results is designed with three types of questions.Each class of question forms a stage of the diagnosis: • Questions that detect whether the end-user's symptoms are mild or not.If any harm is possible, we invite the user to consult a doctor.This class is called Imperative.• Questions that help the system to detect which form of the symptom the patient is suffering from.This class is called Diagnostic.• Questions that provide a list of drugs that are supposed to help the patient toward better health.These questions are bound to the drugs' contra-indications and are named Treatment.
Each class lists a number of questions for a given symptom.These questions represent the rules of our knowledge-based system.All questions require binary (true or false) replies.The architecture for a given form of symptom can be represented by a binary decision tree (Figure 3).
Let's consider an example of the decision tree that will lead the user from the cough symptom to drugs from the "anti-coughing" therapeutic class.
• Choose the upper body in the anatomical section.

•
Choose "cough" among the upper body symptoms.

•
Display general information and the probable causes of coughs.
• Reply to the Imperative class questions.Among the seven questions on coughs, you have to answer "Are you suffering from a chronic respiratory disease?" or "Are you over 50 years old and coughing after a minor physical activity?"• The user then clicks on "Go on" button because none of the questions applied to his case.
• Reply to the Diagnostic class questions: "Your cough is dry or productive?" • The user clicks on "dry cough".
• A second diagnostic question is then asked: "Have you recently suffered from a minor infection?"• The user selects "Yes".
• The system then displays information on dry coughs that persist after an infection and asks Treatment class questions on contra-indications.
• The user then clicks on the "Go on" button because he doesn't match the contra-indications.
• The system displays a list of drugs (23 drugs products) rated from 10 to 18 out of 20.All these drugs belong to the "anti-coughing" therapeutic class.• The user clicks on the product Akindex, an adult syrup.
• A new screen displays all information on this product: name of the product, name of the pharmaceutical laboratory, presentation, price, rate, social security reimbursement, a complete list of contra-indications, side-effects, composition, dosage and information on when and how to use this product, and when to stop.

HUMAN-COMPUTER INTERACTION
The design of human-computer interactions is often cognition related (Winograd & Flores, 1987).This fact is even more preponderant in multi-disciplinary fields where the end-user faces several fields and technologies.
Providing knowledge-based and expert systems to the general public is an innovative approach.For quite a long time, these systems were designed and used by experts who would work with the cognitive science and development teams.Developers usually assumed that the experts knew enough about the system and did not pay much attention to the user interface.Studies of these systems highlighted low usability and poor interaction.As soon as the system is aimed at the general public, human-computer interaction becomes a major concern.In this context, the development of IMSA requires more attention and collaboration between all the teams.The physician and computer science teams were very involved in the design of the user interface.The first step in this collaborative work was to analyse the results from our study of web sites and CD-ROMs.We found that the majority of these systems did not provide efficient navigation.Although most of them were physician-oriented they still offered valuable information about what dialogue mode worked.
The paradigms available are: thesaurus or natural language processing.In a technical domain like medicine, the analysis of natural language can be profitable to the expert but is not useful to the patient without a medical background.Our interface uses a thesaurus based on our auto-medication ontology.
Navigating any user interface should not be a challenge and no previous training should be necessary, this feature is called learnability.Using a thesaurus, the end-user only deals with lists of choices and interacts with mouse clicks.This is the fastest way to navigate in any system and does not require the user to search for words to describe his symptoms.
Interaction, user-friendliness and usability are key words in the implementation of user interfaces.Over the last few years, usability has emerged as a major issue for the success of any web site (Nielsen, 1993).Usability addresses the relationship between tools and their users in order to accomplish tasks in the best possible way.
From the developer's perspective, usability is important and it can mean the difference between the success or failure of a system.In the IMSA environment, usability is even more important because the system is to be used by the general public.We know that end-users do not browse health related web sites for pleasure but out of necessity.Therefore, they are searching for efficiency and quick access to the right information.
Some of the major issues in most usability inspections (Nielsen & Mack, 1994) are download times and the number of clicks needed to reach the user's goal.IMSA responds to these requirements by: • a minimal use of multimedia and images, which cause poor download times.For instance, the selection of the symptom uses an image of the human anatomy.The user either clicks on the upper, middle or lower body part.• setting a maximum of eight to ten clicks to reach a final reply or a drug recommendation from the start of diagnosis.
We also focused on designing consistent navigation support and graphic elements as well as taking special care in rewriting the information on the site to respond to the way people read on the web.

Methodology
The IMSA evaluation methodology is cognitively-based and requires medical and computer science expertise (Curé, Levacher & Giroud, 2001b).Both teams involved in this project worked on the theoretical and pragmatic aspects of the evaluation.Their main tasks were to consider who would run the tests and how they would be run.
We designed user profiles given the requirements of both teams.We ended up with two variables which were openness to auto-medication and experience of the Web.We created the four profile groups using the assumption that an experienced Internet user is someone with at least 6-months experience of the World Web Wide and an average of at least 3 hours of browsing a week.A user open to auto-medication is someone who prescribes medication for himself, doesn't consult a general physician when he or she does not feel that it's necessary and is involved in seeking information on drugs and medicine.
The scenarios were medical case descriptions.Their purpose was to give a well-defined framework for the tests.
The test protocol was the same for all groups: testers were handed a set of scenarios and they were asked to play the patient's role using this medical case description.The collaborative work once again provided valuable requirements: computer scientists wanted to design navigation-driven medical case descriptions while the medical experts were motivated to write diagnostic issue-driven scenarios.Both teams collaborated to design scenarios that would fit all requirements considering the major constraint of time.Our previous experience of usability testing emphasised that the whole test process should not exceed 25 to 30 minutes.Past this time, a computer novice tends to lose focus, get tired or bored.In such conditions, the results become insignificant and unreliable.
Taking account of this time constraint, we defined six scenarios that led to specific treatment recommendations: recommending a single drug, recommending a list of possible drugs, recommending that the patient does not need drugs and is only given tips, recommending that the patient is not given any drugs because he or she presents contra-indications and asking the patient to consult a physician because his symptoms are too serious (two scenarios for this issue).
All six scenarios could have been related to different clinical signs but we decided to have just one symptom.We choose coughing because many forms exist (productive cough, non productive cough) which leads to different treatments.The heterogeneous rating (from 2 to 18 out of 20) of drugs related to coughs helped us to take this decision.
A cognitive approach to writing the scenarios predominated and we were careful with the semantics.All the scenarios needed to be easily understood by patients, so that the help of an evaluator would not be needed.In fact, we used this constraint to make sure our drug-symptom ontology was efficient and responded to the general public's expectations.
Here is one of the scenarios that recommends that the user consults a physician because the symptom is too serious: You are 55 years old and you put on some weight 10 to 15 years ago but never suffered any cardiovascular incidents.You have a tennis background and even though you don't practice anymore you are surprised that you cough when you climb stairs or perform moderate physical efforts.

Results
The results of this study were obtained from an analysis of the formal and informal data.

Analysis of formal data
The formal data was taken from the evaluators' form results.This study highlighted that the main factor in this study is Internet experience.Our analysis did not demonstrate any navigational differences regarding openness to auto-medication.
An analysis of the 20 experimenters' forms indicated that all scenarios ran successfully.The fact that both experienced and novice Internet users successfully navigated the scenarios proved the adaptability of the web pages architecture.Logically, experienced Internet users were faster than novice Internet users.But the difference in web navigation was not consistent throughout the scenarios (Figure 4).
These results demonstrated the relevance of a framework built around a mild clinical sign ontology, a thesaurusbased dialogue mode and the parsimonious use of multimedia and animation.

Analysis of informal data
The study of the comments on the evaluation forms and questionnaires showed interesting results.We detail the results question by question below.
Question 1: Do you find navigating from symptom to drug clear enough?According to the success on all scenarios, the reply is yes from all 20 testers.
Question 2, 3 and 4: Do you understand the meaning of the "imperative", "diagnostic" and "treatment" questions?
Most users understood the concept behind these questions.Some users complained about the term "imperative" which they thought was not explicit enough.
Question 5: How would you describe the number of questions asked: too many, sufficient, not sufficient, no opinion?All testers were surprised at the low number of questions asked and except for two; all the replies were "sufficient".
Question 6: How did you feel about being forced to exit the symptom screen?Users wanted more explanations about the forced exit.Telling them to consult a general physician was not enough and they wanted more information.The testers open to auto-medication were more insistent on this aspect.
Question 7: How did you feel about the way you interacted with the system: interactive enough, too rigid, too flexible?All the testers were surprised at how quickly they could get a list of drugs and all agreed that the dialog form was interactive enough.Only 2 out of the 20 testers found the interaction mode too rigid and they were both experienced Internet users.
During a post-test meeting, an Internet user proposed the use of a natural language interface instead of the use of a thesaurus.The other Internet users immediately argued about how inefficient some of these systems can be.
Question 8: Do you have enough information to choose a medication from a list of drugs?Most testers told us that the categorisation and rating were sufficient to choose a drug.We designed three categories: our selection, a complementary list and a not-recommended list.Our selection of drugs included all the drugs that belonged to the 16 to 20 rating interval.The complementary list encompasses the drugs in the 10 to 15 rating.All the other drugs are in the not-recommended list.
Half the testers complained about the fact that one of the scenarios only recommended drugs from the notrecommended category.We had to explain that for this symptom no OTC drugs were suitable.
Question 9: Do you think that IMSA proposes interesting services?All the testers replied yes.
Question 10: If such a system was available on the World Wide Web, would you use it?Would you trust it?Surprisingly, not all replies were affirmative.Twenty five percent of the users, who happened to be satisfied with the product, were not ready to use such systems.All of them belonged in the group that was not open to automedication (2 were experienced Internet users and 3 were Internet novices).We believe that the quality of the system or the media were not in question.The issue refers more to the cultural background of the user.

CONCLUSION
The implementation and evaluation of the IMSA project emphasised some valuable points in the field of patient oriented medical-information systems.
The first interesting point is in the importance of a framework of cognitive science, knowledge-based systems and human-computer interaction.As a multi-disciplinary field, medical informatics is a privileged domain for cognition and knowledge representation, the goal being to extract complex data from one or several domains linked to medicine and to represent them on a computerised system.
Because the application is aimed at the general public, the quality of the human-computer interaction is important.This requires a usable and user-friendly interface.We opted for a thesaurus dialogue mode where the end-user selects his reply from a list.This minimises misunderstandings between the system and the patient.The amount of work involved in this solution is comparable to a natural language processor because the terms and relations within the lexical field must be studied.This stage is equivalent to the design stage of an ontology.
The IMSA framework refers to auto-medication, medicine and pharmacology.We would like to emphasise that this implementation environment considerably simplified the development of the diagnosis module because: • you have to manage a subset of symptoms.
• for ethical reasons, the diagnosis replies are not detailed and only advised consulting a general practitioner.
The design of a structured collaborative framework is a major issue in multi-disciplinary projects.The first step is to define a feasible and valuable project and then to find competent and motivated teams in each field of study.
Within IMSA, we were fortunate to have all the expertise concentrated within two teams.We feel that the fewer teams there are, the easier it is to maintain a high level of motivation and efficiency.We designed a collaborative protocol that used internet and intranet technologies as well as meetings.
Another concern in the implementation of a medical data processing project are the ethical considerations.Some members of the pharmacology laboratory in the Cochin hospital are active in medical organisations and were very concerned with the deontological aspects of their field.
The ultimate goal of IMSA work is to prove the feasibility of a system that provides health-care information and diagnosis to patients.Many tests with a broad range of end-users (health-care professionals, computer scientists, Internet neophytes) concerned about auto-medication confirmed that such a tool is of interest.The results of our evaluation emphasised that such systems can be implemented using well-known and robust technologies.
Among the possibilities envisioned during our tests is the development of a tool designed for medical students and young general practitioners.We conducted tests with medical students and were quite surprised at their reactions.They played the scenarios like a guessing game and were really interested in the drug recommendation module.We know from our pharmacology team that medical students do not attend enough classes about drug prescription.An adapted IMSA tool could help students through this process.We are also working on a formalisation of our auto-medication ontology, providing support for reusability and knowledge sharing between general public health-care systems.

Figure 2 .
Figure 2. Cognitive tasks related to the diagnosis module.

Figure 3 .
Figure 3. Diagnostic module architecture Different combinations were created by mixing the variables, with interesting results.All our tests were done with four different patient profiles: internet novices open to auto-medication; internet novices not open to auto-medication; experienced internet users open to automedication; experienced internet users not open to auto-medication.

Figure 4 :
Figure 4 : Time difference between experienced and novice Internet users