Towards a New Paradigm of Federated Electronic Health Records in Palestine

Abstract

While efforts are underway to create a sound system of electronic health records in Palestinian health institutions, there remain obstacles and challenges. Given modern day demands on health systems, we propose a federated electronic health system based on the clinical document architecture (CDA) that is compliant within the Palestine context. This architecture also brings a normalized electronic health record and a structure of blockchain to enhance interoperability with scalability, fault tolerance, privacy, and security. The new architecture and technologies will enhance services by allowing health care players, patients, and others to have the opportunity to obtain improved access and control of their health services. This may also serve as a useful model for other low-middle income countries.

1. Background

According to the World Health Organization (WHO), the electronic health records (EHRs) adoption rates of the last 15 years have been very low in the lower-middle to low income countries, i.e., 35% and 15% respectively [1]. Many of the systems in these countries are not compliant with the International Organization for Standardization (ISO) standards and do not meet the requirements for federated electronic health records (FEHRs). A lack of sustainability due to poor economics and resources has also impacted implementation in some countries [2], and despite good intentions, many clinics are using incomplete or incompatible solutions [3].

For the purpose of the Palestinian context, we propose a FEHR system that is an integrated national system of all electronic health records with numerous functionalities (see Section 2). Palestine may be the ideal country to create a case study that will trigger the adoption of new open systems that may leverage telehealth around the world.

Status of Healthcare Sector in Palestine

The Palestinian territories is a low-middle income country with a population of approximately 4.98 million—with 2.99 million in the West Bank and 1.99 million in the Gaza Strip [4]. According to the Palestinian Central Bureau of Statistics (2016), the total current expenditure on health reached 1.419 million USD (10.7% of GDP). Expenditure is covered by the government (around 37%), private insurance companies (around 3%), households/out-of-pocket (around 41%), nonprofit organizations (around 18%), and others (around 1%). A World Bank report in 2018 noted that around 29% of Palestinians live in poverty, while 2.5 million are in need of humanitarian assistance with some 2.5 million reported as food insecure. Furthermore, access to healthcare, movement of patients, doctors, and ambulances in the West Bank are all adversely impacted by numerous restrictions, i.e., the Israeli separation wall and checkpoints and the requirement to obtain Israeli issued permits. Obtaining a permit can be complicated and can thus result in delays or even refusal. The separation wall is an obstacle to health, denying so many the right to health [5]. The lack of availability of services also contributes to unmet needs of patients and families, which illustrates why this model to create an effective EHR infrastructure is a priority [4,6].

When planning or improving health systems and service delivery, one must consider an array of factors, which includes four strategic areas as suggested by the WHO (2019) [4]:

a.

The first strategic area is to strengthen and build resilience of the Palestinian health system and progress to universal health coverage. Currently, the Italian government and the WHO support capacity building and data analysis in health information management and health financing. The aim is to improve health service delivery using the family medicine approach. They are also advancing the integration of services at the primary and secondary levels. The WHO has supported the Ministry of Health (MOH) to strengthen the quality of health care and patient safety. According to the Palestinian National Institute of Public Health (2018), there are 743 primary health care centers in Palestine (583 in the West Bank and 160 in Gaza), and 81 hospitals (51 in the West Bank, including East Jerusalem, and 30 in Gaza) [7]. Jabari et al. [2] reported that there were more than 400 primary care centers (governmental sector) connected to the District of Health Information Systems (DHIS).

b.

The second strategy is to strengthen core capacities in the Palestinian territories to meet the International Health Regulations (2005) [1]. This strategy includes the development of guidelines that will manage communicable disease outbreaks among all heath care providers and agencies, estimate and integrate event-based surveillance, strengthen coordination mechanisms within the MOH, etc.

c.

Noncommunicable diseases are the leading cause of morbidity and mortality in the Palestinian territories [7]. The WHO has listed this as the third strategy whereby the Organization will work with the MOH to boost the capacity to prevent, manage, and control noncommunicable diseases.

d.

The fourth strategy is to strength the capacity of the MOH and other health care providers to protect the right to health, reduce barriers to access, and improve social determinants of health.

The establishment of health information systems that allow Palestinian health institutions to share patients’ data among themselves will foster the achievement of the aforementioned strategic areas and lead to strengthening the national health strategy. Regarding the current situation of health information systems (HISs) in Palestinian health institutions, HISs are operated by four main providers, namely (1) the Palestinian government, (2) the United Nations Relief and Works Agency for Palestinian Refugees (UNRWA), (3) nongovernmental organizations (NGO) or nonprofit institutions, and (4) the private sector. Most health institutions that are operated by the Palestinian government (i.e., hospitals and primary healthcare centers) have adopted an HIS called AveCenna, which connects all governmental health institutions and fosters sharing of patients’ EHRs among them [8]. The UNRWA developed their own HISs and has used it in more than 140 UNRWA healthcare centers distributed in the West Bank, Gaza, Jordan, and Syria. All UNRWA patients’ EHRs are shared among UNRWA healthcare centers only [9]. Healthcare institutions that are operated by other nonprofit organizations and the private sector independently contract with private companies to develop their HISs. Patients’ EHRs generated by these systems are only accessible inside an institution and are not sharable with other healthcare institutions. Therefore, patients’ EHRs are not sharable among all Palestinian health institutions that are operated by various providers.

