1. Introduction

Enterprise Architecture (EA) at its core can be defined as a blueprint for allocating IT resources for the ultimate support of business goals. When applied successfully, EA becomes a tool that enterprise architects and decision-makers can use to understand an organization’s current state. Organizations can also use EA to pinpoint future goals and map a way of achieving them.

To successfully leverage EA, architects must be able to understand and diagram their organization’s IT architecture, identify and understand business architecture as-is, and determine what future organizational business goals are (to-be). Once goals are outlined, a gap analysis can be performed to determine how IT can support the realization of organizational goals.

Enterprise architecture allows organizations to achieve great performance by ensuring there is a seamless flow of information and services throughout the organization. This requires that processes and systems are well integrated, and a high level of connectivity is maintained.

For an HIE to achieve great performance, there needs to be a bi-directional flow of data and processes between the HIE and the health institutions it serves. A smooth bi-directional flow is evidenced in an organization’s computing resources’ ability to seamlessly share data and information.

Health Information Exchange (HIE) organizations and technologies have become an essential component of well-developed healthcare environments. In the United States, federal health policies have been enacted to encourage the establishment of HIEs as a healthcare solution. The 21st Century Cures Act in 2016 and the Health Information Technology for Economic and Clinical Health Act (HITECH Act) in 2009 allowed HIEs to serve as a solution for healthcare interoperability [1], [2].

There are two general forms of HIEs: query-based and directed-data serving. Query-based HIEs function as an informational hub for healthcare providers, health institutions, and related organizations who have opted-in to access and edit patient records. Directed-data serving HIEs transfer data directly to opted-in institutions and organizations. With this solution, HIEs functioning as a data transfer point through which records are transmitted. Both HIE solutions utilize health data standards like Continuity of Care Document (CCD), DIRECT Secure Messaging, and other “push” triggered transmissions to ensure records are transferred [3].

Although HIE solutions, operations, and technologies are well established, challenges still exist in scenarios where records need to be urgently transferred or made available. These challenges stem from the complex data intake and transference workflows HIEs manage [4,5].

Well established HIEs serve multiple health institutions and deal with a wide variety of health records. Some of these records include demographic information, lab results, image reports, transfer summaries, radiology reports, and much more. Successful management of health data and ensuring that records are retrieved on-demand require a well-designed architecture and robust computing capabilities.

While current solutions allow health institutions to forward data to other care providers, data is not always readily available when needed. In emergency scenarios, access to patients’ complete health records on-demand will greatly assist emergency caregivers in making better decisions and preventing medical errors.

Most HIEs and health institutions are addressing data transfer challenges by migrating from an on-premises environment to cloud-based computing and storage solutions. Private cloud sharing systems [6] and cloud computing technologies like IoT [7] have been researched and implemented. In healthcare, cloud-based health data exchange services and electronic health record (EHR) systems have become extremely popular. To smoothly transition from an on-premises HIE environment to a cloud-leveraged solution, it is necessary to architecturally account for all aspects of the migration. All the work involved in the project and the impact of every change must be taken into consideration. Enterprise architecture provides a valuable tool in that regard.

 The rest of this paper is organized as such: section two discusses enterprise architecture concepts and introduces the three main enterprise architecture frameworks (EAFs) utilized to develop the proposed solution. Section two also provides an overview of HIEs and Cloud technologies. Section three provides a literature review of work done in this field. In section four, a cloud migration plan is proposed and an EA institutionalization framework for applying the architecture is presented. An architectural validation mapping and a means of testing the architecture is provided. Section five concludes the paper with a summary of the proposed solution, potential future work, and acknowledgments.

2. Background

2.1. Health Information Exchange (HIE)

As technology has improved over the past few decades, there have been great leaps in patient data recording and storage. These improvements brought about the development of Electronic Health Record (EHR) systems as a means of digitally recording and storing health data.

Before the introduction of HIEs, patient data like immunization records, lab test results, allergies, admission and checkup information, etc. were digitally managed on hospital EHR systems and health data was only accessible to the organization that recorded it. The inability to transfer health records among multiple health institutions limits healthcare coordination and produces unneeded costs, both to healthcare institutions and patients. The introduction of HIEs addressed those limitations and provided continuous care improvement and provisioning to patients.

Health Information Exchanges are collaborative health organizations established to provide a smooth transference of patient records between health institutions (i.e. Hospitals and Clinics) in a geographic location. The geographic location where an HIE resides is dependent on the local government’s determination and the HIE’s ability to accommodate data transference.

Depending on the government’s influence on healthcare, health institutions like clinics, hospitals, etc., may not be mandated to participate in an HIE [2]. In any scenario, institutions that participate in an HIE environment expect their EHR systems and HIE technologies to be well integrated. These expectations mean that HIEs must accommodate heterogeneous EHR infrastructures, handle a variety of data formats, and be able to transfer records to different network architectures. For this reason, government agencies invest a lot of resources to ensure that necessary HIE operations are in place for EHR communication. Sometimes, government agencies are established and well-funded to support, promote, and monitor the success of HIE institutions. For instance, in 2010, the United States Department of Health and Human Services awarded over $548 million through the State HIE Cooperative Agreement Program [4] to several state HIEs throughout the country.

2.2. Enterprise Architecture (EA)

