Cloud architecture for electronic health record systems interoperability

Abstract

BACKGROUND:

Current Electronic Health Record (EHR) systems are built using different data representation and information models, which makes difficult achieving information exchange.

OBJECTIVE:

Our aim was to propose a scalable architecture that allows the integration of information from different EHR systems.

METHODS:

A cloud-based EHR interoperable architecture is proposed through the standardization and integration of patient electronic health records. The data is stored in a cloud repository with high availability features. Stakeholders can retrieve the patient EHR by requesting only to the integrated data repository. The OpenEHR two-level approach is applied according to the HL7-FHIR standards. We validated our architecture by comparing it with 5 different works (CHISTAR, ARIEN, DIRAYA, LLPHR and INEHRIS) using a set of selected axes and a scoring method.

RESULTS:

The problem was reduced to a single point of communication between each EHR system and the integrated data repository. By combining cloud computing paradigm with selected health informatics standards, we obtained a generic and scalable architecture that complies 100% with interoperability requisites according to the evaluation framework applied.

CONCLUSIONS:

The architecture allowed the integration of several EHR systems, adapting them with the use of standards and ensuring the availability thanks to cloud computing features.

Keywords

Electronic health records Cloud EHR interoperability health informatics standards HL7 FHIR OpenEHR

1. Introduction

Electronic Health Record (EHR) arises in order to fulfil the need of prompt access to patient health information. The EHR is a repository of information regarding the health of a subject of care, in a computer processable form [1]. Even though tendencies indicate an increasing EHR adoption, patient health data remains isolated in different healthcare centres. EHR systems are built using different data representation and information model. In many cases, a proprietary format is used [2, 3]. EHR systems do not often incorporate interoperability mechanisms and, if there exists one, it is often an ad-hoc approach [4]. The lack of interoperability mechanism adoption is mainly caused by a high implementation cost [5].

There are several works that tackle the interoperability issue between EHR systems [3, 6, 7, 8, 9, 10, 11, 12, 13]. The issue is still open, however. This scenario can be noticed by the small number of electronic health data transmission among healthcare centres, reaching only 50% and 20% of moderate to heavy use in high and low-mid income countries, respectively [14].

To achieve EHR systems interoperability, the objectives of this work are as follows:

•
Identification and selection of health informatics standards.
•
Proposal of a scalable architecture that allows the integration of information from different EHR systems.
•
Validation of the architecture through a comparison with similar works.

Limitations of this work are cited below:

•
Security and privacy mechanism are not included within the scope of this work.
•
An identification provider for patients and doctors is assumed.
•
Identification and registration of medical staff and patients are not included.

We do not intend to provide a specific implementation of the architecture in this work; however, we present examples of tools that can be used in each part of the architecture (see Section 3.5).

The rest of the article is organized as follows: Section 2 mentions concepts and background to address the context of the work. Section 3 details the proposed architecture and presents examples of how parts of the architecture can be implemented. Section 4 presents the proposed evaluation mechanism and the validation of our proposal. Finally, conclusions and future works are mentioned.
2. Background

This section introduces concepts of technologies and health informatics standards.

2.1 Cloud computing application

Cloud computing technology provides ubiquitous and on-demand access to computational resources (e.g., networks, servers, storage, among others) that can be managed with less cost in comparison with traditional client-server architectures [15]. Moreover, potentials benefits, and opportunities of this technology have been identified within the context of patient care [16], such as:

•
Pay-per-use model of computational resources replaces large initial investment in IT infrastructure. Furthermore, this may reduce EHR adoption barriers.
•
Faster services deployment.
•
Abstraction from the complexity of build and manage data centres which allows healthcare centres to focus on their business.

2.2 Basic minimum data set

The Basic Minimum Data Set (BMDS) is the core set of information about a patient that should be stored in a healthcare center. Such core information may be used in patient care as well as in administrative context [17].

The goal of the BMDS is to normalize data bases capable of providing valid, trustful and comparable health care information from healthcare centres that conform to the national healthcare system [17].

BMDSs can be defined for different clinical documents. Examples includes BMDSs such as: BMDSs documents established in Spain for urgency, primary care, laboratory test, discharges report documents, among others [18]; the Consolidated Clinical Document Architecture (CCDA) that is based on HL7 Clinical Document Architecture (CDA) templates incorporating components of Integrating the HealthCare Enterprise Patient Care Coordination (IHE PCC), and Continuity of Care Document (CCD) [19].

2.3 Health informatics standards

To ensure interoperability, a set of complementary standards in different domains should be applied [1]. These domains can be grouped as follows:

