The Implementation of a National Health Information Exchange Platform in Israel [excerpt 2/3: the need and the solution]


This is an excerpt of the publication above, focusing on the overview of the project.


IDB and Healthcare Israel
Amir Gilboa and Luis Tejerina
2022


Edited by


Joaquim Cardoso MSc.
The Health Revolution Institute

Research Institute for “Better Health and Care for All, at a lower cost”
June 15, 2022


Structure of the publication

  • Preface
  • Executive Summary
  • Background
  • Introduction
  • The Need for the HIE, and the Challenges it Addresses
  • The Israeli National HIE Solution
  • The Israeli National HIE Implementation
  • Evaluation of Results
  • Reflections and Recommendations



3. THE NEED FOR THE HIE, AND THE CHALLENGES IT ADDRESSES


3.1. Health Services Challenges 

3.2. Terminology Challenges 

3.3. Security Challenges



3.1. Health Services Challenges


Israel’s hospitals and HMOs have used EMRs for the past three decades.
All medical information for each Israeli citizen is stored by one of Israel’s HMOs. From this digital starting point, Israel took the next step to leverage the power of this data.

When building the national HIE, Israel recognized three major challenges it wanted medical information sharing to tackle:

i.Challenge one: Accessing a patient’s full medical history

ii.Challenge two: Preventing unnecessary procedures and tests

iii.Challenge three: Providing life-saving patient data in emergencies


i.Challenge one: Accessing a patient’s full medical history


Each Israeli patient has a family physician who sees the patient from time to time and stays up to date on the patient’s history, illnesses, medications, and medical procedures. When the patient requires hospitalization, care performed in the hospital is not under the family physician’s purview. But upon patient discharge, care is ideally transferred from the hospital back to the family physician. However, it is common for care to be disrupted or ceased upon discharge. Hospital physicians commonly ask the patient to update his or her family physician upon discharge so that there is a seamless transfer of care from the hospital to the community clinic. But in many cases, patients have either not visited their family physician to continue their treatment after hospital discharge or have not brought the family physician all their discharge documents. As a result, in these scenarios, family physicians could not continue optimal treatments and patients continued to suffer and were sometimes even rehospitalized.


An early attempted solution to this problem was for hospitals to send discharge letters to family physicians by fax. But there are clear problems inherent in this interim solution: the need for the hospital to identify the correct family physicians, the need to appropriately time the transmissions and accuracy of transmissions, and the need to have patient data readily available.

ii.Challenge two: Preventing unnecessary procedures and tests


Unnecessary procedures and tests can have negative consequences for patients’ health and the financial and operational health of hospitals. Over the years, hospitals and physicians have brought up this issue, but systematic data collection has never been done. The requirement that patients bring all of their medical documents or test materials to the hospital is not realistic or practical, especially in emergencies. On the healthcare provider side, without a clear picture of a patient’s medical history, unnecessary procedures and tests are often ordered at great expense to the hospital and healthcare system and at the expense of being able to move as fast as possible when doing so is critical to saving a patient’s life.


The implementation of the HIE between separate organizations addresses both the need to access all relevant data from different organizations as well as the need to prevent unnecessary procedures and save resources.

iii.Challenge three: Providing life-saving patient data in emergencies 

During medical emergencies, doctors and emergency medical professionals may be unaware of a patient’s medical history, allergies, or current medications (to avoid drug interactions) — which can lead to unnecessary life-threatening crises. For decades, attempts have been made to solve this age-old problem, including the MedicAlert bracelet, created in the 1950s by Dr. Marion Collins and his family after his 14-year-old daughter suffered a near-fatal allergic reaction during a visit to an emergency room (MedicAlert, n.d.)[1]. While a system of stamping medical information onto a metal bracelet (which patients must remember to wear) did save lives for years, today Israel has a nationwide HIE solution that delivers critical, life-saving data when and where it is needed by patients and medical professionals, be they primary care providers, ambulatory specialists, or staff at ambulatory or hospital-based emergency centers and hospitals.

The national HIE means that patients do not have to carry around their medical files, medical professionals can obtain the critical patient data needed to save lives and money and prevent unnecessary procedures and tests, and real-time access to patient data informs and empowers medical teams to provide the right medications and treatments at the right time.


3.2. Terminology Challenges


Once information-sharing is in place, the challenge of different organizations using different terminologies must be addressed and overcome

While connecting two or more health organizations, and transferring medical data among various EMRs, it is important that everyone can understand the data. 

Over the years, health organizations in Israel have used different coding standards, such as ICD, Snomed, RxNorm, Loinc, and others. 

In addition, many organizations added custom codes and subcodes to fit their specific needs. 

This created challenges when integrating the systems, as it was necessary to ensure that all health organizations spoke the same “language.” 

For example, myocardial infarction can be called “MI” in some places, “heart attack” in other places, and “myocardial infarction” in others. 

Accordingly, care and careful management are applied to effectively transfer data between the organizations without disrupting individual systems and standards — a balance that comes from experience over multiple integrations.


3.3. Security Challenges


When implementing an HIE, a key consideration for system architects and managers is the secure and proper use of sensitive data, such as medical information and patient data. 

The architects of Israel’s HIE applied the following security principles to provide protection for and careful use of sensitive medical data:

  • No use of a central database
  • Provision of data at the time of care only
  • Ensured security standards

· No use of a central database — Israel made the strategic decision not to save its important medical data in one central database. Central databases are ripe targets for hackers who seek to inflict maximum damage and hack the maximum data with minimal effort, so decentralized databases help protect important medical data. The decentralized architecture also addresses stakeholders’ psychological barriers to adopting HIEs, as each organization (hospital and HMO) holds its own information.


 Israel made the strategic decision not to save its important medical data in one central database.


· Provision of data at the time of care only — Israel further secures patients’ medical data by ensuring availability only to specific healthcare professionals at the time of care. For instance, a patient’s primary physician can have access to most of a patient’s medical data, such as for better holistic diagnoses and treatments. But, when specific treatments or tests are needed, other specialists or medical team members can access only a specific patient’s data, for a specific purpose, during a specific period.

· Ensured security standards — All data transfers and connection points between organizations must meet relevant security standards and regulatory requirements, including Israeli security and privacy regulations and international standards such as HIPAA, GDPR, ISO, and others.




4. THE ISRAELI NATIONAL HIE SOLUTION


4.1.History 

4.2. Architecture 

4.3. Terminology 

4.4.Security


4.1. History


Clalit, Israel’s largest HMO took the first step toward HIE use in Israel. Clalit serves 4 million Israeli citizens, and has two main divisions

the community division, in charge of primary care and specialist services in the community, and the hospitals division, in charge of managing the 14 Clalit-owned hospitals. 

This combination of community clinics and hospitals gave Clalit a clear perspective and deep understanding of the needs of hospitals, communities, and the patients they serve.

Prior to adopting its HIE, Clalit’s community and hospital divisions used different EMRs, which served each division well but provided integration challenges. 

In early 2000, Clalit launched the Ofek Project, a product of the company DB-Motion to deliver the minimum necessary patient data to every healthcare provider within the HMO at every patient encounter.


Ofek defined six core principles to achieve its primary goal:

· Retrieving data from any kind of EMR through a specific interface

· Defining a minimal clinical data set

· Using patient-centric solutions

· Keeping data where it was created

· Requiring less than a 10-second response time

· Ensuring data security and privacy


The solution for the Ofek implementation was a distributed system that acted as a virtual data repository, which eliminated the need to build a central data repository


In the Ofek project, all the data was stored, owned, and maintained where it was created. 

Information was retrieved only when required and in read-only mode, so external users were unable to make changes in the source systems. 

Users needed only to build interfaces to the Ofek network. 

The information remained stable and secure and available for access only when and where it was needed, based on predetermined levels of access for each end-user.


After Clalit adapted the Ofek system to its needs, it began implementing the system in 14 hospitals from 2000 to 2002, following a successful pilot project in Soroka Hospital. 

The next step of the implementation was to expand the HIE to Clalit’s 1,300 community clinics, which was a success because of the large scale of the implementation, and then to organizations outside of Clalit.


In 2003–2004, DB-Motion expanded the Ofek network to three large non-Clalit hospitals. 

Over the next few years, Ofek received positive feedback from stakeholders in the health system and physicians, which brought it to the attention of the MOH. By 2010, the MOH adopted the Ofek solution, turning it into Israel’s national HIE. The process of securing all of the necessary government approvals and funding took several years, but between 2012 and 2014, all HMOs and public hospitals were officially connected to the Ofek network (Figure 2).

The last phase in the Ofek project was to implement it in geriatric and psychiatric hospitals as well as in the IDF (Israeli Defense Forces) and the IPS (Israeli Prison Services). 

By the end of 2015, all of these organizations were connected to Ofek. For further details on the implementation and expansion process of Ofek (figures 2 and 3), see sections 5 and 6.


After Clalit adapted the Ofek system to its needs, it began implementing the system in 14 hospitals from 2000 to 2002, following a successful pilot project in Soroka Hospital.


While implementing Ofek nationwide, DB-Motion and the MOH started developing the second version of the HIE, Eitan

The Eitan version expanded on Ofek’s capabilities, solved some technical problems, and provided a better experience and better functionalities for users (for example, see section 4.2.2). 

Between 2016 and 2020, most of Israel’s health organizations upgraded from Ofek to Eitan. 

As of 2022, the MOH has continued transitioning organizations to Eitan while improving functionality and user benefits for both healthcare providers and patients. The ministry is developing the next version of the HIE, Eitan 2.0.


FIGURE 2: Development of Information Sharing in Israel (a 20 year + journey

Source: Internal Ministry of Health presentation.


 Development of Information Sharing in Israel (a 20 year + journey)


FIGURE 3: Israel’s HIE National Network

Source: Internal Ministry of Health presentation.


4.2. Architecture


The Israeli HIE network architecture was designed to meet the security and functionality needs of patients, healthcare professionals, and the government

To avoid interruptions in clinical work and provide security, the system designers decided to collect data from a local EMR and transfer it to a local (not centralized) HIE database. 

The local HIE database is not an EMR replica. It holds all of the EMR data, but, in the transfer process from the EMR to the HIE, the data structure changes to the national data structure to allow for a national data sharing format.

The data transfer process from the EMR to the HIE database is fully under the control of local health organizations. 

Each local health organization decides which kinds of data to transfer (according to the national instructions and subject to MOH approval) and can even choose to stop data transfers entirely (opt out). 

However, the system designers decided that only organizations that are sharing data may receive data, so none of the organizations ever opted out.

Once the data is transferred to the local HIE database, it becomes part of the HIE network. For each public hospital and clinic (regardless of ownership), there is a local HIE database, and all network members are connected to it through an internal VPN. 

The connection hub is located in the MOH, and all health organizations are connected via this main junction. 

The MOH administers the hub but cannot gain access to data transferred through the network unless the MOH is one of the parties earmarked on a specific data request.


The data is ordered in the HIE software, and the user can see data types (lab results, background diseases, etc.) arranged by clinical domain

At the point of care, a physician can explore a patient’s data from the HIE, and when the physician closes the EMR at the end of a patient visit, the patient’s data from other organizations is deleted from the recipient organization. 

In general, the HIE data cannot be entered into receiving organizations’ EMRs, except for discharge letters that by law must be delivered to HMOs.

FIGURE 4: Israel’s HIE Architecture

Source: Internal Ministry of Health presentation.


4.2.1. Data Types and Clinical Domains


A major challenge in designing the national HIE was to maintain the delicate balance between using a minimal data set and providing enough clinical data

This challenge was solved by the MOH using dual-step decision-making. 

The first step was to decide on the clinical domains included in the project and then choose the minimal data types with the maximum value for each clinical domain. The clinical domains and data types are summarized in Table 2.


4.2.2. Eitan’s Architecture

Some of the key improvements of Eitan compared with Ofek are as follows:

· The end-user software has been replaced with a new agent that is connected to an organization’s EMR and appears above the individual EMR as a floating window. A physician can easily open and close it.

· The amount and types of clinical data used in the system have been expanded.

· It is possible to view not only the radiologist summary documents but also the PACS (picture archiving and communications system; X-ray, CT, ultrasound, etc.) files.

· An improved infrastructure supports terminology mapping and conversion as well as analytics for user organizations and the MOH.


TABLE 2: Ofek’s Clinical Domains and Data Types

Source: Internal Ministry of Health presentation.


FIGURE 5: Eitan’s Floating Component Closed

See the original publication


FIGURE 6: Figure 5. Eitan’s Floating Component Open

See the original publication


FIGURE 7: Eitan’s Floating Component Internal Sections Open

See the original publication


4.3. Terminology


Once information sharing is in place during an implementation process, the challenge of different organizations using different terminologies must be addressed and overcome. One way to overcome it is by using Fast Healthcare Interoperability Resources (FHIR), which is an electronic standard for exchanging healthcare information and terms. FHIR is a new specification based on emerging industry approaches and informed by years of lessons learned about requirements, successes, and challenges of health data use. Given the growing importance of standardization across healthcare organizations around the world, many organizations are adopting the FHIR standard.

When Israel began implementing the HIE platform, though, the FHIR standard had not been created, so there was a need for another solution.

The goals in adopting a solution were:

· Integrate data between organizations and between systems within each organization.

· Transfer data to the EMR.

· Organize and group the data.

· Analyze and gain insights from the data.


The terminology issue was addressed by using technology and forming a professional committee to map and define terms. The technology solution became a central component of the HIE within the MOH, and it is responsible for including each local phrase (diagnosis, procedure, etc.) in a baseline catalogue of terms. When a local organization or healthcare provider seeks medical data, the request is filtered through a central catalogue that converts it into a locally recognized term. This way, local organizations can continue to use localized terms without having to change their EMRs or workflows. The team is working to build a comprehensive terminology solution.


For a central terminology catalogue to work, the converting mechanism must be very accurate

To achieve this level of accuracy, the MOH formed a professional committee divided into three subgroups. The first consists of leaders from the MOH. The second (the Mapping Group) is a subgroup of specialists that includes physicians, a medical registrar, a laboratory worker, a pharmacist, and medical students and is led by a specialist in internal medicine. The third subgroup consists of hospital and HMO representatives. As the groups worked together, they found that 50 percent of the phrases covered 95 percent of the cases, so they focused on mapping those phrases. Once the mapping was done, data was shared with hospitals and HMOs, feedback was gathered, and the catalogue was clarified and refined. This work is still in progress, so the final report has not been published. Many sections are still being revised.


4.4. Security


The security and privacy components in the HIE network were a major part of its design and architecture.
 

The security components were designed to meet the requirements of the MOH’s chief information security officer as well as other regulatory agencies including the Israel National Cyber Directorate[2] and the Privacy Protection Authority.

The key security requirements were:

· There is no central repository (clinical database).

· Data from the EMRs or the HIE cannot be used for medical research unless previously approved by the Helsinki Committee.

· Data is accessible to the medical team during the treatment period and for a limited period afterward.

· Central profiles and permissions apply to any user nationwide.

· All actions are monitored (user, data type, timestamp, etc.).

· Classified data are filtered (set a classified encounter or set permissions only for certain users). For example, all psychology encounters and data on abortions are classified.

· The infrastructure is secure (encryption, secure communication).

· There is an opt-out option for patients who do not want to share their data (according to MOH instructions, the default for all patients is in, but there is an option to opt out).

· The HIE solution is developed and implemented in accordance with these security requirements, making sure the provider works closely with the MOH’s chief information security officer and the cyber team throughout the process.

· The implemented security measures include other components (role-based approach, data classification with confidential information options, opt-out models, centralized logs, and more).


There is an opt-out option for patients who do not want to share their data (according to MOH instructions, the default for all patients is in, but there is an option to opt out).






References

See the original publication


About the authors

Written by: Amir Gilboa.

Technical edition: Luis Tejerina.


The author wishes to thank the following people for their contributions and remarks:

• Hagai Dror — Managing Director, Healthcare Israel
• Dr. Izhak Zaidise — Chief Medical Officer, Healthcare Israel
• Mrs. Mali Shapira — HIE Division Manager, IT Department, Israeli MOH
• Tziel Ohayon — Sr. Sales Engineer, PH Solutions Architects, DB Motion — All Scripts


Originally published at https://publications.iadb.org

Total
0
Shares
Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Related Posts

Subscribe

PortugueseSpanishEnglish
Total
0
Share