Finally, financial factors must be considered, given the costs of (1) software and hardware, (2) personnel re-training for the new workflow process, and (3) information technology support. In addition, this new care process requires business model innovations to sustain operations in the long term.

All these early and well identified, solutions proposed in hand, didn’t help much in moving forward with widespread EHR adoption. Failures created more confusion, because the value of a health databank seems apparent to everyone. As people and organisations involved in digital health and not only were trying to figure out how it is possible a databank of health information not to become mainstream one word came out repeatedly: interoperability. 

The convergence towards a smoothly operating interoperability framework of Health Records at international or European level is a long-term vision, but far from the reality even today. Different approaches in terms of perspectives (business, information and technical), semantic and technical solutions, standards and profiles used, terminologies adopted, etc., have been tried with limited, either in scope or in applicability, success. In European Union alone a lot of money have been invested in this effort. Small victories claimed mainly through the work of epSOS and the cross-border e-prescription and patient summary services. But even these require a huge effort on manpower and money for a minimal or even questionable impact. These results are the natural consequence of centralised approaches at Member State or European level attempting to create profiles taking into account the many factors influencing architectural decisions in Digital Health deployment, including culture, domain, country, implementation timeline and the interoperability layers addressed.

More specifically, the idea of standards is often associated with protocols and the expectation of “plug and play” interoperability achieved when two or more systems are able to interact, to satisfy well-defined real-world health administration or clinical processes. This happens when humans and/or machines are able to exchange information stored in two or more Health Record implementations. All standards have the challenge to be on one hand generic enough to be universally applicable, and on the other hand to be concrete and unambiguous to enable interoperability in a specific context. This is usually proposed to be resolved through profiling: capturing common characteristics and defining rules for using a (set of) standard(s). In other words, profiles (are supposed to) specify how to use standards for a specific scope or in a specific setting by defining constraints and extensions. This way additional layers of complexity and cost are added to the interoperability process. This explains also why profiling is usually a layered process⁴.

A profiling approach extensively tested and promoted within the European Union is the idea of the so-called gateway-based approach. It promotes to construct a federated “network of communities”, where each community has a single gateway that manages all cross-community communication. This leads to schemas where interoperability issues are pushed to the communities, while an API like interoperability is “achieved” at the federated level using a commonly pre-agreed set of rules and documents: very far from the idea of “plug and play” and the core definition of interoperability, but the best of what we managed to do so far.

The primary example for this approach is the set of IHE Cross-Community Access Profile specifications⁵, which define rules for exchanging Electronic Health Record extracts (such as patient summaries or prescriptions). The profile assumes that health information is exchanged in the form of documents, that a community Gateway constructs complying to the agreed formats, but only as far as communication at the “federated network” is concerned. What happens behind the gateways is of no concern to the design of profile. Usually, chaos is what happens there; so sad.

For example, in the epSOS (Smart Open Services for European Patients) project⁶ and its follow-up activities (e.g. the projects e-SENS and EXPAND and, more recently, the CEF eHealth Digital Service Infrastructure)⁷, the concept of a “National Contact Point” was established. This is the IHE gateway, which stands between the country and another country’s IHE gateway exchanging what is known as ‘pivot’ documents (e.g. patient summary, ePrescription/eDispensation), an intermediate format for the document conversion, for which a mapping from and to each national format has to be defined: a nightmare for which nobody talks; interoperability at the federated “cross-country” level has been achieved. What has actually been achieved is a centrally agreed set of rules, for which separate implementations in each country must be built-up from scratch. CEF is funding this as we speak, out of desperation to prove that interoperability has been achieve. How this is more efficient than, for example, an API based network still remains unclear. Furthermore, it is still questionable that seamless interoperability can be achieved using this approach. For example, as demonstrated by the Trillium Bridge project⁸, conformance with the IHE profiles is not sufficient to assure interoperability: in Trillium Bridge both parties used the same IHE XCPD transaction but they were not interoperable. Additional specific service contracts and behaviours were required to be negotiated and agreed. Finally, such an implementation completely ignores personal health records, or PHRs. This is a health record where health data and information related to the care of a patient is maintained by the patient⁹, or even not necessarily a patient, why not a citizen, after all one should not wait to become a patient to care about one’s health! This stands in contrast to the electronic health record (EHR), which is usually operated by institutions (such as hospitals) and contains clinical and health administrative data. The value of the PHR lies when it is able to provide a complete and accurate summary of an individual’s medical history, which is accessible anytime, anyplace is needed. The health data on a PHR include self-reported outcome data, lab results, data from wearable or homecare devices. Ideally the PHR, to be truly helpful for self-management, is seamlessly connected to electronic health record systems, which automatically update it.

I believe that in the core of these failures or limited successes lies the choice of centralization on the approaches towards achieving interoperability. The idea of super Authorities setting rules that all actors have to comply with may sound familiar as a notion to EU Member States, but unfortunately has failed to prove to be suitable for solving the problem of Electronic Health Record interoperability. Such approaches simply add additional layers of authoritative ruling, which increase complexity and costs, demoralising the patient and doctor communities and creating negative incentives.

Decentralized approaches seem more suitable to solve the PHR/EHR interoperability issues in Europe if not for any other reason, just because health information by nature is produced and processed at distributed places and times.

Recent technological developments are providing tools that can build trusted distributed networks ensuring security and privacy by design supporting both storage and transactions. Sounds like a PHR? Sure does! One such technology promoting a promising answer to PHR/EHR interoperability is the use of blockchain technology¹⁰, which can be used to ensure data integrity, security and trust to the flow of health information regardless whether it is generated by health providers or the citizens themselves, automatically by machines or input be humans. Most fundamentally, blockchain could enable data exchange systems that are cryptographically secured and support privacy by design. This would enable seamless access to historic and real-time patient data, while eliminating the burden and cost of data reconciliation. Interoperability by default! No need for intermediate or subordinate layers, nor “interoperability” specific implementations. Can this be the solution long sought? A lot of experts think so. Definitely, the hopes are raising high again. Maybe this time there’ll be no more disappointments?