•
Medical terminology: provides specific codes for clinical concepts that may differ in paper records. This group of standards can be divided into reference terminologies and classification terminologies. Reference terminologies are sets of concepts and relationships that provide a common reference point for comparisons, adding data about the health care process, which can be administrated by different users of the healthcare network (e.g. SNOMED CT). Classification terminologies are standards intended for classifying clinical conditions and procedures to support national and international statistical data analysis required by the healthcare system, by using clinical classification systems (e.g. ICD-10-CM/PCS).
•
Information exchange: provides syntax and structure for the information and its context, besides, provides the interface to allow the communication.
•
Information model: represents concepts, relations, restrictions, rules and operations that specify data semantics within a discussion universe.

Two of the most important standards that are applied in our proposal are OpenEHR and Health Level 7 Fast Healthcare Interoperability Resources Release 4 (HL7 FHIR ${}^{\@setsize{\scriptsize}{9.5pt}{\viiipt}{\@viiipt}\textregistered}$ R4).

OpenEHR proposes a two-level approach for information modelling. The first level is the reference model, and the second is the modelling of high-level clinical concepts. Only the first level is implemented through software development while the second level is achieved by defining archetypes and templates.

The reference model defines data types and data structures to support creation of archetypes [20]. Archetypes constitute a semantic domain expression, technology independent, and can be used to guide database schemes, software logic, and even user interfaces. An archetype defines a basic domain concept (e.g., blood pressure) [20].

Templates are conformed by groups of archetypes or being part of archetypes. They represent more complex concepts or particular workflows within an organisation. For example, by grouping several archetypes, a template of medical encounter can be defined where one of the archetypes would be the blood pressure archetype [20].

HL7 FHIR is an information exchange standard in healthcare. HL7 FHIR is composed of modular concepts that represents a high-level information model, named as resources. Every content to be exchanged is encapsulated within resources. Resources can represent administrative concepts such as the patient, a provider, or an organization, as well as clinical concepts (i.e. medications, diagnostic reports). HL7 FHIR goal is to build a set of resources to satisfy information use cases, being used in conjunction or isolated [21].

Our work is based on the use of the health informatics standards and cloud computing to ensure interoperability and scalability. The BMDS defines the scope of the information to be exchanged between EHR systems. The proposed architecture is described in the next section.
3. Proposed architecture

The proposal consists in a generic architecture to integrate information from various healthcare centres. To achieve interoperability, we selected several standards dominants in their respective area (see Table 1).

Table 1
Standards selection summary

Selected standard	Application group
SNOMED CT [23]	Reference terminologies codification
LOINC [24]	Reference terminologies codification
ICD 10 PCS [25]	Classification terminologies codification
HL7FHIR [30]	Information model, data structures for information exchange, REST API
OpenEHR [21]	Reference information model

An overview of the architecture shows that the health care centres may use an EHR system (Fig. 1a), and the information is sent to a high availability repository (Fig. 1b). The integration is accomplished by converting the collected information to a standardized information model HL7 FHIR (Fig. 1b). Integration of information from healthcare centres that do not have an EHR system is also considered. This is achieved by providing a web interface through the Software as a Service (SaaS) modality (Fig. 1c) [15]. Unlike centralized systems described in [25], where there is risk of losing all of the data if the centralized organisation is destroyed, we propose the data integration using the materialized approach (see Section 4.2.2).

Figure 1.

Overview of the proposed architecture.

With this proposal there is only a single point of communication between each EHR system and the integrated data repository. Through this approach, systems are abstracted from the number of participants. Patient data will be integrated and ready to be accessed by system members.

The repository and services provided by the architecture are maintained in a cloud infrastructure, ensuring the availability and scalability thanks to the features offered by cloud [15]. As a result, a robust and centralized architecture is obtained instead of relying on the availability of multiple services and systems maintained by different institutions [26].

Figure 2.

Proposed architecture for the EHR systems interoperability.

The proposed architecture is composed of HL7 FHIR information model adapters (Fig. 2a), OpenEHR templates to represent HL7 FHIR resources (Fig. 2b), the mapping of the standardized information to the OpenEHR reference model (Fig. 2c), and an EHR system offered through SaaS (Fig. 2d).

In the next sections, we explain the details of the architecture components (Sections 3.1–3.4) and at the end (Section 3.5), we outline its implementation in the context of immunization information exchange.

3.1 HL7 FHIR adapters

A prerequisite for information integration and interoperability is to standardize the information model to be used [27]. For this purpose, we map the Basic Minimum Data Set (BMDS) to the HL7 FHIR information model. A set of resources is chosen to represent the BMDS.

HL7 FHIR combines the best features of previous HL7 standards for information exchange. Moreover, HL7 FHIR can be used together with previous standards, such as HL7v2 or HL7v3 [28]. The current version of the HL7 FHIR standard is 4.0.1, which corresponds to the Standard for Trial Use (STU).

In order to standardize the information model, we propose a module that is in charge of the mapping between external standards and the HL7 FHIR model called “FHIR Adapter”.

