Break down data silos and drive data interoperability through Daml Integration
This is a quick introduction video of the Healthcare blog series by Corey Todaro, check it out:
After years of experimentation with blockchain and distributed applications, I am still struck by the phrase of putting a business asset or process “on the blockchain.” In the case of healthcare, that could be medical records, medical claims, clinical research, supply chain tracking. One can hardly blame hype about a comparatively new technology to be light on details. But the phrase misses the point, or at least hides what ought to be happening.
The true innovation of blockchain or Distributed Ledger Technology (DLT) is how they enable multiple parties to easily and securely share a single source of truth without centralizing all the necessary information. Put in the context of business, blockchains enable seamless and synchronized multiparty workflows, often called “smart contracts.” Daml is a toolchain that delivers efficient, clear and secure multiparty applications deployable on a range of blockchain platforms.
But how do we bring the power of smart contracts into healthcare operations? Rather than put “medical records” on the blockchain, we should be supporting multiparty workflows using medical records to generate real value for the healthcare system and, most importantly, patients themselves. But how do we get the data from a business process to smart contracts? As an industry, healthcare suffers a not undeserved reputation for piles of paper, faxes and multi-day waits for a business process to complete. The industry has a range of standard document messaging specifications (ex. X12) and even some evolving powerful API specifications (ex. FHIR). With Daml, we can tap these resources to not just send messages but to build real multiparty shared automated workflows.
As a practical example, let’s take FHIR, a powerful new clinical data specification. FHIR moves clinical data access beyond clinical “documents.” For example, instead of receiving a CCR (Continuity of Care Record) upon discharge, with FHIR, an application could receive granular data specifications. In other words, FHIR enables us to build API’s to pull and push clinical data between EHR (electronic health record) systems (ex EPIC or Cerner) and applications designed to use clinical data. The opportunity for physicians, insurers and consumers to be able to tap the wealth of clinical data stored within EHR’s.
With Daml, we can make use of existing specifications and APIs to integrate smart contracts with existing data sources and processes in healthcare, a powerful combination. We can translate messaging specifications into Daml types, natively representing healthcare data within Daml smart contracts. But we can also create automated bots that listen for API events and enable the multiparty logic of the smart contract to automate a response.
With Daml, we have the essential tooling to automate multiparty processes like Prior Authorization or Value Based Contracting. In each of these cases, stakeholders are forced to synchronize data with other entities. In Prior Authorization, very commonly a provider like a radiologist will require authorization from a health insurer in order to deliver an imaging study, like an MRI, to a patient. This process is largely still paper based, requiring phone calls, faxes and often days in delay. With Daml, a shared process can be constructed whereby essential qualifying clinical data is delivered via a FHIR certified API to a Daml smart contract which contains health insurers eligibility logic, returning not only the authorization to deliver the essential service but also properly formatted messages, in this case an X12 278 message as required by state regulations.
There are more examples of this Daml-enabled integration that will be explored in forthcoming Daml healthcare blog posts.
Corey also previously wrote "Daml Driven Development: Hashed Health"