Architecture Issues For eHealth Interoperability
Written by Nikos Vaggalis   
Monday, 16 June 2014
Article Index
Architecture Issues For eHealth Interoperability
Implementation with OpenNPC

What architecture do you need to establish the flow of patient medical data, stored in different ways and languages, across country boundaries? The solution involves a common intermediate structure and open sourced components to make implementation by many different countries easier. 

epSOS – European Patients Smart Open Services – is the main European electronic Health (eHealth) interoperability project co-funded by the European Commission and 47 beneficiaries. It focuses on improving medical treatment of citizens while abroad by providing health professionals with the necessary patient data

To find out more about this large-scale project, Nikos Vaggalis attended last month's epSOS Industry Team and Open Source Community Workshop held as part of the 2014 E-Health Forum in Athens,Greece.

 

esposphoto

Here he presents what he discovered and raises questions for software architects.

The Concept

The epsos project dates back to 2008 and enters its final phase this June of 2014. It has produced several guidelines and services that enable cross border patient information sharing, with the actual goal being to

"develop a practical eHealth framework and ICT infrastructure [based on existing national infrastructures] that will enable secure access to patient health information, particularly with respect to a basic Patient Summary and ePrescription, between European healthcare systems"

The ways epSOS achieves this are:

  1. By defining and setting up the necessary infrastructure based on the National Contact Points (NCP) . NCP's are the portals that facilitate the actual exchange of patient information between countries
  2. By defining, testing and evaluating the services from a user’s (health professional and patient) perspective. There were two services used for that purpose, E-Prescription and Patient Summary.

epsosmap

 

Representing Oracle, Miroslav Koncar gave a detailed account of the epSOS organization and infrastructure and explained that the project's primary aim was to support the mobility of EU citizens around the member states through exchanging patient information between the country of residence and destination countries in order to offer quality health services to people traveling for vacation, work, or study, a benefit that became a citizen's right under an European Union (EU) Directive in 2011.

epsosfacts

 

From the point of view of software implementation the project needs to be considered from three perspectives: 

1. Stakeholder involvement

Ministries and organizations from 22 EU member states and 3 non-EU member states, plus an industry consortium of 30 companies with potentially conflicting interests.

2. Semantic interoperability

Bridging the different languages, infrastructure and clinical/medical terminology to enable interoperability and a common understanding.

3. Development activity

OpenNCP, the open source components that facilitate the actual building of the National Connection Points.


epSOS Pilot Project

To evaluate epSOS in practice, the project entered a pilot phase on April , 2012 and focused on two use cases:

1. E-prescription - how you get the prescription from one country to the other. For example if a tourist with chronic disease visits another country, he should be able to execute his prescription at his destination

2. Patient Summary - access to important medical data for patient treatment giving the ability to search, retrieve and update the patient's profile, no matter the country of residence or destination. The point is that for a doctor to provide high quality health care services, he has to have full access to the patient's profile (prior drugs, procedures, diagnoses) so he can offer the right drugs or treatment

To providing these services, several obstacles had to be overcome:

 

1. Interoperability

How to connect, share and exchange data between countries without altering each country's national regulations, legislation and infrastructure, nor requiring central management, in other words, how to integrate each country's diverse architecture into one system?

That is where the concept of the National Contact Point emerged: if you don’t want to change the local infrastructure you have to use a data flow gateway from country A to country B with the two points being able to trust each other from a security point of view thus making sure that the data both originated on and received by validated partners

 

2. Security

How to protect the data traveling between NCPs?

Encryption and many other security measures were employed at the application level , while at an administrative level it was made sure that access to the patient's data is given only to the healthcare personnel that asked for the data in the first place, and not anybody else. Of course all of that can only happen if the patient consents for his data to be accessible.

3.Semantics

Data is encoded another way in country A and another on country B. How can it be valid and make sense when these points communicate ?

The solution is to use a common language denominator called the Pivot format, which is how eSOSs perceives data like i.e how prescriptions or how diagnoses should look like for enabling cross border exchange of information. So each data sending country would trans-code from its format to the common Pivot format which in turn would be trans-coded to the appropriate format needed on the recipient country.

4. Avoiding Vendor lock-down

At the hardware level, how can we ensure that each country’s NCP does not get locked down to a particular vendor such as Microsoft or Oracle? 

The solution is to use the IHE (Integrating the Healthcare Enterprise) Framework and Integration Profiles to enable NCPs to "talk to each other so that any system can communicate with any other system regardless of the vendor.

 



Last Updated ( Wednesday, 18 June 2014 )