Toggle Bar
  • (+30) 2310 474762
  • This email address is being protected from spambots. You need JavaScript enabled to view it.

EHR the Holy Grail of Digital Health

Electronic Health Records (EHR) have been the Holy Grail of Digital Health for decades now. Originally presumed as the «killer application» of Health IT systems, it proved out along the way healthcare reality was much more difficult to disrupt than a database + fancy UI combo solution. As technology evolved so did hopes that access to one’s health information will become seamless courtesy to digital technologies. Together with hopes a big ledger of failures evolved as well, HealthVault1 by Microsoft and Google Health2 by Alphabet (at the time just Google) are the big boys examples sitting together in the same unfortunate company with numerous attempts of various players ranging from startups to National States.
Access to health care is a multi-dimensional concept involving both geographic and financial accessibility, availability, and acceptability. The ability to provide quality care has been traditionally limited by a need for the medical provider to have direct access to his or her patient, constraining the number of patients a single provider could treat. 
Digital Health technologies look ideal to help overcome this barrier. The odds looked favourable, a series of converging trends was expected to ease the adoption of EHR solutions: just to name a few, rapid advances in mobile technologies and applications and their integration with existing electronic health services, falling prices of smartphone hardware, sensors and data service, and the dramatic growth of cellular coverage in even the most remote areas of the world were thought to contribute to meeting the basic requirements for a thriving ecosystem of Digital Health services (aka eHealth or mHealth).3
Nonetheless, although advances in the internet industry were a driving force behind major milestones in EHR accessibility and adoption, significant challenges remained in developing cost-effective solutions. A crucial challenge for the adoption of EHR technologies in this complex environment has been the lack of a free and easily configurable platform, operating in the public space.
Digital Health technologies seek to overcome this barrier in part by redefining the roles and relationships of traditional care providers and community resources. As tools, they support the care process by maximizing provider interconnectivity, archive medical information for long-term tracking and outcome analysis, and reduce time to diagnosis for patients. Successful examples have been in operation for many years at both sides of the pond at different scales and penetrations. Various obstacles make scaling of this approach a difficult goal to achieve. For patient populations living in rural areas, network coverage may be spotty, making the efficient transfer of large data files (e.g. images, videos) problematic. Patient experience is also a key factor in the healing process, and patients may not feel comfortable receiving digitized complex care plans or teleconsultations. Cultural and language barriers may limit project scope, so active engagement with all stakeholders is crucial during software customization. 

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 process4.
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 specifications5, 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) project6 and its follow-up activities (e.g. the projects e-SENS and EXPAND and, more recently, the CEF eHealth Digital Service Infrastructure)7, 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 project8, 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 patient9, 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 technology10, 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?

  3. Building Alliances Series: Health, United States Agency for International Development (USAID), 2010
  4. D4.2: Interoperability Guideline for eHealth Deployment Projects,
  5. IHE IT-Infrastructure Technical Frameworks. Online:
  9. Tang, Paul; Ash, Joan; Bates, David; Overhage, J.; Sands, Daniel (2006). “Personal Health Records: Definitions, Benefits, and Strategies for Overcoming Barriers to Adoption”. JAMIA 13 (2): 121–126. doi:10.1197/jamia.M2025. PMC 1447551. PMID 16357345