By Daniel Grossman
Read Kasushal Mhalgi’s original paper here
The problem:
Supply chain traceability of medical devices (from manufacturer to healthcare institution to patient) can be untrustworthy and inefficient, partly because modern ERP systems lack the infrastructure to sustain complex data streams.
READ MORE: WHAT IS AN ERP SYSTEM, PROBLEMS IN HEALTHCARE SUPPLY CHAIN, BLOCKCHAIN FOR SUPPLY CHAIN
The solution:
A blockchain-based ‘digital thread’ that records the device’s life cycle throughout the supply chain.
This technology enables one to track the product, identify all vendors involved, identify associated manufacturing and shipping batches, and recall the product. Given that all transactions are immutable in a blockchain (one cannot tamper with supply records), the data is secure as long as the network’s nodes operate in good faith.
How it works:
We used Hyperledger Fabric to build a system where the digital thread of a medical device is encrypted with AES-256 and stored on a permissioned blockchain. We deployed the network on Kubernetes to automate node recovery and efficiently balance loads. Additionally, we use NuCypher to securely share data outside of the network with patients.
The system:
1) A device manufacturer puts the encrypted digital twin on the blockchain upon ordering.
2) The digital thread (and decryption key) is shared with the patients’ healthcare institution once it purchases the device, fetching shipment data via APIs to update the thread.
3) Once the device reaches its destination, the institution verifies the shipment.
4) If they have expired devices, manufacturers and institutions can query the blockchain to find and return them. Patients can lookup their device information using a re-encrypted digital thread key provided by NuCypher.
HLF Transaction Flow:
1) A transaction proposal is submitted by the client (ie. healthcare institution, manufacturer) to one or more endorsing peers.
2) The endorsing peers sign the transaction with their digital key. Each peer has a synchronized copy of the current ledger.
3) The endorsements are sent to an ordering service, which verifies the peers’ cryptographic signatures. If the endorsements are satisfactory, the ordering service sends the transaction to all participating peers.
4) All peers update their copy of the ledger.
Performance results:
As the number of network peers increases, the throughout drops (low peers had 101.8 transactions per second, compared to 17 with a high number of peers). A 1 megabyte block size provided higher throughput with a lower number of peers. However, a 16 megabyte block size provided equal throughput with an increased number of peers. No transaction failure occurred.