Enterprise Architecture is derived from the words, enterprise and architecture. An enterprise refers to organizations, businesses, or large corporations. Architecture is usually defined as a logical representation or design of a physical system. Combined, EA is defined as the complete expression of an organization’s business, information systems, and technology strategies. EA also includes the process of identifying business processes, pinpointing business functions, and determining the impact of Information Technology (IT) on it.

Developing an enterprise architecture involves utilizing generally accepted EA principles, standards, and techniques to collect and document an organization’s business strategies, processes, principles, and practices into understandable artifacts. The business artifacts are then married with already documented IT processes and assets. The purpose of accomplishing this is to facilitate the realization of organizational goals.

Once successfully applied, enterprise architecture provides a sense of clarity for organizational decision-makers. Using EA principles and practices, decision-makers can automate and streamline processes to better accomplish tasks. EA can also be used as a tool that facilitates the accomplishment of goals and the realization of technologies. Using an as-is architecture coupled with a to-be architecture, architects can perform a gap analysis to map a path to reach goals.

High-Performing healthcare organizations like Mayo Clinic in Minnesota, US and Lafayette General Health System (California, US) have engaged in these strategies and tactics to drive technical performance and improvement [8].

An enterprise architecture framework (EAF) is a predesigned architecture template used to develop enterprise architecture. Because EA combines a wide array of disciplines ranging from business management and organizational development to IT architecting, EAFs serve as a tool to define how an EA can be designed and applied to enterprises. EAFs provides guidelines on how to create an architecture and can provide best practices in architectural design and development.

The process of applying an EA framework to an enterprise is termed institutionalization [9]. To apply or create an EA, enterprise architecture frameworks provide a set of well-defined guidelines and procedures that must be followed. The solution presented in this paper utilizes three EAFs: The Patient Demographic Data Quality Framework (PDDQ), the Zachman EA Framework, and The Open Group Architecture Framework (TOGAF).

The Open Group Architecture Framework (TOGAF)

TOGAF is the most well-adopted and applied EAF. TOGAF is made up of five key components, the Architecture Development Method (ADM), the ADM Guidelines and Techniques, Architecture Content Framework (ACF), Enterprise Continuum, and Architecture Capability Framework. These five pieces provide a comprehensive approach to enterprise architecture. As technology has evolved, the framework has been improved and revised [10]. The most current release of TOGAF is at version 9.2.

The ADM contains phases of the TOGAF EA design and implementation. Following the ADM phases step-by-step, organizations can develop an enterprise architecture. The phases are, Preliminary, Architecture Vision, Business Architecture, Information Systems Architectures, Technology Architecture, Opportunities and Solutions, Migration Planning, Implementation Governance, Architecture Change Management, and Architecture Requirements Management. The ADM also provides a set of guidelines and techniques that can be used to design and implement the framework [10].

The ACF provides a collection of artifacts that be utilized as building blocks for the design and implementation of architecture. With the ACF, architects have a tool that helps define how artifacts relate to each other, its importance, and how they fit into the development of an EA. Artifacts are also categorized in different TOGAF ADM phases so that architecture development and implementation is facilitated.

Enterprise Continuum provides practices and tools to classify and group architecture artifacts during the institutionalization process [10].

Zachman Enterprise Architecture Framework

The Zachman Enterprise Architecture Framework is an EA classification scheme of descriptive representations that can be utilized to design and develop an enterprise architecture [11].

At its core, the Zachman Framework is an ontological representation of systems and projects. For enterprise architects, Zachman provides a logical structure that can be emulated to categorize, arrange, and depict system/organizational artifacts in a detailed manner. The framework can be used to support healthcare institutions in the development, design, integration, and management of information systems.

Zachman is a matrix of representations that categorize actors, their roles, and their contributions to a system or an enterprise. The framework provides illustrations that describe actors’ viewpoints to a system/organization based on their concerns. The matrix contains six columns: data, function, network, people, time, and motivation. The rows are comprised of the different stakeholders and their needs. For each matrix, there are a set of artifacts that contribute to the creation of architecture.

Patient Demographic Data Quality Framework (PDDQ)

The Office of the National Coordinator for Health Information Technology (ONC) of the United States government worked with the Capability Maturity Model Integration (CMMI) Institute to develop a framework that healthcare organizations can use to measure their patient data management capability. In 2015, The PDDQ Framework was derived from the Data Management Maturity model as a module to support the development of health systems, HIEs, and other health institutions alike.

The PDDQ is comprised of nineteen process areas across five categories. The five categories of the framework are Data Governance, Data Quality, Data Operations, Platforms and Standards, and Supporting Processes. These process areas provide a list of best practices needed to develop a sustainable healthcare data management organization/system so that patient data quality is improved and maintained [12].

2.3. Cloud Technologies

Cloud technologies, commonly termed Cloud Computing, provides a wide array of on-demand computing resources and services to its customers with great availability. The provisioning of these computing resources can greatly improve the development of IT in the support of their organization’s goals. As cloud services are provided to an organization, IT has the responsibility of ensuring that the right services are acquired and resources are utilized to their full capacity [13].

Generally, cloud technologies service providers provide computing resources to its clients virtually from remote facilities (the cloud). Resources are categorized into three major services, Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS).

Software as a Service

