Abstract
Decision support systems in the medical field have to be easily modified by medical experts themselves. The authors have designed a knowledge acquisition tool to facilitate the creation and maintenance of a knowledge base by the domain expert and its sharing and reuse by other institutions. The Unified Medical Language System (UMLS) contains the domain entities and constitutes the relations repository from which the expert builds, through a specific browser, the explicit domain ontology. The expert is then guided in creating the knowledge base according to the pre-established domain ontology and condition–action rule templates that are well adapted to several clinical decision-making processes. Corresponding medical logic modules are eventually generated. The application of this knowledge acquisition tool to the construction of a decision support system in blood transfusion demonstrates the value of such a pragmatic methodology for the design of rule-based clinical systems that rely on the highly progressive knowledge embedded in hospital information systems.
Clinical decision support systems (CDSSs) have been shown to be very helpful to medical practitioners. Knowledge acquisition and modeling play leading roles in the development of such knowledge-based systems. Unfortunately, two key factors limit the development of CDSSs and their integration into hospital information systems—the time and effort required by medical experts to create and maintain knowledge bases, and the extreme difficulty of sharing and reusing the validated knowledge bases because of their idiosyncrasies and lack of clarity for users outside the originating institution.
The latter factor is considered the main obstacle to daily use of CDSSs.1 The goal of our work is the design of a knowledge acquisition tool to facilitate the creation and maintenance of a knowledge base by the medical expert, and its subsequent sharing and reuse by other medical institutions. Reuse may be approached from several directions; in particular:
Through generic abstractions. Lexicons, ontologies, and problem-solving methods are developed and then adapted to fit the specific needs of a typical medical domain application.2–5
Through the standardization of the knowledge representation. Several standards have been proposed, such as KIF,6 Ontolingua,7 and Arden Syntax.8
Through specific models, such as GLIF9 or PROforma,10 to represent certain kinds of clinical guidelines and support their dissemination.
Our project relies on the first two approaches.
Some knowledge acquisition environments have been proposed, taking into consideration the specifics of the medical reasoning process and medical expertise. The research project GAMES11 views the knowledge acquisition process as the construction of two models—the epistemological model, entailing the knowledge required to perform a particular task, and the computational model, containing data structures and algorithms designed to allow the computerized execution of that task. The PROTÉGÉ12 environment allows developers to configure available problem-solving methods that are mapped to domain ontologies and generates task-specific knowledge acquisition tools.
In parallel to research into architectures for knowledge acquisition, considerable work is under way to create medical ontologies, a key component in building and reusing knowledge-based systems. For instance, the representation and integration language GRAIL, from the GALEN project, is specially designed to support models of medical terminology and achieve reuse of taxonomies.4,13
The Unified Medical Language System (UMLS) constitutes a knowledge corpus that is useful for building knowledge bases. Our approach, less general than that of PROTÉGÉ, is designed for medical experts without specific training in medical informatics. It allows them to configure rule-based templates that are mapped to the UMLS-based domain-specific lexicon that they have previously constructed. Medical logic modules (MLMs) written in Arden Syntax are eventually generated to facilitate reuse and sharing of this knowledge base.
Medical logic modules have been used to generate clinical alerts, interpretations, and diagnoses.14–18 For several years, numerous attempts have been made to facilitate the creation of MLMs with respect to the Arden Syntax. Interesting clinical experiences with MLM editors have been reported.19–21
Our project differs from previous work in that it integrates the generation of MLMs into the general process of knowledge acquisition (ontology and knowledge base). In this article we report on our knowledge acquisition methodology; the use of this methodology to build a CDSS applied to blood transfusion; and a preliminary test of our system.
In blood transfusion, the evolution of both medical knowledge and government regulations imposes a continuous adaptation of the CDSS that wholly justifies the use of our approach. Several CDSS have been proposed in this field.22,23 Like all classical rule-based systems, these systems were difficult to maintain and extend. No specific knowledge acquisition technique was used for their development. One application embedded in the HELP system concerns a computerized monitor blood ordering system based on a critiquing approach.24–26 A set of knowledge tools is proposed to the expert for the definition and the maintenance of the knowledge base, and a local data dictionary can be used. All these CDSSs in blood transfusion turn essentially on the question of whether to transfuse. In addition to this issue, we studied the choice of the qualifier (e.g., phenotyped or irradiated) of the product to be transfused. Our CDSS is currently being tested at the Henri Mondor Hospital in Créteil, France.
Methodology
Our methodology for knowledge acquisition and representation relies on two steps. First, a domain ontology is developed— the expert selects the entities and relations present in UMLS that are relevant to constructing the domain ontology, and introduces new terms and relations if they are needed. Second, the domain knowledge is constructed—according to the pre-established domain ontology, the expert is guided in creating the knowledge base via condition– action rule templates. Corresponding MLMs are eventually generated automatically. Figure 1▶ represents our methodology.
Figure 1 .