2. Federated Electronic Health Records

The definition of a FEHR adopted in this paper is a global integration of all existing EHR implementations, meaning that key clinical diagnostic and atomic data elements are stored and shared in one network, using blockchain technology [10,11]. The FEHR has the ability to grant any health professional the access to a patient’s health data; provide patient privacy and confidentiality; provide data security; support the hospital’s workflows, logistics, human resources, and global management; and provide data for health management. It can also provide information for drugs discovery and clinical good practices and research, as well as provide information for policy makers and others who need access to national health indicators and simulations. An example by Dewri Rinku et al. explains: “A federated query portal in an electronic health record infrastructure enables large epidemiology studies by combining data from geographically dispersed medical institutions” [12]. The FEHR may also accommodate travelers and tourists’ healthcare services. An important point is, the FEHR is scalable to cover the national needs, compatible with any legacy system, and configurable to any service.

The implementation of normalized EHR may follow the ISO standards, but different models and technologies can be found in the field. Globally speaking, the most common implementations are the Health Level 7 (HL7) and OpenEHR. The FEHR will integrate all implementation in a single architecture, and it will promote a unique view about all data and the flow of information while handling large queries across patients from different institutions.

We propose that the establishment of a FEHR system in the Palestinian territories would be appropriate for such a country that is low-middle income (World Bank, Washington, DC, USA, 2019) with meagre resources. Bringing all stakeholders from all health care sectors, governmental, nongovernmental, and private sectors together when they are economically, politically, and socially challenged will make for a more efficient health care delivery system.

There are justifications for having FEHRs, such as data being stored on cloud technology, which eases the economic burden for small institutions and individual physicians. It is also much more efficient to consolidate patient registries for disease control and for research, such as the federated research platform InSite. Claerhout et al. [10] discussed the advantages for research of structured, coded information in EHRs, which would lead to more data that can be evaluated, and the authors recommended that more work is needed so that such software is more fully utilized, especially for international research such as clinical trials.

While FEHRs have their advantages, there are barriers related to implementation of a FEHR, such as concerns about privacy. Alhaqbani and Fidge [13] discussed that new policies and access methods should be put in place for FEHR systems, whereby patient data are accessible by authorized persons only, although the data are made available when needed in life-critical situations. They found that no single security system is sufficient in a federated healthcare environment, but it is necessary to ultimately combine several levels of data security.

Other issues with implementation may be due to clinical data centralization in hospital information systems and the complexity of the software applications. To achieve a comprehensive and satisfactory FEHR model, the following requirements should be met:

• The software application should run in any mobile device or desktop;
• The protocol should be open, human readable, and easy to integrate with legacy EHR or new systems;
• The protocol should be flexible and must have an easy integration process.

2.1. The Clinical Document Architecture (CDA)

