Lexicon Query Service
RFP Response
Revised Submission
3M Health Information Systems
Protocol Systems, Inc.
OMG TC Document CORBAmed/98-03-22
Lexicon Query Services 98/03/06 2 © Copyright 3M, 1998
© Copyright Protocol Systems, Inc., 1998 All rights reserved.
The companies listed above hereby grant to the Object Management Group, Inc. (OMG) permission to copy and distribute this document for the purpose of evaluating the technology contained herein during the Lexicon Query Services RFP submission and evaluation process. Distribution for any purpose other than technology evaluation is prohibited.
The material in this document is submitted to the OMG for evaluation. Submission of this document does not represent a commitment to implement any portion of this specification in the products of the submitters.
WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, THE COMPANIES LISTED ABOVE MAKE NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. The companies listed above shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance or use of this material. The information contained in this document is subject to change without notice.
This document contains information which is protected by copyright. All Rights Reserved. Except as otherwise provided herein, no part of this work may be reproduced or used in any form or by any means graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems without the permission of one of the copyright owners. All copies of this document must include the copyright and other information contained on this page.
The copyright owners grant member companies of the OMG permission to make a limited number of copies of this document (up to fifty copies) for their internal use as part of the OMG evaluation process.
RESTRICTED RIGHTS LEGEND. Use, duplication, or disclosure by government is subject to restrictions as set forth in subdivision (c) (1) (ii) of the Right in Technical Data and Computer Software Clause at DFARS 252.227.7013.
CORBA, OMG and Object Request Broker are trademarks of Object Management Group.
Contents
1
Preface ____________________________________________________________ 8
1.1 Submission Contact Points... 8 1.2 Supporting Organizations ... 8 1.3 Acknowledgements ... 82
Overview __________________________________________________________ 10
2.1 Introduction ... 102.1.1 Structure of This Document _________________________________________________ 10 2.1.2 Using This Document______________________________________________________ 10 2.1.3 Notation ________________________________________________________________ 11
2.2 Scope of Proposal ... 11
2.2.1 Approach _______________________________________________________________ 12 2.2.2 Proof of Concept Statement _________________________________________________ 12 2.2.3 Resolution of RFP Requirements _____________________________________________ 13
3
Definitions ________________________________________________________ 20
4
Use Scenarios______________________________________________________ 26
4.1 Information Acquisition ... 26 4.1.1 Text Lookup_____________________________________________________________ 26 4.1.2 Phrase Lookup ___________________________________________________________ 27 4.1.3 Phrase Matching__________________________________________________________ 27 4.1.4 Keyword Matching________________________________________________________ 27 4.1.5 Code Refinement _________________________________________________________ 28 4.1.6 Possible Value Enumeration ________________________________________________ 28 4.1.7 Field Validation __________________________________________________________ 29 4.1.8 Pick List Generation_______________________________________________________ 294.2 Information Display... 29 4.2.1 Code Translation _________________________________________________________ 29 4.3 Mediation ... 30 4.3.1 Code Transformation ______________________________________________________ 30 4.3.2 Code Mapping ___________________________________________________________ 30 4.3.3 Structural Composition/decomposition ________________________________________ 30 4.3.4 Field Validation __________________________________________________________ 31
4.4 Indexing and Inference ... 31
4.4.1 Relationship Inquiry_______________________________________________________ 31 4.4.2 Data Element Location_____________________________________________________ 31
4.5 Browsing ... 32
4.5.1 Service Browsing _________________________________________________________ 32 4.5.2 Concept Attribute Discovery ________________________________________________ 32 4.5.3 Association Discovery _____________________________________________________ 32
4.6 Composite Concept Manipulation... 32
4.6.1 Concept Attributes Retrieval ________________________________________________ 32 4.6.2 Composition _____________________________________________________________ 32
Lexicon Query Services 98/03/06 4 4.6.4 Normalization____________________________________________________________ 33
5
Reference Model ___________________________________________________ 34
5.1 Model Overview ... 35 5.2 Data Type Definitions ... 365.2.1 Basic Types _____________________________________________________________ 36 5.2.2 Naming Authority_________________________________________________________ 37 5.2.3 Basic Identifiers __________________________________________________________ 40 5.2.4 Terminology Identifiers ____________________________________________________ 42 5.2.5 Meta Concepts ___________________________________________________________ 43 5.2.6 Composite Types _________________________________________________________ 45 5.2.7 Collections ______________________________________________________________ 46 5.3 Terminology Service ... 47 5.3.1 Coding Schemes__________________________________________________________ 48 5.3.2 Value Domains___________________________________________________________ 65
6
IDL Interface ______________________________________________________ 67
6.1 Notation ... 676.1.1 Sequences and Sets _______________________________________________________ 67 6.1.2 Iterators ________________________________________________________________ 67
6.2 NamingAuthority Module ... 68
6.2.1 TranslationLibrary interface_________________________________________________ 72
6.3 Terminology Service Module ... 73
6.3.1 Basic Coding Terms_______________________________________________________ 74 6.3.2 Meta Types______________________________________________________________ 75 6.3.3 Coding Terms____________________________________________________________ 77 6.3.4 Coded Concept and Coding Scheme Terms _____________________________________ 78 6.3.5 Advanced Query Terms ____________________________________________________ 83 6.3.6 Systemization Definitions __________________________________________________ 84 6.3.7 Value Domain Terms ______________________________________________________ 88 6.3.8 Terminology Exceptions ___________________________________________________ 89 6.3.9 TranslationLibrary Interface ________________________________________________ 91 6.3.10 TerminologyService Interface _______________________________________________ 92 6.3.11 LexExplorer Interface _____________________________________________________ 94 6.3.12 CodingSchemeLocator Interface _____________________________________________ 99 6.3.13 ValueDomainLocator Interface _____________________________________________ 101 6.3.14 CodingSchemeAttributes Interface___________________________________________ 102 6.3.15 CodingSchemeVersion Interface ____________________________________________ 104 6.3.16 PresentationAccess Interface _______________________________________________ 108 6.3.17 LinguisticGroupAccess Interface ____________________________________________ 110 6.3.18 AdvancedQueryAccess Interface ____________________________________________ 111 6.3.19 SystemizationAccess Interface ______________________________________________ 114 6.3.20 Systemization Interface ___________________________________________________ 115 6.3.21 ValueDomainVersion Interface _____________________________________________ 121
6.4 Terminology Service Values Module ... 123 6.5 Trader Service ... 127
7
Meta-Terminology _________________________________________________ 129
7.1 Association ... 1297.1.1 Association Characteristics ________________________________________________ 131 7.1.2 Vendor Defined Associations_______________________________________________ 138
7.2 Association Qualifier ... 140 7.3 CharacterSet... 141 7.4 Coding Scheme ... 141 7.5 Language... 142 7.6 LexicalType... 143 7.7 PresentationFormat ... 143 7.8 Source ... 143
7.9 Source Term Type... 144
7.10 Syntactic Type ... 144
7.11 Usage Context ... 144
7.12 Value Domain ... 145
8
Conformance Points _______________________________________________ 146
8.1 Minimum Implementation ... 1468.2 Additional Conformance Levels ... 147
8.2.1 CodingSchemeLocator Conformance_________________________________________ 147 8.2.2 ValueDomainLocator Conformance__________________________________________ 148
9
Complete IDL Specification _________________________________________ 149
Appendix A - Diagram Notation _________________________________________ 170
A.1 Class... 170A.2 Association ... 171
A.3 Inheritence ... 173
References___________________________________________________________ 174
Lexicon Query Services 98/03/06 6
List of Figures
Figure 1 - Model Overview _____________________________________________________________ 35 Figure 2 - Basic Types _________________________________________________________________ 36 Figure 3 - Naming Authority ____________________________________________________________ 37 Figure 4 - Basic Identifiers______________________________________________________________ 40 Figure 5 - Terminology Identifiers________________________________________________________ 42 Figure 6 - Meta Concepts_______________________________________________________________ 43 Figure 7 - Composite Types_____________________________________________________________ 45 Figure 8 - Terminology Service __________________________________________________________ 47 Figure 9 - Coding Scheme______________________________________________________________ 48 Figure 10 - Coding Scheme Version ______________________________________________________ 50 Figure 11 - Concept Description 1 ________________________________________________________ 52 Figure 12 - Concept Description 2 ________________________________________________________ 53 Figure 13 - Presentations _______________________________________________________________ 55 Figure 14 - Presentation Types __________________________________________________________ 57 Figure 15 - Systemization ______________________________________________________________ 58 Figure 16 - Concept Expression__________________________________________________________ 61 Figure 17 - Concept Expression Example __________________________________________________ 63 Figure 18 - Value Domain ______________________________________________________________ 65 Figure 19 - Naming Authority ___________________________________________________________ 68 Figure 20 - Terminology Service Module Outline ____________________________________________ 73 Figure 21 - Basic Definitions ____________________________________________________________ 74 Figure 22 - Meta Type Definitions________________________________________________________ 75 Figure 23 - Coding Terms ______________________________________________________________ 77 Figure 24 – Coded Concept and Coding Scheme Terms _______________________________________ 80 Figure 25 – Advanced Query Terms ______________________________________________________ 83 Figure 26 - Systemization Terms _________________________________________________________ 85 Figure 27 - ValueDomain Terms _________________________________________________________ 88 Figure 28 – Terminology Service Exceptions _______________________________________________ 90 Figure 29 - TranslationLibrary Interface ___________________________________________________ 91 Figure 30 – Terminology Service Interface _________________________________________________ 92 Figure 31 - LexExplorer Interface ________________________________________________________ 95 Figure 32 - CodingSchemeLocater Interface ________________________________________________ 99 Figure 33 - ValueDomainLocator Interface ________________________________________________ 101 Figure 34 - CodingSchemeAttributes Interface _____________________________________________ 102 Figure 35 - CodingSchemeVersion Interface _______________________________________________ 105 Figure 36 - PresentationAccess Interface__________________________________________________ 108 Figure 37 - LinguisticGroupAccess Interface ______________________________________________ 110 Figure 38 - AdvancedQueryAccess Interface_______________________________________________ 111 Figure 39 - SystemizationAccess Interface ________________________________________________ 114 Figure 40 - Systemization Interface ______________________________________________________ 117 Figure 41 - ValueDomainVersion Interface ________________________________________________ 121 Figure 42 – Terminology Service Values Module ___________________________________________ 125 Figure 43 - IDL Sample _______________________________________________________________ 125 Figure 44 - Trader Service Definition ____________________________________________________ 127 Figure 45 - Sample Classification by Meaning _____________________________________________ 130 Figure 46 – Association Characteristics___________________________________________________ 131 Figure 47 - Reference Association _______________________________________________________ 134 Figure 48 - Subtyping Association_______________________________________________________ 135 Figure 49 – Non-Semantic Association ___________________________________________________ 137 Figure 50 - Sample Vendor Association __________________________________________________ 138 Figure 51 - Sample Generic Association __________________________________________________ 139 Figure 52 - TerminologyServices.idl _____________________________________________________ 165 Figure 53 – TerminologyServiceValues.idl ________________________________________________ 169
List of Tables
Table 1 – Example of a Possible Value List ... 29
Table 2 - Registration Authority Formats ... 72
Table 3 - Association Codes ... 142
Table 4 - Association Qualifier Codes ... 142
Table 5 - Language Codes ... 144
Table 6 - Lexical Type Codes ... 145
Table 7 - MIME codes ... 145
Table 8 – Sample Source Term Type Codes... 146
Table 9 - Syntactic Type Codes ... 146
Lexicon Query Services 98/03/06 8
1 Preface
This submission is a response to the CORBAmed RFP2, for a set of Lexicon Query Services.1
1.1 Submission Contact Points
Harold Solbrig
3M Health Information Systems 575 West Murray Boulevard Murray, UT 84123-4611 (801) 265-4312 [email protected] Tim Brinson Protocol Systems 8500 SW Creekside Place Beaverton, OR 97008-7107 (503) 526-4392 [email protected]
1.2 Supporting Organizations
The following organizations have been involved in the process of developing and/or reviewing this submission. The submitters of this response thank them for participating and giving their valuable input.
• 2AB, Inc.
• Microelectronics and Computer Technology Corporation
• Medical Informatics Group, University of Manchester
• MULTUM Information Services, Inc.
• Reparto Informatica Medica, Istituto Tecnologie Biomediche, Consiglio Nazionale delle Ricerche
1.3 Acknowledgements
The authors of this document wish to express their sincere appreciation to those listed below for their invaluable contributions of ideas and experience. Ultimately, the ideas expressed in this document are those of the authors and do not necessarily reflect the views or ideas of these individuals, nor does the inclusion of their names imply an endorsement of the final product.
Carol Burt Karen Keeter
Tim Brinson Anthony Nowlan
Keith Campbell Alan Rector
Chris Chute Jeremy Rogers
Tom Culpepper Angelo Rossi Mori
Kevin Keck Danny Solomon
Peter Elkin Boris Zadov
We also thank the National Technology Alliance for generously providing us with the web page and resources.
Lexicon Query Services 98/03/06 10
2 Overview
“The question is,” said Alice, “whether you can make words mean so many different things”. “The question is,” said Humpty Dumpty, “which is to be master—that’s all.”
Through the Looking-Glass Lewis Carroll
2.1 Introduction
This document contains a response to the OMG CORBAmed Lexicon Query Services (LQS) RFP. This response specifies a set of IDL interfaces to be used in querying and accessing computerized medical terminology resources.
2.1.1 Structure of This Document
This document begins with an overview of the approach, rationale, and methodology used to develop this proposal. It then covers the required proof of concept statement and addresses the specific RFP requirements and discussion points. This, in turn, is followed by the specification, which begins with a set of definitions followed by a description of what is believed to be a representative set of use requirements. We then present the model that underlies the submission, followed by a detailed description of the submission. This description includes the interfaces, metadata, and other structures needed to produce an interoperable implementation. A discussion of the mandatory and optional interfaces and a complete set of IDL definitions complete the submission.
2.1.2 Using This Document
Sections 1 and 2 of this document identify the people who have contributed to this document and describe the basic requirements that brought it into being. When
accompanied by the LQS RFP1, these sections provide an overview of what this document intends to accomplish. Section 3, Definitions is a reference section. It may be skipped and referred to as necessary. Section 4, Use Scenarios describes some of the various situations in which a terminology service would be used and how the LQS interface will work in those situations.
Section 5, Reference Model presents an abstract “semantic” model that attempts to define and describe the associations between each of the entities referenced in the submission. Note that there is not a one-to-one mapping between the entities in section 5 and the Interface Definition Language (IDL) in section 6, IDL Interface. The IDL has undergone several transformations in the process of simplifying the interfaces, making necessary changes to enhance performance and factoring out mandatory and optional components. Section 5 should be useful, however, in understanding the terminology and descriptions used in section 6.
Sections 5.3.1.4.2, IDL Interface, 7, Meta-Terminology, 8, Conformance Points, and 9, Complete IDL Specification are provided as reference material for use in the
implementation.
2.1.3 Notation
The following notational conventions are used throughout this document: IDL Interface This font is used when referencing IDL interface properties, operations, etc.
Italic An italic font is used when referring to abstract model classes, attributes and methods.
<Concept> This notation is used when discussing the “meaning” of a particular concept. It allows us to give examples without having to resort to some sort of lengthy phrases such as “the intended meaning of the concept ‘C1234’ in UMLS.”
2.2 Scope of Proposal
The focus of this proposal is to specify a set of common, read-only methods for accessing the content of medical terminology systems. What constitutes a medical terminology system can vary widely, from a simple list consisting of a set of codes and phrases at one extreme, to a dynamic, multi-hierarchy classification and categorization scheme at the other. Our focus was on determining what could be construed to be “common” elements of terminology systems. By “common” we mean the set of elements in which the semantics are fairly widely accepted, even though they may not be present in all or even many of the terminology systems available today. Our goal was to produce a specification that could be used to implement a reasonable and useful interface to any of the major medical coding schemes.
A key goal of this specification is to provide a single, agreed-upon way to ask a given question of a terminology system. Terminology systems may vary radically in their forms of representation and access. For example, the question “Is penicillin an antibiotic?” could be presented to one system in the form “Does there exist a subtype relationship in which the concept code for antibiotic is the supertype and the concept code for penicillin is the subtype?” In another system, the question may be presented as “Is there a record in the drug database whose key is ‘penicillin’ that has the value of ‘Yes’ in the antibiotic column?” The intention of this specification is to provide only one specific interface that may be used to answer any given question, regardless of the underlying implementation. While this may increase the complexity of some implementations, we believe that this approach will greatly simplify the process of writing terminology clients.
Lexicon Query Services 98/03/06 12 The primary guide in the formulation of this proposal was the set of requirements specified in the Lexicon Query Service RFP1. The RFP was deliberately limited to requesting read-only services, in the belief that read access was the most immediate, feasible, and pressing need. We further subdivided read-only services into two categories:
• High volume on-line services. These services are used by an on-line production system. The services include translation, inference, presentation, and the like.
• Perusal and browsing services. These services are used occasionally as a means of understanding the content and structure of the specific terminology.
The primary focus of this proposal was the first category of services, the high volume on-line type of service. It was our belief that the immediate needs rested within that specific area, and that was the area that contained the most commonality and was the best understood. Perusal and browsing services were addressed only as necessary to satisfy specific RFP requirements.
2.2.1 Approach
We began this proposal by soliciting a set of use requirements and scenarios for accessing medical terminology systems. This input was first used to arrive at a common set of terms and definitions (a terminology of terminology) which allowed us to begin to analyze the use scenarios with some precision.
The use scenarios and the corresponding terminology set were then used to design an abstract object model of the various components of a terminology system. The purpose of the abstract object model is to refine the use requirements and the eventual interface. It is not intended to be a model that describes the “ideal” terminology system (if such is conceivable). Its sole function is to add additional precision to the meaning of the various entities discussed in the interface specification.
The attributes and operations necessary to satisfy the use requirements were then added to the various entities in the object model. Once a reasonable level of agreement was reached, the model was manually translated into an IDL. The IDL translation process was anything but mechanical. It had to take performance, compiler limitations, accepted styles, etc. into consideration. The resultant IDL does not always line up exactly with the intentions of the model. Whenever there are questions of intent, the reader should refer to the model for the final word.
2.2.2 Proof of Concept Statement
A design based on this specification has been completed and a prototype is under construction. The underlying model of the prototype is based on an implementation of a commercially available terminology system.
2.2.3 Resolution of RFP Requirements
to perform. This section lists the RFP requirements, and describes how the interfaces described in this proposal would perform each task. In these descriptions, the names of interface items (such as operations, entities, attributes, or the interfaces themselves) appear in an identifyingfont. Each description includes a reference to the page on which the interface item is fully described.
2.2.3.1 Mandatory RFP Requirements
2.2.3.1.1
The lexicon query services shall provide the means of enumerating the concepts
that a given lexicon contains, along with whatever information is available that
defines, describes, or differentiates the concepts.
This requirement is satisfied through the following steps:
1. Acquire a list of all the coding scheme identifiers in the service. This can be done using the TerminologyService interface operation get_coding_scheme_ids (page 92). This operation is inherited by all TerminologyService components: LexExplorer, ValueDomainLocator, and CodingSchemeLocator.
After retrieving the coding_scheme_ids, the user may use one of the following operations to retrieve concept information. For access to all of the information about the concept, use the following:
2. For each coding scheme identifier, use the CodingSchemeLocater interface operation get_coding_scheme_version (page 99) to locate the default coding scheme version for the coding scheme.
3. For each concept in the coding scheme, use the CodingSchemeVersion interface operations get_definitions,get_comments,get_instructions, get_all_text, etc. to acquire the desired information. (page 105). A CodingSchemeVersion may also support PresentationAccess interface operations such as get_presentation_info and SystemizationAccess interface operations such as get_default_systemization that can be used to locate concept systemization information. Through the Systemization interface (page 117), the ConceptExpansions interface operation expand_concept can be used to access the “cannonical” expansion of each concept, if one is available (page 117).
Alternatively, a summary of the concept information within the default coding scheme may be accessed as follows:
For each coding scheme identifier use the LexExplorer interface operation list_concepts to obtain a summary of information about each concept in the default version of the coding scheme.
2.2.3.1.2
The lexicon query services shall provide a means of retrieving a concise and
unique external identifier (unique, over time, within that particular lexicon) for
each individual concept.
The ConceptCode structure (page 74) represents the required identifier. Note that a
Lexicon Query Services 98/03/06 14
2.2.3.1.3
The lexicon query services shall provide a means of retrieving the appropriate
attribute value (in the appropriate format) for that concept, depending on the
arguments to the query. The arguments should support, for example, translation to
other coding schemes, presentation formats, languages and settings in which the
concept needs to be externally presented.
This submission makes a clear distinction between definitional attributes, which serve to define, categorize, or classify concept codes and attributes which are used to externally represent the concept code. The first class of attributes is retrieved via the
Systemization interface (page 117). The operation
list_associated_target_entities will return all of the concept codes or all of the characteristics that have an association (relation) defined for the supplied concept code. The second class of attributes are retrieved via the PresentationAccess interface (page 108), and, optionally, by the CodingSchemeVersion interface (page 105). The operations get_preferred_presentation and get_presentation_for_context retrieve a presentation in the appropriate format, language and context.
Translation to other coding schemes is accomplished via the LexExplorer interface (page 95) operations translate_code and translate_codes, which translate a code from one coding scheme into another.
2.2.3.1.4
The lexicon query services shall provide a means of enumerating the various
named attribute types and/or relationship types which may exist within a lexicon.
In this specification, an Association (page 85) may serve to associate a ConceptCode with either another concept code or a Characteristic (page 85), which, in this document, represents non-coded information associated with the concept. This relieves the client software from having to know at the time of query whether or not information is classified as an attribute or a relationship by the coding scheme. The Systemization interface operation get_association_ids can be used to enumerate all of the associations in a systemization (page 117). The get_association_definition operation can be used to determine the semantics of the association. If a total inventory is desired, the iteration operation described in the first requirement may be used to list all coding scheme versions, followed by the SystemizationAccess operation
get_systemization_ids to iterate through all systemizations within the entire system (page 114).
2.2.3.1.5
The lexicon query services shall provide a means of enumerating a list of concepts
which participate in a specified relationship (hierarchical or non-hierarchical) with
other known concepts.
The Systemization interface (page 117) provides several operations to accomplish this depending on the exact nature of the query:
• The operation list_associated_target_entities returns the set of concepts, concept codes, and/or characteristics that are related to a known concept as a target of the named association.
• The operation list_associated_source_concepts returns the set of concept codes that is a source in the named association with the supplied concept code or
characteristic.
• The operations get_associations_for_source and
get_associations_for_target return the associations in which a known concept code participates as either a source or target respectively.
• The operation get_entity_graph returns a hierarchical graph of the transitive closure of an association over a known concept
2.2.3.1.6
The lexicon query services shall provide a means of enumerating, for a particular
concept, the attributes and/or relationships and their values
The CodingSchemeVersion interface operation get_all_text, (page 105) along with the PresentationAccess interface operation get_presentation_info (page 102) provide the means of listing all of the external representations associated with the concept code.
The Systemization interface operations list_associations_for_source, list_associations_for_target (page 117) provide the ability to list all of the associations in which a concept code participates. Detail for each of these associations may then be acquired via the list_associated_target_entities and
list_associated_source_concepts interfaces which enumerates all of the “values” (codes and characteristics) which are associated with the particular concept code.
2.2.3.1.7
The lexicon query services shall provide the ability to allow enumeration of
concepts which could potentially be represented by a specified attribute value.
As discussed in section 2.2.3.1.4, this submission makes a distinction between attributes which are external representations of a concept code and attributes and relationships which serve to define, categorize, and/or catalog the concept codes.
To enumerate concepts that can be externally represented by a given attribute, the CodingSchemeVersion interface operations get_concepts_by_text,
match_concepts_by_text, and match_concepts_by_keywords (page 105) all allow the retrieve concept codes that match the supplied attribute or attribute fragment. To enumerate concepts which are defined, categorized or cataloged by their association with particular attributes, the Systemization interface operation
list_related_entities (page 117) may be used to find all of the concept codes which have a specific association with a specific attribute value.
2.2.3.1.8
The lexicon services shall be able to allow enumeration of concepts which satisfy
multiple relationships and/or attribute value combinations.
The AdvancedQueryAccess Interface operation query (page 111) provides this capability by allowing the client to construct a constraint query, which is a regular expression consisting of Property values, as outlined in this specification and governed by the rules of the OMG Trader constraint language.2
Lexicon Query Services 98/03/06 16
2.2.3.2 Optional RFP Requirements
2.2.3.2.1
The lexicon query services may support the ability to perform partial pattern
matching, soundex, and more sophisticated forms of generic selection on concept
names and/or attribute values and/or other matching criteria.
The CodingSchemeVersion interface operations match_concepts_by_string and match_concepts_by_keywords (page 105) provide this interface.
2.2.3.2.2
The lexicon query services may be able to support traversal of relationships within
the lexicon. This may include support for location of immediate parents/children,
leaf nodes, root nodes, etc.
This requirement is partially satisfied via the Systemization interface operations are_concepts_associated, are_entities_associated, and
get_associated_entities (page 117). These all provide a parameter that specifies whether the query applies only to directly related entities or to the transitive closure of the same association. The get_entity_graph operation provides a means of retrieving the entire transitive closure of an association in one fell swoop.
2.2.3.2.3
The lexicon query services may be able to represent concepts as coordinated terms,
where a concept may be viewed as a single entity or composite entity consisting of
several simpler concepts.
The Systemization interface (page 117) provides a variety of means of expanding terms (representing concepts as a composite entity) or simplifying (coordinating) them.
2.2.3.3 Issues to be discussed
Confidentiality and privacy. It is expected that they who implement the LQS will use the CORBA Security service when confidentiality and privacy issues are of concern. An implementation may use the facilities of the OMG Security Service to provide
Authentication and Authorization of the Principle user. Credentials may also be accessed by the implementation, if necessary to conform to Security Policy. There are no explicit security-related interfaces in this submission.
Registration and identification of multiple lexicons; application of lexicon services across multiple lexicon domains. The NamingAuthority and a standard Name for registration with the Naming Service and Trader Service addresses many of the issues involved in the registration of unique lexicons, which will be referred to as coding
schemes in the remainder of this document. A terminology service implementer may also
provide named access to multiple coding schemes within the same implementation. Definition of the query as well as the form of the expected response to the queries. Insofar as this issue concerns static definitions, it is addressed in this submission. An implementer may choose to support the AdvancedQuery interface, which provides dynamic query capabilities and uses the OMG Trader query language.
Proposals may include a suggested ‘minimum data set’ for attributes and/or relationships for a concept. The MetaConcepts module and the Meta-Terminology section in this document address this issue at length.
Proposals may comment on the use of a push versus a pull strategy for providing lexicon services. For example, a push strategy could be used to update a ‘cached’ lexicon subset with new concepts that have been added in the authoring environment. The details of one strategy vs. another have been left to the implementation vendor.
One of the issues specifically discussed involving this separation is whether the
specification should include a separate terminology-to-terminology interface to optimize caching and bulk transfer. Specifying the interface would facilitate interoperability, eliminating the need for the caching client and corresponding server to be provided by the same vendor. We concluded that terminology-to-terminology information transfer would make a good subject for a future RFP. It is not addressed in this document.
Proposals shall also discuss issues related to scalability to enable support of large (hundreds of thousands) of concepts. We have represented concepts and several other large volume entities as structures rather than object types. A concept is represented solely by its code; text is represented by a structure containing a string and a character set, etc. A number of “objects” in the model have been encapsulated within CORBA objects that provide interfaces to the terminology service capabilities without exposing the large number of object references associated with a fine-grained object model. Many operations return collections with iterators to ensure that the client has the ability to manage large-volume responses.
2.2.3.4 Relationship to Existing OMG Specifications
2.2.3.4.1
CORBA Security
See “Confidentiality and Privacy” discussion above.
2.2.3.4.2
CORBA Event Services
No interfaces related to CORBA Event Services are used in this specification.
2.2.3.4.3
CORBA Naming Services
We anticipate that the CORBA Naming and/or Trader Services may be used to acquire the initial reference to the TerminologyServices module. The
TerminologyServiceName attribute has been provided explicitly for this purpose.
2.2.3.4.4
CORBA Relationship Service
The CORBA Relationship Service describes a powerful means of representing
associations among objects. The relationships managed by the Terminology Service are between entities that are not exposed as CORBA objects. This specification addresses many of the issues discussed in the OMG Telecommunications Topology Services RFP3.
2.2.3.4.5
CORBA Property and Query Services
The Property Service is not used in this response. It is common practice in terminology systems to view a Characteristic/Property/Facet as the target of a relationship because a Characteristic is often also a coded concept within the coding scheme.
Lexicon Query Services 98/03/06 18 This specification primarily provides static query services, as defined in the IDL. Dynamic Query Services are provided via the AdvancedQuery interface, which uses the OMG Trader query language rather than the Query Service.
2.2.3.4.6
CORBA Interface Repository
This submission does not directly address or use the interface to this facility, although clients may use the IR to discover the capabilities of a TerminologyService dynamically.
2.2.3.4.7
Meta-Object Facility
The OMG Meta-Object Facility (MOF) states:
To understand the possible usage patterns for the MOF, the first thing one needs to understand is the two distinct viewpoints for the MOF:
• Modeling viewpoint: The designer’s viewpoint, looking ‘down’ the meta levels. From the modeling viewpoint, the MOF is used to define an information model for a particular domain of interest. This definition is then used to drive subsequent software design and/or
implementation steps for software connected with the information model.
• Data viewpoint: The programmer’s viewpoint, looking at the current meta-level, and possibly looking up at the higher meta-levels. From the data viewpoint, the MOF (or more accurately, a product of the MOF) is used to apply the OMA based distributed computing paradigm to manage information corresponding to a given information model. In this mode, it is possible for a CORBA client to obtain the information model descriptions and to use them to support reflection.
The MOF addresses a set of modeling constructs that are useful in defining object-oriented metamodels from both structural and behavioral perspectives. The OA&D Facility metamodel, which UML represents, is one such metamodel that can be supported by MOF.
The terminology service submitters used UML to define the underlying information model for the Lexicon Query Service. We see no reason why this information model could not be made accessible from a commercial MOF repository. However, implementation of the Terminology Service interfaces does not depend upon MOF interfaces or the availability of a MOF-compliant repository. The interfaces proposed in this specification are intended to provide run-time access to terminology meta-data needed to support medical coding systems. A MOF repository, if available, could be used by an implementation to provide the run-time meta-data necessary for a compliant implementation of this specification. The MOF might also provide an excellent resource for Terminologists to manage and explore the terminology service model itself. This use of the MOF, however, is outside the scope of the Lexicon Query RFP.
2.2.3.4.8
Business Object Facility Object Analysis and Design
This submission does not have any dependencies on the Business Object Facility, which is currently in the OMG adoption process. It is hoped that Terminology Services will have applicability outside the medical domain and may be used to manage common business object terminologies.
2.2.3.4.9
Telecommunications Topology Services
The Telecommunications Topology Services RFP3 solicited proposals which, among other things, provided the ability to create, modify, and destroy topological relationships, support large populations of objects, describe constraints, and provide query and traversal services. This is closely related to portions of the Systemization interfaces described in this document. The sole response to the Topology Services RFP was withdrawn in December 1997, and is no longer available for discussion.
Lexicon Query Services 98/03/06 20
3 Definitions
“That’s a great deal to make one word mean,” Alice said in a thoughtful tone. “When I make a word do a lot of work like that,” said Humpty Dumpty, “I always pay it extra.”
Through the Looking-Glass Lewis Carroll
The definitions below are specific to this document. While attempts have been made to align the terminology of this document with accepted general definitions, there will be cases where the words used in this document will have a significantly different meaning than they have in general usage. Terms appearing in boldface type below are defined elsewhere within this section.
Association
An association is a binary predicate applied to an ordered pair of types. The first type is referred to as the source type and the second is the target type. In this specification, the source type must be a concept code and the target type must be either a single target element or a set of target elements.
Association Instance
An instance of an association; a binary predicate applied to a specific ordered pair of entities, which must be of the source type and target type specified in the association itself. The first entity in the ordered pair is referred to as the source entity. (not to be
confused with Source, as defined below), and the second is the target entity.
Association Qualifier
A qualified code that may be attached to a target element to provide additional information about the nature of the particular association. With the exception of cardinalities, association qualifiers are left undefined in this specification. Blob
Acronym for Binary Large Object; used in this document to represent an opaque string of bytes that is passed unchanged between the service and the client.
Characteristic
A non-coded property or attribute associated with a concept code. As defined in this specification, a characteristic provides non-semantic attributes for a concept code. Coding Scheme
A relation between a set of concept codes and a set of presentations, definitions, comments, and instructions, which serves to designate the intended meaning behind the codes. A coding scheme may also have one or more systemizations defined across a subset of the concept codes within the scheme. Coding schemes are evolutionary in nature, with codes being added, deleted, and modified. The intended meaning behind a concept code must not change within a given coding scheme.
Coding Scheme Version
A specific release or version of a coding scheme. A coding scheme version represents a consistent, fixed image of a coding scheme at a point in time. Therefore, it may define and/or describe only a subset of the concept codes contained within the coding scheme itself. Each coding scheme version may also associate a different set of presentations, definitions, etc. with a given concept code so long as this association does not change the intended meaning of the code.
Comment
A non-defining text string, which is used to annotate or provide remarks about a concept code within a coding scheme version.
Concept Code
A local name, consisting of a fixed sequence of alphanumeric characters, that is used to designate one or more presentations, definitions, comments, instructions, etc. within a coding scheme.
Concept Description
The set of definitions, comments, instructions and presentations associated with a concept code in a given coding scheme version.
Concept Expression
A base concept qualified by one or more optional “attribute-value” pairs that serve to further define the total concept. An attribute-value pair consists of an association which serves to identify the “attribute” and either a concept code or a characteristic which serves to identify the value portion of the attribute. An attribute-value pair may also reference an optional list of association qualifiers.
Definition
A statement that describes a concept in order to permit its differentiation from related concepts.4 In this document, definitions are prose descriptions, which describe the intended meaning of a concept code, permitting its differentiation from the meaning associated with other related concept codes.
Implementation Vendor
A company or other organization providing terminology software which presents itself through the interface specification provided in this document.
Instruction
Additional information in either machine or human readable form that describes when, where, and/or how a concept code should be used.
Language
A “natural language”—any spoken or written language, such as French, English, German, etc.—as opposed to a formal language, such as Fortran, C, or FOPL.
Lexicon Query Services 98/03/06 22 Lexical Type
A tag indicating whether a presentation falls into any of several special types. The purpose of this tag is to indicate terms that are not generally appropriate for stemming and other natural language techniques.5 Example: lexical types include “abbreviation,” “acronym,” “eponym,” “trade name,” etc.
Linguistic Group
A group of presentations which are lexical or syntactic variants of each other. As an example, the textual presentations “Atrial Fibrillation”, “Atrial Fibrillations”, “Fibrillation, Atrial” would all belong to the same lexical group, while the textual presentations “Auricular Fibrillation” and “Auricular Fibrillations” would belong to another.
Lexical Type
A tag indicating whether a presentation falls into any of several special types. The purpose of this tag is to indicate terms that are not generally appropriate for stemming and other natural language techniques.6 Example: lexical types include “abbreviation,” “acronym,” “eponym,” “trade name,” etc.
Local Name
An identifier which is unique within the context of a naming authority. In this document, a concept code is a local name within the context of a coding scheme, which is a naming authority. See section 5.2.2, Naming Authority for further details.
Naming authority
A registered authority which is responsible for managing a set of local names, all of which must be unique within the name space of the authority. In this document, a coding scheme is a type of naming authority that manages a set of concept codes. See section 5.2.2, Naming Authority for further details.
Native Coding Scheme
The primary coding scheme supported and provided by a terminology service. Although it is not formally required, the native coding scheme typically will have exact synonyms for all of the concepts contained in all of the non-native coding schemes supported by the terminology service.
Pick List
An ordered list of one or more concept codes along with a presentation deemed
appropriate to represent the concept code in an external list or other selection mechanism. Presentation
An sign or symbol used to represent a concept code externally. Presentation Format
A code which identifies the type of external processing necessary to correctly present a presentation. Example: presentation formats include “plain text,” “HTML,” “Rich Text Format,” etc. The Internet MIME codes are the proposed way of representing
presentation formats within this document. Presentation Usage
The association of a presentation with a concept code. This association carries additional attributes about how the presentation is used in the context of the concept codes, references, etc.
Qualified Code
A qualified name which identifies a coded concept within the context of a coding scheme. A qualified name consists of the coding scheme identifier (the naming authority) and a concept code (the local name).
Qualified Name
A globally unique name for an entity. A qualified name consists of the combination of a naming authority and a local name. See section 5.2.2, Naming Authority for further details.
Registration Authority
An organization authorized to register and issue naming authority identifiers. Role
A name which serves as a synonym for either the “source” position or “target” position within a specific association. As an example, a subtyping association places the supertype in the source position and the set of subtypes in the target position. Within this specific association, the role “supertype” would be a synonym for the source and the role “subtype” would be a synonym for the target.
Source
The document, book, person, or other reference from which a definition, comment, instruction, or presentation was drawn.
Source Term Type
The code for the use to which a specific presentation is put within a source. Example: source term types include “Disease Name,” “Language Qualifier,” “Adjective,” etc. Syntactic Type
A syntactic form that a given phrase has within a linguistic group. Typical syntactic types may include “plural”, “different spelling”, “different word order”, etc.
Systemization
A structure applied across a set of qualified codes and, optionally, characteristics which represents an organization, categorization, classification, or other structuring of the various entities.
Target Element
Lexicon Query Services 98/03/06 24 end of an association.
Terminology
A set of terms representing the system of concepts of a particular subject field.7
Terminology Service
An implementation of this specification, providing an interface to one or more coding schemes, as well as an optional set of value domains which serve to correlate the coding schemes with external screens, messages, data bases, etc. A terminology service serves to present the contents of a terminology externally.
Usage Context
A qualified code that represents a context in which a presentation would be deemed appropriate. Usage contexts may include the type of application, user, display device and other information that is used by the terminology service to pick the most appropriate presentation for a concept code or set of concept codes.
Value Domain
A value domain represents a set of values which may be used fill a field on a data entry screen, a column in a data base, a field in a message, or some other external entity in which it is possible to record or transfer concept codes. A terminology service may be used to return a list of qualified codes, which are possible values for a field, etc., as represented by a value domain.
Lexicon Query Services 98/03/06 26
4 Use Scenarios
The following scenarios describe some of what are believed to be typical uses of terminology systems. This list of uses is not exhaustive. However, it has served as a guideline in designing the terminology service interface. The set of uses is subdivided into six sections:
• Information Acquisition. Using terminology services to aid in the process of entering coded data.
• Information Display. Using terminology services to translate coded data elements into human or machine-readable external forms.
• Mediation. Using terminology services to transform messages or data records from one form or representation into another.
• Indexing and Inference. Using terminology services to inquire about associations which may or may not pertain between various data elements, and to assist in the location of various data record sets which may contain information relevant to the specific topic or entity.
• Browsing. Using the terminology services to determine the structure and meaning of a terminology system.
• Composite Concept Manipulation. Using the terminology services to aid in the entry, validation, translation and simplification of composite concepts.
Each of these sections is dealt with in greater detail in the paragraphs that follow.
4.1 Information Acquisition
A key factor in coding data is the ability to quickly and precisely translate an external term, phrase, or image in the user’s mind into the code or codes that represent the information to be conveyed. The terminology services provide several means of assisting in this translation process.
4.1.1 Text
Lookup
The data entry application knows the specific code that represents a target concept. The terminology service receives the code and coding scheme from the application and returns the preferred phrase that represents the specific code.
Example: a user wishes to encode the fact that a patient has a mild atrial flutter. The user is familiar with the ICD-9 coding system and wishes to start with the code 427. The terminology service is asked for the phrase that corresponds with the code 427 in the ICD-9 coding scheme and returns the text “Cardiac Dysrhythmias.”
4.1.2 Phrase
Lookup
The user of the data entry application knows the precise text that represents a target code or set of codes. The user supplies the string and the name of the target coding scheme to the terminology service. The service returns the code or codes whose presentations match the string, along with a list of the preferred presentations for each code.
The user may constrain the search by supplying a list of contexts in which the text is used. Example: an application may wish to locate all concepts that correspond to the text “Cold” in the UMLS coding scheme. It supplies the text “Cold” and the language indicator for “English” to the terminology services and asks for all matching concepts in the UMLS coding scheme. The terminology system returns two concepts:
C0009443 - Common Cold C0009264 - Cold <1>
The user can limit the search by supplying the information that the resulting concepts must belong to the domain “Enterovirus Infections,” which would then constrain the output to the single concept representing the disease. The user could also indicate that the supplied text was used as a short column heading, which might further constrain the results.
4.1.3 Phrase
Matching
This case is identical to the previous case, except the user knows only an approximate string that represents the target concept or concepts. The string may contain wild cards and other information to direct the search. With the exception of the string itself, the information supplied to the terminology service is identical to the case described above. The terminology service returns a set of concepts that might match the supplied phrase. The set is ordered by match likelihood with the most probable matches supplied first. Example: the user could supply the string “Art* Fibrillation” and the language indicator for “English” to the terminology service and ask for all matching concepts in the UMLS coding scheme. The terminology service might return the following set of concepts:
Code Phrase Weight
C0155709 Atrial fibrillation and flutter 0.9
C0004238 Atrial Fibrillation 0.5
4.1.4 Keyword
Matching
This case is identical to the previous two cases, with the exception that the user knows one or more keywords, which are used to locate the target concept or concepts. For example: the user could know the words “heart,” “valve,” and “flutter.” The terminology serviced is asked for matching concepts in the UMLS coding scheme and returns the appropriate set of matching codes.
Lexicon Query Services 98/03/06 28
4.1.5 Code Refinement
The user of the services wishes to determine the best possible concept code to represent a specific situation (e.g., the condition of a patient). The user first selects a starting concept through some other mechanism. Given this starting concept, the user wishes to supply additional words or phrases, along with a relationship (more general, more specific, synonymous). The terminology service returns an ordered set of concept codes that participates in the supplied relationship with the starting code, as well as contains the additional words or phrases in their external representation. As with phrase lookup, the order of the set is based on match quality with exact matches occurring first.
Example: the user may start with the concept for <Cardiac Dysrhythmias> in the ICD-9 coding system. The terminology services are supplied with this concept, the words “atrial” and “flutter,” and the relationship “more specific.” The coding system would return an ordered set of concepts which partially or completely meet these criteria, and the user could select the concept (and code) which most closely represented his own image of the situation (which, in this case, would probably be code 427.32, Atrial Flutter).
4.1.6 Possible Value Enumeration
The user wishes to examine a list of the possible codes, along with their corresponding phrases or other representative external representations that might be supplied for a specific data entry field.
The terminology service is supplied with the value domain representing the data entry field, the coding scheme to be used in the field, and the language and usage context in which the selection list is to be presented. The terminology services return a list of codes and the appropriate presentation for each code in the given context. The return list may also contain indicators showing which code(s) are defaults for the selection.
Example: the user wishes to encode the patient’s gender into an HL7 message, using the HL7 Version 2.3 Table 001. The terminology service is given the “domain” identifier CX0001234, representing the concept Patient Sex Value Set. It is also given the
information that the user is interested in an English selection set for use in a short, textual list. The terminology services return a list containing:
Code Presentation Text
M Male
F Female
U Unknown
O Other
4.1.7 Field Validation
The application needs to determine whether a specific code for a given field in a data record or message is valid. The application passes the code, the value domain, and the coding scheme to the terminology service. The service returns TRUE if the code is valid for the field; FALSE otherwise.
Example: an application has just received an HL7 message and needs to determine whether it is valid and can be processed further. As the application iterates over the various coded entries within the message, querying the terminology service about the validity of the entries, it encounters the field in which the patient gender is encoded. It passes the concept representing the gender domain “CX0001234,” the code itself “M,” and the identifier of the HL7 Version 2.3 Table 001 coding scheme to the terminology service. The service returns TRUE indicating that “M” is a valid code for the specified domain in the coding system.
4.1.8 Pick List Generation
The application wishes to present a formatted, ordered list of possible selections for an input field. The specific user, facility, or some other factor may customize this list. The specific list to be returned may depend upon the application requesting it, the specific user, and other context-specific information. The list may also need to specify which of the selections may be considered as default selections.
4.2 Information Display
It is necessary to be able to translate a code from a coding scheme into the appropriate form for presentation to an external viewer. This translation may have as its target a printout, a video display screen, a sound generation device, or some other medium. The display will depend upon the application doing the presentation, the target medium (screen, hard copy, etc.), the language spoken by the viewing user, and, possibly, the user’s identity and classification.
4.2.1 Code Translation
An application wishes to represent the meaning of a specific code from a specific coding scheme to an end user. The terminology service is given a code and the observer’s preferred language, and, possibly, additional context describing how the concept is to be presented. It returns the most appropriate presentation of the concept, given the situation. Example: an application may have a data record that contains the code “123” in the laboratory test field. The application wishes to display a small (< 30 characters ) textual string representing that particular code to an English-speaking person. The terminology service is given the code, its coding scheme, the code for the English language, and an ordered list of contexts (e.g., 30 character string, heading, abbreviation, textual name)
Lexicon Query Services 98/03/06 30 any.
4.3 Mediation
One of the “holy grails” of terminology services is the ability to translate coded information from one database and/or coding system into another, independently developed, database and coding system. While the terminology services will not provide this capability by any stretch of the imagination, they should provide some building blocks upon which more complete information translation may be based. The use cases below describe some of these building blocks.
4.3.1 Code Transformation
Perhaps the simplest situation in mediation is that of two different systems using different coding schemes to represent identical information. While there may not necessarily be a 100% mapping in either direction, it is possible to supply the terminology service with a code, a source coding scheme, a target coding scheme, and, optionally, a specific value domain and have the service transform the code from the source code into the target code. Example: an external system may encode all of the coded values in a message (e.g., gender, location, laboratory test identifier, etc.) as positive integers, with each domain beginning at the number 1. In this case, each of the specific value domains represents a separate coding scheme. For example, the gender coding scheme might represent “Male” with a 1, “Female” with a 2, etc. Similarly, the system might encode laboratory tests with “Serum Creatinine” as 1, “Serum Chloride” as 2, etc. In this situation, it is possible to construct a cross-scheme mapping which transforms the gender coding scheme above into the HL7 Table 1 coding scheme and transforms the laboratory test scheme above into the LOINC coding scheme.
4.3.2 Code Mapping
It is not uncommon for two different systems to use different coding schemes to represent
similar information. In this situation, there may not be exact alignment between the codes.
Also, a code within one system may represent more specific information than a code in another system. In certain situations, the user may determine that this imprecision is acceptable and may use the terminology service to determine the closest match for a given code between systems.
4.3.3 Structural Composition/decomposition
Some terminology systems provide the capability to represent a concept as a set of related concepts within the same coding scheme. This provides the rudiments of the capability to change the structural representation of a concept between databases. A simple example of this situation might appear in the representation of a urine drug screen. One system may treat this test as a set of {drug, result} tuples, with the domain of drug being
{Amphetamines, Cannabinoids, Cocaine, Methamphetimines, …} and the domain of result being {pos, neg}. A second system might treat the test as a set of domains {AmphetimineUrineScreen, CannabinoidsUrineScreen, CocaineUrineScreen,…}, with each domain having a {pos, neg} value set. A third system might treat the same test as a
set of {drug}, where the presence of a drug in the list implies a positive result.
There are countless variations on this theme, and while a terminology service may assist in these transformations, the ability to do this sort of transformation is still well outside the scope of this submission.
Note: See section 4.6, Composite Concept Manipulation scenario for more detail.
4.3.4 Field Validation
Verify that a specific presentation is a valid value for a specific domain within a domain usage context.
Note: See section 4.1.7, Field Validation for more detail
4.4 Indexing and Inference
The presence of coded information within a computerized system provides an opportunity to augment the system with “decision support” software. This class of software examines information entering the system, looking for situations which may warrant additional action, such as posting alerts, generating additional data, etc. One example of such a system is a drug/drug interaction monitor that examines all incoming drug orders looking for potential adverse reactions with current patient medications.
This type of software can use terminology services to make “inferences” about information in incoming records and to assist in locating information in existing databases. These cases are described below.
4.4.1 Relationship
Inquiry
Decision support programs are often written in terms of classes of concepts and they must be able to inquire about associations between various classes. For example, a particular module may be written to scan new drug orders looking for drugs that belong to the class or classes recorded in patient allergy records. A patient allergy record might contain the fact that the patient is allergic to Penicillin. The decision support program would supply the code for an ordered drug (e.g., Pen-VK) to the terminology service, along with its allergy class (e.g., Penicillin) and ask the service whether a “hasSubtypes” relationship exists between these entities. If the response is TRUE, the application would then take appropriate action to warn the patient or pharmacist of the potential problem.
4.4.2 Data Element Location
A decision support application might need to locate existing information in a database based on some classification scheme. If we extend the example above, a second decision support program might be written to examine all patient allergy entries. If a record is entered showing the patient to be allergic to Penicillin, the decision support program might wish to scan the database looking for all references to orders for Penicillin.