The goal of adapter module is that each participant of the many systems exchange information through it. Each external system can send and receive data from the integrated data repository in its standardize, by eliminating the complexity of understanding how to communicate with each participant. External systems thus only need to communicate with one interface, which enables to query all integrated data and send its data as well. Those external systems that implement HL7 FHIR do not need an adapter. As an example, three hospitals exchange data through a HL7 FHIR server (Fig. 2a).

The information model also includes selected terminology standards (LOINC, SNOMED, ICDE), to codify the concepts. HL7 FHIR defines a data type called “CodeableConcept” which establishes a structure for coded concepts exchange [21]. CodeableConcept is composed by text, which describes the exchangeable concept and coding which represents a code for the concept that is defined within a standard terminology. Another property of HL7 FHIR system allows identifying the concept of the code, the codification system, the version of the system being used, etc. [21].

3.2 HL7 FHIR resources representation in OpenEHR templates

The OpenEHR two-level approach is adaptable to changes that occur in the information model, without incurring in modifications in the reference model schema [20, 29]. This approach provides a scalable way to support new requirements of the BMDS, HL7 FHIR updates or creating new types of resources.

On the other hand, the OpenEHR standard is defining how to offer services to query and record data in the data repository through a REST API interface. The specification of the OpenEHR REST API interface is in the trial version [30]. In this regard, HL7 FHIR standard is a great match by defining the information structure to be exchanged and specifying how to perform queries and send data through a REST API.

HL7 FHIR also allows “Profiling”, which is a process of creating an implementation guide that describes the general features that are supported by the system for each kind of resource. A specific implementation of HL7 FHIR may extend or limit the use of the resources [21]. Although there are some projects that provide structures to store FHIR resources (e.g., FHIR Base [31]), which are not part of the HL7 FHIR standard specifications. In order to provide a standard and scalable solution, we propose to use OpenEHR as a model and storing modifications or updates made to the resources, taking advantage of the stable OpenEHR reference model scheme [20], while FHIR provides the higher level model and REST API for data exchange.

Data types and HL7 FHIR objects are used as input to the model archetypes (Fig. 2b). When archetypes are defined, they can be grouped to conform OpenEHR-FHIR templates that represent HL7 FHIR resources.

3.3 From HL7 FHIR to OpenEHR

After obtaining the OpenEHR templates that represent HL7 FHIR resources, a direct bidirectional mapping with the OpenEHR templates instances is performed for each resource generated from the communication with external systems. Then, examples of the templates with values in their attributes are stored in the data repository using the OpenEHR reference model.

A service acts as an intermediary between HL7 FHIR resources coming from the external systems communication and the persistence server (Fig. 2c). The intermediary oversees instantiating the OpenEHR templates that represent the corresponding resources and store data contained in the templates.

3.4 EHR system through SaaS

The EHR module goal is to deliver a Software as a Service (SaaS) modality to those healthcare centres that do not have an EHR system. The service will be deployed in the cloud and clients will only need terminals (web or mobile) to access the system. With this approach, healthcare centres will not be needed to mount and maintain a significant IT infrastructure.

SaaS modality helps to expand the EHR adoption to healthcare centres that are isolated or suffer from adjusted budget [3, 32]. Collected data from these healthcare centres through the EHR module will be ready to conform the HL7 FHIR resources and be thus integrated into the central repository, to allow users within these healthcare centres to query the integrated data from the central repository.

Hospital interaction with the central repository is possible with the EHR system Fig. 2d. Users in the hospital are allowed to query integrated data from the repository and data collected in the place sent with HL7 FHIR model conformance.

3.5 Outline of the architecture implementation

The mappings within the adapters can be dinamical or performed case by case, the final mapping should be reviewed by an expert in the given health context. In some cases, the external format can be based on other standards, such as HL7 v2 [33], where mappings to FHIR resources already exist [34].

We can model a generation of OpenEHR FHIR templates following the proposal in [35], where data types and composite data types are extracted from the HL7 FHIR Ecore model [36] to build archetypes that represent the “FHIR Reference Model” and then use these archetypes to conform the resources. The process can be done automatically to obtain archetypes from new FHIR resources and resources updates.

The OpenEHR FHIR templates can be stored in the data repository using the OpenEHR reference model. The implementation of an OpenEHR data repository and the corresponding reference model was developed in an open source project named “EHR-Server” [37].

Once HL7 FHIR is established as API interface to interact with the data repository, there are several ways to deliver a SaaS to clients that do not have access to an EHR system. These SaaS can be delivered through web or mobile applications by implementing the correspondence to HL7 FHIR clients. HL7 FHIR server API as well as HL7 FHIR clients can be implemented by using libraries which are available as reference implementations [38]. For example, HAPI-FHIR is a java library which provides support for the resource models, REST API definition and client-side support in JAVA [39].