This paper attempts to present the CDA, which is a component of the HL7 framework. CDA is suitable in that it covers the abovementioned requirements, such as sharable data, being interoperable for a distributed EHR compliant with the Palestine context in particular, while also adaptable by other low-middle income countries. It is also possible for the CDA to utilize open source editors, and the most popular one is probably LINKEHR (https://linkehr.veratech.es/). The structure of a CDA document is a header and a body with multiple entries.

The main difference between CDA and other EHR models is the concept of a full document instead of a piece of data. Main EHR models treat each entry as a piece of data that can represent any part of a medical record, and the aggregation of these elements will be the whole episode structure.

The system that supports the entered data must deal with all structure and hierarchy of classes to represent all relevant information about patients. This architecture is very flexible, scalable, and consistent, as per ISO 13606 (Figure 1)

The CDA has the advantages of treating the clinical notes as a whole while each clinical record is indivisible, and it is authenticated with the author digital signature. In accordance with Kaith [14], the six characteristics of clinical documents are:

• Persistence
• Stewardship
• Potential for authentication
• Context
• Wholeness
• Human readability

CDA meets these criteria with the addition that it allows for the usage of light devices, i.e., mobile phones, while having an XML protocol that uses different types of templates to collect the clinical notes and to share them. The XML file has tags and references to normalized ontologies. The data entries can have different semantic meanings in accordance with the chosen ontology and concept.

It is possible to use ATC, SNOMED, ICD, ICF, DIACOM, among others. Thus, a CDA document can contain symptoms, clinical findings, and diagnoses, medical and nursing procedures, prescriptions, clinical images, X-rays, and any kind of data useful for medical treatments. It may also include the patient’s identification, including demographic data and memo fields (Figure 2).

2.1.1. Advantages of CDA

The main advantage of CDA is the capacity to accommodate any EHR and define a structure in accordance with a template. It is possible to define templates for every type of health data, including the medical records. A CDA document is an Extensible Markup Language (XML) document that can be shared and distributed across any network of patients and caregivers. HL7 developed a list of CDA templates for the following activities [15]:

(1)

Discharge summary note;

(2)

History and physical;

(3)

Progress note;

(4)

Consultation note;

(5)

Referral note;

(6)

Continuity of care document (CCD);

(7)

Unstructured document.

According to Chelsom et al. [16], “The XML structure of a CDA document is ideal for representing the hierarchical decomposition of tasks in a pathway, and the processing of the pathway can take advantage of some general properties of XML as a hierarchy of document nodes, in which parent nodes have child nodes which are an ordered set of siblings.” In addition to CDA standards, HL7 provides a list of sections already designed to create templates and treatment workflows:

• Allergies
• Care team
• Encounters
• Family history
• Functional status
• Immunizations
• Medical equipment
• Medications
• Mental status
• Plan of treatment
• Problems
• Procedures
• Referrals—planned and completed
• Social history
• Vital signs

2.1.2. Compliance with Widely Accepted Ontologies and Technologies

Some open source software to design templates and develop FEHR records is already available to all platforms. This software can be installed in different environments and customized in accordance with local requirements [17]. Despite all these features, it is mandatory to design an information system architecture capable of relating all information, provide clinical charts templates, and compound an EHR of each citizen. Fortunately, the World Wide Web Consortium (W3C) developed a set of standards to publish metadata about “entities, activities, and people involved in producing a piece of data or thing, which can be used to form assessments about its quality, reliability or trustworthiness” [18]. With these standards it is possible to share and disseminate metadata about the origins and type of data. The health data can be structured in entities, activities, and agents. It is possible to create graphs that describe the clinical episodes, including relationships. In accordance with Paolo Misser et al. [19], “The nodes represent instances of the three types of Provenance (PROV) elements, namely Entities (the documents, the papers), Activities (drafting, commenting, etc.) and Agents (Alice, Bob, etc.). Directed edges represent relations (derivation, generation, usage, association, etc.) that hold amongst these elements.”

Some authors have developed solutions such as using Integrating the Healthcare Enterprise (IHE) messages with Cross-Enterprise Document Sharing (XDS), a norm to integrate data among healthcare institutions [20]. However, this path can have the disadvantage of promoting a continuity of legacy systems and a mesh of many standards.

2.1.3. Blockchain as a Solution

Andrea Margerith et al. [21] proposed a system to interconnect caregivers based on blockchain infrastructure. With regard to the scalability, security, and a fault tolerant blockchain, this approach may have many benefits, and the proposed system embraces this method.

Dinh C. Nguyen et al. [22] also proposed a model of blockchain for secure EHRs sharing of mobile cloud-based e-Health Systems based on blockchain Ethereum implementation. In this model, three requirements are proposed: the Ethereum account, the smart contract in which the users permissions is defined, and the transaction. The cloud blockchain network has the following components:

• EHR manager—this component is responsible for controlling all user EHR transactions;
• Admin— this component is responsible for deploying the smart contracts and manage the user permissions;
• Smart Contracts—this component is responsible for managing the Application Binary Interface;
• Decentralized Storage—this component is responsible for the storage of large amounts of data that cannot be shared with blockchain (e.g., clinical images, videos, or all multimedia data related with healthcare);
• Data block structure that defines the data organization and its contents.

2.2. Detailed Architecture of the Proposed Model

The main problem of a fragmented system is the lack of consistency of the primary key that can aggregate all data. To overcome this barrier, a patient code of identification is merged with the clinical data and authenticated with the user’s private key and a timestamp. This user’s digital signature will establish a trust connection between the user and the cloud server.

To develop the EHR, a set of methods and technologies already known or available can be used while establishing certain domain requirements, such as the following:

• A decentralized and flexible format of electronic clinical messages should be used.
• The semantic alignment of the messages should be compliant with international standards but must also be adaptable to local culture.
• It should be possible to aggregate each piece of clinical data in a clinical episode and each episode in the EHR.
• The clinical data should be open to clinical research, but the patient’s identification should be secure.

To support the decentralized and shareable architecture of an EHR, the following technologies and models are proposed:

• Blockchain (Figure 3) to guarantee the decentralization of messages, security, and scalability (the model proposed by Dinh C. Nguyen et al. [22] is suitable to this purpose);
• W3 PROV [18] (p. 3) to promote the information about data structures about the relationships among data elements, actors and activities;
• Repositories with clinical classifications aligned with the Value Set Authority Center [16];
• CDA infrastructure to promote the flexibility and dynamics of clinical charts.

Clinical classifications and official coding can be achieved with a central repository of ontologies connected with a Value Set Authority Center. This repository can be hosted on the cloud and accessible with microservices. The microservices architecture will be scalable and can guarantee a high availability rate for clients.

Regarding data repository and confidentiality, a central repository about each CDA template with a unique ID to each structure is also necessary, and it can be accessible with microservices. The metadata repository has the information related with clinical data structures and used data types (Figure 3). To aggregate each piece of clinical data, each message must have a patient ID. The sequence of blockchain structure is enough to establish the chronological order. The research about a patient ID algorithm is mandatory.

The master patients’ index is responsible for aggregating all demographic information and ID about each patient. The patient ID is a code without any information about the patient identification, but it has a correlation with all details that are in the master patient index file and all clinical records. This central repository will make it possible to address all patients’ records across all networks.

The advantage of purging the patient identification details from the clinical charts is that this keeps all data flow lighter and also keeps the patients anonymized across the network. The patients’ details, therefore, are only in one repository, and the rest of the architecture only uses the IDs. For other stakeholders such as labs, the pharma industry, researchers, and policy makers, all patient information is protected.

2.3. Advantages of the Blockchain Infrastructure

One of the main advantages of correlating all clinical data with a unique ID is the possibility of deploying tags to all citizens and giving all the opportunity to log in to the system even if the patient master index is not available. The blockchain infrastructure will provide credentials to all healthcare providers, labs, pharmacies, industry, researchers, and policy makers.

This system will also promote the electronic orders, such as prescriptions and lab tests, thus avoiding paperwork and promoting interoperability while also increasing drug control and providing results all across the network. This should result in greater efficiency and conservation of resources while decreasing the clinical risk as the clinical charts, prescriptions, and lab tests will be available across the network.

Currently, many legacy systems are not concerned with change and integration. Our model, however, can be developed and implemented gradually by utilizing an architecture that is very flexible. In addition, it is possible to develop gateways that will connect the existent hospital systems with the closest node of the blockchain architecture [23].

Interface with Other Systems—Increase Efficiency

This model has the flexibility and ability to be interfaced with any laboratory management information system. Specific gateways can be developed to each specific model and version. The laboratory equipment industry can be easily involved in future developments regarding interoperability and data sharing.

Another dimension of this model is the possibility to share information with the pharmaceutical industry, especially the data related to clinical trials. In this case, we can track the drugs efficiency, effectiveness, and adverse reactions before a drug goes to the market (phase 3^. clinical trials) and after the drug is on the market (phase 4). To use this model for clinical trials, some specific filters and software application should be developed in order to create cohorts of patients while guaranteeing their privacy and data security.

To promote the health management and indicators for policy makers, the model can have a gateway to a data warehouse and aggregate data from all citizens, status of health, diseases, medical procedures, prescriptions, labs exams, and all other information related to family health and wellbeing.

It is possible for any device with a browser or an installed app to enter and access the clinical notes, prescriptions, or clinical exams. This is out of the scope of this paper, but to develop the app it is possible to use cross-platform tools. Inupakutika et al. [24] used cross-platforms tools to develop a mobile health system architecture for chronic patient supportive care. An advantage of these platforms is the portability to different environments, platforms, and ubiquity.

2.4. Security, Privacy, and Confidentiality of the Proposed Model

Our proposed model has many advantages that are related to the CDA structure and specification, to ensure patient data protection. It is more secure than most existing systems that are often based on shared or central database management systems. Those systems typically allow the database base administrator full access. Every clinical document must be digitally signed (the health professional’s identification is automatically achieved) while guaranteeing the integrity of the document. As the blockchain infrastructure splits the clinical charts into different messages and encrypts each message, each user must be authenticated to the blockchain network, thus ensuring that only users with the privileges to access clinical data will be granted access to the CDA message. Finally, only the patient ID number is identifiable while the completed identification is on a central database.

3. Conclusions and Future Work

The emergence of new diseases and the challenges that the healthcare organizations are presently facing are not compatible with gaps of information, lack of interoperability and lost time, resources, and human capital.

The new challenges require solutions that should be adaptable to the installed systems but at the same time should follow the new requirements, standards, and technological advancements. They must also be affordable, especially for the lower-middle and low income countries that are lagging when it comes to employing the latest EHR technologies. The proposed model, which allows for efficiency, security, and a good use of resources, can enhance the healthcare sector’s abilities and performance in Palestine and in other low and low-middle income countries.