Developing an open source DLT layer for healthcare data exchange
“It’s 2040. I’m 80 years old and fully able to manage my own health. We finally have the secure information infrastructure that allows us to collect, analyze and compare our health and behavioral data ourselves.” 
Unfortunately, the reality of today is that there are still significant barriers in exchanging healthcare information between different sources (hospitals, insurance, wearables devices, etc.), which may delay providers’ decision-making ability, prevent patients from having a more engaged role in their health and leading to higher costs.
In the USA, a 2017 study showed that c. 60% of the assessed hospitals were not able to find, send, receive and integrate electronic patient information from outside care providers . Additionally, in almost 40% of the cases where information was exchanged, it was a challenge to match or identify the correct patient between systems . The situation is not much different in Europe, where only a limited number of citizens were shown to have online access to their healthcare records, and the percentage of hospitals exchanging healthcare records electronically was shown to be stubbornly low (e.g. only 39% of hospitals exchange information electronically within the same country, and only 4% of hospitals exchange information with hospitals in other countries) .
The purpose of this article is, therefore, to introduce a new approach for healthcare data exchange, by making use of the decentralized and therefore always available nature of DLT.
Benefits of achieving this interoperable healthcare data exchange  include:
- Strengthened care coordination — by having real-time access to patient data, providers, patients and caregivers can collaborate and make joint care decisions
- Improved safety and quality — interoperable patient data helps to avoid duplicate tests and conflicting medications, which ultimately translates into better and safer care
- Increased efficiency and reduced costs — information sharing saves clinical and administrative time as well as reduces repeated exams, which ultimately reduces costs for patients, providers, and insurers
- Robust public health registries and research data — anonymized aggregated patient health information will allow for faster monitoring of public disease threats and to support in advanced research
One could argue that the described problem could be addressed with a centralized database architecture. Several initiatives such as healthcare information exchanges (HIEs), middleware providers and patient portals, have shown that that is true.
However, for certain use cases, the DLT approach presents advantages over the centralized approach due to:
- by nature, it enables patients to own and manage access to their data (as only they are in control of encryption keys)
- it removes the need to trust a single authority with one’s data, by inverting data ownership dependencies
- it opens the room for innovation and for a broader spectrum of healthcare applications to be deployed since the consequence of 1 and 2 is the removal of data silos, potentially making healthcare more patient-centric
One of the most well-known advantages of IOTA is its feeless nature. In combination with MAM (a second layer protocol for IOTA), this allows for free data exchange.
The feeless nature of IOTA is particular useful in those cases requiring continuous/high volume data exchange. In healthcare, this would be represented by the Internet of Medical Things (IoMT) space, where millions of devices (e.g., wearables, mhealth apps, etc.) currently generate continuous data streams. Since providers do not have the time to analyze this raw data, analytics tools need to be developed that develop digestible insights. Advancements in this data analytics space is therefore highly dependent on the fluidity and exchange of device generated data.
FHIR — A healthcare standard
In healthcare, one key requirement for the adoption of new technologies is interoperability with older systems in place. For this reason, we have chosen Fast Healthcare Interoperability Resources (FHIR) as the underlying exchange protocol for healthcare data.
This allows integration into existing systems by facilitating the JSON or XML API functionalities that are specified within the FHIR spectrum.
Besides interoperability, FHIR has other benefits that let it stand out as a healthcare standard, such as versioning (different versions of FHIR can co-exist in a system) or the strict usage of web standards .
As part of our Untangle Care project  our goal is to build a solution that enables for patient-generated health data to be exchanged fluidly and freely with the rest of the healthcare ecosystem (doctors, insurance, caregivers, etc.), while still keeping patients in control of its ownership and access. We are therefore developing a FHIR compliant system , which allows data-generating applications (e.g. connected devices, mHealth apps, etc.) to work with FHIR resources, exchanged on the Tangle via MAM.
This system is divided in three parts, which we explain further in the following passages.
It implements interactions as use cases and defines an interface for the FHIR data source (decoupled from IOTA). Implementing the interface allows us to work with different data sources, thus making the system more flexible and integrable with existing FHIR data sources.
Iota Implementation Layer
The IOTA layer  comes with an implementation of the FHIR data source interface. Internally it uses MAM to manage FHIR resources and defines interfaces that need to be implemented in order to work in a stateful environment.
FHIR allows resources to reference each other. This is particularly useful when resources need to be linked to a patient.
All linked resource streams are derived from one seed. This obviously comes with the responsibility to take care of a patients’ seed, as it is the “master key” to all FHIR resources but allows to switch between devices, without the need to persist the credentials of any stream, since all streams can be imported in a deterministic manner.
Given a patient that received an immunization, the patients’ resource stream would be at position 1 of the seed and the immunization would be at position 2. An additional resource would have position 3 and so forth.
One of the main reasons to use a DLT as a data exchange layer is the inversion of data dependencies. This means, that only patients have direct access to their data, and only they may grant permission to view or alter it.
Anyhow, it must be assumed that not all patients want to manage health records by themselves. This is why there are two options to manage a seed and its resources.
On the one hand for patients who do not want to manage healthcare records, it is possible to let the healthcare provider (e.g., a clinic or an insurance company) to manage their seeds. On the other hand, people can choose to manage the seeds by themselves and just share access to certain resources, by sharing the corresponding MAM channel credentials.
Since MAM channels are stateful by default, it is advisable to keep track of resource channels in a stateful environment.
The IOTA layer, therefore, specifies an interface that defines how to keep track of MAM channels and subscriptions. As this layer carries all data that is needed to access patients’ resources, it should internally handle data in an encrypted manner.
SQL Lite Iota Layer
As mentioned above, the IOTA layer specifies certain interfaces that need to be implemented. The SQL Lite layers’  function is to demonstrate a reference implementation for those interfaces.
MAM Channel Credentials
All resource MAM streams are derived from one seed. The Credential Provider implementation keeps track of the current position on that seed (a pointer). This allows for new channels to be created faster, as it makes the need to incrementally check positions for an existing MAM stream obsolete.
Resolving the reference into the seed for the linked resources is what the Reference Resolver does. This obviously means that it has access to the said seed. We, therefore, handle all data encrypted using Rijndael encryption .
The Resource Tracker persists all channels and subscriptions belonging to a seed. This is necessary since MAM channels are not stateless. All channels and subscriptions are encrypted using Rijndael encryption .
Given the nature of DLT, it is not possible to delete transactions that have been issued. Consequently, it is not possible to delete FHIR resources. One possible solution for this problem is to just mark the resource as deleted. This may be integrated in a later development cycle.
In addition, it is currently not possible to have transactional requests on multiple resources, since that would require the system to have the option of a rollback.
While the presented data exchange solution promises to overcome said data exchange hurdles, further research needs to be done.
During this further research, it is crucial to keep in mind the existing data privacy and management legislation (e.g. GDPR or HIPAA). We will therefore start to validate the system with the help of Synthea ., a „synthetic patient generator that models the medical history of synthetic patients“, allowing us to work with realistic patient data, while maintaining GDPR/HIPAA compliance, due to the nature of its synthesized data .
To bring the above in relation with Untangle Care , a detailed documentation about everything said above and the development of a Synthea based “validation application” will mark the end of the current milestone.
While being the end of the current milestone, the Synthea application also marks the beginning of the next one, as it will be iteratively extended into a working patient management system in the form of a FHIR web application.
If you are interested in updates to any of the mentioned topics or have any questions about them feel free to join us on discord.
 Holmgren A J, Patel V, Adler-Milstein J. Progress in interoperability: measuring US hospitals’ engagement in sharing patient data. Health Aff. (2017)