3m_culpepper_position

Experience with Creating a Prototype for a Medical Terminology System Coupled with Terminology Services for use in a

Distributed Object Computing Environment

Position Paper Presented by: Thomas C. Culpepper 3M Health Information Systems 575 West Murray Blvd. Murray, Utah 84123-4611 801 265 4534 801 263 3553 Fax tcculpepper@wpmail.code3.com

Contents

Introduction . . . . . . . . . 3

Why a Standard Terminology Interface . . . . . . 4

Drive to use Object-Oriented Technology . . . . . . 5

Why a Distributed Object Computing Environment . . . . . 8

Conclusion . . . . . . . . . 10

References . . . . . . . . . 14

Endnotes . . . . . . . . . 15

Introduction

This position paper deals with our experiences in the creation of a prototype for a terminology system coupled with terminology services to be used in a Distributed Object Computing (DOC) environment. Our decision to create the prototype was driven from three fronts.

· First, we believed there existed a need to develop a standard terminology interface in an effort to more widely disseminate the use of terminology services.

· Second, we were interested in understanding the ramifications of utilizing an object-oriented technology approach in accomplishing such a task.

· Third, we wanted to develop this prototype utilizing DOC to demonstrate the viability of a distributed environment and also identify the benefits that a terminology system coupled with terminology services could provide in linking disparate systems.

Each area is discussed below identifying the factors that were taken into account in order to assist in our decision phase. The CONCLUSION section at the end of the paper outlines the PROS, the CONS, and the ISSUES.

Why a Standard Terminology Interface

Because we live in a world where human languages structurally make the communication of information a complex problem, we must look at how to address this problem before we can begin to hope for meaningful and unambiguous information exchange. The field of terminology is looking at assisting in this endeavor. The word terminology is often used to refer to a specialized subset of language, and terminology processing focuses on the computerized "understanding" of the specialized language of a field of knowledge. Terminology assists in the ability to manage information efficiently, acquire ongoing knowledge, provide adequate configuration management, manage products, and disseminate information unambiguously.

The medical domain provides a good example of the difficulty of managing data without adequate terminology, given the large number of disparate terminologies in use today, such as: The International Classification of Diseases: 9^th revision, Clinical Modification (ICD-9-CM)¹, Medical Subject Headings (MeSH)¹, Systemized Nomenclature of Human and Veterinary Medicine (SNOMED)¹, Physicians Current Procedural Terminology (CPT-4)¹, and Logical Observation Identifier Names and Codes (LOINC)¹. There are also countless ad hoc terminology systems developed as proprietary solutions to specific problems. Recent pushes for an electronic medical record, along with the demand for integration of many previously disparate computerized medical systems, has begun to expose the differences in approach, functionality, and content between these various systems. Frequently, information in one terminology system cannot be recognized by other systems, thereby hindering the ability to integrate component applications into larger systems.¹ The following example appears in a conference paper entitled Desiderata for Controlled Medical Vocabularies in the Twenty-First Century:

Consider, for example, how a computer-based medical record system might work with a diagnostic expert system to improve patient care. In order to achieve optimal integration of the two, transfer of patient information from the record to the expert would need to be automated. In one attempt to do so, the difference between the controlled vocabularies of the two systems was the major obstacle-even when both systems were created by the same developers.²

Given the wide variety in the purpose and scope of different systems it is unlikely that a single universal vocabulary could be agreed upon for each type of content-be it telecommunications, insurance, healthcare, defense, or any other content area that is dependent on a wide range of terms and yet requires clarity of communication. However, a common means of accessing information across different terminology systems would go a long way toward resolving the problems inherent in using disparate systems.

Consequently, we focused on modeling a standard terminology interface. We have done so in a fashion that will allow vocabularies to evolve independently of the interface definition, with the interface definition itself evolving at controlled intervals.

Drive to use Object-Oriented Technology

The submission and prototype were developed utilizing a wide breadth of object-oriented technologies.

First, however, we had to develop a vision, a long-term outlook and our goals for wanting to utilize object-oriented technology-each of which had their own influencing factors. Once these steps were completed, we focused on the architecture.

The architecture was divided into three basic areas; the model, the platform and the tools-all encompassed in a DOC environment or a driving force for utilizing a DOC environment. Our vision, long-term outlook and goals assisted us in making the necessary technological decisions.

Vision

Utilizing Object-Oriented Technology (OT) as an engineering practice we can design and develop reusable components, which, in turn, allows us to produce higher quality, more timely solutions to help us meet our business needs.

Influences for our vision:

1. Utilization of object-oriented design to combat complexity.

2. Cost-effective technology.

3. Large success in our industry.

4. Risk could be reduced to an acceptable level due to the availability of sufficient knowledge and tools.

5. Availability of pertinent operating systems.

6. Reusable component packages, such as libraries

7. Case tools that support the OO Development Life-Cycle

8. Training and mentoring availability.

9. Standards being developed by several standards organizations, e.g., OMG, IEEE, ANSI, ISO, HL7.

10. Seamless integration of distributed objects for heterogeneous systems.

Long-term outlook

Software development has progressed from complex monolithic applications to structured design. We believe OT will advance us toward greater software reliability, greater development effectiveness and greater functionality. Consequently, by embracing OT as an engineering practice, we maintain our place in the software development evolutionary process.

Influences for our long-term outlook:

1. With the advent of SIMULA in the mid 1960's; which introduced classes and data abstraction, the move to OT was beginning.

2. Smalltalk evolved in the mid/late 1970's; in the early 1980's other object-oriented languages followed.

3. Large-scale development began to utilize OT in the late 1980's because traditional methods either failed or were failing and because the emergence of sound C++ development environments were occurring.

4. OT's acceptance has exploded since the mid 1980's. It is now available with complete development environments, numerous commercial libraries, a large set of supporting tools for object-oriented development, as well as the development of standards.

Goals

In the absence of clearly defined goals, we are forced to concentrate on activity and ultimately become enslaved by it.

--Chuck Coonradt

With this in mind, we outlined the goals we wanted to achieve.

1. We wanted to understand how Object-Oriented Analysis/Design could help developers cope with the increasing complexity of software systems.

2. We wanted to understand how Object-Oriented Programming can help the developers of complex systems overcome the limitations of conventional procedural programming paradigms.

3. We wanted to understand how an Object-Oriented Database differs from a Relational Database, and how those differences may allow us to provide the highest possible performance in managing our complex systems.

Influences for goals:

1. Create an Analysis Model that was close to what the domain experts understood but also could be expressed in the terminology of object concepts.

2. Utilize an object-oriented programming language that supports the basic object concepts; encapsulation, polymorphism, and inheritance. Encapsulation provides the ability to control visibility in a flexible manner. Polymorphism provides flexibility in making it possible to send the same message to different objects and elicit a distinct but semantically similar response from each. Inheritance promotes behavior reuse and object substitution.

3. The retrieval and organizational structure of the data elements potentially could become large and complex, which, in turn, may render relational technology inadequate in its ability to perform adequately and at the same time minimize the proliferation of redundancy.

Architecture

1. Model

FACTORS:

· Exploit the power of object-oriented programming languages

· Encourage the reuse of software and design

· Develop a system more resilient to change

· Reduce the risk of developing a complex system

· Appeals to human cognition

These factors drove us to look at designing in an object-oriented foundation, whose elements are called an object model. The object model encompasses the principles of encapsulation, polymorphism, and inheritance. The basic building blocks of the object model are classes and objects. Consequently, we needed a modeling language that we could use to express classes and objects in a meaningful way. There were several choices for modeling languages, however, because of the joint development of the Unified Modeling Language (UML) by Grady Booch, Ivar Jacobson and Jim Rumbaugh and their evolutionary approach to object-oriented analysis and design, we chose to use their modeling language.

2. Platform

FACTORS:

· Impact on current development

· Availability

· Cost of development

In order not to impose prototyping efforts on our existing development environment, we decided to utilize an existing workstation. It was available and it had been used to develop existing products as well as prototypes.

The original machine used to develop the prototype was an HP Vectra 90MHz Pentium, 4gig drive, 48MB RAM.

Today the prototype is working on a Gateway 9100XL 266MHz Pentium II Processor, 5GB, 64MB