Software as a Service is a cloud computing delivery model by which software is distributed to enterprises and organizations. SaaS software is usually procured on a subscription or license-based model and is accessed through the internet. Maintenance and the management of SaaS products are handled by the cloud computing service provider.

From an HIE perspective, software as a service can be leveraged for the organization’s internal processes and functions. Organizational activities like HR and legal, finance and accounting, and sales and customer relationship management can benefit greatly when software can be delivered virtually. Architecturally, IT support and maintenance costs can be alleviated when there are fewer in-house applications to manage. The role of IT in these scenarios is to ensure that robust governance standards and policies are established and practiced by all users. IT must also provide resources that end users can use to access SaaS software and applications.

Platform as a Service

With Platform as a service, application platforms and development tools are provided to enterprises. Using cloud technologies, organizations can leverage these services to provide its stakeholders with the hardware and software environments required to develop and deploy enterprise-level tools.

PaaS services are quickly becoming the most widely leveraged cloud computing technology resource because of the flexibility it provides to organizations to plan, build, and test quickly. PaaS provides computing platform resources like development tools and management services, computing middleware and frameworks, collaboration tools, and other integrated development services.

Because the value proposition of HIEs is to provide an environment where health data can be transferred across health institutions seamlessly, it is imperative that HIE IT departments quickly adjust to its customers’ (health institutions) changing technology requirements. As EHR systems are upgraded or modified, HIE may require modifications to its transfer software codebase so that patient health records are transferred consistently. PaaS can provide HIE IT development teams with the resources needed to effectively perform its development activities.

Infrastructure as a Service

Infrastructure as a Service provides organizations and businesses with the computing infrastructure required to perform day to day business functions. Some of the infrastructure services IaaS provides include virtualized computing, storage, and networking.

Although PaaS provides organizations with a level of computing, storage, and network capabilities, IaaS encompasses the outsourcing of infrastructure components. Using the internet, organizations can access complete computing infrastructure components like servers, data centers, etc. from the cloud.

For HIEs, IaaS allows IT to outsource the complexities that result from managing computing infrastructures inhouse. On-premises architectures require major planning for backups, disaster recovery, and fault tolerance. However, with the introduction of IaaS, organizations can shift their focus to improving their technological provisioning while cloud service providers handle major infrastructure undertakings [13].

3. Related Work

Several HIE-related solutions have been proposed, developed, and implemented in the past decade. These solutions either seek to improve the level of interoperability in health data exchange or enhance HIE architecture.

Proposed solutions that address health data exchange interoperability have focused on interoperability architecture frameworks, cross-organizational standards (ex. HL7, SNOMED-CT), open source APIs to facilitate plug and play development solutions, complete middleware software applications, or a combination of the above.

For enterprise architecture focused solutions, S. In [14], the author highlighted successful EA implementations, discussed some of their characteristics, and presented the factors that lead to a successful EA implementation. A. In [15], the author also discussed successful implementations and recommended methods of assessing architecture institutionalizations. Although both papers address broad EA challenges, their proposals do not specifically target the development and implementation of a cloud migration architecture. A. In [7], the author provided an EA implementation template but did not identify specific methodologies and building blocks for creating an architecture. Although D. In [16], the author provided general guidelines for EA development in public sector organizations, the recommendations are general and do not specifically apply to HIE migrations to a cloud architecture. F. In [17], the author proposes a healthcare-specific EA but only focuses on the technology and infrastructure domains of architecture.

HIE Architecture solutions can be classified into four domains, Business, Data, Application, and Infrastructure. The subsections below introduce related solutions and discuss how previous work fits into the four domains of architecture.

Figure 1: HIE Architecture Domains

In enterprise architecture, The Business Domain represents HIE and health institution organizational activities and goals. A combination of the Data, Application, and Infrastructure Domains represents IT. Within IT, the combination of application and data domains of architecture is referred to as Information Systems. The infrastructure domain is usually referred to as the Technology domain. Below is a breakdown of each architectural domain.

3.1. Business Domain

The Business Domain represents an aspect of architecture where business (healthcare) processes occur. To ensure HIEs are successful, organizational standards must be communicated and documented. Processes and activities must also be streamlined with effective documentation, practice, and governance.

Several articles identify useful references for developing interoperability on a business process level [8,18]. In [19], the author proposed business-focused enterprise architecture approaches for enhancing healthcare interoperability. Most of the related work proposed in this domain do not address items from other domains in detail.

3.2. Data Domain

At the Data Domain, health data collection, formatting, and management are at the forefront of all activities. HIEs must ensure that data security is enforced, and unauthorized individuals are prevented access to data. HIE organizations must also work to ensure a smooth transference and storage of health data. Lastly, HIEs should strive to maintain a high level of data interoperability in this domain.

Health data standards like Health Level 7 (HL7), Digital Imaging and Communications in Medicine (DICOM), and Systematized Nomenclature of Medicine (SNOMED CT) has been established to facilitate the storage, transference, and management of health records. Several articles have proposed solutions to leverage the HL7 standard, SNOMED CT, etc. [14], but very few have dealt with data management in a context where all four domains of architecture are addressed.

3.3. Application Domain

The application domain is a highly researched field that focuses on all software and application related tools used to enhance HIE operations.

