corbamed/97-01-04 Object Management Group Framingham Corporate Center 492 Old Connecticut Path Framingham, MA 01701-4568 Telephone: +1-508-820 4300 Facsimile: +1-508-820 4303 Lexicon Query Services Request For Proposal OMG Document: corbamed/97-01-04 Submissions due: September 1, 1997 Objective of this RFP This RFP solicits proposals for specifications of IDL interfaces for the common features of a set of lexicon query services. This RFP describes the requirement for services to support lexicons (controlled terminology resources) in a distributed object system conforming to the OMA.. Despite many efforts over the years, the ability to consistently and precisely represent information, such as observational and historical data in healthcare, has eluded the industry. This ability to represent a concept in an unambiguous machine-readable format is key to the better management of clinical processes within a healthcare organization, and between a healthcare organization and its various trading partners. The ability to support a discrete Lexicon Query Services RFP January 17, 1997 1 corbamed/97-01-04 coded lexicon is of critical importance within the healthcare business segment. It is the first step towards being able to: . Better manage the communication of information between disparate organizations . Support the collection and analysis of clinical processes and outcomes as a result of consistent and clinically specific encoding . Enable the use of sophisticated rule-based 'decision support' tools, which require consistent data representation to be effective. For example, the rule: If the order is for any drug in the category antibiotics and there is a history of allergy to any antibiotic, send an alert regarding possible cross-allergic reactions requires the ability to classify all antibiotics under a single 'parent' in a specified hierarchy to assure that no matter what drug is ordered, if it is in the category antibiotics, this rule is triggered. . Assist in the reporting of information to various interested parties in a consistent manner It is important to make the distinction between the lexicon content (i.e., the _vocabularies_ themselves), and the methods to support lexicon queries and functions. In fact, we should not assume that the lexicon query services defined through this effort are necessarily limited to support of a health lexicon/domain of content. It may be the case that these services are a requirement across other domains/task forces within OMG. It is anticipated that responses could be received from vendors who provide similar services outside of the healthcare arena. However, since the primary interest and critical, near term need resides within the healthcare domain, CORBAmed has taken the lead the effort to define these services. Lexicon Query Services RFP January 17, 1997 2 corbamed/97-01-04 Lexicon Query Services RFP January 17, 1997 3 corbamed/97-01-04 1.0 Introduction 1.1 Goals of OMG The Object Management Group (OMG) is the world's largest software consortium with a membership of over 600 vendors, developers, and end users. Established in 1989, its mission is to promote the theory and practice of Object Technology (OT) for the development of distributed computing systems. A key goal of OMG is create a standardized object- oriented architectural framework for distributed applications based on specifications that enable and support distributed objects. Objectives include the reusability, portability, and interoperability of object-oriented software components in heterogeneous environments.To this end, the OMG adopts interface and protocol specifications, based on commercially available object technology, that together define an Object Management Architecture (OMA). 1.2 Organization of this document The remainder of this document is organized as follows: Chapter 2 - Architectural Context - background information on OMG's Object Management Architecture. Chapter 3 - Adoption Process - background information on the OMG specification adoption process. Chapter 4 - Instructions for Submitters - explanation of how to make a submission to this RFP. Chapter 5 - General Requirements on Proposals - requirements and evaluation criteria that apply to all proposals submitted to OMG. Chapter 6 - Specific Requirements on Proposals - problem statement, scope of proposals sought, mandatory and optional requirements, issues to be Lexicon Query Services RFP January 17, 1997 4 corbamed/97-01-04 discussed, evaluation criteria, and timetable that apply specifically to this RFP. Additional RFP-specific chapters may also be included following Chapter 6. Lexicon Query Services RFP January 17, 1997 5 corbamed/97-01-04 1.3 References The following documents are referenced in this document: Richard Soley (ed.), Object Management Architecture Guide, Third Edition, Wiley, June 1995. The Common Object Request Broker: Architecture and Specification, Revision 2.0, July 1995. CORBAservices: Common Object Services Specification, Revised Edition, March 1995. CORBAfacilities Architecture, Revision 4.0, November 1995. Business Committee RFP Attachment, OMG Document omg/96-01-01. Policies and Procedures of the OMG Technical Process, OMG Document pp/96-12-01 or successor. These documents can be obtained by contacting OMG at document@omg.org. Many OMG documents, including this document, are available electronically from OMG's document server. Send a message containing the single line _help_ to server@omg.org for more information. For more information about OMG visit OMG's Web page (URL http://www.omg.org/). If you have general questions about this RFP send email to responses@omg.org. Lexicon Query Services RFP January 17, 1997 6 corbamed/97-01-04 2.0 Architectural Context 2.1 Object Management Architecture The Object Management Architecture Guide (OMAG) describes OMG's technical objectives and terminology and provides the conceptual infrastructure upon which supporting specifications are based. The guide includes the OMG Object Model, which defines common semantics for specifying the externally visible characteristics of objects in a standard implementation-independent way, and the OMA Reference Model. The Reference Model identifies and characterizes the components, interfaces, and protocols that compose the OMA. This includes the Object Request Broker (ORB) component that enables clients and objects to communicate in a distributed environment, and four categories of object interfaces: _ Object Services are interfaces for general services that are likely to be used in any program based on distributed objects. _ Common Facilities are interfaces for horizontal end-user-oriented facilities applicable to most application domains. _ Domain Interfaces are application domain-specific interfaces. _ Application Interfaces are non-standardized application-specific interfaces. A second part of the Reference Model introduces the notion of domain-specific Object Frameworks. An Object Framework component is a collection of cooperating objects that provide an integrated solution within an application or technology domain and which is intended for customization by the developer or user. Through a series of RFPs, OMG is populating the OMA with detailed specifications for each component and interface category in the Reference Model. Adopted specifications include the Common Object Request Lexicon Query Services RFP January 17, 1997 7 corbamed/97-01-04 Broker Architecture (CORBA), CORBAservices, and CORBAfacilities. The wide-scale industry adoption of OMG's OMA provides application developers and users with the means to build interoperable software systems distributed across all major hardware, operating system, and programming language environments. 2.2 CORBA The Common Object Request Broker Architecture defines the programming interfaces to the OMA ORB component. An ORB is the basic mechanism by which objects transparently make requests to - and receive responses from - each other on the same machine or across a network. A client need not be aware of the mechanisms used to communicate with or activate an object, how the object is implemented, nor where the object is located. The ORB thus forms the foundation for building applications constructed from distributed objects and for interoperability between applications in both homogeneous and heterogeneous environments. The OMG Interface Definition Language (IDL) provides a standardized way to define the interfaces to CORBA objects. The IDL definition is the contract between the implementor of an object and the client. IDL is a strongly typed declarative language that is programming language-independent. Language mappings enable objects to be implemented and sent requests in the developer's programming language of choice in a style that is natural to that language. CORBA 2.0 is an extension and restructuring of the earlier CORBA 1.2 specification. CORBA 2.0 is a family of specifications consisting of the following components: _ Core (including IDL syntax and semantics) _ IDL C language mapping _ IDL C++ language mapping _ IDL SmallTalk language mapping (added in 1995) Lexicon Query Services RFP January 17, 1997 8 corbamed/97-01-04 _ IDL Ada'95 language mapping (added in 1996) _ Interoperability Each component is a separate compliance point. The minimum required for a CORBA-compliant implementation is adherence to the core and one language mapping. 2.3 CORBA/Interoperability Interoperability between CORBA-compliant ORBs is provided by OMG's Internet Inter-ORB Protocol (IIOP). Adopted in December 1994 as the mandatory CORBA 2.0 protocol for _out of the box_ interoperability, IIOP is the TCP/IP transport mapping of a General Inter-ORB Protocol (GIOP). IIOP enables requests to be sent to networked objects managed by other ORBs in other domains. The OMG interoperability architecture also accommodates communication using optional Environment- Specific IOPs (ESIOPs), the first of which is the DCE- CIOP. 2.4 CORBAservices Object Services are general purpose services that are either fundamental for developing useful CORBA-based applications composed of distributed objects, or that provide a universal - application domain-independent - basis for application interoperability. Object Services are the basic building blocks for distributed object applications. Compliant objects can be combined in many different ways and put to many different uses in applications. They can be used to construct higher level facilities and object frameworks that can interoperate across multiple platform environments. Adopted OMG Object Services are collectively called CORBAservices and include Naming, Events, LifeCycle, Persistent Object, Relationships, Externalization, Transactions, Concurrency Control, Licensing, Query, Properties, Security, Time, Collections, and Trading Services. Lexicon Query Services RFP January 17, 1997 9 corbamed/97-01-04 2.5 CORBAfacilities Common Facilities are interfaces for horizontal end- user-oriented facilities applicable to most domains. Adopted OMG Common Facilities are collectively called CORBAfacilities and include an OpenDoc-based Distributed Document Component Facility. A specification of a Common Facility or Object Service typically includes the set of interface definitions - expressed in OMG IDL - that objects in various roles must support in order to provide, use, or participate in the facility or service. As with all specifications adopted by OMG, facilities and services are defined in terms of interfaces and their semantics, and not a particular implementation. 2.6 Object Frameworks and Domain Interfaces Unlike the interfaces to individual parts of the OMA _plumbing_ infrastructure, Object Frameworks are complete higher level components that provide functionality of direct interest to end-users in particular application or technology domains. They are vertical slices down the OMG _interface stack_. Object Frameworks are collections of cooperating objects categorized into Application, Domain, Facility, and Service Objects. Each object in a framework supports (through interface inheritance) or makes use of (via client requests) some combination of Application, Domain, CORBAfacilities, and CORBAservices interfaces. A specification of an Object Framework defines such things as the structure, interfaces, types, operation sequencing, and qualities of service of the objects that make up the framework. This includes requirements on implementations in order to guarantee application portability and interoperability across different platforms. Domain Task Force RFPs are likely to focus on Object Framework specifications that include new Domain Interfaces for application domains such as Finance, Healthcare, Manufacturing, Telecom, Electronic Commerce, and Transportation. Lexicon Query Services RFP January 17, 1997 10 corbamed/97-01-04 Lexicon Query Services RFP January 17, 1997 11 corbamed/97-01-04 3.0 Adoption Process 3.1 Introduction OMG adopts specifications for interfaces and protocols by explicit vote on a technology-by-technology basis. The specifications selected each fill in a portion of the OMA Reference Model. OMG bases its decisions on both business and technical considerations. Once a specification is adopted by OMG, it is made available for use by both OMG members and non-members. For more detailed information on the adoption process see the Policies and Procedures of the OMG Technical Process. 3.2 Role of Board of Directors The OMG Board of Directors votes to formally adopt specifications on behalf of OMG. The OMG Technology Committees (Domain and Platform TCs) and Architecture Board (AB) provide technical guidance to the Board of Directors. In addition, the Business Committee of the Board provides guidance to ensure that implementations of adopted specifications are made commercially available. 3.3 Role of Technology Committees and Architecture Board Submissions to RFPs are evaluated by the TC Task Force (TF) that initiated the RFP. Selected specifications are recommended to the parent TC after being reviewed by the Architecture Board for consistency with the OMA. The full TC then votes to recommend adoption to the OMG Board. 3.4 Role of Task Forces The role of the initiating TF is to technically evaluate submissions and select one or more specifications that satisfy the requirements of the RFP. The process typically takes the following form: _ Voter Registration Lexicon Query Services RFP January 17, 1997 12 corbamed/97-01-04 Interested TF members may register to participate in specification selection votes for an RFP. Registration ends on a specified date 6 or more weeks after the announcement of the registration period. The registration closure date is typically around the time of initial submissions. Companies who have submitted an LOI are automatically registered to vote. _ Initial Submissions Initial submissions are due by a specified deadline. Submitters normally present their proposals at the next following meeting of the TF. Initial submissions are expected to be full and complete proposals and working implementations of the proposed specifications are expected to exist at the time of submission. _ Evaluation Phase A period of approximately 120 days follows during which the TF evaluates the submissions. During this time submitting companies have the opportunity to revise and/or merge their initial submissions, if they so choose. _ Revised Submissions Final revised submissions are due by a specified deadline. Submitters again normally present their proposals at the next following meeting of the TF. Finalists may be requested to demonstrate implementations of their proposal. _ Selection Vote When the registered voters of the TF believe that they sufficiently understand the relative merits of the revised submissions, a specification selection vote is taken. 3.5 Goals of the evaluation The primary goals of the TF evaluation process are to: _ Provide a fair and open process Lexicon Query Services RFP January 17, 1997 13 corbamed/97-01-04 _ Force a critical review of the submissions and discussion by all members of the TF _ Give feedback to allow submitters to address concerns in their revised submissions _ Build consensus on acceptable solutions _ Enable voting members to make an informed selection decision Submitters are expected actively to contribute to the evaluation process. Lexicon Query Services RFP January 17, 1997 14 corbamed/97-01-04 4.0 Instructions for Submitters 4.1 Submission Effort Unlike a submission to an OMG Request For Information (RFI), an RFP submission may require significant effort in terms of document preparation, presentations to the initiating TF, and participation in the TF evaluation process. Several staff months of effort might be necessary. OMG is unable to reimburse submitters for any costs in conjunction with their submissions to this RFP. 4.2 Letter of Intent A Letter of Intent (LOI) must be submitted to the OMG Business Committee signed by an officer of your organization signifying your intent to respond to the RFP and confirming your organization's willingness to comply with OMG's terms and conditions, and commercial availability requirements. These terms, conditions, and requirements are defined in the Business Committee RFP Attachment and are reproduced verbatim in section 4.3 below. The LOI should designate a single contact point within your organization for receipt of all subsequent information regarding this RFP and your submission. The name of this contact will be made available to all OMG members. The LOI is typically due 60 days before the deadline for initial submissions. LOIs must be sent by fax or paper mail to the _RFP Submissions Desk_ at the main OMG address shown on the first page of this RFP. Here is a suggested template for the Letter of Intent: This letter confirms the intent of <___organisation required___> (the organisation) to submit a response to the OMG <___RFP name required___> RFP. We will grant OMG and its members the right to copy our response for review purposes as specified in section 4.6 of the RFP. Should our response be adopted by OMG we will comply with the OMG Business Committee terms set out in section 4.3 of the RFP and in document omg/97-01-01. Lexicon Query Services RFP January 17, 1997 15 corbamed/97-01-04 <____contact name and details required____> will be responsible for liaison with OMG regarding this RFP response. The signatory below is an officer of the organisation and has the approval and authority to make this commitment on behalf of the organisation. <___signature required____> 4.3 Business Committee RFP Attachment Terms and Conditions The OMG Business Committee has produced a document entitled _OMG Policy on Adoption of Specifications_. When reviewing submissions to each RFP, the specific items that the OMG Business Committee will be considering during the selection process are outlined below: _ The optimization of interoperability and portability goals across multiple platforms. _ Commitment by the proposed technology supplier to make the implementation available on commercially reasonable terms, applied in a non discriminatory fashion. _ Submission of a Standard License Agreement and Support plans _ A preferred, but not required, method for achieving multi-platform interoperability is source code licensing. Please include any provisions as such. _ Assurance that the results in the duplication of the _look and feel_ of any aspects of such proponents implementations from specifications will not result in infringement or obligation to pay royalties. _ Plans for future revisions, enhancements, maintenance. _ Agreement to grant to the Object Management Group, Inc., a non-exclusive, royalty-free, paid-up, worldwide license to copy and distribute the Lexicon Query Services RFP January 17, 1997 16 corbamed/97-01-04 specification document and to modify the document and distribute copies of the modified version. Implementations or instantiations of the specifications are owned by the developer.. _ Upon OMG's acceptance of the sponsoring company's interfaces, the sponsoring company agrees to provide all documentation in an OMG prescribed format and in OMG endorsed terminology. Definition of Commercial Availability For technology to be accepted and adopted by the OMG Board Of Directors (reference OMG document tilted _OMG Policy on Adoption of Specifications - 2/12/90_) it must be commercially available within twelve (12) months or less from when the OMG Task Force (prior to the Technical Committee and Board vote) adopted the specification(s). This is required for proof of concept and expedient implementation of actual product and licensing procedures. Commercial availability is delineated as: _ Technology that has been publicly announced as a product or embodied within another product. _ Technology that is of production/manufacturing quality, has cleared a process of product shipment authorization, and can be demonstrated at OMG request (including installation, documentation, service, and support). Demonstrations may be required following RFP presentations to the OMG Technical Committee. _ Technology that can be referenced by at least two (2) consumers (customers) of the technology. A statement of commercial availability must be accompanied by a letter of authorization by an officer of the company proposing the technology. 4.4 Responding to RFP items Separate proposals Unless otherwise indicated in Chapter 6, independent proposals are solicited for each separate item in the RFP. Each item is considered a separate architectural entity for which a proposal may be made. A submitter may respond to any or all items. Each item will be evaluated independently by the initiating TF. Lexicon Query Services RFP January 17, 1997 17 corbamed/97-01-04 Submissions that do not present clearly separable proposals for multiple items may therefore be at a disadvantage. It should be noted that a given technology (e.g. software product) may support two or more RFP items. So long as the interfaces for each item are separable, this is not precluded. Complete proposals Proposals for each separate RFP item must be complete. A submission must propose full specifications for each item and address all the relevant general and specific requirements detailed in this RFP. Additional specifications Submissions may include additional specifications for items not covered by the RFP which they believe to be necessary and integral to their proposal. Information on these additional items should be clearly distinguished. Submitters must give a detailed rationale as to why these specifications should also be considered for adoption. However submitters should note that a TF is unlikely to consider additional items that are already on the roadmap of an OMG TF, since this would preempt the normal adoption process. Alternative approaches Submitters may provide alternative RFP item definitions, categorizations, and groupings so long as the rationale for doing so is clearly stated. Equally, submitters may provide alternative models for how items are provided within the OMA if there are compelling technological reasons for a different approach. 4.5 Confidential and Proprietary Information The OMG specification adoption process is an open process. Responses to this RFP become public documents of the OMG and are available to members and non- members alike for perusal. No confidentiality or Lexicon Query Services RFP January 17, 1997 18 corbamed/97-01-04 proprietary information of any kind will be accepted in a submission to this RFP. 4.6 Copyright Waiver If a submitted document is copyrighted, a waiver of copyright for unlimited duplication by the OMG is required to be stated in the document. In addition, a limited waiver of copyright is required that allows each OMG member to make up to fifty (50) copies of the document for review purposes only. 4.7 Proof of Concept Submissions must include a _proof of concept_ statement, explaining how the submitted specifications have been demonstrated to be technically viable. The technical viability has to do with the state of development and maturity of the technology on which a submission is based. This is not the same as commercial availability. Proof of concept statements can contain any information deemed relevant by the submitter, for example: _This specification has completed the design phase and is the process of being prototyped._ _An implementation of this specification has been in beta-test for 4 months._ _A named product (with a specified customer base) is a realization of this specification._ It is incumbent upon submitters to demonstrate to the satisfaction of the TF the technical viability of their proposal. OMG will favor proposals based on technology for which sufficient relevant experience has been gained in CORBA-based or comparable environments. 4.8 Format of RFP Submissions This section provides guidance on how to structure your RFP submission. Lexicon Query Services RFP January 17, 1997 19 corbamed/97-01-04 General _ Submissions that are concise and easy to read will inevitably receive more consideration. _ Submitted documentation should be confined to that directly relevant to the items requested in the RFP. If this is not practical, submitters must make clear what portion of the documentation pertains directly to the RFP and what portion does not. _ The models and terminology in the Object Management Architecture Guide and CORBA should be used in your submission. Where you believe this is not appropriate, describe and provide a rationale for the models and terminology you believe OMG should use. Lexicon Query Services RFP January 17, 1997 20 corbamed/97-01-04 Suggested Outline A three part structure for submissions is suggested: PART I _ Copyright Waiver (see 4.5) _ Submission contact point (see 4.2) _ Overview or guide to the material in the submission _ Overall design rationale (if appropriate) _ Statement of proof of concept (see 4.6) _ Resolution of RFP mandatory and optional requirements Explain how your proposal satisfies the mandatory and (if applicable) optional requirements stated in Chapter 6. References to supporting material in Part II should be given. In addition, if your proposal does not satisfy any of the general requirements stated in Chapter 5, provide a detailed rationale. _ Responses to RFP issues to be discussed Discuss each of the _Issues To Be Discussed_ identified in Chapter 6. PART II _ Proposed specification PART III _ Summary of optional versus mandatory interfaces Submissions must clearly distinguish interfaces that all implementations must support from those that may be optionally supported. Lexicon Query Services RFP January 17, 1997 21 corbamed/97-01-04 _ Proposed compliance points Submissions should propose appropriate compliance points for implementations. _ Changes or extensions required to adopted OMG specifications Submissions must include a full specification of any changes or extensions required to existing OMG specifications. This should be in a form that enables _mechanical_ section-by-section revision of the existing specification. _ Complete IDL definitions For reference purposes and to facilitate electronic usage, submissions should reproduce in one place a complete listing in compilable form of the IDL definitions proposed for standardization. 4.9 How to Submit Submitters should send an electronic version of their submission to the RFP Submissions Desk (rfp@omg.org) at OMG by 5:00 PM U.S. Eastern Standard Time (22:00 GMT) on the day of the submission deadline. Acceptable formats are Postscript, ASCII, FrameMaker, Word, and WordPerfect. Submitters should make sure they receive electronic or voice confirmation of the successful receipt of their submission. Submitters should also send, within three (3) working days after the submission deadline, a single hardcopy version of their submission to the attention of the _RFP Submissions Desk_ at the main OMG address shown on the first page of this RFP. In addition, submitters are responsible for making available 100 paper copies to attendees of the TF meeting immediately following a submission deadline. There are normally two such presentation meetings, one for the initial and one for the revised submissions. Lexicon Query Services RFP January 17, 1997 22 corbamed/97-01-04 5.0 General Requirements on Proposals 5.1 Mandatory Requirements 5.1.1 Proposals shall express interfaces in OMG IDL. Proposals should follow accepted OMG IDL and CORBA programming style. The correctness of the IDL shall be verified using at least oneIDL compiler (and preferably more then one). In addition to IDL quoted in the text of the submission, all the IDL associated with the proposal shall be supplied to OMG in compiler-readable form. 5.1.2 Proposals shall specify operation behavior, sequencing, and side-effects (if any). 5.1.3 Proposals shall be precise and functionally complete. There should be no implied or hidden interfaces, operations, or functions required to enable an implementation of the proposed specification. 5.1.4 Proposals shall clearly distinguish mandatory interfaces and other specification elements that all implementations must support from those that may be optionally supported. 5.1.5 Proposals shall reuse existing OMG specifications including CORBA, CORBAservices, and CORBAfacilities in preference to defining new interfaces to perform similar functions. 5.1.6 Proposals shall justify and fully specify any changes or extensions required to existing OMG specifications. This includes changes and extensions to CORBA inter- ORB protocols necessary to support interoperability. In general, OMG favors upwards compatible proposals that minimize changes and extensions to existing OMG specifications. 5.1.7 Proposals shall factor out functions that could be used in different contexts and specify their interfaces separately. Such minimality fosters re-use and avoids functional duplication. Lexicon Query Services RFP January 17, 1997 23 corbamed/97-01-04 5.1.8 Proposals shall use or depend on other interface specifications only where it is actually necessary. While re-use of existing interfaces to avoid duplication will be encouraged, proposals should avoid gratuitous use. 5.1.9 Proposals shall specify interfaces that are compatible and can be used with existing OMG specifications. Separate functions doing separate jobs should be capable of being used together where it makes sense for them to do so. 5.1.10 Proposals shall preserve maximum implementation flexibility. Implementation descriptions should not be included, however proposals may specify constraints on object behavior that implementations need to take into account over and above those defined by the interface semantics. 5.1.11 Proposals shall allow independent implementations that are substitutable and interoperable. An implementation should be replaceable by an alternative implementation without requiring changes to any client. 5.1.12 Proposals shall be compatible with the architecture for system distribution defined in ISO/IEC 10746, Reference Model of Open Distributed Processing (ODP). Where such compatibility is not achieved, the response to the RFP must include reasons why compatibility is not appropriate and an outline of any plans to achieve such compatibility in the future. 5.2 Evaluation criteria Although the OMG adopts interface specifications, the technical viability of implementations will be taken into account during the evaluation process. The following criteria will be used: 5.2.1 Performance Potential implementation trade-offs for performance will be considered. Lexicon Query Services RFP January 17, 1997 24 corbamed/97-01-04 5.2.2 Portability The ease of implementation on a variety of ORB systems and software platforms will be considered. 5.2.3 Compliance: Inspectability and Testability The adequacy of proposed specifications for the purposes of compliance inspection and testing will be considered. Specifications should provide sufficient constraints on interfaces and implementation characteristics to ensure that compliance can be unambiguously assessed through both manual inspection and automated testing. Lexicon Query Services RFP January 17, 1997 25 corbamed/97-01-04 6.0 Specific Requirements on Proposals 6.1 Problem Statement Today, there are many different lexicons, which have been developed over time to serve different purposes (research, diagnosis coding, procedure coding, bibliographical indexing, observation reporting, multilingual translation, etc.). None is a single, comprehensive view that supports the needs of all users. A common set of CORBA based lexicon query services will enable access to heterogeneous lexicon implementations. 6.2 Scope of Proposals Sought This RFP requests responses which address the ability to query information related to a concept, such as its definition, print representation, synonyms, translation, or parent/child relationship with other concepts. These are examples of the attributes and relationships (see section 6.9.1 for definition of these terms), which may be used to describe a particular concept. It is suggested that the reader review the definitions prior to review of the requirements statement to better understand the context in which these terms are used. The intended use of this service is users or applications requiring access to common representation of coded data, or access to multiple sources of lexicon content 6.3 Relationship to Existing OMG Specifications . CORBA Security- Even though this RFP does not ask for responses in an area that contains highly confidential information, concerns exist nonetheless regarding patient confidentiality in the healthcare domain. It is expected that proposals will use CORBA Security as required.. . CORBA Event Services- There may be situations where applications need to be notified of changes to the lexicon (for example, where some or all of the lexicon is cached on multiple servers). In this scenario, use of the CORBA Event Services may be required. Lexicon Query Services RFP January 17, 1997 26 corbamed/97-01-04 . CORBA Naming Services- It is possible that the CORBA naming services may be used to support the creation of `registered' names for various well known lexicons. . CORBA Relationship Service- There is a potential for overlap between the Lexicon Services' representation of relationships and the CORBA Relationship Services. It is expected that submissions will use the CORBA Relationship Services in the solution where appropriate. . CORBA Property and Query Services- There is a potential for overlap between the Lexicon Services' representation of relationships and the CORBA Property and Query Services. It is expected that submissions will use the CORBA Property and Query Services in the solution where appropriate. . CORBA Interface Repository- Submitter may address the relationship, as appropriate, between the concepts represented by Lexicon Services and the CORBA Interface representations of interfaces to those objects. At the time of issuance of this RFP, the following facilities are in the process of adoption, and it is anticipated that there may be overlap between these facilities and the Lexicon Query Services. Therefore, submitters must be cognizant of this potential overlap and address them in their response . Meta-Object Facility (MOF)- Submitter should address the relationship between the concepts represented by Lexicon Services constructs and the meta-meta-model specifications of the MOF, where appropriate . Business Object Facility (BOF)- Submitter should address the relationship between the concepts represented by Lexicon Services and the meta-model constructs that represent OA&D objects, where appropriate. . Object Analysis & Design(OA&D)- Submitter should address the relationship between the concepts Lexicon Query Services RFP January 17, 1997 27 corbamed/97-01-04 represented by Lexicon Services and the metadata specifications of the BOF, where appropriate. 6.4 Related Documents and Standards [AMH 1993] The American Heritage College Dictionary.Third Edition (1993) [ISO/IEC 11179] Specification and Standardization of Data Elements. Part 1, Working Draft 8. (Sept 1996) [MOSE] CEN/TC251/PT0003/N34 E v4.1d Medical Informatics- Categorial structures of systems of concepts- Model for representation of semantics (June 1995) [Sager 1990] A Practical Course in Terminology Processing,Juan C. Sager (1990) CORBAmed White Paper on Lexicon Query Services and its references ANSI X3L8 ISO/IEC 11179 Draft definitions 6.5 Mandatory Requirements In Section 6.5 and 6.6, we list the mandatory and optional requirements, respectively. The use case scenario is the existence of one or more applications which are 'lexicon aware'. 'Lexicon aware' means that the application is knowledgeable about the presence of a lexicon and the capabilities that it supports. These applications may be communicating among themselves or communicating with the lexicon services to support specific functions. The Proposal shall address the following requirements: 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 Lexicon Query Services RFP January 17, 1997 28 corbamed/97-01-04 the concepts 2. The lexicon query services shall provide a means for retreiving a concise and unique external identifier (unique, over time, within that particular lexicon) for each individual concept. 3. The lexicon query services shall provide a means of retreiving the appropriate attribute value (in the appropriate format) for that concept, depending on the arguments of 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, etc. 4. The lexicon query services shall provide a means of enumerating various named attributes types and/or relationships types which may exist within a lexicon. 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. 6. The lexicon query services shall provide a means of enumerating, for a particular concept, the attributes and/or relationships and their values. 7. The lexicon query services shall provide the ability to allow enumeration of concepts which could potentially be represented by a specified attribute value. 8. The lexicon services shall be able to allow enumeration of concepts which satisfy multiple relationships and/or attribute value combinations. 6.6 Optional Requirements The Proposal may also address the following requirements: Lexicon Query Services RFP January 17, 1997 29 corbamed/97-01-04 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. 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. 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. 6.7 Issues to be discussed The proposals shall address implementation issues of confidentiality and privacy, where appropriate. Proposal may discuss issues related to registration and identification of multiple lexicons. Proposals must discuss application of these services across multiple lexicon domains. The proposals shall establish both the definition of the query, as well as the form of the expected response to the queries. Proposals may include a suggested `minimum data set' for attributes and/or relationships for a concept. 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. Proposals shall also discuss issues related to scalability to enable support of large (hundreds of thousands) of concepts. Proposals shall discuss relationships to other services as identified in section 6.3 (at a minimum). 6.8 Evaluation Criteria Evaluation of proposals will be based on: . Completeness of proposal and ability to address mandatory requirements . Extent to which optional requirements are addressed Lexicon Query Services RFP January 17, 1997 30 corbamed/97-01-04 . Solution must be portable such that it can be implemented on a variety of platforms . The solution must be scaleable so that it can be used to support a simple, flat lexicon structure as well as addressing support for more complex and detailed lexicons. . Proposal must be flexible enough to address the unique requirements of countries and states, as well as of individual enterprises . Extent to which solution is applicable outside of the medical domain 6.9 Other information unique to this RFP 6.9.1 Important Definitions Attribute A characteristic of an object or entity [ISO/IEC 11179] Examples of attributes are: Print name of concept, display name of concept, synonyms of concept, language translation equivalents of a concept. Attributes are used to more fully describe a particular concept. Attribute values can be multi-dimensional and of arbitrary types. Concept A unit of thought constituted through abstraction on the basis of characteristics common to a set of objects [ISO/IEC 11179] Lexicon A stock of terms used in a particular profession, subject or style [AmH 1993] The vocabulary of a language as distinguished from its grammar and construction [ISO/IEC 11179] Lexicon Query Services RFP January 17, 1997 31 corbamed/97-01-04 A controlled vocabulary, arranged in a given order, which includes concepts and the relationships between concepts. Relationship The hierarchical or non-hierarchical s association between two or more concepts. Examples of relationships are: parent/child relationships between concepts, `is caused by', `affecting', `is used in (i.e., to treat)', etc. Relationships are used to link concepts together in some manner. 6.9.2 Examples of usage The following are some examples of queries that might be performed using the lexicon services described above. . Is "high blood pressure" a valid attribute for a concept? . What are the direct subordinate concepts of the concept "antibiotic" using the hierarchical relationship _is-a_? . What concepts could be represented in a printable display by the text _High Blood Pressure_? . What concept corresponds to identifier "333"? . What attribute value is displayed for the concept that corresponds to the identifier _333_ when it displayed for a French speaking physician? . What is attribute value for the concept that corresponds to identifier _333_ when it is printed? . What attribute value is displayed for the concept Lexicon Query Services RFP January 17, 1997 32 corbamed/97-01-04 that corresponds to identifier _333_ when it is displayed on a terminal? . Find lexically equivalent concept for the string 'HBP' (through matching, likeness) . What concept corresponds to the acronym _HBP_? 6.10 RFP Timetable The timetable for this RFP is given below. Note that the TF may, in certain circumstances, extend deadlines while the RFP is running, or may elect to have more than one revised submission step. The latest timetable can always be found in the Member Services section of OMG's Web page (URL http://www.omg.org/) Approx Event or Activity Actual Day Date Preparation of RFP by TF Approval of RFP by Architecture Board Review by TC (_Three week rule_) 0 TC votes to issue January 17, 1997 RFP 60 LOI to submit to RFP due June 17, 1997 120 Initial submissions due September 1, 1997 134 Voter registration closes September 15, 1997 141 Initial submission Week of presentations September 22, 1997 Preliminary evaluation by TF 240 Revised submissions due December 1997 or January 1998 261 Revised submission January 1998 presentations Lexicon Query Services RFP January 17, 1997 33 corbamed/97-01-04 Final evaluation and selection by TF Recommendation to AB and TC Approval by Architecture Board Review by TC (_Three week rule_) 330 TC votes to recommend January 1998 specifications 360 BOD votes to adopt January 1998 specifications Lexicon Query Services RFP January 17, 1997 34