During the 1997 Gulf War, limited means existed to access and share medical information for U.S. service personnel involved in Operation Desert Storm. In 1998, the Presidential Review Directive addressed this problem, directing the development of an interagency architecture for federal health care systems. In response to this directive, the federal agencies responsible for providing health care, namely, the Department of Defense (DoD), the Veteran’s Administration (VA), and the Indian Health Services (IHS) initiated a project called the Government-wide Computer-based Patient Record (GCPR). GCPR allowed for the electronic sharing of existing medical information at health care facilities run by these agencies.
This article addresses key architectural aspects of integration and interoperability encountered during the GCPR project. For a single sign-on system to be implemented, for example, the various security policies and procedures associated with certification and authentication of legitimate system users had to be reconciled. A common mechanism had to be designed to allow access to differing data schemas and record formats. Also, standard interfaces had to be implemented for access and communication across heterogeneous platforms and applications.
Unlike a typical hospital e-record system [7], the GCPR project required the formulation of an architecture that allowed for the sharing and integration of a patient’s e-record among three federal health care agencies. The challenge with this project was to identify a framework allowing the development and documentation of interoperability architecture across the three distinct agencies. Interoperability is the capability of distributed software entities to communicate information in a mutually agreed-upon manner in order to understand and process that information correctly [1]. Some of the interoperability problems the architecture addressed involved:
- Security policies for data access;
- Procedures for user authentication and certification;
- Data schemas and record formats;
- Interfaces for access and intersystem communications; and
- Hardware and software environments.
Architectural Frameworks for Interoperability
A number of architectural frameworks were available for consideration. Examples include the Open Systems Environment (OSE) model from the IEEE; the Federal Enterprise Architecture Framework (FEAF), developed by the Chief Information Officers Council; or the Computer, Communication, Command, and Control for Information Surveillance and Reconnaissance (C4ISR). However, these models do not provide the wide spectrum of viewpoints needed to address the gamut of interoperability concerns. The need for interoperability led to the selection of the Reference Model for Open Distributed Processing (RM-ODP), an ISO standard, as the best suited framework because it spanned the entire gamut of interoperability concerns mentioned here. RM-ODP has been used as a framework for CORBA-based distributed applications management [3].
Benefits of RM-ODP include its independent representation syntax, language of implementation, and underlying transport mechanism. Also, five architectural viewpoints are defined in RM-ODP that address the entire range of interoperability concerns from policies and procedures to engineering solutions: the enterprise, information, computational, engineering, and technology viewpoints. These viewpoints are not layered, but are rather different abstractions on the same system, separating concerns by focusing on specific areas [3].
The enterprise viewpoint defines social and organizational policies in terms of active and passive “objects.” It is a purely functional view of the architecture that sets out the general goals and scope of the project, the entities in the health care domain, and the rules and policies that govern their interaction. The objects taken from the problem domain are grouped into hierarchies and organizations, and given roles in terms of policies. Roles are described in terms of policies governing the behavior of the domain objects. The policies are divided into three main categories: permissions, or allowable actions; prohibitions, or prohibited actions; and obligations, actions that must be performed.
In order to reconcile the differences in permissions, prohibitions, and obligations, the RM-ODP identifies and documents these categories at each of the distributed sites for the three agencies. Use cases have been traditionally used to describe requirements [2], and can be included in the enterprise viewpoint.
The information viewpoint captures the information shared between Open Distributed Processing (ODP) applications in terms of metadata, states, and structures of an object. The information may be static, which covers a particular instance of an object; dynamic, which describes possible state and structure changes to an object; or invariant, which describes properties that must be upheld in an object. Information models and database schemas are generally defined here.
The information viewpoint allows one to define models that represent the attributes of the information exchanges between interagency systems. These attributes are represented in the form of templates used to exchange information between heterogeneous systems. The templates are key to solving the interoperability problem for information exchanges between heterogeneous data stores. Two schemas were developed for the GCPR project: the template metadata schema, and the RIM metadata schema.
The template metadata schema defines tables that describe how data is packaged for transmission between heterogeneous systems. Templates are used to exchange information between interagency systems compliant with the GCPR architecture.
The RIM metadata schema defines tables that process templates to decide how data is logically stored in a persistent state, such as a relational database management system. The purpose of the RIM metadata schema was to create a structure that holds persistent data. In order to implement this data structure, two tables were created: the object table and the relational table. The object table, RIM_Metadata, of type RIM_META_CLASS_TY, is used to insert data. The RIM Metadata Schema consists of object types RIM_ATTRIBUTE_TY, RIM_ASSOCIATION_TY and RIM_META_CLASS_TY, as well as two arrays, RIM_ATTRIBUTE_ARR and RIM_ASSOCIATION_ARR. The relational table, RIM_ROOT, references RIM_META_CLASS_TY and is used to determine the starting point for constructing a graph of objects that represents the actual structure of the object to be implemented.
The GCPR project required the formulation of an architecture that allowed for the sharing and integration of a patient’s e-record among three federal health care agencies. The challenge with this project was to identify a framework allowing the development and documentation of interoperability architecture across the three distinct agencies.
The template metadata schema is derived from the RIM metadata schema. As shown in Figure 1, the template metadata schema consists of object types TEMPLATE_ATTRIBUTE_TY, TEMPLATE_ASSOCIATION_TY and TEMPLATE_CLASS_TY, as well as two arrays, TEMPLATE _ATTRIBUTE_ARR and TEMPLATE _ASSOCIATION_ARR. The TEMPLATE_ROOT object table is used to determine the starting point for constructing a template for the transport of patient data using the CORBA-domain-specific Clinical Observation Access Service (COAS) [6].
In this project, the templates for data structures are written in IDL. The template model (Figure 1) can be converted to graphs of objects. From these graphs, with objects as nodes, one can deduce the COAS transmission data structures, expressed in IDL. Programmers code data structures as a class graph. Figure 2 illustrates a sample class graph (Person) and its associations to other classes. Metadata for templates can be generated in XML Metadata Interchange (XMI) format from the UML models. The XMI forms the persistent definitions read by various interface components [7]. These components know how the data is grouped and organized because they read the XMI in the course of a data retrieval.
The computational viewpoint describes the functionality of ODP applications in a distribution-transparent manner, generally in terms of one or more interfaces an object offers to encapsulate both its private data and processing. The CORBA Interface Definition Language (IDL) is an example of a specification of the computational viewpoint.
The computational viewpoint allows one to address the interface differences among interagency architectural components. In the GCPR project, the computational viewpoint specified the functionality of the components and CORBA services, regardless of where the component resides. From the interoperability perspective, the key to understanding components is through their interfaces. Figure 3 shows a sample diagram identifying the interface components and services of the GCPR interoperability architecture.
For example, the Patient Identification Service (PIDS) is used for unique identification of persons. The COAS specification allows the retrieval of clinical data without the need to know the underlying storage format of the data. The Terminology Query Service (TQS) helps address the major challenge of preserving the meaning of data between sites and organizations that may use different terminology and units of measurement. The TQS supports the translation of terms from one context into another.
The Resource Access Decision (RAD) service is a mechanism for obtaining authorization decisions and administrating access decision policies. It enables a common way for an application to request and receive an authorization decision. The facility is used by security-aware applications.
From the services diagram (Figure 3) one can transition to design details by way of component-level sequence diagrams. They show how the components interact to satisfy the use cases1 defined in the enterprise viewpoint. A use case has one or more sequence diagrams associated with it.
The strength of RM-ODP is that it forces architects to address high-level issues, such as policies and procedures, as well as low-level issues bordering on design activities, such as data formats and object classes.
The engineering viewpoint describes the domain-independent elements of distributed applications that support the software distribution and the general infrastructure. For example, network topology, communication standards, and deployment diagrams for communications, and the security infrastructure are described in this viewpoint.
This viewpoint allows us to address the heterogeneity of hardware and software across all three agencies. In the GCPR project, the engineering viewpoint described the system distribution model for the architecture. It described, for example, the components that make up a GCPR node (workstation or server). This viewpoint defines a set of objects that support communication channels, as well as a set of objects to create engineering structures and define necessary co-locations [4].
In our case, the logical view of the engineering viewpoint covers the basic distribution mechanism, including Object Request Brokers (ORB), Interfaces (IDL),2 communications protocol, the security infrastructure, and models of the low-level system control and logging capabilities.
The ORB portion of the middleware provides everything necessary to facilitate the channels in the information viewpoint of RM-ODP. ORB elements such as the bindings, stubs, object adapters, and the ORB itself provide the necessary engineering to support transparent distribution.
The core technology of the CORBA-based solution presented here is its OMG Object Management Architecture (OMA) backbone [7], which offers much more than just another middleware suite. CORBA and the OMA are the result of over a decade of work by several hundred leading software developers to support the interoperation of distributed software objects. OMA objects are described using IDL, which provides the traditional benefits of object orientation to the interfaces of all elements, regardless of their implementation or deployment strategy.
Connections between CORBA-based solution components and legacy systems can be made in two ways. The preferred way is the security connection using the CORBA security services. It is also possible for the GCPR implementation to issue its own X.509-compliant digital certificates without using CORBA security services. However, since not all of the agencies share a common Public Key Infrastructure (PKI) solution, trust relationships and interoperability issues between the agencies need to be developed before the latter method can be considered.
An example of an engineering view is the physical model showing nodes. Our core concept for fielding the CORBA-based solution is that of the node. The node contains the full suite of hardware and software to perform all required server processing. A node has sufficient hardware/software redundancy to support fail-over response and maximum reliability and availability.
A node benefits from a physical security boundary as well as a localized center for monitoring and detecting intrusion. The amount and location of nodes fielded needs to reflect both the physical proximity and usage patterns of both clients and the heritage data sources.
A logical model of the engineering viewpoint needs to represent the mechanics used to support the distribution without constraining it to a single physical instance. In this section, we provide a component view that represents the engineering side of our CORBA-based solution, rather than the computational side. The focus is on areas unconcerned with the functionality of various medical applications.
The technology viewpoint addresses the specific hardware/software elements of the implemented distributed application. RM-ODP does not provide much guidance or control over this viewpoint, as it tries to remain as technology-independent as possible.
The technology viewpoint in RM-ODP focuses on the technology and products for implementation. In our case, it consisted simply of an inventory of hardware, software, products, and standards used throughout the system.
Conclusion
RM-ODP provided a useful framework for addressing interoperability concerns arising during the development of an interagency architecture for federal health care systems. This framework gives architects the level of detail necessary to address key integration and interoperability issues. Our experience demonstrates that had we selected any other framework, including the popular C4ISR architectural framework, we would have had an extensive design phase for converting the architecture into implementable designs. The strength of RM-ODP is that it forces architects to address high-level issues, such as policies and procedures, as well as low-level issues bordering on design activities, such as data formats and object classes. GCPR architects using the five viewpoints provided developers with a first cut at interoperability infrastructure design that included class diagrams, sequence diagrams, and deployment diagrams.
This level of detail across the interoperability concerns is not normally addressed explicitly in OSE, C4ISR, or FEAF frameworks. RM-ODP provided cost avoidance for the design phase by reusing architectural artifacts. While we do not have dollar amounts for cost avoidance on the GCPR project, we know that using RM-ODP enabled significant cost savings in the design and implementation of the architecture.
Lessons learned in using RM-ODP on the GCPR project suggest that commercially available tools may not always provide the graphic support for the various viewpoints. In the enterprise viewpoint, tools such as Rational Enterprise Suite (RES) provide for the use-case method, and link these use cases to the RequisitePro database, where textual requirements such as “Shall” statements are stored. However, in the information viewpoint, we found that certain concepts from RM-ODP are not directly mappable to UML. For example, multiple types for an object, the three distinct types of ODP interfaces, and the distinction between type and class are concepts in UML that are not directly mappable to RM-ODP concepts, such as association, generalization, and aggregation. Capturing RM-ODP semantics is essential, and most tools, including UML, are incomplete in this regard.
In the computational viewpoint, we were able to capture with a few exceptions the behavioral characteristics of the objects in diagrams such as service diagrams and component level sequence diagrams. The exceptions involved objects with real-time and state-persistence behaviors. Finally, GCPR used deployment diagrams for representing the engineering viewpoint.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment