Introduction

There is a critical need to improve clinical, business, and technical functionality within Federal Government large-scale electronic health record (EHR) systems. Driving factors include government-driven initiatives, the need to improve the quality of care, mergers and acquisitions among healthcare providers, and improved care management, among many others. Most of these systems operate in legacy environments characterized by antiquated technology and highly-disparate architectures. Because of this, interoperability across healthcare organizations and systems has been a significant challenge for agencies and other organizations deploying these capabilities.

The achievement of true interoperability is dependent on the ability of participating healthcare organizations to acquire and operate certified automated EHR systems that can meet the evolving standards for complex healthcare systems interoperability. We believe that recent advances in information technology (IT) solutions architecture, as well as integration-enabled Commercial Off-The-Shelf (COTS) products/platforms, are contributing to positive trends in meeting business and clinical needs within the necessary constraints -- thus helping to overcome many former challenges. This paper addresses those trends in terms of opportunities and technologies now available to help to achieve the necessary architectural, developmental and integration objectives.

Healthcare Information Integration Alternatives

There are many alternatives for integrating health information, yet the healthcare industry has relied upon point-to-point messaging as the predominant integration approach in the earlier generation architectures. Newer approaches, such as service-oriented architecture (SOA), have gained attention within the IT community and are expanding in both popularity and market penetration. The benefits of SOA are manifested in integrating disparate information sources and systems into a unified fabric. It allows creating progressively new functionality and combining them with existing services to create composite applications. As described below, the Healthcare Services Specification Program (HSSP)Services Standards (a joint endeavor between HL7 and the Object Management Group (OMG) organizations) will lower risk, because they define minimal interoperability scenarios and profiles, and provide a fundamental, industry-wide approach to creating services and service standards that have broad applicability and simplified operation. SOA promotes reuse of existing functionality, which leads to faster deliveries and better delivery quality (as the reused functions were already stabilized). It allows modifying applications in real time. An application can indeed be updated without having to modify the business process and vice versa.

Through the Department of Health and Human Services (HHS), Office of the National Coordinator for Health Information Technology (ONC) Standards and Interoperability (S&I) Framework efforts, and building onto the efforts of the other industry workgroups discussed above (primarily messaging), ONC has been leading the way towards a feasible approach for integrating and interoperating among owners and stewards of health information.

From a technology view, significant benefits are now realizable by identifying and establishing service offerings within a service-oriented architecture. Precisely identifying the business functions being performed by services, grouping them into levels of testable functionality and conformance, and specifying implementation constraints of these functions in multiple technologies affords the industry the opportunity for standards-based interoperable solutions. This work is predicated on the availability of a robust semantic model describing precisely the information shared across organizations. Planned Systems International, Inc. (PSI), through its many years and multiple programs support to the Department of Defense’s Military Health System and its Defense Health Agency (DHA) -- such as the Armed Forces Health Longitudinal Technology Application (AHLTA)/Composite Health Care System (CHCS) EHR suite, DoD blood donor/transfusion support systems, healthcare services coding/compliance [Third Party Outpatient Collection System (TPOCS)/Coding Compliance Editor (CCE)], and others -- has served a critical role in large scale implementation and deployment of evolving distributed IT architectures, including service oriented architectures. We have also played an important role in helping to implement key aspects of services-based large-scale systems integration for DoD and VA interoperable EHR and other healthcare IT systems.

Healthcare enterprises can only achieve business value if new end-to-end functionality, resulting from the integration/composition of independently designed COTS and legacy applications/services, designed to meet a business objective, succeeds. Both the mix of components and how well these components work together will drive quality of service differentiation. In general, for services-based integration to be viable, services relevant to business integration requirements must be presented to service consumers that can invoke services relevant to business processes and integration requirements. A key aspect of further evolution in EHR architectural trends is by creating an integration that is visible through detailed business process analysis and identification of supported responsive integration services.

The Role of Enterprise Architecture in Enterprise Level Services Integration Blueprints for Improved Solutions

The enormous scope of achieving healthcare IT interoperability dictates the need for an enterprise level services integration blueprint to guide the development of both Business (abstract) and Technical (implementation/solution) Architectures that will be interoperable, reusable, and cost effective and meet stakeholder needs.

Reference Architectures

More advanced organizations, including the Department of Health and Human Services (DHHS), are creating reference architectures (RA) as enterprise blueprints for future, modernized information systems that meet the goals of lower cost, more agile, responsive, and fault-tolerant capabilities, as well as meeting the health care improvement goals for standards-based interoperable systems.

For ONC healthcare IT/EHR solutions, the most effective RAs will be based on an SOA approach. This is due to the alignment of SOA principles and goals with the goals and objectives of the ONC strategic plans and evolving network technical strategies/capabilities. A coherent and comprehensive “platform independent” architecture operating as an “actionable” guideline for vendors/developers will facilitate the migration from the current “as is” to a “to be” state that more effectively meets functional needs, as well as characteristics embodied in the ONC strategic plans. Using the RA will increase agility and responsiveness of the implemented deployed IT/EHR systems through the creation of an open environment that allows the insertion of best of breed plug-and-play components optimally meeting the needs of end-users. Through the use of standard information models, interfaces, and services, RAs will enable the realization of interoperable medical records for all patients and other participants in healthcare. In addition, the architecture must acknowledge government and private industry’s extensive investments in legacy hardware, software, and medical devices that support ongoing healthcare operations, while at the same time buy or develop new prioritized capabilities that integrate with or “gracefully” transition from existing capabilities.  

Multiple studies have identified the need for architectural compliance criteria, best practices, common service specifications, a set of common information models, standards-based interfaces and other artifacts that will guide vendors and developers of components and capabilities that will assure an effective, agile, reusable, business aligned, fault-tolerant, high performance, and highly cost effective EHR and supporting capabilities.

The Evolving Role of Enterprise Architecture in Solution Acquisition

Currently, the government and commercial healthcare information management business community typically provides text-based functional requirements and business process modeling for business functionality related to a specific new desired capability, to their IT program offices from which systems are developed. These systems tend to satisfy a set of specific business needs with implementations that are independently deployed and governed. Without an enterprise architecture containing reusable services to guide the development process, this approach fosters “stove piped,” redundant system implementations and point-to-point data integration patterns that frequently fail to meet end-user expectations, exhibit high maintenance cost, cannot easily adapt to changing requirements, and exhibit end-to-end performance issues. The envisioned RA can be used as the communication mechanism between the IM and IT groups that will foster reuse of common functionality, interoperability, fault-tolerance, and agility.

The implementation architecture makes the abstract RA explicit. Specific Enterprise Service Bus products (ESBs), service implementations, and technology infrastructure have been chosen and specified in implementation architectures. The technology infrastructure consists of hardware (servers, routers, firewalls, etc.) as well as software including operating systems and databases. The RA does not specify any of this, but rather defines the characteristics of the implementation architecture and technology infrastructure that will allow compliance with the RA. Solution designers and developers can implement services as part of the implementation architecture in a number of ways. One or more components provide services and are the basic building blocks of the RA. Components define an abstract interface, similar to an API, which defines the behavior (operations) of the component. Components may be used or combined to create services, which can be exposed as web services using the Web Services Description Language (WSDL) or as a more recent Representational State Transfer (REST) protocol. The REST protocol is lightweight and designed for simplicity, scalability, and reusability, and is trending currently as a more preferred alternative.

Issues to be Addressed in Evolving Health IT Architectural Solutions

Some of the important issues to investigate in support of health IT integration for multiple federal agencies include:

  • What are the business benefits of modeling SOA services or information exchange requirements in the context of use of COTS and/or reuse of legacy systems? 
  • How do healthcare business requirements, such as interoperability and business intelligence, get optimally translated into information, terminology, and data modeling activities? What best practices are used to achieve effective data architectures that enable “computable” clinical information exchanges? 
  •   What service design and governance best practices and patterns adopted by the architectural community support HHS/federal/private sector healthcare SOA requirements?
  • Service Oriented Architecture Initiatives for Healthcare

SOA is emerging within the healthcare sector, following the business benefits it has provided in other industries, such as the financial sector. Federal healthcare organizations, such as DHA, VA, CMS, FDA, SSA, and NIH, are each executing their own approach to SOA. Under the Federal Health Architecture (FHA), within which our team’s primary customers (DoD and VA) are principal stakeholders, a common mechanism for the definition and interchange of health information is being defined.

The Federal Health Architecture (FHA) is an E-Government Line of Business (LoB) initiative designed to bring together the decision makers in federal health IT for inter-agency collaboration -- resulting in effective health information exchange (HIE), enhanced interoperability among federal health IT systems and efficient coordination of shared services. FHA also supports federal agency adoption of nationally-recognized standards and policies for efficient, secure HIE.

The DoD’s Net-Centric Enterprise Services (NCES), Nationwide Health Information Network (NHIN), and the Federal Health Information Model (FHIM) efforts are all SOA based approaches that the federal government is aligning with. The Nationwide Health Information Network is broadly defined as the set of standards, specifications and policies that enable the secure exchange of health information over the Internet. This program provides a foundation for the exchange of health information across diverse entities, within communities and across the country, helping to achieve the goals of the HITECH Act. The Nationwide Health Information Network Exchange is the first community that implemented these standards, specifications, and policies in production. Therefore, a key benefit of using SOA is that it will be more closely aligned and interoperable with the FHA/NHIN and the modernization efforts of our federal partners. ONC and other authorities concerned with interoperability recognize that healthcare IT interoperability requires standardized behavioral models that augment standard use of information models/terminologies motivating the community-wide development and adoption of the HL7 Functional Model and related universal healthcare service specifications.

As a key example of this trend, the HL7 HSSP, in cooperation with OMG are defining healthcare universal services such as the Common Terminology Service (CTS), Entity Identification Service (EIS), Clinical Decision Support (CDS), and others. In these service instances, reuse potential between organizations and enterprises is great. As briefly described above, HSSP is an open, global community focused on improving health interoperability within and across organizations through the use of SOA and standard services. The intention is to reduce implementation complexity, promote effective integration, foster marketplace support, and drive down implementation costs and barriers impacting healthcare solutions.

The Health Informatics Service Architecture (HISA) (ISO 12967-1:2009) was developed internationally as an SOA guideline to describe healthcare information systems through a language, notation and paradigms suitable to facilitate the planning, design and comparison of systems; and to identify the fundamental architectural aspects enabling the openness, integration and interoperability of healthcare information systems. This architecture is therefore intended as a basis both for working with existing systems and for the planning and construction of new systems.

ISO 12967 is broken down into three parts: Enterprise Viewpoint; Information Viewpoint; and Computational Viewpoint, all of which deal with different aspects of ensuring service architecture supports openness and vendor-independence. The Enterprise Viewpoint component of provides health services with guidance in describing, planning and developing new IT systems, utilizing an open distributed processing approach. The Information Viewpoint component describes the information model to be implemented by the middleware to provide comprehensive, integrated storage of the common enterprise data and to support the fundamental business processes of a healthcare organization. The Computational Viewpoint component of ISO 12967 provides details on the fundamental characteristics of the computational model to be implemented by the middleware, to provide a comprehensive and integrated interface to the common, fundamental business processes of the health service.

One of the key tenets within a SOA lies in the ability to adapt the architecture over time, adding new services, replacing existing services, and reconfiguring infrastructure all with minimal impacts to service consumers. SOA is intended to leverage existing resources – it is not a “rip and replace” approach. Service oriented architectures can reduce the number of custom point-to-point interfaces needed in a given environment.  This is an important characteristic, since interface design, development, deployment and maintenance can be expensive. For these reasons, standards based behavioral models, interfaces and data add value as they promote consistency across vendor offerings, provide a common footing for custom development, and allow business partners to interact based on shared capabilities while minimizing the need for custom point-to-point interface development.

Fundamentally, perhaps the most important consideration to be given to SOA-based modernization activities is that SOA is largely a business initiative. SOA projects that are considered to be solely technology-based usually fail. Creating SOA within the healthcare arena means bringing together business functions under common responsibility, governance, and ownership and orchestrating these services from the perspective of business value. Therefore, the perspective of enterprise “value streams” (the business context and the stakeholder value that derived from the services) must drive services specification.

Based on multiple healthcare systems community analyses, including within DoD, using enterprise-wide standards-based services and information models will enable achievement of the envisioned goals of ONC by:

  • Providing greater agility for new application development/revision of existing capabilities
  • Continuously enhancing application interoperability
  • Reducing time needed to take an application from conception to full operational capability
  • Reducing redundancy of capabilities and components among all applications
  • Standardizing business processes and technologies for developing/fielding applications
  • Improving application performance through an evolutionary model of service enhancement
  • Supporting the vision for net-centricity.

The most effective planning trend is through incremental, collaborative, evolutionary methods to pilot concepts, build stakeholder confidence, and address the known issues associated with common services (e.g., governance, infrastructure, coupling/dependencies, training). We will need to balance Common Services development efforts between new starts and service-enabling of existing functionality. Where possible, the approach will be to leverage components that have already been through resource intensive “ancillary” information/IT processes (e.g., proven functionality, certification, and accreditation). However, these existing services should go through an incremental modification process, specified by governance policies, to become useful for other business processes.

As an example of a SOA architectural model developed by PSI to document the DoD AHLTA EHR as a SOA, Figure 1, uses the well-known layered SOA conceptual modeling paradigm, originally developed and published by IBM, to illustrate the specific Appointment Service architecture. This diagram shows the functionality and implementation of the representative service at all levels ranging from Presentation through Operational Systems.

 key trends fig 1

Figure 1 Representative SOA service model PSI developed for the AHLTA EHR Appointment Service

As a macro-level SOA infrastructure example, the following diagram (Figure 2) prepared by PSI shows an application implementation/virtualization model of a representative EHR interoperability/data sharing secure infrastructure, with security zones and DMZ partitioning illustrated. It denotes the levels of protection required to deliver EHR data securely outside an internal enterprise domain network perimeter to/from healthcare partners.

 key trends fig 2

Figure 2 A representative EHR interoperability/data sharing secure infrastructure with security zones and DMZ partitioning illustrated.

Compliance with Representative Enterprise Architecture Framework and the Corresponding EA Principles

One example of an overall approach is the layered HHS Enterprise Architecture Framework, and the corresponding HHS EA Principles--developed and published by the HHS Office of Enterprise Architecture--to serve as a guide to understanding people, process and technologies needed to extend and expand health information exchanges in policy, planning, research and technology.

In alignment with the Office of Management and Budget’s (OMB) “Common Approach to Federal Enterprise Architecture” (FEA V2, May 2012), the HHS framework provides the foundation for allocating resources of all types toward the realization of the Department’s strategic business goals and objectives. It leverages the EA framework, within the overall HHS Enterprise Performance Life Cycle (EPLC), as a strategic resource to plan, invest in, and implement information technology expand health information exchange solutions. It further provides a mechanism for understanding and managing complexity and change. The EA products identify the alignment of the full range of organizational business and management processes, data flows, and technologies involved in the extended and expanded health information exchanges and also enable the identification of relevant capability gaps and duplication – in particular, by developing and representing architecture descriptions that ensure a common denominator for understanding, comparing, and integrating architectures across organizational boundaries.

This framework describes the components of people, process and technologies to provide effective and efficient support for policy development, research and planning for health services research; demonstration, implementation and evaluation of programs and technical options; and information dissemination activities related to health IT, EHRs, and HIE.

Thorough an integrated enterprise architectural view, and by taking in a comprehensive, unified and methodical approach, the community can better unify its efforts and interfaces within the context of a clear road map that meets stakeholder needs. The expected result is more predictable outcomes that support the planning, developing, coordinating, managing, implementing, and/or evaluating of many of the health system policies and programs. This will include policies and programs to accelerate the use, and to enable the interoperable exchange and re-use of health information to support the independence, productivity, health and security of the American people.

The HHS EA Framework can support the modeling, analysis and documentation aspects of this effort, and integrate the models developed under similar efforts within the community. The framework provides the concepts and guidance necessary to maintain and use the EA Repository. It includes a metamodel, which defines the kinds of information that can be recorded in the repository. The kinds of data the framework describes are called entity types (or, sometimes, object types). Entity types are analogous to tables in database theory or to classes in object-oriented theory. Conceptually related entities are grouped together into layers, described in further detail below.

The HHS EA Framework has been organized hierarchically into an eight-layer model where the initial layers represent higher levels of abstraction identifying business and strategic concerns, while subsequent layers focus on more detailed aspects of the architecture typically more technical or detailed in nature. In this way, the definition of the HHS EA Framework follows the paradigm of other widely used EA frameworks, such as the Zachman Framework, by incorporating levels of abstraction within the architecture.

The HHS EA framework layers are also similar to those defined within the Federal Enterprise Architecture Framework (FEAF). Four layers of the HHS EA framework map directly to the FEAF V1 and V2 layers of Business, Data, Application/Service), and Technology/Infrastructure; while the other four HHS layers of Strategy, Investment, Workforce, and Facilities also map into the Performance/Strategy and Business layers of the FEAF. The HHS business architecture layer has been defined to delineate the business architecture in order to capture components that will be important to the ONC view of HIE interoperability. Performance and security aspects cut across all framework layers and are identified as their own groups within the framework. The HHS EA Framework layers that can be utilized for interoperable health information exchange modeling and analysis are:

  • Strategy – identify the strategic goals and objectives for interoperable health information exchange.
  • Business – determine what essential business activities are needed to achieve the goals and objectives and how they will be continued.
  • Investment – represents the financial aspects of enabling interoperable health information exchange; it includes concepts that allow the EA information to be reconciled with investment and project control information.
  • Services/Systems – identify any needed systems that will provide the services needed to support the above interoperable health information exchange activities and how they will be made available.
  • Data – determine what data will be needed to support the interoperable health information exchange business activities, and where it can be obtained.
  • Technology – identify the technology to be used in building the system services.
  • Workforce – identify the roles and key positions needed to support the above business activities.
  • Facilities – identify the facilities needed to support the business activities above.
  • Security and Privacy – identify the security controls that are to be in place at each layer and how they will be implemented.
  • Performance – identify measurement indicators to measure performance at all levels of the interoperable health information exchange community operations.

Using the representative HHS Federated Enterprise Architecture Repository

The federated enterprise architecture repository at HHS implements a common framework for enterprise information, allowing distributed maintenance and sharing of relevant information between and within Operating Divisions (OPDIVs) and Staff Divisions (STAFFDIVs). It exploits the HHS EA “One Model Many Views” principle: there is one model for all EA data, regardless of whether it is target or baseline. Multiple views (such as baseline or target) support various EA stakeholders for interoperability and health information exchanges. The department level metamodel defines the minimum set of information that must be shared across the HHS enterprise, and by extension, the health IT, EHRs, and HIE communities.

Strategic Planning for Technical Architectures

As an example of a current strategic approach to healthcare technical architecture, the DHA published an updated Long-Range Technical Architecture (LRTA) Strategy in October 2016 for the evolving strategic needs of the Defense Health Agency’s (DHA) Health IT (HIT) Directorate to meet future-state requirements with new technical architectures and solutions. This strategic plan proposes areas for future investment from 1-3, 4-6 and 7-10 year perspectives. For the shorter timeframe, the DHA incorporated a flexible service-based EHR implementation approach that will enable real-time integration and the flexible reuse of system data objects across multiple business processes in accordance with the DoD’s Office of the Deputy Chief Management Officer (DCMO) “Business Enterprise Architecture (BEA) 9.0” document and the President’s Council of Advisors on Science and Technology (PCAST) report on HIT.

As part of this effort, the DHA developed an architectural reference implementation, known as the Blueprint Realization, as the basis for developing integration frameworks. The three main areas for legacy and future systems integration focus include:

  • Data Federation. Provides a uniform, coherent, and integrated view of data that are distributed (in systems) and heterogeneous (in structure).
  • Integration. Makes data from different systems available seamlessly though authorized functionalities.
  • Interoperability. Allows different functionalities (in various systems) to seamlessly understand (operate upon) the same data.

These shorter-term integration focus areas are expected to lead to improved solution architectures and enhanced healthcare capabilities in future years.

Conclusion

This paper has discussed some of the important issues in health IT integration, and provided some examples -- particularly within the Federal large-scale EHR arena --  including:

  • The business benefits of modeling SOA services and information exchange requirements in the context of use of COTS and/or legacy reuse. 
  • How healthcare business requirements, such as interoperability and business intelligence, can be optimally translated into information, terminology, and data modeling activities. Included were best practices are used to achieve effective data architectures that enable accurate and timely clinical information exchanges. 
  • Services design and governance best practices and patterns adopted by the architectural community supporting key agencies like HHS and DoD, that are necessary to meet federal/private sector healthcare SOA requirements.

We have concluded that recent advances in IT solutions architecture, as well as integration-enabled COTS products/platforms, are contributing to positive trends in meeting business and clinical needs within the necessary constraints -- thus helping to overcome many of the prior challenges.