This article describes a melding of a government-sponsored architecture for complex systems with open systems engineering architecture developed by the Institute for Electrical and Electronics Engineers (IEEE). Our experience in using these two architectures in building a complex healthcare system is described in this paper.
The work described shows that it is possible to combine these two architectural frameworks in describing the systems, operational, and technical views of a complex automation system. The advantage in combining the two architectural frameworks lies in the simplicity of implementation and ease of understanding of automation system architectural elements by medical professionals.
The purpose of this article is to describe an experience with the Command, Control, Communications and Computer Intelligence, Surveillance and Reconnaissance (C4ISR) architectural framework applied to the electronic health record (EHR) domain. Beginning in the 1960s, electronic storage systems transformed paper-based medical records into EHRs. First-generation EHRs converted information such as patient name, address, date of birth, social security number, and insurance carrier into computer-based records. Little or no attempt was made to capture patient medical records in the same information database. With the advances in networking and telecommunication infrastructure in the 1970s, the integration of individual databases became possible. Geographically distributed medical treatment facilities with different medical databases were able to access information across heterogeneous platforms. This article describes the architecture of what is today arguably the world’s largest healthcare information system. The Composite Health Care System (CHCS), a Department of Defense (DOD)–owned healthcare system, has more than 17 million records in its database as of this writing.
One method for evaluating the sophistication of EHRs is Waegemann’s Five Levels of Electronic Records.1
Level one—Automated medical records that largely depend on paper records for their origin. Most of the paper-based information is converted into computer-generated printouts stored within the medical record. Hospital automation projects (for example, laboratory, radiology, and pharmacy information systems) emulate the paper-based patient record.
Level two—Paper documents are scanned and indexed into an EHR system using document-imaging systems.
Level three—EHRs that contain medical information of the same scope as the scanned system, but the information is rearranged for computer manipulation. All patient information is collected and stored at the site, making the various information systems within a site accessible to all caregivers. In some cases the EHR integrates expert systems.
Level four—EHR systems that contain all healthcare-related information concerning any one person. The patient record contains information from one or more provider sites. This level typically involves an application system capable of uniquely identifying all patient information across various databases, use of common terminology, and security systems.
Level five—This EHR is the most comprehensive collection of an individual’s health information. It differs from the patient record in the unlimited amount of health information about a patient that the caregivers capture. It includes wellness information, particularly behavioral activities (such as smoking, dietary, and drinking habits), and drug-related, exercise-related, environmental, and sexual information.
When CHCS was first deployed, it was a second-level EHR. The CHCS supports a single medical treatment facility (MTF) and maintains information on encounters between the patient and healthcare provider that have occurred at that MTF. Over the past 25 years a set of systems, including CHCS, have been developed and maintained as the military health systems (MHS).
A major effort to address the limitations of CHCS was initiated in 1999. This effort resulted in a new version of CHCS known as Composite Health Care System II (CHCS II). CHCS II provides for creation and maintenance of a complete health record for military personnel and their dependents. A complete health record consists of data collected over the patient’s lifetime across all treatment facilities within the MHS or outside it. CHCS II uses a standardized healthcare data dictionary, which includes MHS-specific medical terminology. CHCS II provides, for the first time, an MHS enterprise-wide EHR. Deployment across the entire enterprise is planned in phases, and certain user functions such as preventive health (occupational and behavioral health) still need to be built before a level five EHR can exist. The problems that led to the creation of CHCS II are discussed below.
CHCS is a level three EHR system, according to Waegemann’s model.1 While it has served the military health community well for the last 25 years, CHCS is written in the Massachusetts General Hospital Utility Multi-Programming System (MUMPS, or M for short) programming language. M has many limitations, such as:
Some limitations of the CHCS are:
CHCS II was developed to address the limitations mentioned above.
In the DOD environment, an architectural framework already exists that can be used to develop, document, and implement complex architectural artifacts associated with highly complex automation systems. A highly complex automation system in this article refers to “a system made up of many independent systems.” The DOD-mandated architectural framework is the C4ISR. Wood and Cohen describe an experience applying the C4ISR framework to architecture generation for a large and complex automation system in the Air Force. 2 This article describes the implementation of the C4ISR guidelines in developing the CHCS II architecture.
The C4ISR guidelines define three architectural viewpoints: the operational, systems, and technical views. The operational view focuses on business rules; the systems view focuses on the hardware and software components; and the technical view depicts the standards used to implement the solution system.
Further details of the C4ISR views have been described earlier.3 C4ISR provides guidance but does not mandate the implementation models for these views. For CHCS II, C4ISR is used to depict the operational view; the systems and technical views of the C4ISR framework are implemented using the Institute for Electronics and Electrical Engineers (IEEE) Open Systems Environment (OSE).
The IEEE OSE framework was used to depict the systems and technical views because the OSE model was the most straightforward to implement. For example, block and stack diagrams required by the OSE model are simple to develop and use for communication among medical practitioners and technicians, who were the primary drivers of the implemented system. Figure One shows the C4ISR views and their relationship to the OSE framework.
Figure Two shows the IEEE OSE model used for the CHCS II architecture in detail. Per the OSE, application software includes programs, data, and documentation, and is referred to as application software entities (ASE). Examples of ASEs in CHCS II are shown in Figure Three. In the CHCS II EHR, these application platform entities (APE) are written in modern languages such as Visual Basic and Java. Consequently, the development and maintenance issues related to the high costs associated with the M programming language are minimized.
The model in Figure Three also identifies the interfaces, services, standards, and their relationships.
CHCS II adds new functionality and extends capabilities of the existing CHCS through ASEs such as Lexicon and Consult Tracking. For example, CHCS II addresses urgently needed standardization of terminology encoding systems among the medical treatment facilities owned and operated by all three DOD services through the use of the Lexicon ASE.
All the ASEs for CHCS II shown in Figure Three are defined below:4
An example of an API service is the security application, which includes:
Building the operational view products first and the systems view products second can eliminate some of the confusion in mapping systems to operations. In some cases this method forces an expensive system solution rather than a small operational change. The systems views of the C4ISR model are represented using the OSE model as shown in Figures Two and Three. Additional systems views for the MHS can be found in CHCS II System Views.5
C4ISR mandates operational views for node connections and information exchanges. Operational views are implemented using “node connectivity diagrams” (also known as OV-2 in C4ISR parlance), a commercially available diagramming tool supported by the Unified Modeling Language.
Figure Four shows data flow among the major components of the CHCS II. A set of such diagrams is used to describe the business operations of the CHCS II system and correspond to OV-2 and the information exchange diagrams (OV-3) of the C4ISR framework, where the ovals represent nodes and the arrows represent data flows.
In Figure Four, the Client Core entity represents a government-owned ASE that interacts with the Order Entry User Interface for interactive order placements. Patient and healthcare provider information is transferred in every case through interprocess messages from the interface to the Order Entry ASE.
From the order entry ASE, messages are sent to the database containing MHS business rules (DB/BR) for verification before the order can be executed. For example, contraindicated drugs cannot be ordered as a result of the rule in the DB/BR. The next steps involve sending the order using Health Level 7 protocols to the appropriate CHCS system. This step will continue to function until CHCS is retired. Next, the order is sent to the CHCS II central data repository wherever CHCS II is implemented. Note that CHCS II is currently implemented at only three of the approximately 150 sites it will ultimately service. The final step is order response.
The technical view addresses concerns related to interoperability and interprocess communications. Terminology and communication standards for the technical view are specified in the government-furnished Joint Technical Architecture Standards.6 Technical views typically show the protocols used for bridging ASE, APE, and EEI entities defined in the systems view. Protocols such as Health Level 7 for medical terms are important in that standards allow interoperability among heterogeneous software and hardware entities.
CHCS II has been deployed at Langley Air Force Base and Fort Eustace in Virginia as well as at Seymour Johnson Base in North Carolina. Later in 2004, CHCS II is expected to be deployed at Fort Bliss and Goodfellow Air Force Base in Texas. More than 750,000 DOD personnel are covered for medical services by the existing deployment.
As a lesson learned, the EHR level four and five CHCS II extends the limited capabilities present in the existing CHCS through wider use of modern computer science in medicine, a characteristic of level four and higher EHRs. An architecture based on de facto standard models such as C4ISR and the OSE provides a consistent framework for future developers to refer to when evolving the EHR. Perhaps the most important feature of the architecture for the CHCS II system is that for the first time it provides business planners a mechanism for evaluating system change requests and their impact on the existing and future architectures. Also, costs and schedules for implementing improvements through system change requests can be better estimated using the architecture described above for the CHCS II system.
Our experience with C4ISR shows that while this framework does provide a generic architectural model for describing large and complex systems, it does not prescribe how to implement the system, technical, and operational views. For example, we have developed the three C4ISR recommended views but chose to represent the system and technical views using the OSE model.
Future work is expected to include sophisticated knowledge couplers for automated responses to questions from providers and receivers of healthcare using advanced artificial intelligence methods.
In 1999 Prithviraj Mukherji, PhD, was the chief technologist at Universal Systems, Inc., when his team developed and documented the architecture of the CHCS II system for the Department of Defense Military health systems program. He is currently an independent contractor with the Military health systems program.
Csaba J. Egyhazy, PhD, is an associate professor in the Computer Science Department at Virginia Tech, Northern Virginia Graduate Center.
1. Waegemann, C. Peter. “The Five Levels of Electronic Health Records.” MD Computing 13, no. 1 (1996): 199-203.
2. Wood, William G., and Sholom Cohen. “DOD Experience with the C4ISR Architecture Framework.” Carnegie Mellon Software Engineering Institute. Available at http://www.sei.cmu.edu/publications/documents/03.reports/03tn027/03tn027.html#chap5.
3. Mukherji, Raj, Csaba Egyhazy, and Marco Johnson. “Architecture for a Large Healthcare Information System.” IT Professional 4, no. 6 (2002): 19-27.
4. Wood and Cohen. “DOD Experience with the C4ISR Architecture Framework.”
5. US Department of Defense. “MHS Enterprise Architecture 1.0: Systems View (SV) Supplementary Information.” Available at http://www.tricare.osd.mil/mhsophsc/mhs_supportcenter/MHS_Enterprise_Architecture/supplementSV.htm.
6. US Department of Defense. “MHS Enterprise Architecture 2.0.” Available at http://www.tricare.osd.mil/conferences/himss2003/Enterprise/Version_2/TVea.html.
Article citation: Perspectives in Health Information Management 1;4, Summer 2004