Dan Connolly's tinkering lab notebook

Smart Contracts for Health Research Data Sharing

I'm under contract with RChain, two days a week from June to December, to work on smart contracts for health research data sharing. I'm still at KUMC for the other three days a week.

RChain Devcon Boulder

In April, I was invited to RChain Devcon in Boulder. I enjoyed Greg's RChain VM talk. (More on that later, I hope.) Vlad's CBC Casper talk was mostly familiar; I think I got most of it from his devcon three talk, which was just my speed.

I gave a short talk about Getting Involved in the RChain Bounty Program (video).

TimBL had written The web is under threat, which I used as a springboard for Can RChain Answer? (video). My summary slide is:

It has a lot of the right pieces:

  • Object Capability Discipline
  • Support for Formal Verification
  • Integrated Economics with Network Architecture
  • Scalability
  • Down to transistors
  • Up to the globe
  • Visionary Leadership
  • Cooperative Governance

I did a quick run up of capabilities from simple closure-based objects to sealing and unsealing to capability-based money as in Miller, Morningstar, and Franz from FC 2000, including:

Before presenting the following simple example of capability-based money, we must attempt to head off a confusion this example repeatedly causes. We are not proposing to actually do money this way! A desirable money system must also provide for: ... blinding, non-repudiation, accounting controls, and backing (redeemability).

Then—tada!—I showed that RChain does propose to do money this way by translating the E code to MakeMint.rho:

   contract MakeMint(return) = {
     new pairCh, thisMint, internalMakePurse in {
       MakeBrandPair!(*pairCh) | for(@p <- pairCh) {

HERON Clinical Data Repository Access Policy

The main smart contract I want to work on is an evolution of the HERON policy enforcement layer, a bunch of python / PHP / SQL code that enforces the policy around access to KUMC's clinical data repository on ~500K patients: you have to be qualified faculty or sponsored by one, and your human subjects training has to be current and you have to sign a couple forms:

flow of authority

Once you get through all that, you can use the i2b2 ad-hoc query interface to do "cohort discovery"; for example, to find out if enough of the right kind of patients come through KU Med for the study you want to do.

i2b2 Harvard Symposium

The i2b2 tranSMART Foundation Harvard Symposium was this year's annual meeting of the i2b2 user community. Automation of regulatory processes is a regular topic and this year John Halamka spoke on Emerging Models of Data Flow - APIs, Blockchain and Cloud. He cut through a lot of the mystery around blockchain technology with a great illustration of one-way hashing. :)

Decentralized identity, verifiable claims

While killing time in the airport, I managed to reach Manu Sporny. His work around verifyable prescriptions has certain parallels with research data sharing. It wasn't all good news, but he did put me in touch with a couple of his colleagues in the Boston area.

I had hoped to meet with Chris Webber and sync up on js libraries for linked data capabilities. Capability security seems necessary and sufficient, to me, for decentralized access control. As Stiegler put it in the picture book:

The patterns described in this picturebook are simple because they discard the modern fascination with the identities of the participants. Individual Authentication is so pervasive, it is now a part of the problem.

Suppose that your car, instead of accepting a delegatable key, demanded that your driver’s license match the car’s title registry, which happens to be in your spouse’s name. Entrepreneurs would leap forward to develop ever more powerful "identity management" for automobiles. We would subcontract to security experts so our teenage daughters could borrow the car to buy milk. Heaven forfend that the daughter, breaking her leg, had to delegate to her best friend to get to the hospital.

Unfortunately, while Chris is closer to Boston these days, he's still a couple hours away.

But I did get to meet Dmitri Zagidulin over breakfast. He has done javascript work both with TimBL and company on solid and with Manu on decentralized identifiers (e.g. did-io). He isn't yet working on linked data capabilities yet, so I twisted his arm in that direction, and away from WebID.

Things started to click for him when I talked about verifyable claims in terms of insurance and markets:

Proof of identity, in so much as it involves revelation of the profile, or enables its revelation through the use of unique identifiers, is trade in an asset when the information revealed is more than the minimum required with current technology. -- Vora et. al from HP at W3C 2001 DRM Workshop

Take proof of age, for example. A smart contract for a client might ask "who will bet me $10 at 50-to-1 that this request comes from someone over 21 years of age?" A business where people are routinely physically present is in a position to take such bets with high confidence.

Personal Health Records

Manu also put me in touch with Adrian Gropper, CTO of Patient Privacy Rights. Meeting in the airport as he was arriving and I was departing was a bit hectic, so I couldn't be sure whether I had read the paper he and Mark Miller worked:

His description of HIEofone increased the priority of UMA in my things-to-study-in-more-depth list:

HIE of One (Health Information Exchange of One) is a volunteer-driven open source project to combine emerging standards for access authorization (OpenID HEART) and emerging standards for blockchain-based self-sovereign identity (DID) into a patient-centered health record infrastructure.

He was one of several people on this trip that talked about FHIR deployment in ways that make me want to look into it again. In particular, he mentioned a FHIR sandbox by CMS, the medicare folks.

OCap-safe JavaScript

On the way home, I got stuck in the Washington D.C. airport overnight due to weather. I used the time to start tinyses2rho, some exploratory scala code to integrate TinySES with RChain.

TinySES is a small subset of JavaScript designed so that non-experts can use to write non-trivial non-exploitable smart contracts. It comes from Mark Miller and company, who have been working on object capabilities and smart contracts at least as far back as the early '90s, and recently launched Agoric.

DCA in the wee hours