As the healthcare lead for Digital Asset, I spend a significant portion of my time on issues of privacy. Healthcare and Life Sciences handle incredibly sensitive and personal health information. Any data system that holds or processes Protected Health Information (PHI) must make efforts to secure that information. My work in healthcare is just a subset of a larger, and longer running, discussion on privacy preserving techniques on distributed ledger and blockchain systems, for example complex technologies like zero-knowledge proofs. But instead of talking about advanced cryptography, I wanted to briefly explore the “Daml driven” approaches to building systems compliant with major healthcare data protection regulations like HIPAA and GDPR.
It’s important to note that “compliance” to these regulations is complicated. Compliance includes that the overall architecture, execution and on-going operation of a healthcare solution. It makes no sense to ask whether Daml, or any other individual solution component, is HIPAA compliant. Instead, it’s essential to explore the options and tools that Daml provides for solution designers and operators to meet their compliance obligations. The following are some examples of how Daml is enabling enterprises to build compliant distributed ledger solutions.
Here is a video that I created so it is easier to understand those concepts:
Individual patient consent sits at the heart of both HIPAA and GDPR, as it does ethically for healthcare and life sciences. Compliant solutions must enable patient end-users to give their consent to data collection and processing. This is perhaps the easiest to demonstrate with Daml. As a language, Daml strongly enforces authorization and consent with simple primitives like Party and Signatory. In any workflow written in Daml, the ability for one party to affect is entirely dependent on the consent given by the second party. Without that consent, the following workflow of data collection, sharing or processing is impossible, making Daml an ideal tool for consent compliant workflows in healthcare and life sciences.
HIPAA and GDPR compliance require strict data minimization strategies. Minimizing the scope of the data for a process also minimizes the potential impact of a data breach or other exposure of PHI. When designing a Daml solution for sensitive and regulated data, the choice of what data to record on the ledger is a vital one.
Fortunately Daml gives the designer a number of tools. For those who want to keep such sensitive data completely off-ledger but still want the value of Daml smart contracts, there are a number of well-documented design patterns. More fundamentally, Daml offers a core language feature for contract and transactional Observers. Observer parties can be used to share specific pieces of data without revealing the entire transactional data set, termed “sub-transactional privacy.”
Here, I don’t want to talk about cryptography that typically comes up in discussions of distributed ledgers. Rather, I want to briefly touch on the standard requirements for encryption in transit. Standard solution architectures include passing PHI to the Daml runtime to exercise choices within a defined workflow. Daml’s JSON API Service supports TLS as does the Ledger API though it’s language bindings. See this example of establishing secure connections through Java bindings.
Beyond the larger question of data protection and privacy compliance on distributed ledgers, regulations for PHI introduce new challenges. For example, many countries require all protected health information to be exclusively stored locally, raising serious challenges to a multi-node distributed ledger architecture. This, and other examples, demonstrate that there is no one ledger for all possible industries and use-cases. Daml addresses this issue by offering choice.
Daml Ledgers come in all shapes and sizes, and the range of options is constantly increasing. Rather than having to shoe-horn one’s ledger into the regulatory requirements, Daml gives solution developers the power to let the regulatory and other non-functional requirements to select the best ledger option.
Daml has also a new learn section where you can begin to code online: