DokChain Technical Deep Dive - Part One

In the last post, we introduced DokChain and discussed where we are heading as the definitive platform for the business of health. While we have proven and solved many issues surrounding scheduling, interoperability, and identity, we are also changing the entire substrate of processing for all #HealthIT. So with this in mind we will now embark on a multi-part (chained?) blog series to discuss the current and future areas for DokChain.

We have implemented a version of the ethereum EVM for deployment of DokChain. In addition, we have also created a version of DokChain using the Microsoft Blockchain as a service. We currently have the default method of proof of work. As you will see in future posts, we believe this to be suboptimal for engaging across business mechanics for smart contract generation.

So, how do we go about setting up the services? We had already thought about using blockchain for healthcare back at PokitDok's inception in 2011. Therefore, with the uptake in API usage in Health IT, we designed the system with this in mind.

While we currently generate production ready smart contracts for 270/271 (Eligibility) we will easily have the rest of our platform online later this year.

We will provide on ramp services to all of the current APIs and, for the most part, all of our applications and trading partner interactions will remain unchanged.

So what have we accomplished? The following is an architectural diagram depicting what we presented back in June for production ready code on Microsoft's Azure Infrastructure:

DokChain Architecture

DokChain Architecture

At the top level, we first automatically generate a multi-signature wallet for the consumer and for the provider. All of our agreements including 270/271 (eligibility), 835, 837 (claims) and provider search will be couched within the smart contracts we'll be generating. In the future, when you sign up for our platform these will be automatically generated as part of your DokChain SDK environment.

In the next tier down, we are leveraging the pyethapp crypto state machine. Pyethapp generates core blockchain related logic such as transactional cryptography and virtual machine contracts. In the case of DokChain, we have leveraged this logic and modified it to meet the schema and data needs of our platform. It also allows a complete networked app without any overhead of re-tooling. PokitDok has made several pull requests to this code base (123, 128, 129, 341).

Next in line we have ethjsonrpc which allows a python client for Ethereum using the JSON-RPC interface. Specifically it implements all 62 JSON-RPC methods and provides a high-level interface to create contracts on the DokChain and to dynamically generate and call contract methods and process events. PokitDok has contributed to this code base as well (8, 9).

We then come to the glue code that implements the interface between the ethjsonrpc and the PokitDok platform. This allows full access to all of the current interfaces including payers.

Ok, given the architecture, what is the actual flow of the process on DokChain for an Eligibility check? Below is the flow graph for the production ready code we demo'd in Redmond, Washington:

DokChain Flow for Eligiblity Check

DokChain Flow for Eligiblity Check

Prior to the eligibility transaction itself, or any other DokChain transaction for that matter, identity must be established for the interacting parties. Identity is established via a smart contract or wallet for each participating entity. Providers and consumers get wallet codes on the blockchain that implement access control and storage for verified tokens. Payers are typically represented by smart contracts representing the services they provide, in this case, eligibility verification.

The actual code for the consumer wallet generation is as follows:

Similarly, the provider wallet code:

The eligibilityUpdate  method in each wallet is invoked by the eligibility contract to store the token verifying the status of the individual's insurance when a response is received.

The eligibility contract is the smart contract code, which orchestrates the interaction of the consumer and provider via their on-chain wallets and the payer or other off-chain data or system:

Given that a consumer has approved access to a provider, which is maintained in the wallet code through use of the onlyApprovedAccounts function modifier, a provider can invoke the eligibility contract to request  a current eligibility check be performed on behalf of a consumer. This method will verify that the previous access grant has been stored in the consumer wallet and, if so, will then publish an EligibilityEvent. The off-chain system, PokitDok Platform, will scan for EligibilityEvent  transactions using the ethjsonrpc client, process the legacy ASC X12N 5010 270/271 eligibility transaction request/response with the appropriate payer and then invoke the response method of the Eligibility contract.

Scanning for EligibilityEvent  and processing:

Processing eligibility transaction and invoking the response method of the eligibility contract:

The eligibility contract will then update the token in the wallets for the consumer and provider, given that access is still granted. As noted, this uses Proof Of Work, which as previously mentioned, is not optimal for health transactions on DokChain. We will be addressing in greater detail in the future.

We want to emphasize that all of our of 500+ payer connections that represent over 90% of covered lives do not have to be notified of DokChain interactions. Further, the current set of applications will auto-magically take advantage of this architecture. This is patent pending technology that has been engineered such that anyone who is signed up for our platform can immediately take advantage of it.

This pattern for creating identity, managing access grants, storing cryptographically verified pointers to off-chain data, and orchestrating interactions of these identities with healthcare services is a repeatable means to bring all of the business of health to the blockchain.

It is the intent of PokitDok to become not only the defacto standard for identity management in health IT, but also to become the reference for the intersection of smart contract generation and services for the intersection of #FinTech and #HealthTech. We further believe that given our backgrounds in #machinelearning #graphtheory and #computationaltopology, we will also forge a new level of #artificial_intelligence using DokChain for the health sector.

PokitDok will continue driving and refining these technologies to expand upon this foundation and provide a robust framework for secure, reliable smart contract generation as well as the infrastructure for combining all of the healthcare off-chain data and systems with on-chain execution and intelligence.

In our next blog, we will discuss how we are developing technologies specifically aimed at smart contract validation as it pertains to turing vs non-turing languages.

Until then,



About Ted Tanner

Ted Tanner, Jr. is the Co-Founder and CTO of PokitDok. Ted has had architect positions at both Apple and Microsoft and has held instrumental roles in several startups, including digidesign (IPO and acquired by Avid), Crystal River Engineering (acquired by Creative Labs), VP of R&D at MongoMusic (acquired by Microsoft) and Co-founder and CTO of BeliefNetworks (acquired by Benefitfocus). He was also the CTO of Spatializer Audio Labs (NASDAQ: SPAZ), a company specializing in digital signal processing solutions.

Ted is on the Clemson University Restoration Institute's Executive Advisory Board, the Industry Advisory Board (IAB) for the University of South Carolina Computer Science Department, the IAB for the Center for Intelligent Systems and Machine Learning at the University of Tennessee, and Advisor to the College of Charleston's Department of Mathematics. He has published numerous articles in leading technical magazines and holds several patents in the areas of blockchain, semantics, machine learning, signal processing and signal protection.

View All Posts