4. Evaluation and comparison

The purpose of this section is to validate the proposed architecture by comparing it with similar works reported in the literature through an evaluation framework.

4.1 Evaluation framework

The evaluation was made based on a framework that analyzes EHR systems [4]. According to this, there are four stages of health organization evolution in the progression of autonomous modes of working to fully coordinated shared care with a high degree of specialization and expertise as follows:

•
Stage 1: highly fragmented practice with individuals functioning autonomously and little specialization. There are unspecific tasks for each part.
•
Stage 2: referral networks of loosely structured multidisciplinary teams.
•
Stage 3: more patient care-based team but focusing primarily on needs and intentions of health care professionals with some decision support but little integration of health information.
•
Stage 4: shared multidisciplinary care, evidence-based and patient-centric practice with strong service coordination between practices and with good quality practices and performance measures.

The framework can be applied to asses an EHR system during their progress to stage 4 of full interoperability stage.
4.2 Application of the framework and validation of the proposal

The framework [4] describes an EHR system with a set of axes. In order to validate our proposed architecture, we focused in axes that assess interoperability requirements and data management, and avoided axes that describe purely functional characteristics of system implementations.

Table 2
Axes set considered in the modified framework [4]

Axes	Characteristics
Information model type	Single model	Two level modelling
Distribution of data	Consolidated	Federated	Materialized
Temporal (*)	Retrospective	Concurrent	Prospective
Organisation	Speciality-oriented	Episode-oriented	Problem-oriented	Neutral
Interoperability	Not interoperable	Functional interoperability	Semantic interoperability

Every axis has set of characteristics (Table 2), it is recommended to read it horizontally. Any given axis shown in the table, as an EHR architecture evolves from left to right (horizontally), it improves its ability to support such multidisciplinary shared healthcare, reaching the ideal stage 4. Given an EHR interoperability architecture, it could have more than one choice for a given axis (for instance, the Temporal axis, an architecture may include retrospective, current and prospective information). Although in other axes a given EHR interoperability architecture can satisfy one of the characteristics of the mentioned axis exclusively in this manner. Multiple choice axes are marked with (*). In this research we considered that each characteristic is as important as the others.

4.2.1 Information model type

A “Single” model corresponds to the process of defining information requirements demanded by specialists, and the development of a large data model. The clinical concepts change through the time, so the underlying data model will change too [4]. “Two-level” modelling, also named as adaptive-level model, separates the model of information and the model of knowledge. The information model is represented with a simple and stable data model over time. Although, the knowledge model is represented as an instance of the information level [4].

4.2.2 Distribution of data

Data distribution is the mechanism applied to create unified view of patient data. There are three general types:

•
Consolidated data [1]: data is stored in system repository where the data is retrieved and then delivered to the specialist. There might be problems with scalability and security. Furthermore, it requires that healthcare centres migrate the information from their systems to this repository in order to use it
•
Federated data [1]: data storage distributed across different sources are queried to gather patient information. This approach can suffer from syntactic and semantic integration issues. Moreover, it suffers significant performance limitations due to repeated queries to remote database servers and data integration (transformation) processes that must be performed at the request time.
•
Materialized data [40]: this is a mixed approach from the ones described before, where a part or the whole EHR data may be materialized in a local data repository.

4.2.3 Temporal (*)

An EHR system should provide a longitudinal view of a patient’s health care. In this situation, we cite the following types of information:

•
Retrospective information: medical record.
•
Current information: Present illness and treatment.
•
Prospective information: doctor’s decisions and planned therapeutic interventions.

4.2.4 Organisation

It refers on how information is organized in an EHR, it could be one of these as it follows:

•
Speciality-oriented [4]: refers to speciality organisation with a healthcare center.
•
Episode-oriented [4]: information is indexed along the time-line according to the interactions between a patient and care providers.
•
Problem-oriented [41]: information is indexed by the list of clinical illnesses of the subject. This provides a clinically-oriented view of the patient.
•
Neutral [4]: The EHR structure is not predefined, the organisation of the data is defined by each health professional according to the specific needs.

4.2.5 Interoperability

This refers to the ability of exchanging information between the systems [42]. The EHR system based on architecture is designed to satisfy specific local needs of the healthcare centres, and ignoring interoperability they are classified as not interoperable [4].

The next level corresponds to functional interoperability [1]. This happens when systems agree on the information structure to be transmitted. For instance, applying the standard HL7 v2 in data exchange is a case of functional interoperability. In [4], disadvantages of this approach are addressed. We can cite the following ones:

•
Adchoc agreements between two system of information structure to be exchanged.
•
Documents that were defined by explained information and how it should be interpreted.
•
Ambiguity in optional fields that should be processed.