Most interoperability-focused solutions are developed in this domain. Health data storage, sharing, and analysis solutions are also developed here. Some of these solutions include EHR and data sharing applications like Fast Health Interoperability Resources (FHIR), Integrating Biology and the Bedside (ib2b), and its corresponding APIs [20]. The introduction of blockchain-based healthcare solutions have been generally application and data domain-specific but is also greatly improving the quality of health data management.

3.4. Infrastructure Domain

At the infrastructure domain, system, network, and physical operational solutions are implemented. The purpose of this domain is to support the development and utilization of healthcare applications. The infrastructure domain provides the technology on which the rest of architecture is developed. Although application-based solutions are generally visible to stakeholders, infrastructure components may not always be visible.

HIE infrastructure solutions focuses on network connectivity, physical hardware components, server OS capabilities, storage hardware efficiency, etc. To ensure that the infrastructure domain is well built, HIEs must collaborate with health provider IT representatives and third party multi-disciplinary teams to create integration processes, support activities, and system administration.

4. HIE Enterprise Architecture for Cloud Migration

Enterprise Architecture can be leveraged as a tool for the adoption of technology. As described in section two, cloud technology addresses on-premises HIE challenges by ensuring the timely transfer of data to and from health providers. The HIE Enterprise Architecture presented in this section can be utilized to streamline the adoption of cloud technologies.

A complete enterprise architecture highlighting business level processes, information systems functions, and technology components are discussed in the institutionalization framework. A cloud migration architecture is proposed in section 4.2 and a validation framework is presented in 4.3.

4.1. EA Institutionalization Framework

This section presents how the proposed migration enterprise architecture can be leveraged as a tool for HIE cloud migration.

EA institutionalization requires the following steps to be followed:

1. Understanding an HIE’s major business processes, functions, and policies.
2. Understanding the HIE’s IT, its information systems, and its guiding processes/policies.
3. An understanding of the relationships between business and IT and how technology is constructed to support the HIE.
4. Designing and mapping an organization’s architecture based on the information gathered in Steps 1,2 and 3.
5. Planning a feasible and realistic strategy to attaining future goals.

As discussed in previous sections, the primary step in developing an enterprise architecture is understanding business processes, functions, and activities and developing a robust business architecture.

Once that is completed an IT architecture must be built to fit the business architecture. The goal of EA is to design Information Technology to complement business goals and objectives.

Business Level Processes

The diagram below represents an overview of HIE business processes.

Figure 2: HIE Business Processes

The context diagram presents the five major processes and functions of HIEs.

• Interface – The interface process is the intermediary communication mechanism between an HIE and health institutions. It processes all incoming and outgoing data/records.
• Patient Indexing – Patient indexing comprises of the patient recordmapping processes at the HIE level. HIEs must be able to understand incoming data from other health institutions.
• Notification Services – Notification processes are needed to initiate updates to health records in real-time. This process ensures that health records are updated on time without compromising data integrity.
• Portal – The portal process is the means by which HIE data can be accessible to healthcare institutions and other health providers.

Analytics – Using the analytics process, HIEs can provide a means of converting health data to health information. This process includes query creation and custom reports generation.

Figure 3: HIE Process and Information Systems Flow Diagram

HIEs have two main external stakeholders. These stakeholders are External Healthcare Entities and Healthcare Providers. External healthcare entities are healthcare institutions that may not directly provide health services but function to help improve health results. These institutions may include research institutions, other HIEs, or other health entities. Healthcare providers in this illustration represent partner hospitals and clinics.

External stakeholders usually have similar interactions with their HIEs. Flows include requests for data and updates to healthcare records.

Information Systems Architecture

Figure 3 is an excellent artifact for developing a comprehensive EA. It can be used to illustrate HIE business processes with corresponding application systems. Application systems are then mapped to potential data stores. The Information Systems Flow diagram, also referred to as a Data Flow Diagram is used to represent the relationship between the data domain and application domain of HIE IT architecture.

An understanding of HIE stakeholder relationships, internal application processes, and its relationship with data components can help organizational decision-makers understand the impact of information system changes. A breakdown of the relationships between HIE application systems (processes), external stakeholders, and data stores as portrayed above is as follows.

1. Interface Engine

The interface engine is referred to as the intermediary process between an HIE and its external stakeholders. This process serves as the communication hub for automated data transactions between HIE systems and external systems. Subsystems that reside within the interface engine process are:

• Request Receiving and Processing: This system focuses on receiving and processing external entity requests. This system queries external entities for data as when needed. Figure 3 highlights incoming and outgoing requests from external organizations to the Interface Engine.
• Data Conversion: As health data is received from external parties, tools and services are needed on the interface engine to perform data conversion. Since different health institutes may need to send data in different formats, the data conversion process is required to translate data as it enters the HIE environment for consumption. Some examples of generally accepted health data formats accept are HL7, CSV, and JSON. Data is usually sent back to external entities in a similar format.
• Data Transference: After health data is converted, the interface engine forwards data to the patient indexing subsystem for processing. Health data is forwarded, processed, and shared with internal subsystems using the interface engine.

The interface engine system interacts with a clinical data repository (CDR) data store directly. The interface engine also interacts with notification service processes to ensure health records are automatically transported to and from clinical entities.

2. Patient Indexing

