This summer, I spent six weeks working at Digital Asset (DA) on the Enterprise Solutions team. As a rising junior computer science student at Duke University, I was excited about the opportunity to not only learn about smart contracts and secure multiparty workflows, but also put my skills to practical use. In the short time I spent at DA this summer, I was able to learn Daml and create a functioning reference application, which would have been very difficult to do had I been using another language.

I brought to this project my personal experience of the friction and frustration in dealing with the healthcare system as both my mother and sister have Type 1 diabetes. Timely access to personal medical data is a huge problem. Each healthcare system has their own siloed data store of electronic medical/health records (EHR’s). Getting information to physicians outside a single health system can be complicated, a process still relying on fax machines in many cases. In cases of emergencies, valuable health information is often inaccessible to emergency physicians.  In my own personal experience, there have been situations where my diabetic family member’s blood sugar has dropped so dramatically that they cannot communicate with anyone and require immediate medical attention. In a specific occurrence, a member of an emergency room team thought it was a good idea to give my mother bread to bring her blood sugar back up. However, this would have been a mistake as she also has Celiac Disease and cannot consume gluten. These vital pieces of information were not accessible to the emergency physicians. But for my family being present to communicate this information, this could have ended in disaster. 

Responding to my own experiences, I ideated, designed, and modeled a way for patients themselves to securely give permission and share their medical information and records with physicians or other service providers using Daml. Coming into the summer, I had very minimal exposure to Daml and functional programming in general. As such, a major component of building the reference application was self-teaching Daml by reading the Daml SDK documentation with a bit of help from the experts at DA. 

It was a very fulfilling, albeit at times challenging experience learning Daml. Even after my initial understanding of the features of Daml, it was a continuous learning experience as I built the application. For example, I learned the theoretical application of contract keys, but it wasn’t until I used them in practice and understood the ability to fetch them “globally” without there needing to be template input fields that I appreciated their usefulness. 

I learned that Daml is simple, yet powerful. Reading the reference applications’ code, I am struck by Daml’s readability, extensibility, and its concision. In a just a few lines of code, I could specify very complex and secure multiparty interactions. In building this reference application, I found that Daml simplified application design, abstracting away complexities that are not core to the business logic. Instead, I could focus on the essential value of the application: the ability for patients to securely share essential medical data with healthcare providers across the continuum of care. 

My reference application addresses the problems of inaccessible health data by empowering the patient to create a secure network of healthcare providers who are granted permission to view consumer healthcare data. The key is the individual patient’s consent to share their discrete health information. The workflow is as follows, including Daml code snippets. 

• The patient proposes permission decisions to each health care professional (HCP) in the system stating what data they will receive whenever new data is available. This ensures that HCPs will always only receive personal health information (PHI) that the patient allows.

Alternately, HCPs may also counter-propose different permission decisions if they feel it is necessary:

Importantly, note that the application respects the patient as the owner of the data and the sole party who can give permission for its dissemination. The patient can thus revoke an HCP’s access to their data as they see fit. If they would also like for a new HCP to have access to their data based on already-determined permission decisions, they can consequently use their master contract to share the aforementioned data.

These are the vital components of the patient data propagation workflow that instill confidentiality, immutability, and thus reliability. By using Daml, we are able to provide a significantly more efficient and reliable overall experience for all parties involved.

This reference application can serve as an essential foundation for many other patient health data use-cases. First, as wearable health-focused technology becomes ever more mature including for example, Continuous Glucose Monitors (CGMs) or Apple Watches, this application could incorporate automated wearable feeds and distribute that information to the patient-defined network of HCPs. This also has utility in remote monitoring or home care situations. Even further, the long-standing problem of medical interoperability could be addressed through Daml patient permission templates. 

By using Daml vs. other traditional coding languages, I was able to build a reference application in only six weeks. It is pretty amazing being able to learn an entirely new programming language and write real-world, useful applications in a mere matter of weeks. Building the reference application was made much easier due to Daml’s capabilities that are otherwise not available or very difficult to construct in other languages. I definitely see myself continuing to utilize Daml to model other workflows that also pique my interest as the use-cases that fit within the scope of Daml’s capabilities are seemingly endless. I look forward to seeing all that will be created with such a powerful tool.

Install the Daml SDK now and try for yourself.

Jordan Mittleman is a third year computer science student at Duke University