We were also concerned with developing in an environment that would offset some of the development costs associated with larger systems. For example, development costs may include object-oriented development tools, On-Line Transaction Processing (OLTP) tools, persistent store development and maintenance, operating costs, enhancement costs and maintenance costs.

3. Tools

FACTORS:

· Availability

· Capability

· Cost

Modeling tool:

Because we chose an object model and made the decision to utilize UML as the object modeling language, we needed a tool that could express UML. We chose Rational Rose, primarily because its founders were the chief architects of UML. In the beginning we downloaded a trial copy from the Internet and later purchased a full copy. The trial copy gave us the confidence that this tool would help us succeed in our endeavor.

Client, server tool:

In order not to incur any additional costs, we decided to utilize Visual C++ 5.0 since it was already on the workstation and there was no need to become trained in another environment. Although Visual C++ is arguably not a pure object-oriented language, it provided us the necessary functionality to perform our task. Visual C++ was used to create the TF-Manager, TF-Server, and TF-Client. In the case of the TF-Manager and TF-Client, the user interface was also developed in Visual C++.

Persistent store:

Object Design's ObjectStore was also available on the workstation and familiarity and usage were already gained. It provided us with the ability to offer a scheme that could operate on the object model and at the same time provide seamless integration into the Terminology Framework.

Object Request Broker (ORB):

HP OrbPlus 2.5 Object Request Broker (ORB) was available free of charge for a limited time and was used in the early stages. Once the final update to the specification was completed, a change to Orbix was made in order to utilize a supported product. The ORB product provided us the ability to generate IDL and the necessary stubs and skeletons to implement the LQS specification.

Why a Distributed Object Computing

Environment

The DOC environment could certainly have been included in the Drive to use Object-Oriented Technology section but it was felt that it deserved a section unto itself.

In making a decision to use DOC we first considered the risks of not using DOC and then came up with the benefits for using DOC to see if the benefits would outweigh the risks. We then made our decisions for which DOC to use.

Risks of not utilizing a DOC environment

Healthcare is not unique to the need for informational sharing, it is however one where the complexity of information between disparate groups proves a good test bed. We also believe that by not utilizing a DOC environment in an enterprise setting such as healthcare, the following ramifications will include:

1. Redundancy throughout an enterprise.

2. Latency in the ability to provide timely extensibility.

3. Maintainability problems.

4. Manual deployment.

5. Development lag.

Perceived Benefits

The following outlines some of the benefits that we perceived that a DOC environment could provide:

1. Ability to reuse existing products that have been through the Development Life Cycle.

2. Utilize components.

3. Allows for the use of existing infrastructures.

4. Allows for the concentration of efforts in order to get the correct information to the correct people without manual mechanisms being involved.

5. Minimizes the costs of having duplicate copies of information located at each site.

6. Standard interfaces are available.

7. Standard services are available.

8. Standard interfaces coupled with a thin layer of wrapper code bring legacy applications into the environment.

9. Maximizes programmer productivity.

10. Allows for code reuse.

11. Allows user to mix and match tools within a project.

Choice of a DOC Environment

We organize ourselves around voluntary commitments.

--W.L. Gore

FACTORS:

· Industry-wide input and acceptance

· Utilize existing DOC technologies

· Enterprise interoperability

Because we believed there existed a need to develop a standard terminology interface, we also believed there was wide spread knowledge about terminology as well as many efforts in the development of tools for terminology. Consequently, to ensure that we acquired industry-wide input and acceptance, we chose to respond to an RFP issued by the Object Management Group (OMG) CORBAmed Domain Tasks Force for a Lexicon Query Service (LQS) specification. This allowed us a necessary forum for suggestions and advice from industry and academic experts.

The OMG has developed the Object Management Architecture (OMA) which is a multivendor standard for DOC. This includes CORBA-the Component Object Request Broker Architecture that provided us with a DOC environment. In 1991 CORBA 1.1 was introduced and defined the Interface Definition Language (IDL) and the Application Programming Interfaces (API) required by an ORB to enable an object-oriented implementation of a client/server paradigm. In December 1994, the CORBA 2.0 specification was adopted which specified the interoperability layer between ORB vendor products thus allowing different ORB vendor products to interact in a the distributed world. The success of CORBA in the following domains made it a more intriguing DOC environment to test the waters of our prototype:

· Advertising/Marketing

· Aerospace/Defense

· Banking/Finance

· Chemical/Petrochemical

· Electronic Commerce

· Government

· Healthcare/Insurance

· Manufacturing

· Publishing/Multimedia

· Real Estate

· Research

· Retail

· Software Companies

· Telecommunications

· Transportation

· Utilities

The ORB exists as the middleware-it establishes the relationships needed for the client and server to communicate in a DOC environment. The ORB handles the necessary responsibility of locating the correct object, passing the parameters, invoking methods and returning results. It does so which out regard for the object's programming language, its operating system or platform. Consequently, because many enterprises consist of multiple applications (developed in multiple languages), multiple operating systems and multiple platforms this type of enterprise interoperability made the CORBA/ORB DOC appealing.

Conclusion

As we designed the specification and developed the prototype, we became convinced of the power that a terminology system coupled with a terminology service interface could bring to the medical domain. In addition, we attained a better understanding of the benefits that object-oriented technology could provide. Finally, we ascertained a better understanding of how a standardized DOC environment could solve many of today's legacy problems, how it could be utilized to exchange information between disparate systems, as well as how it could provide an environment that was developer friendly.

Drive to use Object-Oriented Technology

Architecture

1. Model

PROS:

· With the object model we were able to define the essential characteristics of a particular object, This, in turn, gave us the necessary conceptual boundaries we needed in conveying or implementing the model, depending on perspective. We were also able to hide the details of an object that were not essential to its characteristics.

· As we developed the model we began to see patterns and could place where the model could be simplified through inheritance, which resulted in a time savings as well as providing a more robust model.

· The model helped drive applicable solutions and tool sets.

CONS:

· There tends to be more work devoted to the modeling effort in terms of gathering requirements, soliciting constructive feedback, identifying classes and objects, characteristics of objects, relationships between objects, and the behavioral characteristics of objects.

ISSUES:

· Does it meet all the needs of the problem space?

2. Platform

PROS:

· Developer control. The ability to install new releases of tools at random made for a more efficient mode of operation.

· Less costly development. The development tools as well as the ORB tools are considerably less expensive.

· Portable relocation of the prototype.

· Graphical User Interface tools supplied by the ORB vendor made the management of registering objects and monitoring a running CORBA-based application much easier.

CONS:

ISSUES:

· Can a Windows NT environment scale in a large enterprise environment?

· Configuration and scalability of the operating system.

3. Tools

Modeling tool:

PROS:

· Rational Rose gave us a graphical component modeling and development tool that enabled us to model a terminology system that assisted in meeting the current business needs for designing and developing a terminology service.

· UML allowed us to capture and drive the model. Use cases were used to capture the requirements as well as define the business rules. Class modeling was used to define the business objects and application architecture. The object model was used to define the behavior required by the various classes and ensure that the use cases and business rules were supported correctly.

· UML has been adopted by the OMG as a standard which will increase the number and usability of tools and encourage the development of add-ons. This, in turn, means that existing models in UML will not become obsolete in the future.

CONS:

· Utilizing a modeling tool requires a commitment from developers, managers, and users.

ISSUES:

· Modeling tools are not a substitute for hard work and collaboration.

· Modeling tools do not magically insert themselves into the development process-they require a behavior change. Developers must focus on using the model as the blueprint for development, managers need to focus less on getting the code cut and more on learning to value the model and, of course, users must be involved.

Client, server tool:

PROS:

· Ability to build new objects by making incremental modifications to existing ones without having to re-code the parts that already work.

· Components get reused as-is in new or dynamically reconfigured applications. (See CONS)

CONS:

· Unless you pay very close attention to the development of the server, you will render code-reuse and or component reuse non-existent on any platform besides a Windows platform. This is especially true when developing the user front-end in Visual C++ since it is tightly coupled to the Microsoft Foundations Class (MFC).

ISSUES:

· Explore the use of Java as a client while using C++ for the server.

Persistent store:

PROS:

· Because we used an object model and consequently developed with OT we had the ability to access objects in the server that were also stored in the database thereby eliminating any conversion programming. Conversion programs between a relational model and an object model exist because the relational model doesn't match any programming language model. It is necessary to use either embedded Structured Query Language (SQL) or a Call Level Interface API. Further complications exist in the maintenance of conversion code as the data model evolves.

· The ability to utilize standard C++ language constructs to query and manipulate objects from the database meant we would not need to undergo further training in a new query language.

· Ability to import an existing database scheme into the server eliminated the need for redundant programming.

· Object Oriented Database Management System (OODBMS) architecture allowed us an easy way to develop the complex informational model. There also existed a robust set of inter-relationship objects which could be utilized to structure the necessary relationships in the scheme and manipulate them in the programming language.

CONS:

· Acceptance of OODBMS over Relational Database Management System (RDBMS).

ISSUES:

· Object model capacity.

· Importance of object language bindings.

· OODBMS or RDBMS will depend on user's application.

Object Request Broker (ORB):

PROS:

· The use of CORBA IDL provided us with data encapsulation, polymorphism and inheritance.

· Code-generation of server skeletons and client stubs expedited the implementation development of both the client and the server.

· The ability to run a server from a different machine in a different location from the client made the realization that DOC was a reality. Also, it gave us a better understanding of how an ORB could be used to provide a link to legacy systems while making the migratory move to a more fully compliant DOC environment.

CONS:

· The potential lag time for ORB vendors to add new specifications to their product line.

ISSUES:

· ORB's and OLTP monitors distinguishing features have become fuzzier with time. Consequently, we need to pursue the issues of using an ORB transaction tools such as IONA's Object Transaction Monitor (OTM) in order to attain a better understanding of the similarities, dissimilarities and advantages and disadvantages that may exist for developing in a DOC enterprise environment.

· Scaling and configuration of the ORB needs to be looked at more closely including:

Threading.

Concurrency.

Load balancing.

Why a Distributed Object Computing Environment

PROS:

· Information could be accessed in an unambiguous fashion in an environment that allows disparate systems to communicate.

· Allows us the ability to concentrate on the problem space rather than on the underlining technology.

· Standardized architecture improves development quality, costs, and effort.

· Legacy integration can be a reality.

· Maximized programmer productivity through the use of a sophisticated base and seamless integration through transparent distribution.

· Interoperability results because clients on one platform know how to invoke standard operations on objects on any other platform regardless of programming languages, platforms or operating system.

CONS:

· Mindset change.

· Possible change in costing structures.

· Desire to utilize specifications that are not yet mature.

ISSUES:

· The specification is tied to a technology-is this good or bad?

· Integration pertaining to the co-existence with the Distributed Component Object Model (DCOM) from Microsoft needs to be investigated and potentially prototyped.

References

3M and MCC. Mediated Terminology for Interoperable Systems. A proposal submission in response to the Advanced Technology Program of the National Institute of Standards and Technology Administration 98-01. March 1998.

Booch Grady. Object Oriented Design with Applications. The Benjamin/Cummings Publishing Company, Inc.: 1991.

Cattell R.G.G. The Object Database Standard:ODMG-93. Morgan Kaufmann Publishing, Inc.: 1996.

Coonradt Charles A. with Nelson Lee. The Game of Work. Shadow Mountain: 1985.

Goldberg Adele, Rubin Kenneth S., Succeeding with Objects Decision Frameworks for Project Management. Addison-Wesley Publishing Company, Inc. : 1995.

Mowbray Thomas J., Malveau Raphael C. CORBA Design Patterns. Wiley Computer Publishing: 1997.

Object Management Group (OMG). http://www.omg.org/

Siegel Jon. CORBA Fundamentals and Programming. Wiley Computer Publishing Group: 1996.

Stroustrup Bjarne. The Design and Evolution of C++. Addison-Wesley Publishing Company, Inc. : 1994.

Endnotes

Cimino JJ. "Desiderata for Controlled Medical Vocabularies in the Twenty-First Century." Conf. On Natural Language and Med. Concept Rep. Preprint 1997:1.

Cimino JJ, summarizing the findings of Wong ET, Pryor TA, Huff SM, Hau PJ, Warner HR. "Interfacing a stand-alone diagnostic expert system with a hospital information system." Comput Biomed Res. 1994;27:116-129.