At Devcon VI, Ben Jones from the Optimism Collective said of Ethereum: The technology is necessary but insufficient. All infrastructure is simply tools to enable new kinds of actions to be built upon it. Better infrastructure technologies, lower the transaction costs (eg. time, capital, coordination) of actions, and enable new kinds of behaviours, products, services, and paradigms.
In healthcare, the conversation of digital infrastructure centres around the storage, sharing, and retrieval of health data. The systems that enable health data transactions, directly influence our ability to build newer forms of behaviour around human well-being. Our earlier article on Data Composability highlighted this potential in reimagining our health data infrastructure.
The goal of this article is to take a deeper dive into the now and look at healthcare data systems that are widely used today. By grounding ourselves in the present, while dreaming about the future, it becomes possible to plot a path toward our vision for a better healthcare system.
Existing System Architectures
There are three main systems at the technological forefront of enabling the exchange of patient health data, namely, The Open Electronic Health Record (openEHR), Digital Imaging and Communication in Medicine (DICOM), and Fast Healthcare Interoperability Resources (FHIR).
The Open Electronic Health Record (openEHR)
openEHR (pronounced “open air”) is an architecture that was designed with 15 years of requirements recorded from multiple standards and projects around the world.
Before the introduction of openEHR, a patchwork of EHR software from different, incompatible vendors formed the backbone of global health data infrastructure. The lack of interoperability in the market meant that the data of patients were stuck on different platforms. This problem has been documented to cause many misdiagnoses and wrong prescriptions which has in some cases led to preventable deaths and lawsuits.
The openEHR system was able to achieve what its predecessors could not. It unified EHRs and EMRs across the healthcare industry and established a standard that brought siloed health data out into an interoperable global platform. openEHR was also designed with extensive requirements research, especially around patient privacy.
The content within an openEHR health record is separate from identifying demographic information which protects patient identities from data breaches. Versioning of modified items and private-key encryption of a hash ensures that the integrity of items is resistant to repository corruption. Authorization to view/modify patient data is regulated through an access list defined by evaluating relevance to the caregiver and the duration of care. Furthermore, the definition of privacy levels can be specified within jurisdictions of use, giving patients the ability to select the level of privacy they desire.
Standard interfaces drive network effects, and the ability to seamlessly synchronize data across jurisdictions drove openEHR adoption globally.
Today, Norway and Sweden, both well-known for high-quality healthcare, rely on openEHR for health data exchange. Other jurisdictions that use openEHR for health data exchange include Moscow and Australia. In Moscow, 670+ healthcare providers facilitate the management of health and social care records for its 12 million citizens on openEHR. In Queensland, Australia, 4.5 million citizens have their healthcare data on openEHR.
Fast Healthcare Interoperability Resources (FHIR)
In 2013, the FHIR’s first publication was revealed, introducing a novel method for health data exchange. This publication described a streamlined interface for third-party applications to interact with an EHR system. For the first time, developers were able to build applications using common web standards which enabled patients to view and visualize their clinical data in new ways.
Today, the Apple Health team leverages FHIR to retrieve and aggregate health data from multiple EHRs all across the United States, creating a holistic health dashboard for patients. Similarly, the CommonHealth Project allows users to import and access their health information globally. Their data storage system is local-first, privacy-preserving and has over 1.5 million users across 55 countries.
FHIR is still actively being developed and used by health agencies in the United States, Australia and Europe. In the United States, the Cures Act requires that all certified Health Information Technology support SMART on FHIR. During the COVID-19 pandemic, up to 500 issuers in 20 states across America started issuing SMART Health cards as proof of vaccination. SMART Health cards were a layer of cryptographic verification built on top of existing FHIR authorization and API systems, demonstrating the versatility of FHIR as an open federated system.
Digital Imaging and Communication in Medicine (DICOM)
DICOM is the standard that has been used to store medical imaging in hospitals around the globe for over 30 years. In the year 1980, before the introduction of DICOM, it was difficult for anyone other than magnetic resonance imaging (MRI) and computer tomography (CT) manufacturers to understand machine-generated images. The National Electrical Manufacturers Association (NEMA) and American College of Radiology (ACR) then kickstarted a universal standards committee to fulfil the needs of healthcare workers and biomedical equipment vendors.
As of 2019, advanced features are still being appended to the protocol, the most recent being a comprehensive improvement to the web service, applications, and video streaming. In its essence, DICOM specifies a non-proprietary data exchange protocol, file format, and structure for biomedical imaging and information. Through the DICOM standard, automatic interoperability between medical imaging systems, management systems (PACS, etc.), and information systems (Radiology Information Systems, Cardiology Information Systems, etc.) can now be easily facilitated.
DICOM is currently used in medical devices for various medical specialities and it is the bedrock of most medical imaging systems all around the world.
The costs of sharing health data
Health data infrastructure has come quite a way since the advent of digital systems. Today, health data is more standardized and accessible than ever while providing convenient and efficient authentication. But, being better than ever does not imply perfect.
In September 2022, the World Economic Forum published an article criticizing major inefficiencies in the global health data system. The COVID-19 pandemic exposed over-centralization risk and coordination failures in health data infrastructure and the article outlines the potential use of web3 technologies to combat these issues.
As discussed earlier, infrastructure plays a direct role in reducing transaction costs for coordination. This implies that there are bottlenecks in existing infrastructure which could be identified to induce these coordination failures.
The Open Electronic Health Record (openEHR)
As seen from the figure above, openEHR stores patient healthcare data information in a shared platform where different healthcare institutions can access the encrypted data in their local jurisdictions. However, it also highlights that while patients might have control of their healthcare data, they cannot access it directly from anywhere around the globe.
For example, if a user were to experience a medical incident while travelling, foreign hospitals would be unable to view their records as all their health data would reside in their home country’s openEHR system. This means that users have a say but no sovereignty similar to data housed in any client-server system.
openEHR also consists of highly complex archetypes: these are “LEGO bricks” that are used to represent core clinical concepts. As these archetypes are maximal, all of them have to be described before implementation, which requires a lot of time and space.
One example is blood pressure data, in openEHR every possible representation of blood pressure is taken before a template is generated based on which archetype elements are needed (systolic pressure, diastolic pressure, the position of the patient, etc.). This makes openEHR very thorough but a hassle for implementations that do not require that level of detail.
Fast Healthcare Interoperability Resources (FHIR)
A recent study by Diameter Health highlights the inability of FHIR to account for data quality as a major bottleneck. The majority of allergy, lab results, and medication information is not coded precisely in EHRs, thus causing a lot of data to be unusable. This means that most data has to be sanitized before it can be parsed by FHIR.
Additionally, FHIR requires an additional translation layer to be reusable across various technologies. This translation is known as FHIR profiling and it is a necessary step for each new FHIR implementation due to its uniqueness. FHIR profiling customizes resource definitions by constraining the elements required, this is done by removing definitions that are not needed. The removal of unnecessary definitions is a time-consuming task but there are many tools (Kodjin, Forge, Trifolia, etc.) that have been developed to ease this process.
Jurisdictions also have differing requirements for key vital signs profiles: blood pressure profiles in the US use specific fields like Systolic and Diastolic pressure, but there are no such requirements in India. This exacerbates data fragmentation as multiple profiles for different jurisdictions have to be created for the same vital sign.
Digital Imaging and Communication in Medicine (DICOM)
As DICOM is a 30-year-old standard that is used for specialized tasks, most major cyber tools do not support the scanning of this file format. In recent years, security researchers have even found vulnerabilities that allow hackers to insert malware to infect patient data and destabilize an entire hospital’s PACS system.
Manual hash comparison can be done before executing the DICOM file but it is tedious and inefficient to compare the hashes of every single one of these files. Furthermore, even if the hash comparison is done automatically, there is a chance that the original hash was tampered with.
Non-technical costs
In addition to the technical costs of health data collaboration, there are many additional issues regarding regulatory overhead and economical incentives that must be considered.
Legal:
Most states have stringent security and privacy policies around health data, which “protect users” at the cost of cross-organization collaboration. These policies often indirectly incentivize data silos and hinder positive-sum interactions between organizations.
Economical Incentives:
In a competitive economy, user data is a precious resource that can be mined for profit. Sharing data then goes against the profit motives of many for-profit health organizations (private hospitals, health tech startups) which results in a lack of adoption of interoperable software systems. This is an example of incentive misalignment, where health outcomes would be boosted if users had sovereignty instead of just say over their health data.
A review of the existing infrastructure shows key areas of high transaction costs in health data transfer. The following are some solutions to tackle these issues:
-
Health data sovereignty, not health data say
Newer peer-to-peer digital architectures can fully return data sovereignty to users, enabling health records to be transacted over borders, privately and in a human-centric way. This is discussed in greater detail in our post on health data composability, and we are pioneering an initiative on this front called Habitat Health.
-
Automated Data Sanitization
A system that sanitizes data is crucial to make most health data usable. Un-sanitized data might refer to data that contains outdated information, data entered in the wrong fields or filled with duplicates or typos. Self-describing data formats show promise in this area:
One of the ways that organizations can ensure such consistency of data modeling with a multitude of data formats, structures, and sources is by relying on self-describing data models. These models provide the flexibility of schema needed for such a plethora of data types, but still deliver consistency in the modeling for specific applications.
- https://analyticsweek.com/data-modeling-tomorrow-self-describing-data-forma/
-
Open-source encrypted medical file formats
An open form of encrypted medical file format developed by the community will likely surpass the incumbents due to the limitations of proprietary software. As of 2022, there are little to no open-sourced encrypted medical file formats present.
This list is by no means exhaustive. Health data is illegible, complex, multi-faceted and highly personal, which makes it a very difficult data type to operate with. At Happily Ever After, we are thinking about this complexity and designing systems to help us improve outcomes in a way that centres health experiences around users.
While coordination failures in health data transactions are a big problem, they should not be considered a silver bullet. The aggregation of health data is a part of a larger puzzle: the problem of telling stories about a patient in an intuitive, human-centric way. Representation of data in visual forms is the key to conveying this complexity to clinicians and caregivers.
Want to join us?
Check out our wiki for more details on how you can get involved 🥳.
Subscribe to our blog for more long-form thoughts on the intersection between preventive health and web3.
Other HEA Channels:
Check out our website → https://hea.care/
Follow our Twitter → https://twitter.com/hea_care/
Follow our Instagram → https://instagram.com/hea_care/
References
Allen, A. (2022, January 7). Why openEHR is Eating Healthcare. Medium. https://medium.com/@alastairallen/why-openehr-is-eating-healthcare-e28bd792c50c
Apple. (n.d.). Accessing Health Records | Apple Developer Documentation. Retrieved 4 October 2022, from https://developer.apple.com/documentation/healthkit/samples/accessing_health_records
Beale, S. H., Thomas. (n.d.-a). OpenEHR-Home. Retrieved 27 September 2022, from https://www.openehr.org/deployments/jurisdictions/
Beale, S. H., Thomas. (n.d.-b). OpenEHR-Home. Retrieved 23 October 2022, from https://www.openehr.org/deployments/jurisdictions_detail/queensland-health
Beale, S. H., Thomas. (n.d.-c). OpenEHR-Home. Retrieved 26 October 2022, from https://www.openehr.org/deployments/jurisdictions_detail/moscow-city-department-of-information-technologies
Chainlink. (2022, May 13). Bela Supernova Awarded Chainlink-Filecoin Joint Grant. Chainlink Blog. https://blog.chain.link/bela-supernova-awarded-chainlink-filecoin-joint-grant/
CommonHealth. (n.d.). About. CommonHealth. Retrieved 22 October 2022, from https://www.commonhealth.org/about
Deloitte. (n.d.). The Future of Global Health Care. Deloitte. Retrieved 23 October 2022, from https://www2.deloitte.com/global/en/pages/life-sciences-and-healthcare/articles/global-health-care-sector-outlook.html
Diameter Health. (n.d.). FHIR and Data Quality. Diameter Health. Retrieved 24 October 2022, from https://www.diameterhealth.com/2022/07/fhir-and-data-quality/
DICOM. (n.d.-a). About DICOM- Overview. DICOM. Retrieved 22 October 2022, from https://www.dicomstandard.org/about
DICOM. (n.d.-b). History. DICOM. Retrieved 22 October 2022, from https://www.dicomstandard.org/history
Editors, T. Pl. M. (2013). Focusing the Spotlight on Lack of Access to Health Information. PLOS Medicine, 10(4), e1001438. https://doi.org/10.1371/journal.pmed.1001438
Fred Schulte & Erika Fry. (2019, March 18). Death By 1,000 Clicks: Where Electronic Health Records Went Wrong. Kaiser Health News. https://khn.org/news/death-by-a-thousand-clicks/
Haleem, A., Javaid, M., Singh, R. P., Suman, R., & Rab, S. (2021). Blockchain technology applications in healthcare: An overview. International Journal of Intelligent Networks, 2, 130–139. https://doi.org/10.1016/j.ijin.2021.09.005
HealthITSecurity. (2019, April 18). DICOM Flaw Enables Malware to Hide Behind Medical Images. HealthITSecurity. https://healthitsecurity.com/news/dicom-flaw-enables-malware-to-hide-behind-medical-images
HL7 FHIR. (n.d.). Profiling—FHIR v4.3.0. Retrieved 24 October 2022, from https://www.hl7.org/fhir/profiling.html
HL7 International. (n.d.). HL7.FHIR.US.CORE\US Core Blood Pressure Profile—FHIR v4.0.1. Retrieved 24 October 2022, from https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-blood-pressure.html
Maglogiannis, I. (2012). Towards the Adoption of Open Source and Open Access Electronic Health Record Systems. Journal of Healthcare Engineering, 3(1), 141–162. https://doi.org/10.1260/2040-2295.3.1.141
NRC for EHR standards India. (n.d.). FHIR Implementation Guide for ABDM. Retrieved 24 October 2022, from https://www.nrces.in/ndhm/fhir/r4/ValueSet-ndhm-vital-signs.xml.html
ONC. (n.d.). FHIR Version History and Maturity. 2.
openEHR. (n.d.-a). 7 Security and Confidentiality. Retrieved 23 October 2022, from https://specifications.openehr.org/releases/1.0.1/html/architecture/overview/Output/security.html
openEHR. (n.d.-b). OpenEHR Architecture Overview. Retrieved 4 October 2022, from https://specifications.openehr.org/releases/BASE/Release-1.0.3/architecture_overview.html
openEHR Atlassian. (n.d.). Introduction to Archetypes and Archetype classes—OpenEHR Clinical—Confluence. Retrieved 24 October 2022, from https://openehr.atlassian.net/wiki/spaces/healthmod/pages/2949191/Introduction+to+Archetypes+and+Archetype+classes
Sasa software. (2021, August 22). DICOM - The ‘Invisible’ PACS Vulnerability. GateScanner by Sasa Software. https://www.sasa-software.com/dicom-the-invisible-vulnerability-of-healthcare-networks/
Siemens Healthineers. (n.d.). DICOM [Text]. Retrieved 22 October 2022, from https://www.siemens-healthineers.com/en-sg/services/it-standards/dicom
SMART. (n.d.-a). SMART Health Cards. Retrieved 4 October 2022, from https://smarthealth.cards/en/
SMART. (n.d.-b). SMART Health Cards Framework. Retrieved 4 October 2022, from https://spec.smarthealth.cards/
VCI. (n.d.). Retrieved 4 October 2022, from https://vci.org/issuers
World Economic Forum. (n.d.). Is blockchain the solution for failing global healthcare? World Economic Forum. Retrieved 27 September 2022, from https://www.weforum.org/agenda/2022/09/blockchain-solution-for-failing-global-healthcare/