The highest interoperability level corresponds to semantic interoperability where information interchange is interpreted and computer-processable [4], where terminology definitions and domain concepts standards have main roles. The two level approach is important in this context, through information model represented by archetypes points to standardize retrieved and context information. Moreover, archetypes can reference terminology standards [4, 20].
4.3 Scoring method

We propose the following evaluation system using the selected framework axes. For the scoring schema, the results should be normalized to equitably rate each axis. The closer it gets to the right within an axis is a characteristic that improves their rating. Axes with “(*)” means that more than one characteristics can be fulfilled at the same time; thus, all characteristic in these axes are equally rated. The final score is given by the expression:

$\displaystyle\text{Final Score}=\frac{\mathop{\sum}\nolimits_{i=1}^{n}\frac{% \textit{Score}_{i}}{\textit{Total}_{i}}}{n}\ast 100$ (1)

Table 3

Evaluation of our proposal and similar works, in the context of architecture, for EHR systems interoperability

Architecture	Characteristics	Characteristic score	Proposed architecture	CHISTAR	ARIEN	DIRAYA	LLPHR	INEHRIS
Information	Single model	1	–	–	1	1	1	–
model	Two level modelling	2	2	2	–	–	–	2
	Axis score		1.0	1.0	0.5	0.5	0.5	1
Distribution	Consolidated	1	–	–	–	1	–	–
of data	Federated	2	–	–	2	–	2	–
	Materialized	3	3	3	–	–	–	3
	Axis score		1.0	1.0	0.67	0.34	0.67	1.0
Temporal (*)	Retrospective	1	1	1	1	1	1	1
	Current	1	1	1	1	1	1	1
	Prospective	1	1	1	1	1	1	1
	Axis score		1.0	1.0	1.0	1.0	1.0	1.0
Organisation	Speciality-oriented	1	–	–	–	–	1	–
	Episode-oriented	2	–	–	–	–	–	–
	Problem-oriented	3	–	–	–	–	–	–
	Neutral	4	4	4	4	4	–	4
	Axis score		1.0	1.0	1.0	1.0	0.25	1.0
Interopera-bility	Not interoperable	1	–	–	–	–	–	–
	Functional interoperability	2	–	–	–	–	2	–
	Semantic interoperability	3	3	3	3	3	–	3
	Axis score		1.0	1.0	1.0	1.0	0.67	1.0
	Final score		100	100	83.4	76.8	61.8	100

Where:

•

$i$ value corresponds to each evaluated axis.

•

Score corresponds to the number of columns at the right where the accomplished characteristic is located (starting at 1). If the axis has an “(*)”, Score represents the quantity of accomplished characteristics in the axis.

•

Total is the number of characteristics in the axis.

•

$\frac{\textit{Score}}{\textit{Total}}$ represents the normalized score in the axis $i$ .

•

To get the final score, we sum the final score of every axis i, then normalized it by dividing it by n and multiplying it by 100.

•

$n$ stands for the number of axes ( $n=$ 5 in our case).

4.4 Validation of the proposed architecture

In order to validate our work, we present the evaluation made for our proposal and some researches that follow similar approaches to solve the interoperability issues. These researches are the following:

•
Cloud Health Information Systems Technology ARchitecture (CHISTAR) is stored in a cloud and it has an integrative engine, which can integrate information from different standards through semantic matching, making possible to convert data in external formats to the CHISTAR standard information model [3].
•
AdapteR Interoperability ENgine mediation system (ARIEN) consists of ontology mapping [43]. ARIEN build mapping files through the Mapping Authoring Environment (MAE) module, stores them in the Mediation Bridge Ontology (MBO) and use those mapping files in the Mapping Execution Environment (MEE) to perform transformations among different information model standards [9].

Table 4
Differences between the proposal and the CHISTAR and INEHRIS architectures

Architecture Proposed architecture CHISTAR INEHRIS

Data integration Communication structure is defined by HL7 FHIR resources. Participants can communicate to the integrated data repository using standard REST API defined by HL7 FHIR, or using services defined within an adapter that later will be mapped to FHIR structures Data integration is performed through semantic matching within the integration engine A Health Information Middleware Interface (HIMI) transform the health data to a semantically interoperable health information, using the Clinical Information Modeling Initiative (CIMI) for the healthcare providers. The comunication of healthcare providers is performed according to the FHIR standards framework.

Data reutilization Data can be sent or queried from the integrated data repository using SaaS modality or current existing EHR systems by performing request to the REST API Once data is integrated in CHISTAR repository, users can perform certain queries and operations through a web client offered by CHIS-TAR [3] Each transaction between entities is recorded from a logging service along requests to the nearest Health Districte (HD) repository synchronously.

•
DIRAYA is an EHR system employed in Spain, its architecture consists of several interconnected data centres, the main goal of DIRAYA is to integrate the information of every patient, the HL7 v2 standard is used for information exchange [12].
•
LifeLong Personal Health Record (LLPHR) project was designed in Italy. LLPHR provides access to logic links that point to EHR stored in healthcare centres. The integrated EHR is obtained by retrieving each EHR in real time. LLPHR relays on the availability of each system to retrieve the patient EHRs [6].
•
Integrated Nationwide Electronic Health Record Information System (INEHRIS) is a semi-distributed architecture made for the National Greek Health Record System, a new proposal centered in citizens. The main entities are the Ministry of Health, the Health Districts, the public and private Hospitals, private doctors, diagnostic centers, private laboratories, and the citizen that incorporates the advantages of the centralized architecture and the distributed architecture. It gives fast and real time replies on patients’ health data requests using a central repository. There are seven central district repositories that offer fast replies on patients’ health data request because the data is distributed to every repository using a Clinical Information Modeling Initiative [44] – FHIR (CIMI-FHIR), a semantically interoperable standard format by Ministry of Health, which is mainly useful for the EHR basic health data [45]. INEHRIS is a two level of information model type because it uses CIMI for providing a common definition of health information semantically interoperable, a two level approach.

We made the evaluation framework by inferring the architecture of each work description about the axes. The Table 3 shows the score by axis and final score for each work according the fulfilled characteristic founded in the documentation of each work [3, 6, 8, 9, 12]. Both the axis score and the final score were calculated from the expression Eq. (1), according the axes and characteristics from Table 2.

Although scores for our proposal and the CHISTAR’s and INEHRIS architectures are equal according the evaluation framework, we can appreciate a few differences between them, and these are detailed in Table 4. After this evaluation, we can confirm that our architecture is valid for the complex task of EHR system interoperability.
5. Conclusions

Architecture	Proposed architecture	CHISTAR	INEHRIS
Data integration	Communication structure is defined by HL7 FHIR resources. Participants can communicate to the integrated data repository using standard REST API defined by HL7 FHIR, or using services defined within an adapter that later will be mapped to FHIR structures	Data integration is performed through semantic matching within the integration engine	A Health Information Middleware Interface (HIMI) transform the health data to a semantically interoperable health information, using the Clinical Information Modeling Initiative (CIMI) for the healthcare providers. The comunication of healthcare providers is performed according to the FHIR standards framework.
Data reutilization	Data can be sent or queried from the integrated data repository using SaaS modality or current existing EHR systems by performing request to the REST API	Once data is integrated in CHISTAR repository, users can perform certain queries and operations through a web client offered by CHIS-TAR [3]	Each transaction between entities is recorded from a logging service along requests to the nearest Health Districte (HD) repository synchronously.

In this work, we addressed the EHR system interoperability issue. We selected several health informatic standards which are dominant in their respective areas, also complementary between them. The resulting set of standards to be applied are SNOMED-CT, LOINC, ICD-10-CM, ICD-10-PCS, HL7 FHIR and OpenEHR. These standards were applied in the proposed architecture.

The architecture allows the integration of several EHR system, adapting the different information model through the use of standards and ensuring the availability thanks to cloud computing features. Scalability is also accomplished by modelling new BMDS requirements on demand, using HL7 FHIR and OpenEHR. The proposal was validated through an evaluation framework, by comparing it to similar works reported in the literature, achieving a high score in the comparison along with CHISTAR and INHERIS. The main differences between them are the data integration and reutilization. By combining cloud computing paradigm with selected health informatics standards, we obtained a generic and scalable architecture that accomplish the high-level interoperability requisites, according to the evaluation framework. After the comparison with five similar works, the results showed that the proposed architecture is valid in the EHR system interoperability context. For the future, the proposed architecture should be implemented, this will allow the evaluation in performance considering scalability in resources with different workloads as well as the efficiency in the effective rate of information exchange among the various EHR systems.

Footnotes

Conflict of interest

None to report.

References

Schloeffel

. Electronic Health Record Definition, Scope and Context. ISO, TC 215; (2002).

Adebesin

Kotze

Foster

Van Greunen

. A Review of Interoperability Standards in E-health and Imperatives for their Adoption in Africa. ZA Comp. 2013; 50(1): 55-72.

Bahga

Madisetti

. A cloud-based approach for interoperable electronic health records (EHRs). IEEE J Biomed Health Inform. 2013; 17(5): 894-906. doi: 10.1109/JBHI.2013.2257818.

Bisbal

Berry

. An analysis framework for electronic health record systems. Methods Inf Med. 2009; 48(1). doi: 10.3414/ME09-01-0002.

Bender

and Sartipi