Knowledge acquisition process and decision support system design. Top left, The domain ontology is built via the UMLS browser. Top right, The knowledge acquisition interface allows the instantiation of a general problem-solving method using the domain ontology. Medical logic modules (MLMs) are automatically created and organized by the knowledge manager. Bottom, Example of a clinical decision support system (CDSS) architecture in which the knowledge base is generated using our methodology. The arrival of new data (1) triggers the event procedure (2). The relevant medical logic modules (MLMs) (3), which represent the knowledge base, are then executed by the inference engine (4). A results table containing a summary of the diagnosis and the order for blood products is provided (5). Initial data are sent automatically by the hospital information network or are entered manually by a physician.
Construction of the Domain Ontology Using UMLS
To facilitate sharing and reuse, we have chosen UMLS, elaborated to facilitate the integration of information from multiple biomedical sources, to constitute the repository of entities and relations from which the expert builds the domain ontology. Three components constitute the UMLS. The Metathesaurus contains a collection of biomedical concepts and their inter-relations. The Semantic Network, through its high-level semantic types, provides a consistent categorization of all concepts represented in the Metathesaurus. The Specialist Lexicon is an English-language lexicon with biomedical terms. The lexicon entries for each word or term record syntactic, morphologic, and orthographic information. The UMLS provides a shared source of terminology widely used in clinical applications.27–30 To navigate between concepts through the concept hierarchy and through the semantic network, we have designed a specific navigator.31
The UMLS Navigator
The conceptual model of our navigator (Figure 2▶) is based on two components of the UMLS—the Metathesaurus and the Semantic Network. We have adopted an object-oriented representation. Concept is the main class of our Metathesaurus model. It includes several attributes (for example, ConceptDefinition, ConceptLinks). It reflects properties present in UMLS; each concept has a unique identifier. Different terms with the same meaning are linked to the same concept identifier. We have reified the link (LinkConceptTo Variants) between a concept and these terms (preferred term, synonyms, etc). The relation (Concept Link) between two concepts has three parameters represented as classes: a ConceptRelation (e.g., parent, child, general, specific), a ConceptRelationAttribut (e.g., isa, inverse_isa), and an InformationSource (e.g., Mesh98) that provides it. Our representation of the UMLS Semantic Network is then a reified graph whose edges are the semantic relations (Semantic Links) such as affected_by and occurs_in, and whose vertices are the semantic types (SemanticType) or semantic relations (SemanticRelation).
Figure 2 .

Conceptual model of UMLS including Metathesaurus and Semantic Network (object modeling technique diagram37). The lines indicate relations between classes.
Domain Ontology Construction
The construction of the domain ontology requires four steps. First, the expert identifies the medical terms used in the specific domain. Using our specific browser (Figure 3▶), the expert looks in the UMLS Metathesaurus for the corresponding concepts, selects relevant concepts, and adds them to create a list. To facilitate comprehension and enrich the list, the expert then identifies for each concept its ascending hierarchy (i.e., its parents). Depending on the source vocabulary in the Metathesaurus, a concept can be found at several levels in a specific ascending hierarchy. Figure 4▶ shows the different possible ascending hierarchies for the term hemolytic autoimmune anemia. The expert selects the hierarchy that corresponds to the semantic meaning that he or she associates with a specific concept, or constructs a hierarchy by choosing the concepts from the different sources. Because strong standardization is not always possible in medicine, a medical expert may insert new terms or extend the initial hierarchy corpus to take into account particular considerations.32 For term insertion, two constraints must be respected—the new concept must be linked to a semantic type from the UMLS Semantic Network and must have a parent. If a specific classification is constructed, it is saved in the UMLS format (MRCXT table) with a specific tag (PERSO) in the raw source (SAB).
Figure 3 .