The patient indexing system ensures that patient records are properly maintained within the HIE. Indexing processes interact with interface engine systems to ensure received health data is reconciled with internal HIE records and that there are no redundancies. As seen in process two (P2) in figure 3, a patient’s records may exist in different institutions and different EHR databases. Once a record update is received, the indexing process maps those records into a singular HIE record ID (HIEID-####).

The patient indexing system interacts with both provider and client data stores to ensure updates are stored. The indexing system receives record update messages like Admit Discharge Transport (ADT) alerts from notification systems.

Once records are updated, the indexing system transfers records to the reporting data store for data analytics reporting.

3.  Notification Services

The notification services system ensures that records, alerts, and messages are transported to the right systems. This system tracks patient record updates and HIE events as they occur and logs them into the event management data store.

Depending on the system design, notification services processes may manage communications between both internal and external data stores. As previously explained, notification services systems communicate ADT and other update messages to the patient indexing and interface engine systems.

4. HIE Health Portal

The HIE Health Portal serves as a landing system for internal and external stakeholders. The portal also provides a means of communicating with external stakeholders.

As interface engine and reporting services processes append CDR data store, updates are delivered to the Health Portal for authorized user consumption. In special use cases, external health entities and health providers can provide their employees with the authorization to access this customer-facing system as a hub for complete health records access.

Figure 4: HIE Enterprise Architecture Integration

5. HIE Analytics

In our design, Analytics serves more as an ad-hoc system more than it does, a process. HIE Analytics can work in conjunction with the health portal system to provide comprehensive knowledge through queries and reports to all stakeholders.

The analytics system will interact with both the CDR’s real-time data store and the reporting data store to generate relevant dashboards, reports, and queries. It should also be able to portal users with the ability to generate custom queries as needed.

Information Technology Integration Architecture

An EA integration artifact is an essential component of any enterprise architecture. Because the goal of enterprise architecture is to depict a holistic ontology of an organization or business, integration artifacts are essential to show how different layers and domains of architecture relate to each other.

Using ArchiMate, an enterprise architecture modeling language developed by The Open Group, architects can construct different views using its supported toolkit to demonstrate how organizations function. Because ArchiMate was developed based on the IEEE 1471 standard, the language is relatable to most professionals and can be easily adapted to other designing tools and languages.

Figure 4 presents a cross-layered integration of the four HIE architecture domains. Using ArchiMate, three views, Business, Information Systems, and Technology (Infrastructure) are mapped to show how the different layers of architecture interact with each other. This artifact shows how the business layer of architecture in an HIE is affected by data and application components. It also shows how the information systems layer (data and application domains) and its corresponding technology components relate to each other.

As seen in the artifact above the business layer is presented in yellow building blocks. Application and data components are represented in blue building blocks and technology components are represented in green building blocks. At the technology layer, ArchiMate is used to illustrate specific infrastructure components like physical nodes, computing devices, system software, network communications devices, and physical services.

4.2. HIE Cloud Migration Architecture

Executing a cloud migration is beneficial because HIEs can have access to greater computing capability, enhanced security, improved connectivity, and better storage capacity. A successful migration to the cloud requires a phased approach to ensure that no cloud competencies are compromised during migration. An unplanned migration can lead to data loss, systems outages, and cause significant downtime. This section proposes a phased migration plan and an information systems-focused migration architecture.

Phased Migration Architecture

ArchiMate is used with TOGAF ADM’s Phases E, F, and G to illustrate how an implementation architecture will look like. Using the migration architecture in figure 4 as a blueprint, an HIE can transition to leveraging cloud technologies.

The proposed migration architecture breaks the cloud migration plan into three main phases: planning, computing migration, and storage migration.

In this artifact, work packages are broken into a cloud computing migration program and a cloud storage migration program. The cloud computing migration program is triggered by a planning project and the cloud storage migration program is triggered by the computing migration program. Both computing and storage programs are made up of projects (work packages). Storage and computing programs are mapped to deliverables and deliverables are used to perform a gap analysis. Gaps represent the difference between the “as-is” state of an architecture and its associated end-goals (plateau).

Figure 5: HIE Cloud Implementation and Migration View

Mapping all aspects of an enterprise architecture is essential to ensuring that phases of a migration do not affect other architectural building blocks. Below are detailed implementation steps as proposed above.

All technology adoption steps begin with a project proposal and approval. Implementation events are triggers to commence project work. Thus, an HIE cloud migration will begin with an implementation event that shows executive approval of cloud migration. Once an implementation initiative is started, thorough planning must be performed by enterprise architects, program and project managers, and their executive boards.

After the planning work packages have been completed, project plans, program achievement strategies, and to-be architectures must be provided. These two deliverables are required for implementation steps to continue.

Once project plans and future (to-be) architectures have been provided, a compute migration is the first step to cloud migration.

It is important to keep computing systems online during and after the migration is completed. Keeping both on-premises and cloud computing services online will allow on-premises applications to serve as a backup if needed. This strategy can be used for data storage as well.

The work packages specified in this program are interface system cloud migration project, indexing system migration project, and an HIE portal migration project. It must be noted that during the indexing system migration, work should be done to ensure that notification services systems and data store components are functional.

A cloud leveraged computing migration is the first adoption of IaaS. As discussed in 2.3, IaaS includes the provisioning of storage, network, and computing capabilities from a cloud technologies service provider. This plateau marks the first realization state in the migration implementation after planning is completed.

After the computing migration program is implemented, a major gap involving the utilization of PaaS solutions and a cloud leveraged storage service remains.

The storage migration program involves migrating data related components to the Cloud. This begins with the migration of patient and provider databases to a cloud storage service. Once completed, notification services and its related repositories can be migrated. Afterward, other cloud relevant data stores can be migrated as needed.

CDR data should be migrated only after both patient and provider databases are confirmed to be stable in the cloud environment because its data is more mission-critical data. It is also important to note that persistent data like patient and provider data stores should be fully migrated and confirmed to be stable before real-time data like the CDR and notification services are migrated.

Once all HIE data stores have been migrated and storage services are confirmed to be functional, steps can be taken to decommission on-premises systems.

Application and Data Migration Architecture

In scenarios where applications and data stores need to be migrated to a new environment, application and data migration artifacts can be used to demonstrate the high-level processes required for a successful migration. Application and Data Migration Diagrams are usually used alongside as-is and to-be architectures to ensure application and data components are well accounted for. The diagram below highlights the high-level processes required to ensure that an HIE’s Interface System data and applications are well migrated from an on-premises system to a cloud-based environment. Using similar steps, architects can design other HIE information systems migration diagrams.

Figure 6: HIE Interface System Data and Application Migration

      Using the Interface System Data and Application Migration artifact, architects can view an HIE’s Interface System as-is architecture (HIE premises illustration on the left) and a to-be architecture with a cloud leveraged solution (Cloud Provider illustration the right). Once both viewpoints are presented, an architect can analyze and plan a migration path for both data and applications (Cloud solution strategy in the middle).

      As seen in Figure 6, the migration strategy for a Cloud leveraged Interface system is developed in the Cloud Solutions Strategy plateau introduced in Figure 5. At this step, application and data components are broken down into manageable pieces and arranged to ensure a successful migration.

      Both HIE Premise and Cloud Vendor locations are highlighted to distinguish an on-premises infrastructure from cloud vendors. Both on-premises and cloud leveraged equipment are also highlighted to show infrastructural ownership in an on-premises solution versus an IaaS or a PaaS solution.

      Using the processes and artifact presented in this section, other applications and data migration views can be created for the other systems described in this article.

Architectural Impact on Information Exchange

The exchange of information is an integral function of HIEs. An HIE cloud migration facilitates data flow and streamlines the exchange of health information. The introduction highlights two ways HIEs share information. From a business processes standpoint, an HIE’s value proposition and key activities are not greatly altered after a cloud migration. However, the architecture prescribed in our approach ensures that data flow is greatly improved regardless of whether an HIE is query-based or directed-data serving.

HIEs implementing a directed-data serving solution can benefit from a cloud-based solution because of the level of versatility provided when transferring different types of data across an HIE.

The utilization of an IaaS-based Interface System that leverages Platform-as-a-Service (PaaS) storage features with high computing capabilities will ensure that various data types, formats, and sizes can seamlessly flow through an HIE to external stakeholders. The proposed enhancement does not only exist at the infrastructure domain of an HIE architecture but the application domain as well. Specifically, during implementation, DIRECT Secure Messages applications and related CCD/HL7 APIs will need to be modified or migrated to a cloud computing system. Although Business processes will not need to be altered or modified, stakeholders will reap the benefits of this enhanced architecture as health record transfers are improved.

In a query-based solution, HIEs can use enhanced cloud technology to implement different application stacks to improve performance and enhance an HIE’s value proposition. Query-based HIEs provide an informational hub for its users and transfer data from/to health institutions as needed. The utilization of a cloud-based clinical data repository will allow HIEs to perform better real-time health data analytics. Improved transfer of health records from external stakeholders to the HIE will greatly improve how quickly data can be made available in emergency scenarios.

A cloud migration in a query-based HIE can affect all domains of architecture. Once an HIE cloud migration is completed, the use of ADT messages can be used as a trigger to real-time analytics. The improved infrastructure (technology) layers can birth improvements to application and business domains. Although major changes may not be required for the business layers, HIEs can be presented with more functionality. HIEs can adopt enhanced cloud capabilities and tools to develop applications and tools for its customers. For example, an HIE can use the enhanced processing power leveraged by cloud technologies to develop predictive reporting to external stakeholders using artificial intelligence and machine learning frameworks.

4.3. HIE EA Validation Framework

This section provides a validation framework for the migration architecture. Using the validation mapping and architecture evaluation plan presented below, architects are provided with a means of ensuring that HIE Enterprise Architecture for Cloud Migration is well implemented.

Architecture Validation Mapping

TOGAF and Zachman offer artifact templates that can be used to build an EA. The PQQD, as explained in the background section is a means of certifying that an HIE is adequately managing health data. To ensure that an HIE’s EA is well applied, the Validation Mapping Framework below has been proposed.

The diagram below shows a mapping of the three EA frameworks and presents artifacts types and process areas that can be used to determine if an implemented architecture is well applied.

Figure 7: HIE EA Validation Mapping

Using TOGAF as a core of the validation framework, we align other frameworks to the business, information systems, and technology categorizations of the TOGAF ADM. The TOGAF ADM Guidelines Techniques can be used if an HIE needs to better implement a domain of architecture discussed in this sub-section.

Since Zachman is primarily a classification framework, an HIE can use its structure to organize artifacts in each layer of architecture. Zachman can be used to simplify the creation of EA artifacts provided by the TOGAF ACF.

The PDDQ framework was originated to ensure that patient data is prioritized [12]. For the presented validation mapping, process areas have been re-arranged to fit layers of the TOGAF ADM. For each layer of architecture, process areas are provided to measure an HIE’s patient data management capability. To validate that an HIE is appropriately managing patient data after cloud migration, process area requirements for each layer of architecture should be measured.

Below is a breakdown of three architectural layers presented in the EA validation mapping.

Business: The Business layer represents stage B of the TOGAF ADM. The layer focuses on business strategy, organizational processes, and the day to day functions of a healthcare institution. In this validation framework, the business layer corresponds to the business domain of HIE architecture provided in section three. The Zachman framework recommends contextual, conceptual, and logical artifacts for this layer.

To ensure that an HIE has successfully implemented architecture from the business viewpoint, the following business-related processes from the PDDQ framework have been mapped: Governance Management, Business Glossary, Requirements Definition, Process Management, and Process Quality Assurance. These process areas were intricately studied and found to be related to the business layer.

Information Systems: The Information Systems layer is made up of a combination of the data and application domains in HIE architecture. Using the Zachman framework, Conceptual, Contextual, and Logical artifacts for scope, enterprise model, and system model are recommended.

HIEs can validate the architecture and its implementation with the following PDDQ process areas: Measurements and Assistance, Metadata management, Data Standards, Data profiling, Data Cleansing and improvements, Data lifecycle Management, and Data Provider Management.

Technology: At the lowest level of architecture, the technology layer deals with the network, hardware, infrastructure, and other physical operational components that support the management of business and information systems. The technology layer corresponds to the Infrastructure domain as discussed in the previous sections.

For Technology management, the PDDQ recommends the following process areas: Historical Data Archiving and Retention, Data Management Platform, and Data Integration. The Zachman framework recommends contextual (scope) and physical technology representation artifacts to create architecture.

HIE Enterprise Architecture Evaluation

An evaluation of traceability, reachability, and dependability is necessary to ensure that an enterprise architecture adequately aligns information technology to business.

Traceability is signified by how closely related components from different layers of architecture fit together to ensure interoperability [21]. Traceability traces how changes within a sector of an architecture propagate throughout other components within the same architecture [10]. An architecture’s robustness is best measured by its reachability. Dependability is a measure of how dependent each artifact and architecture building block is to one another.

An enterprise architecture traceability test is used to ensure that an IT department’s service offerings meet organizational goals. This means that there should be artifacts in place that clearly connect business components to information systems components and technology components, vice versa. The utilization of an IT portfolio is highly recommended by TOGAF. Measuring an IT portfolio with organizational operation metrics like costs, responsiveness, functionality, etc. is a great way to measure traceability. Also, mapping relationships between Business Process Modeling (BPM) diagrams, system design specifications, and use case diagrams are also a great means of evaluating traceability. An EA artifact like a Business Footprints Diagram can also be used to evaluate traceability.

Reachability is a test to ensure that information successfully traverses through an organization’s architecture. When evaluating an HIE’s level of architectural reachability, it is important to test how changes made at one layer of architecture propagates to other layers. For the proposed EA, utilizing architectural tools to simulate technology traversal is crucial. Structured modeled representations like sequence diagrams can be used to depict an architecture’s level of reachability.

      Composite dependability is the underlying goal of EA. While components of architecture should be interconnected, failure within sectors or layers of the EA should not cause the whole complete failure. Impact analyses and related evaluations can be used to perform a dependability assessment. Scenarios where changes within a function or artifact greatly affect the entire architecture should be addressed to strengthen the dependability of the enterprise architecture.

5. Conclusion

As discussed in previous sections, the adoption of cloud technology provides a greater level of availability, scalability, and flexibility to HIEs. HIE systems that reside in a cloud-based environment can efficiently and quickly improve its data transference capabilities as needed by throttling computing and network throughputs.

Enterprise Architecture is a tool that facilitates the adoption and implementation of technologies. For HIEs, EA provides an overarching view of its business and IT architecture. Once a complete view of the HIE’s architecture is developed, a pathway for the realization of desired future goals can be easily created.

The biggest drawback of an EA approach centers around organizational planning and architecting. Without oversight and governance, HIE enterprise architects can be found focusing more on architecture planning and modeling processes than EA implementation and institutionalization. This can lead to delays and project cost overruns.

However, once the EA is implemented, HIEs can achieve strategic alignment between business capabilities, application services, and enterprise systems [22]. An alignment of HIE business functions to organizational goals, enterprise strategy, IT operations, and IT systems becomes more apparent once EA is applied.

In this paper, an enterprise architecture that supports an HIE’s migration to the cloud for the facilitation of timely health data sharing is re-proposed. An EA institutionalization framework highlighting strategies and artifacts required to leverage the proposed architecture is presented. An HIE cloud migration architecture, providing a migration plan from an architectural standpoint is also presented. Finally, a validation framework that includes an evaluation plan and an architecture mapping is proposed to ensure that the HIE EA is well applied.

5.1.  Future Work

As future work, an implementation of the proposed EA will prove important. An evaluation phase should be performed once the EA has been implemented. During the EA evaluation process, the proposed architecture’s dependability, reachability, and traceability will be tested. The HIE EA Validation Mapping introduced in section four can also be used to ensure that the cloud-based HIE is well implemented.

Acknowledgment

The authors would like to thank Maryland’s HIE Chesapeake Regional Information System for our Patients (CRISP) for their help and support in this research endeavor.

1. K. Osei-Tutu and Y. T. Song, “Enterprise Architecture for Healthcare Information Exchange (HIE) Cloud Migration,” in Proceedings of the 2020 14th International Conference on Ubiquitous Information Management and Communication, IMCOM 2020, 2020.
2. L. MELLO, MICHELLE M.; ADLER-MILSTEIN, JULIA; DING, KAREN L .; SAVAGE, “Legal Barriers to the Growth of Health Information Exchange—Boulders or Pebbles?,” Light. Des. Appl. LD A, 48(5), 26–28, 2018.
3. J. R. Vest, M. A. Unruh, J. S. Shapiro, and L. P. Casalino, “The associations between query-based and directed health information exchange with potentially avoidable use of health care services,” Health Serv. Res., 981–994, 2019.
4. H. Wu and E. M. LaRue, “Linking the health data system in the U.S.: Challenges to the benefits,” Int. J. Nurs. Sci., 4(4), 410–417, 2017.
5. Y. Yang et al., “Medshare: A Novel Hybrid Cloud for Medical Resource Sharing among Autonomous Healthcare Providers,” IEEE Access, 6, 46949–46961, 2018.
6. I. I. Systems, “Applying Modular Design in Architecting Interorganizational Information Systems Development in Shanghai,” 2019, September 2008, 175–190, 2019.
7. A. Haghighathoseini, H. Bobarshad, F. Saghafi, M. S. Rezaei, and N. Bagherzadeh, “Hospital enterprise Architecture Framework (Study of Iranian University Hospital Organization),” Int. J. Med. Inform., 114, February 2017, 88–100, 2018.
8. R. Klischewski, “Information Integration or Process Integration? How to Achieve Interoperability in Administration,” 57–65, 2004.
9. H. Song and Y. T. Song, “Enterprise architecture institutionalization and assessment,” Proc. – 9th IEEE/ACIS Int. Conf. Comput. Inf. Sci. ICIS 2010, 870–875, 2010.
10. O. G. Standard and T. O. Group, “Open Group Standard The Open Group,” TOGAF® Stand. Version 9.2, 1–181, 2013.
11. J. a Zachman, “The Zachman Framework For Enterprise Architecture, Primer for Enterprise Engineering and Manufacturing,” CA Mag., 128(9), 15, 2003.
12. C. Institute, “Patient Demographic Data Quality ( PDDQ ) Framework,” Patient Demographic Data Quality Framework. CMMI Institute, 2018.
13. M. Lnenicka and J. Komarkova, “Developing a government enterprise architecture framework to support the requirements of big and open linked data with the use of cloud computing,” Int. J. Inf. Manage., 46, June 2018, 124–141, 2019.
14. S. Lee, S. Oh, and K. Nam, “Transformational and Transactional Factors for the Successful Implementation of Enterprise Architecture in Public Sector,” Sustainability,  8(5), p. 456, 2016. https://doi.org/10.3390/su8050456
15. N. A. A. Bakar, S. Harihodin, and N. Kama, “Assessment of Enterprise Architecture Implementation Capability and Priority in Public Sector Agency,” Procedia Comput. Sci.,  100,  198–206, 2016. https://doi.org/10.1016/j.procs.2016.09.141
16. D. D. Dang, S. Pekkola, and D. Duong Dang, “Systematic Literature Review on Enterprise Architecture in the Public Sector,”  15(2),  132–154, 2017.
17. F. Chitsa and T. Iyamu, “Towards enterprise technical architecture for the implementation of the South African NHI,” Adv. Sci. Technol. Eng. Syst.,  5(2),  724–729, 2020. https://dx.doi.org/10.25046/aj050290
18. J. C. Henderson and H. Venkatraman, “Strategic alignment: Leveraging information technology for transforming organizations,” IBM Syst. J.,  32(1),  472–484, 1993.
19. P. DePalo and Y.-T. Song, “Healthcare interoperability through enterprise architecture,” Proc. 6th Int. Conf. Ubiquitous Inf. Manag. Commun. – ICUIMC ’12, p. 1, 2012.
20. A. Boussadi and E. Zapletal, “A Fast Healthcare Interoperability Resources (FHIR) layer implemented over i2b2,” BMC Med. Inform. Decis. Mak.,  17(1),  1–13, 2017.
21. L. Chung and N. Subramanian, “Bridging the gap between enterprise architectures and software architectures,” Science of Computer Programming, 2007.
22. P. Bhattacharya, “Modelling Strategic Alignment of Business and IT through Enterprise Architecture: Augmenting Archimate with BMM,” Procedia Comput. Sci.,  121,  80–88, 2017. https://doi.org/10.1016/j.procs.2017.11.012

(Click Here)

(Click Here)