. HL7 FHIR: An Agile and RESTful approach to healthcare information exchange. Proceedings of the 26th IEEE international symposium on computer-based medical systems; 2013 June 20-22; Portugal. IEEE: 2013, pp. 326-33. doi: 10.1109/CBMS.2013.6627810.

Barbarito

Pinciroli

Mason

Marceglia

Mazzola

Bonacina

. Implementing standards for the interoperability among healthcare providers in the public regionalized Healthcare Information System of the Lombardy Region. J Biomed Inform. 2012; 45(4): 736-745. doi: 10.1016/j.jbi.2012.01.006.

De Potter

Cools

Depraetere

Mels

Debevere

De Roo

Huszka

Colaert

Mannens

Van de Walle

. Semantic patient information aggregation and medicinal decision support. Comput Methods Programs Biomed. 2012; 108(2): 724-735. doi: 10.1016/j.cmpb.2012.04.002.

Specifications

. IHE IT Infrastructure Technical Framework [Internet]. Revision 13.0, 2016. [updated 2016 Sept 9; cited 2021 Aug 9]. Available from: https//www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev13.0_Vol3_FT_2016-09-09.pdf.

Khan

Khattak

Hussain

Amin

Afzal

Nugent

Lee

. An adaptive semantic based mediation system for data interoperability among health information systems. J Med Syst. 2014; 38(8): 1-18. doi: 10.1007/s10916-014-0028-y.

10.

Koufi

Malamateniou

Vassilacopoulos

Prentza

. An android-enabled mobile framework for ubiquitous access to cloud emergency medical services, 2012 Second Symposium on Network Cloud Computing and Applications; 2012 December 3-4; London, UK. IEEE: 2012; pp. 95-101. doi: 10.1109/NCCA.2012.30.

11.

Lee

S-H

Song

Kim

. CDA generation and integration for health information exchange based on cloud computing system. IEEE Trans Serv Comput. 2014; 9(2): 241-249. doi: 10.1109/TSC.2014.2363654.

12.

Protti

. Moving toward a single comprehensive electronic health record for every citizen in Andalucía, Spain. Electron Healthc. 2007; 6(2): 114-123.

13.

Van Gorp

Comuzzi

. Lifelong personal health data and application software via virtual machines in the cloud. IEEE J Biomed Health Inform. 2013; 18(1): 36-45. doi: 10.1109/JBHI.2013.2257821.

14.

WHO Global Observatory for EHealth. Management of patient information: trends and challenges in Member States: based on the findings of the second global survey on eHealth [Internet]; 2012 [cited: 2021 Aug. 1]. Available from: https//apps.who.int/iris/handle/10665/76794.

15.

Mell

Grance

. The NIST Definition of Cloud Computing: Recommendations of the National Institute of Standards and Technology [Internet]; 2011 [cited: 2021 Aug 1]. Available from: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf.

16.

Kuo

M-H

. Opportunities and challenges of cloud computing to improve health care services. J Med Internet Res. 2011; 13(3): e67. doi: 10.2196/jmir.1867.

17.

Werley

Devine

Zorn

Ryan

Westra

. The Nursing Minimum Data Set: abstraction tool for standardized, comparable, essential data. Am J Public Health. 1991; 81(4): 421-426. doi: 10.2105/ajph.81.4.421.

18.

Ministerio de Sanidad y Política Social. Aprobación del conjunto mínimo de datos de los informes clínicos en el Sistema Nacional de Salud [Internet]. Spain: Boletín Oficial del Estado; 2010 [cited 2021 Aug 1]. Available from: https//www.boe.es/eli/es/rd/2010/09/03/1093.

19.

Health Level Seven. Consolidated CDA Templates for Clinical Notes US Realm Draft Standard for Trial Use Release 21. [Internet]. [cited 2021 Aug 1]. Available from: http//www.hl7.org/implement/standards/product_matrix.cfm.

20.

openEHR Foundation. openEHR. Reference Model (RM) – Release-10.4. [Internet]; 2018 [cited 2021 Aug 1]. Available from: https//specifications.openehr.org/releases/RM/Release-1.0.4/.

21.

Health Level Seven. HL7 Fast Healthcare Interoperability Resources Specification[Internet]; 2020 [updated 2019 Nov 1; cited 2021 Aug 1]. Available from: https//www.hl7.org/implement/standards/product_brief.cfm?product_id=449.

22.

Benson

. Principles of health interoperability HL7 and SNOMED, Springer London, 2010.

23.

LOINC. LOINC and Other Standards [Internet]; 2020 [updated 2020 Jun 26; cited 2021 Aug 1]. Available from: https://loinc.org/kb/faq/loinc-and-other-standards/.

24.

Centers for Medicare and Medicaid Services. ICD-10-PCS Reference Manual [Internet]; 2019 [cited 2021 Aug 1]. Available from: https//www.cms.gov/medicare/coding/icd10/downloads/pcs_refman.pdf.