Graphics user interface of our UMLS Navigator, showing the exploration of the Metathesaurus for the anemia concept.
Figure 4 .

Selection of the relevant hierarchy from different sources. A specific pop-up menu (not shown here) allows for the construction of our personal hierarchy (namely, PERSO).
All the concepts extracted from the UMLS or created by the expert have a local identifier and are stored in a local table. This local table allows the link with the clinical database of the hospital. When introducing new terms and classification, the expert has the responsibility for checking their adequacy and their consistency with the set of information contained in PERSO. The expert also assigns the semantic types from the Semantic Network for any new concept added. As semantic types are general, an intermediate layer, named categories, has been added to introduce more specific types. The categories correspond to the concepts located at the top of the hierarchy of the contextual list selected from those present in the Metathesaurus or created by the expert. For instance, Anemia Sickle Cell is initially linked to the Diseases or Syndrome semantic type. We have introduced the category Hematologic Diseases as a subclass of Disease or Syndrome semantic type, to which Anemia Sickle Cell is linked (Figure 5▶).
Figure 5 .

An excerpt from our domain ontology based on the UMLS: A, semantic types; B, categories; C, terms used in the medical expertise. Rectangles with white backgrounds indicate entities used in Rule 2, as described in the text.
In the fourth and final step, following the classification of the terms according to an ascending hierarchy, all possible relations among these terms are automatically determined. For this purpose, a query is performed on the UMLS Semantic Network, to extract relationships between semantic types and concepts useful for representing the expert's knowledge. Then, the expert selects the relevant relationships between concepts present in the Metathesaurus. Once again, the expert may add new relationships to this contextual list (identified by the label PERSO).
During the ontology design, a local identifier is automatically created for each acquired concept. This identifier is stored in the slot data of the MLM during the knowledge acquisition process. A local table is then designed to link and translate these local identifiers to the clinical database identifiers.
From the development of the domain ontology, three different structures are obtained—the hierarchy of terms and concepts used in the domain, which have an ascending hierarchic context, connected by the relation “inverse_isa”; the concepts located at the top of the hierarchy that have been selected, which will compose the list of categories that subsume the medical terms used; and the UMLS Semantic Network excerpt covering the concepts selected for the domain, such that each term has a semantic type and a category.
For the collection of terms present (n=120), in the blood transfusion domain, the medical expert found corresponding UMLS Metathesarus concepts for 88 (73 percent). The blood transfusion domain used highly specialized terms, such as “transfusion of red blood cell plasma depleted,” “transfusion of red blood cells phenotyped,” and “patient erythrocyte alloimmunized,“ which were not present in the version of the Metathesaurus used. The coverage of disease terms qualified by such adjectives as minor, severe, or chronic was uneven.
Domain Knowledge Construction
Starting from the predefined domain ontology, the expert creates the domain knowledge needed by the application. We have modeled the knowledge with production rule templates. Our knowledge acquisition tool guides the user through three steps of rule description: documentation following the Arden Syntax definitions, specification of the condition part of each rule, and specification of the action part of each rule. The entities that compose the conditions and action parts of the rules come from the domain ontology and are linked to the semantic types.
To illustrate the process of rule specification, let us start with the rule template (Figure 6▶)
Figure 6 .

General outline of the ontology. A, The semantic types in relation to categories. B, Categories that subsume the medical terms used (top row), concepts in relation to medical terms according to a hierarchic classification (second row), medical terms used (third row), and some MLMs (bottom row) in which b1, b3, and b7 are present in condition or action parts.
(A1) → (A3)
After selecting A1 for the condition part, the expert can choose between bα and bβ. The selection of bα leads to three possible choices—b1, b2, or b3. The expert chooses the concepts b1 and b3 for the condition part and then chooses A3, bδ, and b7 for the action part, leading to Rule 1:
IF condition (b1) present
AND condition (b3) present
THEN action (b7) activated (Rule 1)
Generation of Medical Logic Modules
An MLM, equivalent to a single rule in a rule-based expert system, contains enough medical knowledge and data to make a single clinical decision.8 Medical logic modules can be independent of one another but also can be linked by CALL statements. An MLM is an ASCII file composed of slots grouped into three categories—Maintenance, Library, and Knowledge. The category parts of the MLM are acquired via the knowledge acquisition tool. Figure 7▶ shows the interface for the construction of Rule 2.
Figure 7 .

Knowledge acquisition interface. Three list boxes allow the selection of the corresponding entities that appear in condition or action parts of the rule. The rule under construction is shown at the bottom of the figure.
To facilitate maintenance and avoid redundancy or
IF (Sickle Cell Anemia)
AND (Multiple Organ Failure)
AND (Hemoglobin<10) (Rule 2)
THEN (Erythrocyte Transfusion)
inconsistency, MLMs are organized depending on the concepts they manipulate. The name of the MLM is stored in the slot filename of the category Maintenance, and the concepts used in this MLM (e.g., b1, b3, and b7 for Rule 1) are stored in the slot keywords of the category Library. The concepts appearing in the condition part are linked to the corresponding MLMs by the relation “has as rule” to facilitate the retrieval of specific MLMs. The goal of each MLM, represented by its action, is stored in the slot purpose of the category Library. The concepts appearing in the action part are linked to the corresponding MLMs by the relation “the action of. This allows the expert to retrieve easily all MLMs that trigger a specific action. Finally, this knowledge is formalized according to the Arden Syntax with MLMs linked to the domain ontology.
One hundred ten rules (translated in MLMs) make up the knowledge base. The indexing and the referencing of the terms that compose each MLM are used to identify possible redundancies and inconsistencies during the creation of a new MLM. In the current prototype, the checking for redundancy and inconsistency is performed manually. Inheritance property is not used during MLM construction.
Experience with a Clinical Decision Support System for Blood Transfusion
The transfusion of blood products is an inescapable therapy for certain pathologies but has the potential to induce undesirable immunologic and infectious effects, like HIV or hepatitis. The best guarantee of a patient's safety is strict adherence to transfusion guidelines. In addition, the transfusion of blood products is an expensive therapy that, in terms of public health, must be prescribed advisedly. A CDSS that assists in the prescription of blood products seems to be an appropriate tool for enhancing patient safety and reducing heath care costs. However, because of continual expansion of medical knowledge about blood transfusion and changes in government regulations, decision rules for blood transfusion must be frequently updated.
At the Henri Mondor Hospital in Créteil, France, approximately 30,000 blood products are distributed to 5,000 patients each year. This volume justifies the development of a CDSS integrated into the hospital information network to assist clinicians in blood product prescriptions. We constructed a CDSS for blood transfusion using the methodology previously described.
Architecture of the Clinical Decision Support System
Starting from blood data (essentially hemoglobin and platelet concentrations) and the patient's state (disease, current therapy, etc.), the system indicates whether transfusion is required and, if so, which type and quantity of product to transfuse. The system works according to the data-driven and application-driven principles of the MLM controller15,16 that schedules MLM execution. The CDSS is composed of the three modules shown in Figure 1▶: the user interface to retrieve information from the patient database, the knowledge base that contains expertise for blood transfusion in MLMs, and the inference engine that executes the relevant MLMs. Two modes are available—alert (data driven) and consultation (application driven).
Alert
As shown in Figure 1▶, when biological data are automatically sent into the patient database (1), the event procedure is triggered (2). This activates several MLMs (3) executed by the inference engine (4). Actions are performed, and a table of results is generated (5). Depending on the seriousness of the diagnosis, an alarm signal could be set.
Consultation
The physician keys in data about the patient and the prescription, specifying the type and quantity of products to be transfused. Then the system determines whether the transfusion is appropriate and the type, qualifier, and quantity of the product to be transfused. Details of system decisions are displayed to the physician. If the physician disagrees, he or she can order other products and justify the choices in a brief report. A complete report that includes the recommendations of both the system and the physician is sent to the blood bank.
Preliminary Results
A first evaluation was performed to validate the coherence and the correctness of the CDSS. For that, 30 orders were studied, and the reliability of transfusion order was determined (98 percent for platelet and 97 percent for red cell transfusion). A discrepancy about the qualifiers of the transfusion product—such as phenotyped or compatibilized product—was observed between the system and the physicians in 18 of 30 cases (60 percent).
Analysis of these discrepancies revealed a need to add more information about the patient's status and to modify rules in the knowledge base. Twenty new orders were then evaluated using the modified CDSS. Some disagreements persisted between physician's orders and CDSS conclusions (40 percent), but agreement between the CDSS and the experts who reviewed the orders was 100 percent. This result was explained by the fact that physicians did not follow the current transfusion guidelines. A working committee was appointed to modify current practice to adhere to new transfusion guidelines. The prototype is currently being evaluated at the Henri Mondor Hospital.
Discussion
We argue that our approach is a practical way to build CDSSs. It avoids constructing the domain specific ontology from scratch, limits the introduction of idiosyncratic terms and relations, and combines reuse and sharing with domain-specific lexicons familiar to clinicians. In our experiment, the UMLS provides a useful corpus of medical knowledge for designing a domain-specific lexicon. In parallel with efforts to define a specific knowledge representation language for clinical concepts,4 the UMLS provides a pragmatic way to facilitate knowledge sharing and reuse. Many attempts to quantify the content coverage of the UMLS have been made, in several fields—clinical radiology,27 laboratory terminology,28 surgical procedures,30 and in hypertension notes.33 These projects showed limitations of Metathesaurus terms in specific areas, demonstrating the need to add new terms and relations for particular uses of the UMLS. Nevertheless, like other investigators,34 we consider the UMLS a useful formal framework that is readily available to medical institutions and continuously updated by the National Library of Medicine. The introduction of new terms, besides those found in UMLS, reflects the specific needs of experts and respects the philosophy of the UMLS, which concatenates several databases to gather the particularities of each of them.
We have designed a domain-specific interface to allow the domain expert to input directly or modify existing knowledge in a CDSS using domain ontology. Our knowledge acquisition tool uses rule templates, which appear well adapted to the decision-making process in the clinical applications we envisage. Our tool is designed for medical experts without specific training in medical informatics and allows their active participation in the process of CDSS construction. This can facilitate future integration of the CDSS into the hospital system. Domain knowledge is automatically transformed into MLMs in Arden Syntax so that it can be reused and shared by other institutions.
Our knowledge acquisition tool is not only an MLM editor; it allows the acquisition of knowledge through the predefined domain ontology. It is in the same vein of the work of Thurin et al.,35 who proposed a tool for building MLMs from a GALEN-based terminology. Arden Syntax is mature enough to be used successfully in large working projects in clinical institutions. However, it does have drawbacks, such as a style of rule representation that is not necessarily adapted to all clinical applications, low expressiveness of temporal primitives, and possible interactions between MLMs that may pose long-term maintenance problems.
In our system, the introduction of new terms, during domain ontology acquisition, can generate redundancies and conflicts with terms that are already present in the database. During domain knowledge acquisition, some conflicts may appear between rules. In the current implementation, the domain expert receives relatively little help from the system in solving redundancies and conflicts. Temporal aspects of the domain are currently not taken into account. Clearly, our tool should be extended to incorporate specific mechanisms to deal with these drawbacks.
To date, we have used the prototype only in collaboration with two medical experts involved in this project in our hospital. Their involvement since the start of the project clearly biases their fully positive opinion. However, we believe that our tool will be accepted by end users in those medical fields in which decision support systems have to be easily modified by medical experts themselves.
Creating domain ontologies that are reusable in new medical applications is a challenging task.36 Our experiment provides a practical example of how large resources, such as the UMLS, can be used to design a domain ontology and how that ontology can be put to use. Results in the area of blood transfusion demonstrate that the UMLS provides a useful and manageable corpus of medical knowledge for domain ontology construction.
References
- 1.Musen MA. Dimensions of knowledge sharing and reuse. Comput Biomed Res. 1992;25:435–67. [DOI] [PubMed] [Google Scholar]
- 2.Chandrasekaran B. Generic tasks in knowledge-based reasoning: high-level building blocks for expert system design. IEEE Expert. 1986;1:23–30. [Google Scholar]
- 3.Steels L. Components of expertise. AI Mag. 1990;11:28–49. [Google Scholar]
- 4.Rector AL, Bechhofer S, Goble CA, Horrocks I, Nowlan WA, Solomon WD. The GRAIL concept modelling language for medical terminology. Artif Intell Med. 1997;9:139–71. [DOI] [PubMed] [Google Scholar]
- 5.Shahar Y. A framework for knowledge-based temporal abstraction. Artif Intell Med. 1997; 90:79–133. [DOI] [PubMed] [Google Scholar]
- 6.Genesereth MR, Fikes RE. Knowledge Interchange Format, Version 3.0 Stanford, Calif.: Stanford University, 1992.
- 7.Farquhar A, Fikes R, Rice J. The Ontolingua server: a tool for collaborative ontology construction. Proceedings of the 10th Knowledge Acquisition Workshop; Nov 9–14, 1996; Banff, Alberta, Canada; pp 1–19.
- 8.Hripcsak G, Ludemann P, Pryor TA, Wigertz O, Clayton PD. Rationale for the Arden Syntax. Comput Biomed Res. 1994;27:291–324. [DOI] [PubMed] [Google Scholar]
- 9.Ohno-Machado L, Gennari JH, Murphy SN, et al. The guideline interchange format: a model for representing guidelines. J Am Med Inform Assoc. 1998;5:357–72. [DOI] [PMC free article] [PubMed] [Google Scholar]
- 10.Fox J, Johns N, Rahmanzadeh A. Disseminating medical knowledge: the PROforma approach. Artif Intell Med. 1998;14: 157–81. [DOI] [PubMed] [Google Scholar]
- 11.van Heijst G, Lanzola G, Schreiber T, Stefanelli M. Foundations for a methodology for medical KBS development. Knowledge Acquisition. 1994;6:395–433. [Google Scholar]
- 12.Musen MA. Domain ontologies in software engineering: use of Protégé with the EON architecture. Methods Inf Med. 1998;37:540–50. [PubMed] [Google Scholar]
- 13.Rector AL, Nowlan WA. The GALEN project. Comput Methods Programs Biomed. 1994;45:75–8. [DOI] [PubMed] [Google Scholar]
- 14.Hripcsak G, Clayton PD, Pryor TA, Haug P, Wigertz OB, Van der lei J. The Arden Syntax for medical logic modules. Proc 14th Annu Symp Comput Appl Med Care. 1990:200–4.
- 15.Hripcsak G, Clayton PD, Jenders RA, Cimino JJ, Jhonson SB. Design of a clinical event monitor. Comput Biomed Res. 1996;29:194–221. [DOI] [PubMed] [Google Scholar]
- 16.Gao X, Johansson B, Shahsavar N, Arkad K, Ahlfeldt H, Wigertz O. Pre-compiling medical logic modules into C++ in building medical decision support systems. Comput Methods Programs Biomed. 1993;41:107–19. [DOI] [PubMed] [Google Scholar]
- 17.Pryor TA. The use of medical logic modules at LDS hospital. Comput Biol Med. 1994;24:391–5. [DOI] [PubMed] [Google Scholar]
- 18.Jenders RA, Hripcsak G, Sideli RV, et al. Medical decision support: experience with implementing the Arden Syntax at the Columbia-Presbyterian Medical Center. Proc 19th Annu Symp Comput Appl Med Care. 1995:169–73. [PMC free article] [PubMed]
- 19.Gao X, Shahsavar N, Arkad K, Ahlfeldt H, Hripcsak G, Wigertz O. Design and fuctions of medical knowledge editors for the Arden Syntax. Medinfo. 1992:472–7.
- 20.Jenders RA, Dasgupta B. Assessment of a knowledge acquisition tool for writing medical logic modules in the Arden Syntax. Proc AMIA Annu Fall Symp. 1996:567–71. [PMC free article] [PubMed]
- 21.Sailors RM. MLM Builder: an integrated suite for development and maintenance of Arden Syntax medical logic modules. Proc AMIA Annu Fall Symp. 1997:996.
- 22.Spackman KA, Beck JR. A knowledge-based system for transfusion advice. Am J Clin Pathol. 1990;94:S25–9. [PubMed] [Google Scholar]
- 23.Marconi M, Almini D, Pizzi MN, et al. Quality assurance of clinical transfusion practice by implementation of the privilege of blood prescription and computerized prospective audit of blood requests. Transfus Med. 1996;6:11–9. [DOI] [PubMed] [Google Scholar]
- 24.Gardner RM, Golubjatnikov OK, Laub RM, Jacobson JT, Evans RS. Computer-critiqued blood ordering using the HELP system. Comput Biomed Res. 1990;23:514–28. [DOI] [PubMed] [Google Scholar]
- 25.Lepage E, Traineau R, Marchetti P, Benbunan M, Gardner RM. Development of a computerized knowledge based system integrated to a medical workstation: application to blood transfusion. Medinfo. 1992:585–90.
- 26.Lepage E, Gardner RM, Laub RM, Golubjatnikov OK. Improving blood transfusion practice: role of a computerized hospital information system. Transfusion. 1992;32:253–9. [DOI] [PubMed] [Google Scholar]
- 27.Friedman C. The UMLS coverage of clinical radiology. Proc 16th Annu Symp Comput Appl Med Care. 1992:309–13. [PMC free article] [PubMed]
- 28.Cimino JJ. Representation of clinical laboratory terminology in the Unified Medical Language System. Proc 15th Annu Symp Comput Appl Med Care. 1991:199–203. [PMC free article] [PubMed]
- 29.Campbell KE, Oliver DE, Spackman KA, Shortliffe EH. Representing Thoughts Words, and Things in the UMLS. J Am Med Inform Assoc. 1998;5:421–31. [DOI] [PMC free article] [PubMed] [Google Scholar]
- 30.Burgun A, Bodenreider O, Denier P, et al. Knowledge acquisition from the UMLS sources: application to the description of surgical procedures. Medinfo. 1995;8(pt 1):75–9. [PubMed] [Google Scholar]
- 31.Achour SL, Dojat M, Brethon J-M, Blain G, Lepage E. The use of the UMLS Knowledge Sources for the design of a domain- specific ontology: a practical experience in blood transfusion. Proceedings of the Joint European Conference on Artificial Intelligence in Medicine and Medical Decision Making; Aalborg, Denmark; Jun 20–24, 1999:249–53.
- 32.Dojat M, Pachet F. Effective domain-dependent reuse in medical knowledge bases. Comput Biomed Res. 1995;28:403–432. [PubMed] [Google Scholar]
- 33.Campbell JR, Kallenberg GA, Sherrick RC. The clinical utility of META: an analysis for hypertension. Proc 16th Annu Symp Comput Appl Med Care. 1992:397-401. [PMC free article] [PubMed]
- 34.Campbell KE, Oliver DE, Shortliffe EH. The Unified Medical Language System: toward a collaborative approach for solving terminologic problems. J Am Med Inform Assoc. 1998;5:12–6. [DOI] [PMC free article] [PubMed] [Google Scholar]
- 35.Thurin A, Carlsson M, Gill H, Wigertz O. Arden Syntax and GALEN terminology support: a powerful combination to represent medical knowledge. Medinfo. 1995;8(pt 1):110. [PubMed] [Google Scholar]
- 36.van Heijst G, Falasconi S, Abu-Hanna A, Schreiber G, Stefanelli M. A case study in ontology library construction. Artif Intell Med. 1995;7:227–55. [DOI] [PubMed] [Google Scholar]
- 37.Booch G. Object-oriented Design with Applications. Menlo Park, Calif.: Benjamin Cummings, 1990.