25.

Quantin

Coatrieux

Fassa

Breton

Jaquet-Chiffelle

. Centralised versus decentralised management of patients’ medical records. In Medical Informatics in a United and Healthy Europe. Bosnia: IOS Press; 2009; pp. 700-704.

26.

Schiza

Neokleous

Petkov

Schizas

. A patient centered electronic health: eHealth system development. Technol Health Care. 2015; 23(4): 509-522. doi: 10.3233/THC-150919.

27.

Bernstein

Bruun-Rasmussen

Vingtoft

Andersen

Nøhr

. Modelling and implementing electronic health records in Denmark. Int J Med Inform. 2005; 74(2-4), 213-220. doi: 10.1016/j.ijmedinf.2004.07.007.

28.

Health Level Seven. Appendix: The Relationship between FHIR and other HL7 Standards [Internet]; 2019 [cited 2021 Aug 1]. Available from: https//www.hl7.org/fhir/DSTU1/comparison.html.

29.

openEHR. What is openEHR? [Internet], 2019 [cited 2021 Aug 1]. Available from: https//www.openehr.org/about/what/_is/_openehr.

30.

openEHR Foundation. API Overview [Internet]. REST API specification, 2019; [cited 2021 Aug 1]. Available from: https//specifications.openehr.org/releases/ITS-REST/latest/overview.html.

31.

FHIRbase. FHIRbase [Internet], 2016 [cited 2021 Aug 1]. Available from: https://github.com/fhirbase/fhirbase.

32.

Gök

. Introducing an openEHR-Based Electronic Health Record System in a Hospital [Internet], 2008 [cited 2021 Aug 1]. Available from: https//eva.fing.edu.uy/file.php/286/openEHR_-_goek-masters-thesis_2008.pdf.

33.

Centers for Disease Control and Prevention. Implementation Guide for Immunization Data Transactions using Version 23.1 of the Health Level Seven (HL7) Standard Protocol [Internet], 2006 [cited 2021 Aug 1], p. 147. Available from: https//www.cdc.gov/vaccines/programs/iis/technical-guidance/downloads/hl7guide.pdf.

34.

Health Level Seven. Resource Immunization – Content, 2019 [cited 2021 Aug 1]. Available from: https//www.hl7.org/fhir/immunization.html.

35.

Bosca

Moner

Maldonado

Robles

. Combining archetypes with fast health interoperability resources in future-proof health information systems, Digital Healthcare Empowering Europeans: Proceedings of MIE 2015. Madrid, Spain; IOS Press; 2015; pp. 180-184. doi: 10.3233/978-1-61499-512-8-180.

36.

Health Level Seven. FHIR Release 4. FHIR resources. Ecore definitions [Internet], 2012 [cited 2021 Aug 1]. Available from: https//www.hl7.org/implement/standards/FHIR/2012Sep/ecore.zip.

37.

Pazos

. CaboLabs EHR Server Guide [Internet], 2020 [cited 2021 Aug 1]. Availablefrom:https://github.com/ppazos/cabolabs-ehrserver.

38.

Health Level Seven. FHIR Release 4. Open Source FHIR implementations. In: WiKi [Internet], 2019 [cited 2021 Aug 1]. Available from: https//wiki.hl7.org/Open_Source_FHIR_implementations.

39.

HAPI FHIR [homepage on the Internet], 2020 [updated: 2021 Sept. 3; cited: 2021 Aug. 3.]; Available from: https//hapifhir.io/.

40.

Hull

Zhou

. A framework for supporting data integration using the materialized and virtual approaches. Proceedings of the 1996 ACM SIGMOD international conference on Management of data; 1996 June 4-6, NY, US: Association for Computing Machinery: 1996. pp. 481-492. doi: 10.1145/235968.233365.

41.

Weed

. Medical records that guide and teach, 1st edn, Apple Academic Press, 2014, p. 348.

42.

Noy

. Semantic integration: a survey of ontology-based approaches. ACM Sigmoid Rec. 2004; 33(4): 65-70. doi: 10.1145/1041410.1041421.

43.

Berners-Lee

. The Semantic Web, Scientific American [Internet]. [cited 2021 Aug. 3]. Available from: https//www.scientificamerican.com/article/the-semantic-web/.

44.

Health Level Seven. Clinical Information Model Initiative (CIMI) Reference Model Specification [Internet], 2017 [updated 2017 Dec. 6 cited 2021 Aug. 3]. Available from: http//models.opencimi.org/cimi_doc/.

45.

Fragidis

Chatzoglou

Aggelidis

. Integrated nationwide electronic health records system: semi-distributed architecture approach. Technol Health Care. 2016; 24(6): 827-842. doi: 10.3233/THC-161231.