white paper v1 - medchain whitepaper v1.0.pdf · 2018-06-04 · blockchain market, our sec-filed...

White Paper v1.0

Joachim Sandgaard & Steve Wishstar

Executive Summary 7

Mission 7

Summary 7

Some Facts 8

The MedChain Solution 8

Team 9

Key Takeaways 10

The Problem 11

The Backstory 11

Data Security 11

Interoperability 11

The Cost 12

The Problem: Key Takeaways 13

The Solution 14

Ensuring Security 14

Guaranteeing Interoperability 15

Standards Framework 15

Practical Ability 15

Ensuring Patient Control 16

How it Works 16

System Components 17

Tokens 17

Patient dApps 18

Service Provider dApps 18

Nodes/Hardware 19

Blockchain as a Service 19

MedChain White Paper v1.0 Proprietary & confidential. Copyright © 2018 MedChain, inc. All rights reserved. 2

Software as a Service 20

Our Solution: Key Takeaways 20

The Benefits for Providers 20

The Benefits for Patients 21

The Benefits for the MedChain community 21

Technical Details 22

The MedChain Network Overview 22

The MedChain Protocol 22

Files and Database EMRs 23

Patient dApp 24

Overview 24

Key Features 24

New Patient Procedures 25

Service Provider dApp 26

Overview 26

Key Features 27

Federated Servers 27

Secure Medical Record Chain (SMRC) 28

Provider Nodes 28

Storage Nodes 29

Interplanetary Filesystem 29

Proof of SpaceTime 30

Proof of Accessibility 30

Storage Market 31

Duration of Storage 33

Record Token Pricing 34

Auditability 35


Chain Nodes 35

Oracles 36

Secure Medical Discovery Chain (SMDC) 36

Mining Nodes 37

Storage Nodes 37

Storage Market 37

Chain Nodes 37

Oracles 38

Public Verification Chain 38

Blockchain Implementation 39

Entry Block 40

Directory Block 40

Access Block 40

Verification Block 41

Security Tokens 41

MedCoin 41

Utility Tokens 41

Record Token 41

Discovery Token 42

Future Tokens 42

Team 43

Joachim Sandgaard, Founder & CEO 43

Steve Wishstar, Chief Technical Officer 43

Eric Lafleche, Chief Marketing Officer 43

Russ Decker, Blockchain Developer 43

Ethan Plue, Community Manager 43

Advisors 44


Gene Libov, Information Security Advisor 44

Matthew Hunter, Data Extraction and Integration Advisor 44

Hazel Sebastian, Business Development Advisor 44

Dr. Steve Malen MBA, Healthcare Analytics Advisor 44

Accounting / Financial Auditing 44

Thomas Sandgaard, Chairman & Co-Founder 44

Go to Market Strategy 45

Near Term 45

Longer Term 45

Roadmap/Anticipated Timeline 46

Financing 47

Token Allocation 47

Funds Allocation 48

Risk Factors 49

Conclusion 55

Addenda 56

Definitions 56

MedChain 56

The MedChain Security Token 56

IPFS (InterPlanetary File System) 56

Record Tokens 56

Blockchain technology 56

Ethereum 57

HIPAA Regulations and Compliance 57

GDPR 57


This document is for informational purposes only and does not constitute an offer or solicitation to sell shares or securities in MedChain or any related or associated company. Any such offer or solicitation will be made only by means of a Private Placement Memorandum and in accordance with all applicable securities laws.

We may make an offering of securities pursuant to Rule 506(c) under the Securities Act in which case only persons verified as accredited investors may invest.


Executive Summary Mission

MedChain's mission is to use blockchain technology to establish a better, more secure and transparent framework for Electronic Medical Records (EMR) that vastly improves the quality of care for patients while reducing healthcare providers' costs. This allows companies and individuals to build software and applications within a globally compliant framework facilitating secure storage and transparency.

Summary

MedChain is offering a blockchain and distributed storage solution for Electronic Medical Records (EMR) and electronic Protected Health Information (ePHI). The MedChain Network (MCN) is an extensible, layered architecture and protocol system governed and secured by multiple blockchains that utilizes a multi-crypto-token framework. The architecture has been thoroughly vetted because of the highly regulated healthcare arena and the personal interests of all the developers involved.

According to a 2014 CNN report, “no industry has been hit harder by hacking and data 1

breaches than healthcare”, and the problem continues to grow. Additionally, not only is healthcare data being stolen, it is also being lost with “as many as half of patient records mismatched when data is transferred between healthcare systems.” . 2

MedChain’s goal is to secure patient data, improve patient outcomes, reduce costs and put control back into the hands of the patient -- both literally and figuratively.

The MedChain solution benefits providers from the smallest private practice, to all the laboratories supplying the test results or durable equipment, to the largest hospital systems in the nation by improving the interoperability between each EMR system involved. Cost savings will be realized throughout the industry by streamlining data flow and user experience, reducing IT overhead, and ensuring true and accurate data for each patient.

The goal of MedChain is not to become yet another silo of data, but to open up all the silos to form a “common data layer” where all patients’ records are accessible by all the service providers on the network. This interoperable common data layer is a disruptive concept to the status quo, but will prove mutually beneficial to both the patient who wants control of their medical records and those who are storing medical records.

1 “90% of hospitals and clinics lose their patients' data”, Paglieri, CNN, August 2014 2 “Top 5 Challenges to Achieving Healthcare Interoperability”, Monica, EMR Intelligence, August 2017


Funds from our financing campaigns will be used for MedChain development, and for marketing initiatives that raise awareness of MedChain's products.

Some Facts

● “90% of hospitals and clinics lose their patients' data.” 3

● “As many as half of patient records are mismatched when data is transferred between healthcare systems.” . 4

● “Data breaches could be costing the healthcare industry $6.2 billion per year.” . 5

● Medical error is now the third leading cause of death in the USA , surpassed only by 6

heart disease and cancer.

Healthcare continues to lag far behind other sectors when it comes to implementing security and interoperability. It is literally costing lives and it is time for things to change.

The MedChain Solution

The two primary challenges faced by Electronic Medical Records (EMR) and electronic Protected Health Information(ePHI) systems are data security and interoperability.

MedChain solves both by decentralizing Electronic Medical Records and putting control in the hands of the patient.

MedChain's combination of cutting-edge blockchain protocol technology, military-level encryption, distributed secured storage and open-source framework will set a new standard in HIPAA/GDPR/globally-compliant medical record-keeping.

Patients interacting with the MedChain Patient dApp will feel more empowered and in a better position to improve their health because all the data is literally “in their hands” and available when they need it. The patient will have the technology to instantly share the proper information with whomever they choose. MedChain effectively enables the burgeoning fields of medical record interoperability and telemedicine by providing the common data layer that is missing because current EMRs are siloed in proprietary systems.

The Service Provider App vastly improves the doctors’ and clinicians’ experiences by connecting patient lab results, prescriptions, medical history and other data into one coherent record. Faxes and mailed copies will be a thing-of-the-past. The IT Departments for each provider will start seeing reduced overhead (instead of years of increasing requirements)

3 “90% of hospitals and clinics lose their patients' data”, Paglieri, CNN, August 2014 4 “Top 5 Challenges to Achieving Healthcare Interoperability”, Monica, EMR Intelligence, August 2017 5 “Sixth Annual Benchmark Study on Privacy & Security of Healthcare Data”, Ponemon Institute, May 2016 6 “Medical error—the third leading cause of death in the US”, Makary & Daniel, BMJ, May 2016


because the data is automatically handled in a HIPAA & GDPR-compliant way by the Network itself. Backups, fail-safes, and verifications are built into the system. The MedChain solution actually turns data storage into an asset instead of a liability: current hard-drive and databases (yes, and even tape storage) become a source of income to offset the investments made under the “old approach”.

The MedChain approach ensures that our solution is properly certified within the HIPAA and GDPR rules and regulations. These regulations are designed to protect the patient, and thus, has strict mandates the industry must follow that other approaches that are entering the market appear to ignore. Additionally, in order to maintain the strictest integrity of an investable blockchain market, our SEC-filed offerings present our backers an unprecedented level reassurance that no other blockchain related healthcare approach has taken to date!

Team

Joachim Sandgaard, Founder & CEO

Seasoned IT professional with almost two decades of experience in the healthcare and medical device industry in System Administration, and Network Management.

Steve Wishstar, Chief Technical Officer

Experienced CTO, manager, and blockchain/full-stack developer with over 10 years of CTO experience, and 40 years working software projects with world-leading organizations such as NASA, Lockheed Martin & University of Colorado.

Eric Lafleche, Chief Marketing Officer

Former Global Marketing Manager at Budweiser & Lead Innovation Manager at Unilever. co-host of Crypto Starship and Co-Founder of the Tradescout Protocol.

Russ Decker, Blockchain Developer

Developer and analyst at the Mayo Clinic working with medical decision tools and with experience integrating healthcare interoperability solutions.

Ethan Plue, Community Manager

Social media and community management expert.

Gene Libov, Information Security Advisor

Former Director of Security and Technology Assurance at Blue Shield of California.

Matthew Hunter, Data Extraction & Integration Advisor


Data extraction expert and former CIO of Union General Hospital.

Hazel Sebastian, Business Development Advisor

Dr. Steven Malen MBA, Healthcare Analytics Advisor

Over 10 years in pharmaceutical management.

Thomas Sandgaard, Co-Founder & Chairman of the Board

Entrepreneur, Founder & CEO of Zynex Medical, a publicly traded Medical Device company. (Ticker: ZYXI)

SEC Compliance / Legal Advisor

Sichenzia Ross Ference Kesner

Accounting/Auditing

EKS&H

Key Takeaways

MedChain will improve patient outcomes and reduce healthcare costs by solving the two biggest challenges faced by Electronic Medical Records and electronic Protected Health Information systems: data security and interoperability.

We will achieve this by putting the patient at the center of their own medical records, and using a novel implementation of a Hyperledger Fabric blockchain, a novel implementation of a permissioned Distributed Storage Network, and verification anchoring to the Ethereum Blockchain for transparency and auditability.

MedChain is currently the only ICO to offer a SEC-filed offering and HIPAA & GDPR-compliant solution for Electronic Medical Records and electronic Protected Health Information systems.

We invite you to join us in our quest to give all patients the medical care they deserve.


The Problem

The Backstory When the US Congress passed the Health Insurance Portability and Accountability Act (HIPAA) in 1996, they required the establishment of national standards for electronic healthcare transactions. This single act rapidly pushed medical practitioners into the era of Electronic Medical Records (EMR) and electronic Protected Health Information(ePHI).

Unfortunately, while the goals of HIPAA and subsequent EMR legislation may have been noble, implementations have been problematic.

Data Security

A 2017 article in Modern Healthcare noted that medical records are the new frontier for 7

hackers. A 2014 article by CNN is far blunter, stating that “90% of hospitals and clinics lose 8

their patients' data. No industry has been hit harder by hacking and data breaches than healthcare.”

Data security issues are overwhelmingly caused by “bad actors”, such as hackers (50%) or malicious employees (13%) . Current EMR systems are centralized silos, often running on 9

outdated and vulnerable systems . This makes attacks relatively easy, ensuring that EMR 10

systems will remain a popular target.

Interoperability

The challenges of lost or stolen records are further compounded by interoperability issues between different EMR systems.

In a 2017 interview with EHR Intelligence, Shaun Grannis MD, Director of the Indiana-based Regenstrief Institute’s Center for Biomedical Informatics stated, “Matching the correct individual to his or her health data is critical to their medical care. Statistics show that up to one in five patient records are not accurately matched even within the same healthcare system. As many as half of patient records are mismatched when data is transferred between healthcare systems.” . 11

7 “The frightening new frontier for hackers: Medical records”, Sweeney, Modern Healthcare, April 2017 8 “90% of hospitals and clinics lose their patients' data”, Paglieri, CNN, August 2014 9 “Sixth Annual Benchmark Study on Privacy & Security of Healthcare Data”, Ponemon Institute, May 2016 10 “One-Fifth of Healthcare Organizations Still Run XP“, Muncaster, Infosecurity Magazine, Nov 2017 11 “Top 5 Challenges to Achieving Healthcare Interoperability”, Monica, EMR Intelligence, August 2017


Many of these interoperability challenges are caused by the nature of the EMR tools market.

At the high end, there are systems from vendors such as Cerner (PowerChart), Epic (EpicCare Ambulatory), Allscripts (Allscripts Professional) and eClinicalWorks. These monolithic systems are complex, hard to implement and incredibly expensive. In 2015, Beckers Hospital Review examined the cost of multiple Epic EHR implementations . They found totals ranging from tens 12

of millions of dollars to $1.2 Billion for Boston-based Partners HealthCare. The report also noted that the Partners HealthCare implementation cost twice the original estimate.

Clearly, only the very largest healthcare providers can afford such systems.

Smaller healthcare practitioners, such as pediatric or primary care physicians, are forced to use either ad-hoc custom solutions, or smaller scale systems from companies such as Care360, NextGen and PracticeFusion. These systems do not directly integrate with the larger systems used by hospitals and bigger healthcare providers.

Unfortunately, the entire Electronic Medical Records industry has a very poor track record in addressing interoperability concerns. According to Nebraska Medicine Vice President of IT Brian Lancaster, “A lack of standardization and control over file sharing continues to make EHR interoperability a significant challenge for healthcare organizations” . 13

While this comment was made in 2017, the interoperability problem has been well documented and discussed for almost a decade . 14

The Cost Issues of data security and interoperability have a very real human and financial cost.

In light of the many challenges faced by Electronic Medical Records, it is perhaps less surprising that medical error has been estimated as the third leading cause of death in the USA

, surpassed only by heart disease and cancer. 15

The human cost of EMR challenges is compounded by significant financial cost. A 2016 study from the Ponemon Institute estimated that, “data breaches could be costing the healthcare industry $6.2 billion per year.” . 16

12 “8 Epic EHR implementations with the biggest price tags in 2015“, Beckers Hospital Review, July 2015 13 “Lack of EHR Interoperability Standards Challenges Health IT”, O’Dowd, Health IT Infrastructure, Sept 2017 14 “Lack of Standards Delay Electronic Medical Records”, Huslin, Washington Post, Feb 2009 15 “Medical error—the third leading cause of death in the US”, Makary & Daniel, BMJ, May 2016 16 “Sixth Annual Benchmark Study on Privacy & Security of Healthcare Data”, Ponemon Institute, May 2016


Healthcare costs in the United States continue to rise, accounting for 17.9 percent of the country's gross domestic product . And yet, for most patients, healthcare quality is arguably 17

stagnant or in decline.

The Problem: Key Takeaways Current EMR systems are centralized silos with limited communication capability and are often designed for other main purposes such as billing, accounting, etc. They lack both transparency and interoperability. The systems were also designed based on the premise that the patient data should reside within a single provider’s system.

With the changing nature of healthcare, a significant percentage of patients now receive care from multiple providers. Since the data cannot follow the patient, there is an inevitable increase in information delays and costs, repeated procedures, and a corresponding decrease in the overall quality of care.

The Joint Commission Center for Transforming Healthcare estimates that 80% of serious 18

medical errors involve miscommunication between caregivers during the transfer of patients”. 19

From the patient's perspective, current systems also limit the access and control they have over their own medical information, including how it is used and where it is stored.

The current system is a mess. Healthcare continues to lag far behind other industries when it comes to implementing security and interoperability. It is literally costing lives, and it is time for things to change.

17 “National Health Expenditure Data, Historical”, Centers for Medicare & Medicaid Services 18 “Joint Commission Center for Transforming Healthcare Releases Targeted Solutions Tool for Hand-Off Communications”, June 2012 19 “Joint Commission Center for Transforming Healthcare Releases Targeted Solutions Tool for Hand-Off Communications”, June 2012


The Solution The two primary challenges of data security and interoperability are solved by MedChain by decentralizing Electronic Medical Records and putting control in the hands of the patient.

MedChain's combination of cutting-edge blockchain protocol technology, military-level encryption, distributed storage, coupled with open-source framework will set a new standard in HIPAA/GDPR/globally-compliant medical record-keeping.

Healthcare providers that implement MedChain infrastructure will have access to vastly more secure storage and a far more effective data transfer mechanism.

Finally, by putting control of EMR in the hands of the patient, MedChain ensures that critical medical records are no longer trapped in isolated, inaccessible silos. Patients can quickly grant access to any authorized healthcare provider, ensuring that the right information is in the right hands at the right time.

Ensuring Security The MedChain blockchain eliminates centralized silos, making it far harder for bad actors to attack the system.

The MedChain system is built on a blockchain. Blockchain is an ideal method for secure medical record keeping. A patient’s information is encrypted, then split into many pieces before being distributed across the entire network of storage servers. The information is only retrievable when requested from authorized individuals holding the correct private key and data-hash. MedChain’s blockchain also employs sophisticated identity verification methods and state of the art cryptography to secure user identities. Security options include 2-step verification and biometrics, such as fingerprint and facial recognition on smartphones.

MedChain will use layered data structures to upload hashed records of encrypted electronic Private Health Information (ePHI) and store the file locations on its blockchain. The information will be divided into multiple pieces which will be recombined when accessing the information via the patient’s private key.

The provider’s key can also be used to authenticate an information request from a doctor, hospital, or health insurance provider. Utilizing smart contracts, this authentication process will function in a way that adheres to the current HIPAA guidelines, with the ability to modify future smart contracts to comply with new rules and regulations that may appear.


With the MedChain solution, large-scale data breaches will be impossible. A single patient could inadvertently compromise their own information by unlocking it without verifying the source, but the breach would always be limited in scope.

Guaranteeing Interoperability There are two aspects to interoperability: the standards framework that allows one system to share data with another, and the practical ability to do so.

Standards Framework

MedChain will be fully compliant with the FHIR and CDA standards, as defined by Health Level Seven International (HL7).

HL7 is a not-for-profit, ANSI-accredited standards developing organization dedicated to the creation of a comprehensive framework for interoperability in Electronic Medical Records and electronic Protected Health Information . 20

The Fast Healthcare Interoperability Resource (FHIR) defines a standard for exchanging healthcare information electronically. It aims to simplify integration to provide a consistent and rigorous mechanism for exchanging data between applications.

The Clinical Document Architecture (CDA) standard defines a structure for any clinical content 21

with the purpose of enabling data exchange between healthcare providers and patients.

Practical Ability

HL7 was founded more than 30 years ago and many EMR systems are fully FHIR compliant. So why is interoperability still a poorly solved problem? The answer is simple: neither FHIR nor CDA solve the underlying issue: who controls the data.

In current systems, the healthcare provider controls the medical record. With the changing nature of healthcare, a significant percentage of patients now receive care from multiple providers. That inevitably leads to fragmented records, with pieces of a patient’s critical medical history locked up in disconnected silos.

MedChain will put the patient at the center of their own medical records, not the healthcare provider.

The patient is already the common link between all of these disparate records and providers. MedChain simply formalizes this relationship while adhering to the regulatory framework.

20 See http://www.hl7.org/implement/standards/index.cfm 21 See http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7


With MedChain, any provider can add information to a patient’s records, but the records are irrevocably attached to the patient. The end result is that all of a patient’s medical records travel with them, and the patient can control who has access to those records.

MedChain decentralizes the physical storage of patient data, but not the control (from a regulatory and patient perspective), all the while keeping within the regulatory framework.

Ensuring Patient Control The MedChain protocol will be used to prove and designate ownership and access to ePHI.

When a patient’s data is uploaded to the MedChain Blockchain, a unique hash is created. This unique hash, combined with the patient’s private key, controls access to the underlying data. If a provider needs access to the patient’s file (and they don’t yet have authorization), then the patient can choose to share a decrypt key with that provider.

The patient will verify that the request to see their EMR is valid by using the provider’s key to authenticate an information request from a doctor, hospital, or health insurance provider: this two-key system ensures that the patient is in control of their data.

Utilizing smart contracts, the authentication process will function in a way that adheres to the current HIPAA & GDPR guidelines, with the ability to modify future smart contracts to comply with new rules and regulations as they appear.

How it Works The MedChain Network will be launched in multiple phases. The first phase will establish the “common data layer” that all existing and future software providers can plug into, and that all future phases will build upon. That common data layer is called the Secure Medical Record Chain (SMRC). Subsequent phases will release complementary blockchain networks that build features and capabilities on top of the SMRC. Two distributed applications (dApps) will also be distributed during Phase I. Those are the Patient dApp and the Service Provider dApp.

The Patient dApp will be available free to patients around the nation and globe. With this dApp, the Patients can view their medical files, see who has used them, and give their specific service providers access to some or all of those files. In future phases, the patients will be able to schedule doctors visits, manage insurance bills, and see alternative options to improve their well-being.

The Service Provider dApp will be a user interface for service providers to add files to a patient’s EMR, as well as an application programming interface (API) for existing software providers to interface directly with the SMRC to help their customers store EMR data. This dApp will give the provider access to all medical results ever produced for a patient (no matter who ordered the


procedure) and track the orders they have specifically prescribed. In Phase II, the Service Provider dApp will also have access to a wealth of data that can be deduced from other similar patients across the nation/world using data analytics, machine learning, AI, and diagnosis automation.

Once any of the dApps receives a new file to add to a patient’s record, the nodes on the blockchain will securely handle all the encryption, data transfer, utility tokens, storage, storage invoices, pricing, compliance, re-assembly and delivery. As regulations change and get updated, the MedChain blockchain will also evolve to ensure data is always stored and transferred in a correct and legally compliant manner.

Each subsequent phase of the MedChain deployment will add features and capabilities. In Phase II, a Secure Medical Discovery Chain (SMDC) will accept only anonymous EMR and run analyses against millions of records. This is currently not possible because patient data is locked up in multiple proprietary systems. The MedChain common data layer realizes the true potential of machine learning and telemedicine that is stymied by today’s limited data sets.

System Components Tokens

The MedChain solution works by using several data layers on top of MedChain's blockchain protocol. The system uses two distinct tokens types.

The external token, MedCoin, will function as a tradable ‘Security Token’.

The internal token, Record Tokens, have the function of adding hashes to the blockchain, which serve as a map of the distributed patient record. Each record could include plain text, database objects, scanned documents, pictures, etc. pertaining to a particular patient.

To disincentivize potential hackers and thieves, the Record Tokens will be tied to a unique identifier and not tradable to any other person or account. This should also help ensure that information is added to the correct account and avoids the risk of erroneous transactions. Adding additional information to an existing account is possible by considering the account a repository of hashes tied to a unique identifier/patient.

For the purpose of adoptability, the internal token and the function thereof will be available for purchase, through MedChain directly or through an automated process within the provider software. The internal token will be tied to a real fiat value, currently projected at $0.001US, to eliminate the need to worry about conversion rates or the volatility of a tradable cryptocurrency or token. This leaves the external token to gain or lose value on its own merit while it will be tradable for the internal Record Tokens at the current conversion rate to USD. The Storage Market will be coded to maintain a realistic market-value of storage costs so that service providers are not priced out of storing data on MedChain instead of locally. Reading any stored


data is priced at only one Record Token cost (i.e. $0.001US) so that there is no reason to worry about costs when requesting EMRs to save patients’ lives.

Patient dApps

Decentralized applications can be built on top of the MedChain platform by third parties, to facilitate a world-wide interoperability solution for the healthcare space. As we are developing our framework, we will be deploying the initial applications ourselves.

The MedChain Patient dApp is being developed for iOS and Android smartphones, tablet and desktop use as a web application. This dApp always provides the most up-to-date information, such as medical test results, as well as the documentation all patients are entitled to under HIPAA and EMR guidelines. The MedChain applications will also notify users of access requests from service providers, doctors, hospitals, and health insurance providers. Realizing that patients are not always privy to full documentation from all sources (e.g. full psychiatrists records), the access control will allow for segmentation of view privileges, while still affording subsequent determination for distribution by the patient to approved providers.

The MedChain Patient dApp will function as a wallet of information tied to the patient’s unique public identifier and is accessible only with the patient's unique private key. When information is requested from any of the user's platforms, their private key will be used to decrypt the hash of the information location, allowing care providers to access and retrieve the information.

Utilizing an intuitive, user-friendly interface, the MedChain Patient dApp allows the patient to designate access to private health information, including information tied to their account that might be available only to specialists, such as psychological records and evaluations that even the patient cannot see or utilize. Through further development, additional functions will enable the patient to upload their own data.

As a key feature of our approach to healthcare, the MedChain Patient dApp will be available as a no-cost downloadable application through app stores and available as a Web App on the MedChain website to encourage provider adoption of our Service Provider dApp and blockchain technology.

Service Provider dApps

Following the deployment and integration of patient applications, we envision collaboration between MedChain and providers to tailor-make custom applications fit for each institution’s needs. The initial rollout of The MedChain Service Provider dApp will function as an automated intermediary of interoperability between the provider's current HIPAA & GDPR-compliant software database and the MedChain blockchain and distributed storage network. While functions already exist to encrypt data prior to distribution, MedChain is developing additional ways to ensure encryption before fragmentation and subsequent transmission.


Following encryption of electronic Protected Health Information, the MedChain software will hash the information and create defined chains of entries to the blockchain as a functional way of verifying data integrity and eliminating the chance for foul-play or unauthorized data manipulation. MedChain’s Software will function as nodes authorized and federated by MedChain, requiring zero on-site upkeep.

The MedChain Service Provider dApp will be marketed at a low-to-no-upfront cost to providers based on a SaaS model that requires a subscription to use the software and access the blockchain. This subscription may be integrated with internal token usage or kept separate.

The consumption of tokens to add information to the MedChain blockchain is a key part of our business model.

To upload information to the network, a purchase of either external and transferable MedCoins or internal non-transferable Record Tokens must be made. Record Tokens function as credits within the ecosystem, keeping their price tied to a fiat currency and allowing providers to access the blockchain without concern over volatile cryptocurrency for data uploads. Keeping the Record Token price tied to a fiat currency, such as the US Dollar, will prevent undesirable market manipulation which could cause unsustainability.

Nodes/Hardware

Nodes are essential to the function of a blockchain as they hold and verify the blockchain ledger, and can ensure tamper-proof ePHI records and patient information. Multiple nodes form the stronghold of the network’s Federated Servers which ensure the blockchain is kept decentralized and functioning as the immutable record keepers. These Federated Servers will likely be existing healthcare storage services within and outside of existing service provider facilities. The Federated servers will serve several essential functions in the MedChain ecosystem. These nodes perform the storage and retrieval of data as necessitated for our business model and is explained further in the Technical Details section.

Blockchain as a Service

MedChain will provide a rapid, low-cost, low-risk platform for healthcare organizations to share ePHI between each-other. In other words, the MedChain Network is a service that allows any existing and future EMR systems to access the security of the blockchain infrastructure: blockchain-as-a-service (BaaS) or platform-as-a-service (aka PaaS). MedChain enters the world of BaaS alongside IBM, Azure and AWS to offer a specialized BaaS platform that will tie together all medical related systems.

MedChain is positioned to become the standard blockchain, or “common data layer”, that will connect everyone’s medical records together for true interoperability between systems. With this vision in mind, the MedChain Network will allow developers to build applications in a global healthcare compliant workspace to facilitate innovation in the healthcare space while ensuring


data security. Existing software such as Allscripts, eClinicalWorks, NextGen (to name only a few of the hundreds offered) and the various packages from Epic and Cerner can access MedChain EMR/EHR through established HL7/FHIR standards and the open-sourced, local API calls that allows direct access to the blockchain and the records referenced there.

Other applications built on the MedChain platform will function with the use of Record Tokens as a fuel payment within the protocol. Record Tokens will be purchased through MedChain at a flat-rate based upon the fiat US dollar. This rate will be based upon the per gigabyte/per month storage costs of EMR data. The price of each Record Token will be determined by a Storage Market that is built into the smart contracts that each node executes.

BaaS allows researchers access to anonymized data, facilitates cross-EMR system integration, and is one of the first steps needed to encourage adoption of the MedChain Network. BaaS, and the associated use of Record Tokens, is one of the long-term funding mechanisms MedChain will implement to ensure company growth. Future growth phases of MedChain will add on new internal tokens that will fund new blockchains and new features/functionality.

Software as a Service

With software-as-a-service (SaaS), MedChain will be able to provide continuous and automatic updates and full-time support for our software. SaaS is provided on a “pay as you go” and “pay for what you need” basis. The MedChain solution accommodates providers from the smallest private practice, to the laboratories supplying test results or durable equipment, to the largest hospital systems in the nation by providing a SaaS model that fits each. SaaS is another of the long-term funding mechanisms MedChain will implement to ensure company growth. Future growth phases of MedChain will expand on the SaaS models that will fund new software and services and new features/functionality.

Our Solution: Key Takeaways The Benefits for Providers

MedChain's blockchain-based solution gives healthcare providers near-instant access to the medical records of new and existing patients.

MedChain ensures that patient information is far more secure, with dramatically reduced risk of identifiable data being leaked.

MedChain also greatly reduces lost and compromised data, reducing medical error and saving the healthcare system several billion dollars each year in costs associated with data breaches.


The Benefits for Patients

With MedChain, patients will finally be in control of their data. Critical health records will no longer be locked in disconnected silos. Patients can finally be sure that all of their medical records have reached the provider they are interacting with.

Utilizing MedChain's smartphone and web applications, patients will be also be able to eliminate and/or avoid redundant testing due to lack of record-sharing between providers.

Health records can also be near-instantaneously available in cases of emergency, including when the individual is non-responsive, by issuing an Emergency Override within the system.

The Benefits for the MedChain community

MedChain has outlined multiple streams of revenue through our BaaS/PaaS and SaaS payment models. A strong corporate growth can be achieved by creating the “common data layer” (aka blockchain-as-a-service) for all medical software companies to build upon, assisting other companies to integrate into our platform (aka platform-as-a-service), and using the established software-as-a-service philosophy to maintain and improve upon our offerings.

Growth in the BaaS/PaaS and SaaS revenue streams comes from an increased market share of patients, providers, and 3rd party software using the interoperability solution that MedChain makes available. No other company, blockchain-based or otherwise, is offering the breadth of products and services that can penetrate this classic market. By building a system that all other companies can build upon, MedChain is positioned to be the cornerstone of electronic medical record storage and retrieval that each sector of medicine needs in order to service their patients.


Technical Details

The MedChain Network Overview The MedChain Network (MCN) is an extensible, layered architecture and protocol system governed and secured by multiple blockchains that utilizes a multi-crypto-token framework. MCN is a “common data layer”, or blockchain-as-a-service (BaaS), that existing and future software companies can build upon. Figure 1 illustrates the components of the MCN. Software applications such as Patient dApps, Service Provider dApps, and Mining dApps form the “application layer”. The Secure Medical Record Chain (SMRC) and the Secure Medical Discovery Chain (SMDC) form the “secure data layer” that is accessed through Record Tokens. The Public Verification Chain (PVC) forms the “public data layer”. The automated data flow between all the layers is the MedChain Protocol that ensures security, privacy, and HIPAA/GDPR/global-compliance at all stages of the data transfer and lifetime. Lastly, MedCoin is the SEC-filed security that tracks the financial health and well-being of the entire system.

Figure 1: The architectural components of the MedChain Network. Note: dApp1 and dApp2 are placeholders for existing and future dApps that can be modified or built to use MedChain. The MedChain Network is a “common data

layer” for multiple companies/softwares to use.

The MedChain Protocol The typical process of writing new data to a patient’s medical records and reading that patient’s medical records are described in Table 1.


1. The patient authorizes the service provider(s) to read and/or add new data through the Patient dApp

2. A service provider or patient has been entitled to Record Tokens (purchased with USD through SaaS subscription)

3. Service Provider dApp identifies new data/files to include in a patient’s EMR 4. Provider Nodes encrypt the files and fragment the files (i.e. data shards). 5. Each fragment is (optionally) stored locally and replicated locally 6. Each fragment is replicated and distributed across the Secure Medical Record Chain

(SMRC) 7. Storage Nodes store the location of each fragment in an Entry Block on the SMRC 8. An amount of Record Tokens are burned proportional to the number of megabytes

stored and the price per megabytes for each write to the SMRC 9. When reading data, a new Entry Block is stored on the SMRC recording the read 10. A single Record Token is burned for each read of the SMRC 11. Provider Nodes store all the fragment locations for each file in a Directory Block on the

SMRC 12. Chain Nodes will validate each new block to ensure Proof-of-SpaceTime and

Proof-of-Accessibility 13. The MedChain Protocol secures a hash of all the valid Access Blocks (reads and

writes) in a Verification Block on the Public Verification Chain (PVC) 14. A PVC token (of the appropriate type) is spent for each read and write to the PVC 15. MedChain Oracles are the only nodes that can change the MedChain/HIPAA/GDPR

rules that the protocol follows 16. <Phase II> If the patient opts-in, new EMRs are anonymized, parsed and stored on

the Secure Medical Discovery Chain (SMDC) 17. An Entry Block is created on the SMRC for each write to the SMDC 18. A single Discovery Token is burned for each write to the SMDC 19. When reading data from the SMDC, a new Entry Block is stored on the SMDC

recording the read 20. An amount of Discovery Tokens are burned proportional to the number of megabytes

read and the price per megabytes for each read from the SMDC

Table 1: The data flow of all reads and writes to the MCN.

Files and Database EMRs

The discussion up to this point has focused on storing and retrieving “files” of data. It is duly noted that some EMRs are stored in databases and must be stored and retrieved with database queries, as opposed to using file addresses. The MedChain Protocol takes care of this by turning those query results into plain text files that can then be stored across the network, and using locally developed “bridge code” to reverse the process to create INSERT statements for


the provider’s database. The format of the query results will adhere to healthcare standards of interoperability such as HL7/FHIR (see Standards Framework). Using this approach, makes the system agnostic to the architecture of each particular storage provider’s EMR system. The details of how “bridge code” will be constructed is saved for another document to be released by MedChain. The rest of this document will continue to label EMR data as “files” for simplicity.

Patient dApp MedChain will offer a first-of-its-kind software application for patients to access their own medical records: the MedChain Patient dApp. This distributed application (a.k.a. dApp) is described below. However, even more importantly, the MedChain Network has been designed to allow any future patient dApps to also access the Network. In this way, MedChain becomes the “common data layer”, or blockchain-as-a-service, that will allow patients to choose the software that is right for them to access their medical records. While the MedChain Patient dApp will be first-to-market and hold an initial marketplace gold-standard in functionality, MedChain encourages other application providers to push that innovation to new heights and improve upon the services offered to the patient. The goal of MedChain is to offer the “common data layer” such that a maximum level of interoperability and user experience is realized.

Overview

The Patient dApp is a combination private-key wallet, user interface (UI) and API for patient access to the SMRC. The Patient dApp will function as the private key holder, similar in fashion to the way a cryptocurrency wallet functions. Only the user that can unlock the wallet can access the medical records associated with that wallet. The UI will allow the patient to grant permissions to their providers and revoke permissions, as necessary. The UI will allow the patient to see a complete history of all reads/writes to their medical record, and provide proof to the patient that the data integrity is maintained. The API provides access to the SMRC to record the permission changes and provide the blockchain history on the specific patient. Future software that wants to build upon the MCN can simply use the API in conjunction with their own user interface.

Key Features

● Granting and revoking permissions ○ Patients can grant/revoke permission to read and/or write to their medical

records. The patient can initiate this approval when making a new appointment, or the service provider could issue a Request for Access (RFA) that the patient can approve or deny.

● History of medical record ○ Patients can view an entire history of all the reads and writes to their own medical

records.


● Proof that data integrity is maintained ○ Patients will see a continual visual indication that their medical records are safe

and secure. The patient can opt-in to reviewing each and every access so all activity is known and appropriate.

● Wallet functionality that holds the “Patient Keys” ○ The Patient dApp is a crypto-wallet that holds the patient’s private keys so only

they have access to their own medical records (and whomever the patient gives access to).

● List of prescriptions ○ Patients can see, at a glance, the list of their medications, any new prescriptions,

when their refills expire, etc. Patients can subsequently allow other providers the ability to view this list also (i.e. pharmacists, PCPs, etc).

● Emergency Access ○ Patients can delegate one or more Emergency Access Keys to their trusted

relatives, friends or PCP in the case of emergency. If an Emergency Access is requested (i.e. by an emergency room), a notification will be issued to alert you that your immediate attention is required.

● Roadmap for future improvements: ○ In Case of Emergency (ICE) contacts ○ “Click to schedule” to make your next appointment on your mobile/web device

New Patient Procedures

There will be several different options for a new patient to start using MedChain depending on what works best for them and their service provider. In most cases, the patient will want to set up their MedChain Key prior to any initial visits. The MedChain Key could possibly be the most valuable “password” they’ll ever choose in their life because it will exist their entire life and must remain secure. If the patient does not have the resources to create their own MedChain Key (i.e. they don’t have access to a computer), the service provider can offer the patient a secure terminal to create one. In the event that a patient has, indeed, already set up a Key but has forgotten to give a particular doctor access, a temporary key can be assigned for that specific visit and associated to the original Key by the patient at a later date. Some other possible procedures/scenarios are outlined in Table 2. MedChain is researching the feasibility of each because different patients will have different needs.

● Patient can be instructed to set up ID before first visit (or bring password) ● Patient can be instructed to grant provider permission before visit ● Patient can only make appointment after permission given ● Patient automatically gives permission when making appointment via Patient dApp ● Patient gets assigned ID from PCP on first visit if don’t have one or forgot ● Patient can merge records later if needed ● Patient gets handwritten password and wraps around photo ID


● Patient grants permission to new PCP when signing up for new insurance ● Patient grants permission to PCP that allows PCP to grant/revoke permissions as

necessary ● Patient Keys are “laptop keys” (i.e. keys, that if lost, can be revoked and new ones

created = lost password feature) ● “Master keys” are stored either with MedChain, with PCP, or on physical media (in a

safe-deposit box) with patient ● Patient can opt to get “laptop keys” or “master keys”

Table 2: Possible scenarios to establish new patient MedChain Key.

Service Provider dApp Similar to the Patient dApp, MedChain will offer its own software for the service provider to access their patients’ medical records: the MedChain Service Provider dApp (SPdA). This distributed application (a.k.a. dApp) is described below. However, even more importantly, the MedChain Network has been designed to allow any existing and future EMR systems to also access the Network. In this way, MedChain becomes the “common data layer”, or blockchain-as-a-service, that will connect everyone’s medical records together for true interoperability between systems.

This means that existing software such as Allscripts, eClinicalWorks, NextGen (to name only a few of the hundreds offered) and the various packages from Epic and Cerner can access MedChain EMR/EHR through established HL7/FHIR standards and the open-sourced, local SPdA API that allows direct access to the blockchain and the records referenced there.

Overview

The SPdA is a combination private-key wallet, user interface (UI) and API for provider access to the SMRC. The SPdA will function as the private key holder, similar in fashion to the way a cryptocurrency wallet functions. Only the user that can unlock the wallet can access the medical records permissioned for that wallet. The UI will allow the service provider to request and receive permissions from their patients to view the needed medical records. The UI will allow the service provider to see a complete history of all reads/writes to their patients’ medical records, and to pull the needed information. The API is a feature-rich set of methods that existing software packages can use to access MedChain records as if they were built into the origin EMR software. Existing EMR software can implement the API such that the data pulled from the MedChain Network looks as if it came directly from that EMR software provider’s data store.


Key Features

● SPdA API is the middleware between the provider’s existing EMR software and the SMRC

● The SPdA UI is the graphical interface to implementing all the available API calls ● Service Provider can send a Request for Access (RFA) ● Service Provider can see all patient data in one place (and the provider that requested it) ● Service Provider can see proof that data integrity has been maintained ● Service Provider can get Emergency Access (in order to save lives even when patient is

unconscious) ● Roadmap for future improvements:

○ In Case of Emergency (ICE) contacts ○ Allow patients to make their own appointment times on their mobile/web device

Federated Servers The collection of Federated Servers that make up the Secure Medical Records Chain (SMRC) and the Secure Medical Discovery Chain (SMDC) are all HIPAA-compliant computers and form “permissioned networks” of trusted member systems. These computers are likely to be existing EMR storage and processing devices that are currently in use at hospitals, laboratories, and EMR Warehouses around the nation and around the world. Since these data-stores and processing units are already adhering to strict security standards, and already storing the data that will be required, they are a natural fit to become a part of the network. It is understood, however, that some companies may opt out of dedicating their proprietary storage space and processing power to a nationwide, shared network. This is a valid, initial choice and the MedChain Network has been engineered to still be able to exist and grow even without major players.

In order to grow and secure the space and processing needed for the peta/exabytes of patient information around the nation, the MedChain Network will incentivize these Federated Servers for network storage. This means that hospitals, laboratories and EMR Warehouses will get compensated for their storage and processing commitments and see a return on investment (ROI) by joining the network. Incentivization for proper EMR storage and processing will actually bring new providers into the network and grow existing providers’ capacity.

As part of the SMRC and SMDC, the Federated Server becomes part of the blockchain network and will store and maintain the blockchain. Each Federated Server can elect to store medical records, in addition to retrieving them. If the Federated Server elects to be a Storage Node in either blockchain, it will store and serve data to the Service Providers. Each Federated Server can perform one or multiple roles such as Provider Node, Storage Node, or Chain Node. The sections below detail the various executables running for each role on the Federated Servers within the SMRC and SMDC.


Secure Medical Record Chain (SMRC) The SMRC is a blockchain architecture based on the Hyperledger Fabric permissioned network of Federated Servers. The Federated Servers can perform one or more different roles within the SMRC: 1) Provider Nodes, 2) Storage Nodes, 3) Chain Nodes, and 4) Oracles. Each of these roles are explained in detail below.

Provider Nodes

Computers within the MedChain Network that communicate directly with the SPdA are called Provider Nodes. These Provider Nodes are typically co-located with the Service Provider, but they do not have to be. These Federated Servers perform actions on the EMR files/data prior to distributing to the SMRC and are responsible for adding data to the SMRC. When the SPdA collects new files to add to an EMR, the SPdA sends those files to the Provider Node. If the Provider Node is co-located at the Provider’s office, the Provider Node can be initialized with a special flag to have that new file stored in Provider Storage. Provider Storage is simply a local hard drive that will store all the Service Provider’s patient records. This local hard drive is essentially the status quo of how EMR is currently stored today (i.e. file-based or within a database), and forms a fail-safe storage area so that Providers can get to their patients’ records even if there is a power/data outage and the rest of the Network cannot be reached. If the Provider Storage Flag is not set, the “original” file can be stored prior to reaching the Provider Node (i.e. if the Service Provider already has existing software that does this), or the “original” data can be stored directly on the SMRC as described below. In either case, the Provider Node will then take care of saving replicated (i.e. backup) copies of the “original” file on the SMRC.

The Provider Node is configured according to the Service Provider’s settings. For every file that is received, at least one additional copy of the file will be replicated across the SMRC. The MedChain Oracles will determine if more replicas are needed as security and retrieval speeds mature. The Provider Node encrypts the file and fragments the file creating data shards that will be stored with the Storage Nodes. The Provider Node will submit an “order” through a MedChain Smart Contract function to find Storage Nodes to store each fragment. As fragments are added to the SMRC by each of the Storage Nodes, the Provider Node will record each fragment’s location and create the Directory Block of the total file record.

When the SPdA requests to retrieve new data, the Provider Node will fetch the file from the SMRC. If the Provider Storage Flag is on, then the data will be pulled directly from Provider Storage (if not already pulled). However, even when pulled from local storage, the Provider Node will still “verify” that the local data has not been tampered with. The Provider Node will do this by requesting a hash of remotely stored data (i.e. just the hash and not the entire file). This hash can then be compared to the hash of the locally stored file. If they do not match, then alerts will be thrown and an investigation started. If the Provider Storage Flag is off, or the file


appears corrupted or is missing, then the Provider Node will go out and fetch one of the backup copies of the file.

Table 3 outlines the process by which a Provider Node handles data.

1. The SPdA requests that the Provider Node store a file on the SMRC 2. The Provider Node encrypts the file and fragments the file (i.e. data shards) 3. The Provider Node submits an “order” through a MedChain Smart Contract function to

store the data for each replica of each fragment 4. The Provider Node makes an Directory Block containing all the addresses of all the

fragments for each of the replicas stored 5. The SPdA requests that the Provider Node fetch a file from SMRC 6. The Provider Node will lookup the Directory Block on the SMRC 7. The Provider Node will request each of the data fragments (i.e. data shards) from

each of the Storage Nodes 8. The first Storage Node to respond with the information requested will get rewarded 9. The Provider Node will re-assemble the encrypted file from the fragments retrieved

from various Storage Nodes 10. The Provider Node will use the Patient’s decryption key to unlock the file

Table 3: Provider Node data flow

Storage Nodes

Computers within the MedChain Network that store EMR data form the distributed storage network of the SMRC. In this role, the computers dedicate a given amount of storage for a given amount of time. This dedicated space allows the computer to accept an invitation to store EMR and to get compensated for that storage.

Interplanetary Filesystem The SMRC is a consortium network that follows the existing InterPlanetary File System (IPFS) protocol. The SMRC has a strict, whitelist-only set of routing addresses of computers that can be used for EMR. This means that only trusted, HIPAA/GDPR/globally-compliant computers (i.e. Federated Servers) can be used to store EMR. Please see the technical description of IPFS at https://ipfs.io/ for more details on the IPFS protocol. The MedChain SMRC will use SCTP/IPv6 connections that are routed between addresses of a limited (and closely monitored) hash table stored on the blockchain. The Object Merkle DAG will additionally hold a custom data structure to be stored with each fragment of a file to identify which fragment it is, out of how many fragments, as well as other security related pieces of information.


https://ipfs.io/

Proof of SpaceTime Once the data is stored, the Storage Node will periodically be asked to provide a Proof-of-SpaceTime (PoSt) to verify that the data has been stored. An initial PoSt will be submitted when the data is first saved, and randomly scheduled checks on that data will yield follow-up PoSt. The MedChain Storage Verification Smart Contract will randomly schedule the PoSt requests throughout the life of the contract. PoSt allows the MedChain network to verify the integrity of the EMRs, over time, after that storage space has been allocated. For each PoSt provided, the Storage Node is compensated proportional to the total number of PoSt requests anticipated.

Adding the PoSt to the blockchain results in the Storage Node being paid with the MedChain token. The PoSt, and the token system used to pay the Nodes, are the novel protocol enhancements that FileCoin has added to the IPFS protocol. More details about the specifics can be found at https://filecoin.io. These proofs are used to verify that the Storage Node has stored the data they were paid to store.

Proof of Accessibility For every piece of data stored on the SMRC, backup copies are also stored. At least one backup copy is generated, with an option to store more depending on the Service Providers’ level of additional security desired. MedChain uses a new consensus algorithm to ensure that data is accessible even if a Storage Node is unexpectedly taken out of service. The MedChain Storage Validation Smart Contract generates a Proof-of-Accessibility (PoA) to verify that the data has been stored, replicated, and that <50% of the data fragments that make up a complete file cannot live on the same machine, and that data can be accessed from every part of the service area. PoA is a method for allowing a Federated Server Chain Node to verify data has been dedicated physical storage on separate devices. Note: the 50% limit is adjustable as 22

HIPAA regulations and industry best practices change.

Table 4 outlines the process by which a Storage Node handles data.

1. The Provider Node encrypts the file and fragments the file (i.e. data shards) 2. The Provider Node submits an “order” through a MedChain Smart Contract function to

store the data 3. The Storage Nodes “compete” for the chance to store the data through a Storage

Market 4. The Storage Market contains all the independent storage costs for each Provider 5. The lowest cost (or other provider-chosen algorithm) Storage Node that adheres to the

storage requirements of each particular data fragment, and that stakes the required collateral, will be chosen

22 “Proof of Replication Technical Report (WIP)”, Protocol Labs, July 27, 2017


https://filecoin.io/

6. The winning Node enters a contract to store the data, allocates the storage, transfers the data from the original source, then generates a Proof-of-SpaceTime that is added to the SMRC

7. The Storage Verification Smart Contract periodically issue a request for a Proof-of-SpaceTime operation on each data fragment and their replicas

8. The Storage Verification Smart Contract ensures that sufficient copies of the data are stored through a Proof-of-Accessibility

9. The Storage Node will perform the periodic PoSt to ensure the data is present 10. In the event of invalid input, the server may be demoted and no-longer eligible for

storage rewards for a period of time

Table 4: Storage Node data flow

Storage Market The Storage Nodes “compete” for the chance to store EMR data through a Storage Market. Through this Market, the Storage Nodes will be compensated for the space used for the files stored. When a new Storage Node comes on-line, the Node will post its current storage rate for all Provider Nodes to see. When the Provider Node submits an order to save data, the lowest cost Storage Node (or other provider-chosen algorithm) that adheres to the storage requirements of each particular data fragment, and that verifies they can do the job, will be chosen. The total amount of compensation depends on the size of the file and how long the file is stored. The compensation package consists of partial payments for each month the data is stored, plus an allocated portion for each read of that data, plus a final payment at the end of the contract for successful storage of that data.

When the Storage Node posts that specific node’s storage rates in the Storage Market, it is based upon a “per megabyte per month” rate. This means that for each megabyte stored, the Storage Node will expect the posted storage rate per month. This storage rate is unique to each Storage Node and based on what that storage provider believes it needs to operate. If the Storage Node believes its storage is more reliable and more readily accessible, then it can charge higher rates. However, if the storage rates are too high, then other lower cost storage will be used first. If all the lowest cost storage has been filled, then either new Storage Nodes will come on-line, or the higher cost storage will be used. The Storage Market should, therefore, be its own fair, equitable, and self-regulating view of the actual cost of EMR storage.

In order for a Storage Node to prove that it can “do the job”, the Storage Node will “stake” a required collateral payment. This collateral, in Record Tokens, will be held in escrow by the Storage Market Smart Contract until the file storage contract is completed. Thus, if the Storage Node goes off-line or fails to properly store the contracted data, a portion of that stake will be forfeit. In such a case, the Storage Node will not only not get paid for the remaining contract, they will actually pay the Market to re-allocate that data to a more reliable server. If a Storage Node continues to not fulfill its contracts, an increasing penalty fee will drive the Storage Node


out of business. If, however, the failure was an unforeseen hardware failure, the one-time nature would not continue to trip the penalty fee monitor and the penalty fees would return to zero in a short period of time.

For a Storage Node to win an order for new data, the Node must also satisfy certain requirements for that data. The storage requirements of each particular data fragment ensures that less than 50% of the data fragments that make up a complete file cannot live on the same machine and that data can be accessed from every part of the service area. This is criteria that the Proof-of-Accessibility will looking to verify in subsequent reviews. Therefore, prior to bidding, the Storage Node will lookup all the fragments of the same file it is currently bidding on and make sure it is not over its limit and that it is in the service area requested.

An example linear payment schedule is shown in Table 5 below. Note: The actual formula that defines the payout amounts will likely be non-linear and favor higher rewards for longer storage contract lengths and increasing payouts throughout the life of the storage contract. This will encourage Storage Nodes to complete their contracts and avoid early termination of the contract.

1. Per month: 50% * (1/(contract_length_mo)) for each month (with a current PoSt) 2. Xth read: 50% * (1/1000 reads total) for each read (up a maximum of 50%) 3. Last payment: last monthly installment + unused “read” credits

Table 5: An example Storage Node payment schedule

The Storage Market allows Service Providers to not only get the lowest costs for properly storing their data, it allows them to only pay for the storage they need and to gauge their costs over time. The Providers can optimize their costs by paying for a longer contract length at current Record Token prices, or they can request short contract lengths when needed to manage costs. For instance, if storage prices of an equal supply/demand system are observed to be rising at a fairly predictable rate, then a Provider may wish to create a contract term for the full period required by law for that data (currently, in the US, HIPAA states EMRs should be kept for 6 years after last access date). In this scenario, the Provider can pay for all 6 years at current Record Token prices and forgo paying the inflation rates. However, if the practice is new, perhaps their financials only allow them to commit 6 months to a year at this time. The Storage Market and Storage Smart Contracts, however, do take into consideration that once an EMR file is created, it must be kept for the requirement amount of time for that jurisdiction. So even if a Provider chooses to only issue an order for one year, the Provider will be responsible for paying the full six years (for example in the US). It is because of this requirement, that in some jurisdictions, the Provider is required to “escrow” the entire cost for the full duration of the EMR saved and shorter contract lengths would only apply after that mandatory period.


The most direct benefit to the service provider and the storage provider is that all of these market factors and behaviors will be taken care of automatically through smart contracts and all the provider’s auditing documentation is automatically done for them.

Duration of Storage When a provider generates new data for a patient’s EMR, some jurisdictions mandate that the data be kept for a certain number of years. Currently in the U.S., HIPAA states EMRs should be kept for 6 years after last access date. This duration can also be modified by individual states in the U.S. For other nations and regions, this number can change. So depending on where MedChain will be implemented and used, the appropriate mandatory storage duration must be identified.

In order to ensure that new data will be kept for the entire duration, the provider who generates the data must “prepay” an amount of Record Tokens equal to the cost of the total mandatory storage duration. Due to the sub-one-cent pricing anticipated for the storage market, this prepayment will not be an exorbitant amount (see Record Token Pricing section) for each new record. The prepayment can simply be rolled into the cost of the procedure that generated the data. Since the service provider is required to keep these files anyways, it is not an unreasonable requirement keeping in mind that the prepayment is just an escrow account in case the provider should cease operations. If the provider stays in business, and the patient continues coming to the same provider, then the typical monthly fees are applied from this prepayment escrow for the length of the mandatory storage duration. Should the file never be opened again, then the escrow account and the monthly payments will cease at the end of the mandatory storage duration. Should the file continue to be used, additional months of storage will be added and paid at the end of the contract to bring the total duration since last access date back to equal the current mandatory storage duration. In the event that a new provider take over the patient’s records, they never were responsible to pay the entire mandatory storage duration, but, if they access the data during that time period, then they are responsible for the extra monthly payments to bring that mandatory storage duration back into line with the last access date.

Once an EMR file has reached its mandatory storage duration, the record no longer needs to be retained in the readily available storage pool. With current regulations, this data can thus be purged from storage (note: the file pointer is still permanently in the blockchain, but it will be a dead pointer). MedChain not only has the capability to change the actual mandatory storage duration for each change in a jurisdiction’s law, but MedChain can also allow the provider to mark the file eligible for long-term storage. Long-term storage will be a future phase enhancement of MedChain such that a new storage market will be created to pull the data out of a Storage Node and save it long-term media (i.e. tape, “off-line” storage, etc.). When long-term storage is an option, then a permanent end-of-life storage duration will be specified (and


changeable) that will permanently remove the data after, say, 125 years from date-of-birth (or whatever realistic life-expectancy numbers are obtainable).

Of course, MedChain recognizes that a patient’s EMR data may very well be relevant even after the minimum mandatory storage duration for data analytics, machine learning, AI, and diagnosis automation. In MedChain’s Phase II developments, the relevant information will be pulled out and anonymized for that very purpose in the SMDC. The storage duration of the SMDC will likely be dramatically different than that of the SMRC and may even last forever on the SMDC blockchain itself.

The most direct benefit to the provider is that all these considerations will be taken care of automatically through smart contracts and all the provider’s auditing documentation is automatically done for them.

Record Token Pricing The cost of an Record Token will always be tied to a fiat currency. The initial value for the Token is slated to be $0.001 US through MedChain. The Record Token allows a Service Provider to store 1 MB of data for one month. This means, for example, that 1GB of files for a practice would be $1/month. Our research into average medical record size for a typical patient tell us that most patients would generate about 80 MB of data per year [ref]. This means at $0.001 per Record Token, the average doctors office seeing 1000 patients per month would spend $80 to store their records the first year. Then $160 for the 2nd year because the record storage will compound. See Table 6 for other values.

Cost per Year of 80MB/patient

Number of Patients

Cost per month 1 2 3 4 5 6 7

1 $0.01 $0.08 $0.16 $0.24 $0.32 $0.40 $0.48 $0.48

100 $0.67 $8.00 $16.00 $24.00 $32.00 $40.00 $48.00 $48.00

1000 $6.67 $80.00 $160.00 $240.00 $320.00 $400.00 $480.00 $480.00

10000 $66.67 $800.00 $1,600.00 $2,400.00 $3,200.00 $4,000.00 $4,800.00 $4,800.00 Table 6: Example costs for EMR storage

Reading data from a Storage Node is intentionally set to a very low value (currently at a single Record Token cost of $0.001US). MedChain wants to maintain the security and traceability of using Record Tokens for all transactions, but does not want to burden the service providers with the cost of reading data when it comes to saving lives. Therefore, all reads from the SMRC will be one Record Token per fragment.

The Storage Nodes will post their own individual storage costs, which may or may not match the $0.001/MB/month baseline. Every year, a special Smart Contract will execute within the


MedChain Oracles that will re-evaluate the price of the Record Token. If the average storage rates are lower than the going rate for Record Tokens, the cost will be forced down. If the average storage rates are higher, the Record Tokens’ price will be forced upwards. The Storage Market should follow typical economic trends such as:

1. As Storage Nodes add capability, the supply will increase and the price should fall. 2. As storage hardware gets cheaper, the cost of doing business will decrease and the

price should fall. 3. As Storage Nodes are filled, the supply will decrease and the price should rise. 4. As new Storage nodes come on-line, the supply will increase again and the price should

fall. 5. If individual Storage Nodes try to ask above the market value, the lower cost solutions

will be filled first and should raise the cost to match the higher asking values.

Thus, in equilibrium, the cost of Record Tokens purchased per month by the Service Providers will equal the costs charged by the Storage Nodes per month.

Auditability As Storage Nodes submit proof of storage to the blockchain, information can be verified without access to the data which is paramount for compliance of electronic medical record storage. More about the on-chain auditing parameters will detailed in a later paper by MedChain.

Chain Nodes

Computers within the MedChain Network that hold, update and maintain the blockchain ledger are called Chain Nodes. The Chain Nodes create the distributed ledger (i.e. blockchain) that track the file pointers of the Storage Nodes and the permissions granted by the patient.

The Chain Nodes have different roles: peers, endorsers, and orderers. They participate together in the transaction flow: A client (e.g. Provider Node or a Storage Node) sends a transaction to connected endorsers in order to initiate an update of the ledger. All endorsers have to agree upon the proposed transaction, thus a consensus has to be reached regarding the proposed ledger update. The client now successively collects approval of all endorsers. The approved transaction is now sent to connected orderers which again reach consensus. Subsequently, the transaction is forwarded to peers holding the ledger for committing the transaction.

The consensus algorithm for endorsers and orderers will follow a Byzantine Fault Tolerance (BFT) protocol. BFT defends against failures of system components with or/and without symptoms that prevent other components of MedChain from reaching an agreement among themselves. In Fabric’s three-step execute-order-validate model, the results of executing chaincode for a transaction are explicitly agreed upon (according to the endorsement policy)


before the transaction is added to the ledger . Making agreements explicit allows Fabric to use 23

non-deterministic chaincode, written in golang, for the guaranteed operation of MedChain.

Oracles

All the Federated Servers will adhere to a strict set of rules that will conform to the regulations for the nation in which MedChain is implemented. These regulations determine how long to store EMR data, the procedures for replication, the structure around verification of data, etc. These regulations can change however, and must therefore be able to securely change within MedChain. The MedChain Oracles are dedicated Federated Servers that will be the only mechanism to change these overall settings. In addition to regulations, the market variables that control the payout schedule and the storage validation will be funnelled through the Oracles. Each of these variables are written into a MedChain Settings Smart Contract and can only be changed by a whitelisted Oracle after consensus is reached by all the Oracles.

To avoid the Oracles becoming a single point of failure in the system, the whitelisted Oracles will be continuously rotated among the bigger set of possible Oracles. In other words, every 60 seconds, the MedChain Oracle Election Smart Contract will remove the existing set of computer addresses and replace them with a new set. By choosing a new set of Oracles every 60 seconds, no single computer can be targeted for malicious activity. In addition to rotating the whitelist, the consensus mechanism for any Oracles changes will likely be a “near-unanimous vote” algorithm so that any dissenting systems can be identified and investigated. Because of the “near-unanimous” requirement, the availability of Oracles on the network will likely be more closely monitored and enforced than those of other Federated Servers.

The values that the MedChain Oracles control will be added to the Public Verification Chain so that they can continually be monitored and validated. This transparency allows everyone who uses the network to know exactly how it is configured.

Secure Medical Discovery Chain (SMDC) For patients who have opted into allowing their anonymous data to be used for research, a rich pool of EMR records is available for data analytics, machine learning, AI, and diagnosis automation. This anonymous data is stored in the Secure Medical Discovery Chain (SMDC). The SMDC is a blockchain architecture based on the Hyperledger Fabric permissioned network of Federated Servers. The SMDC holds many similarities to the SMRC and will be a natural extension of the codebase already developed for SMRC. The synergistic nature of having such similar codebases provides an easy roadmap for a Phase II addition to the MedChain Network. The Federated Servers within the SMDC are very similar to those in the SMRC. The servers can

23 “Understanding Hyperledger Fabric — Endorsing Transactions”, Rilee, K, Feb 9, 2018


perform one or more different roles: 1) Mining Nodes, 2) Storage Nodes, 3) Chain Nodes, and 4) Oracles. Each of these roles are explained below.

Mining Nodes

Computers within the MedChain Network that communicate directly with the Mining dApps are called Mining Nodes. These Mining Nodes are typically co-located with the Medical Research Facility, but they do not have to be. These Federated Servers pull relevant information out of EMR data that is contained in the SMRC. This relevant information is strictly anonymous. The anonymous medical records (AMR) is then passed to the Storage Nodes of the SMDC to save. Specific details on how the Mining Nodes pull data and ensure anonymity will be finalized during the MedChain Phase II timeframe.

Storage Nodes

Computers within the MedChain Network that store SMDC data are the Storage Nodes. The SMDC Storage Nodes are very similar to the SMRC Storage nodes in that these computers dedicate a given amount of storage for a given amount of time. This dedicated space allows the computer to accept an invitation to store AMR and to get compensated for that storage. These Storage Nodes are typically co-located with the Medical Research Facility, but they do not have to be. Similar to the SMRC Storage Nodes, Proof-of-SpaceTime and Proof-of-Accessibility will be produced for all data saved. Specific details on how the Storage Nodes might differ from those in SMRC will be finalized during the MedChain Phase II timeframe.

Storage Market The Storage Market for AMR will function very similar to that of the SMRC. However, the main difference between the SMRC and the SMDC is that data is stored with a single Record Token per fragment on the SMDC and the amount of data read is paid for by the megabyte, as opposed to vice versa for the SMRC. This means that Storage Nodes are posting their rates on a “per megabyte per read” rate. Thus, the Mining Node used by a Medical Research Facility will choose the lowest cost Storage Node each time it wants to read the data. Since reads are atomic, this simplifies the market over the SMRC implementation, but the code structure still remains similar enough to see how SMRC and SMDC construction will go hand-in-hand.

Chain Nodes

Chain Nodes within SMDC are very similar to those in the SMRC and use the same peers, endorsers, and orderers roles. These computers hold, update and maintain the blockchain ledger. The Chain Nodes create the distributed ledger (i.e. blockchain) that track the file pointers of the Storage Nodes and the permissions granted by the patient. Specific details on how the Chain Nodes reach consensus will be finalized during the MedChain Phase II timeframe.


Oracles

All the Federated Servers within SMDC will adhere to a strict set of rules that will conform to the regulations for the nation in which MedChain is implemented. These regulations determine what data can be mined, the procedures for anonymizing the data, the structure around verification of anonymity, etc. These regulations can change however, and must therefore be able to securely change within MedChain. Similar to the Oracles in SMRC, the SMDC Oracles will be a rotating set of trusted computers that are the only addresses that can change these regulations. Specific details on what data the Oracles oversee will be finalized during the MedChain Phase II timeframe.

Public Verification Chain Due to the sensitive nature of medical records, MedChain must ensure that no personally identifiable information (PII) is leaked onto a public network. Therefore, the SMRC and SMDC have been specifically designed to exist within a permissioned network provided by the Hyperledger framework. However, because everyone has medical records, there exists an inherent requirement that there should be a way for the public to verify and validate the interactions with this permissioned (aka private) network. MedChain employs a 3rd party blockchain to hold this verification data: the Public Verification Chain (PVC).

The final choice of a PVC has not been made, and will likely be designed such that multiple options could exist to house this chain. Initially, the PVC is being designed on the Ethereum network. If, for any reason (economic or technical), the Ethereum blockchain will no longer work, the PVC can be moved to another chain. This is possible because if the Ethereum chain holds the initial Validation Blocks from a certain time period, the new chain will hold Validation Blocks from the new time period forward. It is a hallmark of the PVC to contain a genesis reference to the previous blockchain employed and its ending values. From this, the new chain can propagate.

Each entry to the PVC, gets placed there by an SMRC Oracle. Since this is a “sensitive” operation that is present to offer transparency to the public, the rotating nature of the Oracles are an obvious fit to handle this activity. The Oracles will have a special API for writing directly to the PVC Network.

The costs associated with saving data to the PVC come from the SMRC’s Storage Market in the form of an operational expense. The SaaS subscriptions collected from Service Providers entitle each provider to a certain number of Record Tokens, and the value of each Record Token includes the operational expenses plus the cost charged by the Storage Nodes. The value of any and all operational expenses will be transparently stored on the PVC itself so that anyone can reconcile the internal budget of the SMRC.


Blockchain Implementation

Fig.2 Components of the MedChain blockchains

The MedChain SMRC functions as a hash and permission repository for the decentralized storage network, which is fully auditable and verifiable by a network of federated servers. All storage and retrieval requests require the use of Record Tokens. Figure 2 illustrates the various steps the data takes through the system. For each file that the EMR system brings in, it is encrypted and sharded on the Service Provider’s computer before transmitting across a network. The Provider Node tracks each file with a Directory Block on the blockchain which stores the file addresses of each data shard, who the file belongs to, who created the file, and some additional metadata about the file. Each data shard is stored by a Storage Node and tracked with an Entry Block on the blockchain. Every interaction with any fragment is then tracked with an Access Block on the blockchain. Finally, a Verification Block anchors each transaction to a public blockchain to provide the transparency required to secure all EMR data. The structure of each of these blockchain entries are outlined below.


Entry Block

The structure of an entry block is shown in Table 7. This is the only data required to successfully track any file fragments stored on the MedChain Network. This structure will tell us who wrote the fragment and where the fragment is located/hash of that fragment.

● storage_provider: <addr> ● shard_address: <hash>

Table 7: The Entry Block structure

Directory Block

The structure of a directory block is shown in Table 8. This is the only data required to successfully track any EMR data on the MedChain Network. This structure will tell us what patient the data belongs to, who created it (e.g. you, your doctor, your laboratory, etc.), some metadata about the file itself, where the file is located, and if this particular file is a stored backup copy.

● patient_address: <addr1> ● provider_address: <addr2> ● file_hash: <hash1> ● enc_hash: <hash2> ● shard_data: [ [addr3,hash3], [addr4,hash4], ...] ● provider_notes: <json> ● replication_num: <0=orig,1,2,3,...>

Table 8: The Directory Block structure

Access Block

The structure of an entry block is shown in Table 9. This is the only data required to successfully track any transaction on the MedChain Network. This structure will tell us what file was accessed, what operation was performed (e.g. a read or a write), and who performed it (e.g. you, your doctor, your laboratory, etc.).

● shard_address: <addr1> ● operation: <read/write> ● provider_address: <addr2>

Table 9: The Access Block structure


Verification Block

The structure of a Verification Block is shown in Table 10. This is the only data required to make public so that all interactions on the MedChain Network are successfully tracked. This block will consolidate the relevant data from a list of 10 Access Blocks at a time, plus a hash of all of them, into one block on the Public Verification Chain. Note: The total number of Access Blocks in one Verification block may vary and continually be optimized as testing and markets change. This number will be dictated by the MedChain Oracle.

● num_entries: 10 ● entries: [access_block0,1,2,3,4,5,6,7,8,9] ● hash: <hash>

Table 10: The Verification Block structure

Security Tokens MedCoin

The MedCoin token is the SEC-filed security that tracks the financial health and well-being of the MedChain Network. MedCoin is an Ethereum-network based ERC-20(or similar) token with an initial distribution supply of 100,000,000 and a mintable total supply of 1,000,000,000. The fixed supply and asymptotic minting rate of the remaining token pool are the driving force behind the MedChain infrastructure and important factors for the long term economics of MedCoin. See the Initial Coin Offering (ICO) specifications on our website for more details.

MedChain is currently investigating the feasibility of offering MedCoin tokens as a reward system for HIPAA, GDPR and globally compliant storage space providers instead of using fiat currencies as described in the sections above. The evolving SEC regulations and interpretations will dictate if securities can be used as payment mechanisms.

Utility Tokens All storage and retrieval requests, and other internal uses in the system, will use utility tokens, never MedCoins. Currently, there is one utility token called the Record Token for the SMRC.

Record Token

The MedChain utility token for the SMRC is the Record Token. The Record Token is tied to a real fiat value to eliminate the need for service providers to worry about conversion rates or the volatility of a tradable cryptocurrency or token. The initial value for the Token is slated to be $0.001 US through MedChain. The Record Token allows a Service Provider to store 1 MB of


data for one month. This rate will change as the Storage Market changes through changing storage prices and infrastructures costs. The design of the Storage Market, however, has been carefully architected so that it reflects actual storage costs (a.k.a. real-costs) available from the Storage Nodes.

The “real-cost” architecture and behavior of the Storage Market will ensure that the service providers are not unduly overcharged. Thus, the cost of Record Tokens will reflect an actual cost-of-doing-business for the providers. This means that service providers will not be “priced out” of storing their patients’ records on MedChain. In a similar effort to not “price out” the provider from actually reading patient information in an emergency situation or during high patient volumes, the cost to read data from the SMRC is at a fixed price of only one Record Token per fragment. The sub-one-cent price of a token will ensure that even busy hospitals seeing hundreds of patients per day will not be unduly burdened to get their patients’ records.

As a matter of security, Record Tokens will be tied to the account or user ID of the purchaser which prevents use by any other party. This renders them unlikely targets for theft as they serve no purpose outside the initial purchasers’ account.

Record Tokens will be created every month as part of the Software-as-a-Service (SaaS) model. Each SaaS package offered will include a set number of Record Tokens to be used for writing or reading EMR data. Should all the SaaS Record Tokens be used before the month is over, additional Record Tokens can be purchased at the current Record Token rate. If Record Tokens remain at the end of the month, they will roll-over to the next month to be added to the next month’s SaaS allotment. Record Tokens will be “burned” as they are used. There will be no need to re-use them or maintain their total supply quantity.

Discovery Token

It is anticipated that the SMDC will require a second utility token for the Phase II additions to the network. This is because the fiat value of SMRC writes will be priced differently than the SMDC reads for research purposes. The specifics of the Discovery Tokens will be finalized during the MedChain Phase II timeframe.

Future Tokens

As new phases of MedChain are implemented, new economic markets will need to be established to track specific pricing and utility. New tokens may be created for these new markets.


Team Joachim Sandgaard, Founder & CEO

Joachim Sandgaard is a seasoned IT professional with almost two decades of experience in the healthcare and medical device industry. He has extensive knowledge of current EMR system integration, document management, and healthcare compliance regulations.

Joachim founded MedChain in 2017.

Steve Wishstar, Chief Technical Officer

Steve is an experienced CTO, manager, and full-stack developer. He has over 10 years of CTO experience, and 40 years working software projects with world-leading organizations such as NASA, Lockheed Martin, Raytheon and University of Colorado. He is an experienced executive manager, program manager, and software engineer with a demonstrated history of developing/implementing corporate strategic roadmaps, and directing our Technical Teams to produce maintainable code, automated test driven architectures, and solid full-stack integrity.

He holds a Master's Degree in Aeronautics & Astronautics from Stanford University

Eric Lafleche, Chief Marketing Officer

Former Global Marketing Manager at Budweiser and Lead Innovation Manager at Unilever. Experienced Cryptocurrency investor and co-host of the ‘CryptoStarship’ podcast and co-founder of the TradeScout Protocol.

Russ Decker, Blockchain Developer

Developer and analyst at the Mayo Clinic working with medical decision tools and with experience integrating healthcare interoperability solutions

Ethan Plue, Community Manager

Social media and community management expert


Advisors Gene Libov, Information Security Advisor

Experienced Chief Information Security Officer and former Director of Security and Technology Assurance at Blue Shield of California.

Matthew Hunter, Data Extraction and Integration Advisor

Experienced Executive with deep roots on the technical side, 10 years of experience in healthcare and the IT fields, and over 20 years’ experience in management level roles. Proven experience in implementing health information systems, team building, data extraction, integration, and strategic development of overall IT environment.

Hazel Sebastian, Business Development Advisor

Experienced Business Developer in the Healthcare and Skilled Nursing fields with a history of building strong and lasting relationships.

Dr. Steve Malen MBA, Healthcare Analytics Advisor

Over 10 years experience working in healthcare managing multiple pharmacies utilizing innovative solutions. Currently Pharmacy Manager at Walgreens. SEC Compliance / Legal Advisor

Sichenzia Ross Ference Kesner

Accounting / Financial Auditing

EKS&H

Thomas Sandgaard, Chairman & Co-Founder

Thomas Sandgaard is a highly successful entrepreneur in the medical device industry. He started his career in Europe with Siemens, Philips Telecom, Dataco, and ITT. In 1996 he founded Zynex Medical , a Durable Medical Equipment company. In 2004, he took the 24

company public (stock ticker: ZYXI).

Thomas holds a BS in Electrical Engineering from the University of South Denmark and an MBA from Copenhagen Business School. He is a co-founder of MedChain.

24 "Zynex Medical." https://www.zynex.com/


https://www.zynex.com/

Go to Market Strategy Near Term

MedChain will use a combination of strategies to bring products to market.

The initial focus will be on integration and development of partnerships with companies in all facets of healthcare who have a need for compliant data storage. Healthcare organizations can build within our consortium to develop tailored applications for their desired use-case. Our own proprietary dApps will be pushed through direct sales, initially targeting medical testing labs who are in dire need of an interoperability solution.

Labs are typically stuck in the middle between healthcare provider and patient, forced to interact with both, but caught up in the challenges of data security and interoperability. Labs typically process high volumes of patients and would benefit significantly from MedChain’s solution.

MedChain would begin with small scale pilot programs, initially targeting independent and small regional lab networks. As soon as MedChain can demonstrate successful outcomes with smaller players, we will begin to target larger lab networks.

MedChain’s second target will be Physician Clinics, which we will target by working with Quality Improvement Organizations (QIO).

The QIO Program was launched in 2002 and is one of the largest federal programs dedicated to improving health quality at the local level. QIOs are tasked with helping clinics adopt technology. As a government funded program, their services are free for participating clinics. While QIOs are designed to be objective with no allegiance to a specific product, we believe MedChain’s many benefits will create a strong case for recommendation by QIOs.

MedChain’s third target will be a robust partnership program that promotes integration with smaller EMR and ePHI providers who need to solve data security and interoperability issues.

Longer Term

Over time, as the advantages of building applications on MedChain become clear and our userbase has reached critical mass, we will begin to approach larger organizations, such as more risk averse hospitals and networks of care providers who are still waiting for proven long-term stability of an ecosystem before themselves integrating.


Roadmap/Anticipated Timeline


Financing MedChain intends to raise capital through three sequential funding events.

1. Regulation CF Seed-ICO: $467,000 Raised 25

2. Anticipated Regulation D 506(c) Pre-ICO: $5-15M 3. Anticipated Regulation A+ ICO: $15-30+M

Due to the nature of MedChain’s initial offering, our financials will be subject to review and audit by public accountant(s) independent of MedChain. 26

Token Allocation

The Medchain MedCoin Token will have an initial genesis supply of 100,000,000(100 Million) Tokens with a total issuable supply of 1,000,000,000 (1 Billion) through aforementioned PoSt/PoA/PoR consensus algorithms.

During the initial distribution, disbursement to investors is expected to reach 60%. The total issuable supply will eventually represent 90%+ community ownership of the MedCoin Tokens.

25 "MedChain | StartEngine." 30 Dec. 2017, https://www.startengine.com/medchain. 26 "SEC.gov | Regulation Crowdfunding: A Small Entity Compliance" 13 May. 2016, https://www.sec.gov/info/smallbus/secg/rccomplianceguide-051316.htm.


https://www.startengine.com/medchain

https://www.sec.gov/info/smallbus/secg/rccomplianceguide-051316.htm

Funds Allocation

Funds raised by MedChain will be used to further development of MedChain and the MedChain protocol along with its associated infrastructure.


Risk Factors For a full list of risks please refer to associated offering documentation or Private Placement Memorandum.

This document is for informational purposes only and does not constitute an offer or solicitation to sell shares or securities in MedChain or any related or associated company. Any such offer or solicitation will be made only by means of a Private Placement Memorandum and in accordance with all applicable securities laws.

We may make an offering of securities pursuant to Rule 506(c) under the Securities Act in which case only persons verified as accredited investors may invest.

There may be no trading market available for tokens and peer-to-peer transfers will not be permitted unless and until Token holders are notified otherwise by the Company and informed of the requirements to and conditions do so. As a result of recent regulatory developments, most conventional crypto exchanges are currently unwilling to list securities tokens, such as the Company's tokens. As a result, when the tokens become transferable, they may only be traded on very limited range of venues, including U.S. registered exchanges or regulated alternative trading systems for which a Form ATS has been properly submitted to the SEC. Moreover, even if legally permitted, by purchasing tokens, token holders agree to additional transfer restrictions and shall not be able to effect transfers until such time as the Company informs holders that a registered exchange is available or that peer-to-peer transfer processes have been established. As a result, holders of tokens should be prepared to hold their tokens indefinitely. Moreover, even if the Tokens become transferable, we may rely on technology, including smart contracts, to implement certain restrictions on transferability in accordance with the federal securities laws. There can be no assurance that such technology will function properly, which could result in technological limitations on transferability and expose the Company to legal and regulatory issues. In the event that our tokens remain untradeable for a significant period of time or indefinitely, the value of the tokens would be materially adversely affected. Tokens are novel and the application of U.S. Federal and State securities laws is unclear in many respects. Because of the differences between the securities offered hereunder and traditional securities, there is a risk that issues that might easily be resolved by existing law if traditional securities were involved may not be easily resolved for our securities. In addition, because of the novel risks posed by our securities, it is possible that the regulators may interpret law in a manner that adversely affects the value of our securities. Our securities are highly speculative and any return on an investment in our securities is contingent upon numerous circumstances, many of which (including legal and regulatory conditions) are beyond the Company's control. There is no assurance that purchasers will realize any return on their investments or that their entire investments will not be lost. For this reason, each purchaser should carefully read any associated Memorandum and should consult with their own attorney, financial and tax advisors prior to making any investment decision with respect to our securities. Investors should only make an investment in our securities if they are prepared to lose the entirety of such investment.


Holders of our securities have no voting rights, except, with respect to the Common Stock and those required by state law. As a result, except with respect to matters required to be submitted to token holders under state law, all matters submitted to stockholders will be decided by the vote of holders of the Company's common stock entitled to vote thereon, which shall not include the tokens. As a result, holders of our securities will have no ability to elect directors or, except with respect to matters required to be submitted to token holders under state law, to determine the outcome of any other matters submitted to a vote of the Company's stockholders. The interests of holders entitled to vote on such matters may differ from, or conflict with, the interests of token holders. The Company was founded to develop and commercialize blockchain technology. In recent years, cryptocurrencies and cryptosecurities have become more widely accepted among investors, but have been also faced increasingly complex legal and regulatory challenges and, to date, have not benefited from widespread adoption by governments, central banks or established financial institutions. Any significant decrease in the acceptance or popularity of cryptocurrency or cryptosecurity offerings may have a material impact on the Company's operations and financial conditions and your investments in our securities. Investors may lack information for monitoring their investment. The Investor may not be able to obtain all information it would want regarding MedChain, MedCoins, or the MedChain Network, on a timely basis or at all. It is possible that the Investor may not be aware on a timely basis of material adverse changes that have occurred with respect to certain of its investments. While MedChain has made efforts to use open-source development for Tokens, this information may be highly technical by nature. As a result of these difficulties, as well as other uncertainties, an Investor may not have accurate or accessible information about the MedChain Network. If the MedChain Network is unable to satisfy data protection, security, privacy, and other government and industry-specific requirements, its growth could be harmed. There are a number of data protection, security, privacy and other government- and industry-specific requirements, including those that require companies to notify individuals of data security incidents involving certain types of personal data. Security compromises could harm the MedChain Network’s reputation, erode user confidence in the effectiveness of its security measures, negatively impact its ability to attract new users, or cause existing users to stop using the MedChain Network. The Company’s business involves the storage and transmission of users’ proprietary information, and security breaches could cause a risk of loss or misuse of this information, and to resulting claims, fines, and litigation. The Company may be subjected to a variety of cyber-attacks, which may continue to occur from time to time. Cyber-attacks may target the Company, its suppliers, banks, credit card processors, delivery services, e-commerce in general or the communication infrastructure on which they depend. An attack or a breach of security could result in a loss of private data, unauthorized trades, an interruption of trading for an extended period of time, violation of applicable privacy and other laws, significant legal and financial exposure, damage to reputation, and a loss of confidence in security measures, any of which could have a material adverse effect on the Company’s financial results and business. Any such attack or breach could adversely affect the ability of the Company to operate, which could adversely affect the value of the Tokens. Any breach of data security that exposes or compromises the security of any of the


private digital keys used to authorize or validate transaction orders, or that enables any unauthorized person to generate any of the private digital keys, could result in unauthorized trades and would have a material adverse effect on the Incubator. Because trades utilizing blockchain technology settle on the trade date, it could be impossible to correct unauthorized trades. Furthermore, attackers can manipulate the cryptocurrency market. The price of cryptocurrencies, such as Bitcoin and Ether, are set by several exchanges. If an exchange is attacked such that it is taken offline, traders can take advantage of price differences. Additionally, attackers can target platforms that buy and sell cryptocurrencies and digital wallets that hold cryptocurrencies. It is possible that such an attack could adversely affect the Incubator’s investments and the value of the Tokens. We require the proceeds from this offering to continue our operations. Our ability to continue as a going concern is wholly dependent upon completing this Offering and thereafter obtaining sufficient financing to fund our development strategies. Taking into account the proceeds from this Offering, we will still be required to raise significant additional capital to fund our development strategies. We have no committed sources of additional capital and our access to capital funding is always uncertain. There is no assurance that additional equity or debt financing will be available to us when needed. In the event that we are not able to secure additional financing, we may be forced to curtail operations, cease operations altogether or seek protection from our creditors. MedChain may be forced to cease operations or take actions that result in a Dissolution Event. It is possible that, due to any number of reasons, including, but not limited to, an unfavorable fluctuation in the value of cryptographic and fiat currencies, the inability by the Company to establish the Minimum Viable Product or the Tokens’ utility, the failure of commercial relationships, or intellectual property ownership challenges, the Company may no longer be viable to operate and the Company may dissolve or take actions that result in a Dissolution Event. In a Dissolution Event, investors will likely lose all of their investment. Investments in startups including MedChain involve a high degree of risk. Financial and operating risks confronting startups are significant: MedChain is not immune to these. The startup market in which MedChain competes is highly competitive and the percentage of companies that survive and prosper is small. Startups often experience unexpected problems in the areas of product development, marketing, financing, and general management, among others, which frequently cannot be solved. In addition, startups may require substantial amounts of financing, which may not be available through institutional private placements, the public markets or otherwise. The tax treatment of the Token, the purchase rights contained therein and the Token distribution is uncertain and there may be adverse tax consequences for Investors upon certain future events. The tax characterization of the Tokens is uncertain, and each Investor must seek its own tax advice in connection with an investment in the Company. An investment and the purchase of Tokens may result in adverse tax consequences to Investors, including withholding taxes, income taxes and tax reporting requirements. Each Investor should consult with and must rely upon the advice of its own professional tax advisors with respect to the United States and non- U.S. tax treatment of an investment.


The structure of the MedChain blockchain protocol means that the MedChain Network may be susceptible to developments by users or contributors could damage the MedChain blockchain and MedChain’s reputation and could affect the utilization of the MedChain blockchain and the Tokens. The MedChain Network will operate based on a protocol maintained by MedChain and other contributors. The nature of the MedChain blockchain protocol means that it may be difficult for the Company or contributors to maintain or develop the MedChain Network and the Company may not have adequate resources to address emerging issues or malicious programs that develop within the MedChain Network adequately or in a timely manner. Third parties not affiliated with the Company may introduce weaknesses or bugs into the core infrastructure elements of the MedChain Network and code which may negatively impact the MedChain Network. Such events may result in a loss of trust in the security and operation of the MedChain Network and a decline in user activity and could negatively impact the market price of the Tokens. The MedChain Network may be the target of malicious cyberattacks or may contain exploitable flaws in its underlying code, which may result in security breaches and the loss or theft of Tokens. If the MedChain Network’s security is compromised or if the MedChain Network is subjected to attacks that frustrate or thwart our users’ ability to access the MedChain Network, their Tokens or the MedChain Network products and services, users may cut back on or stop using the MedChain Network altogether, which could seriously curtail the utilization of the Tokens and cause a decline in the market price of the Tokens. MedChains structural foundation, the protocol, the software application(s) and other interfaces or applications built upon the MedChain Network are still in an early development stage and are unproven, and there can be no assurances that the MedChain blockchain and the creating, transfer or storage of the Tokens will be uninterrupted or fully secure which may result in a complete loss of users’ Tokens or an unwillingness of users to access, adopt and utilize the MedChain software. Further, MedChain may also be the target of malicious attacks seeking to identify and exploit weaknesses in the software or the MedChain blockchain which may result in the loss or theft of Tokens. For example, if MedChain and the MedChain blockchain are subject to unknown and known security attacks (such as double-spend attacks, 51% attacks, or other malicious attacks), this may materially and adversely affect MedChain. In any such event, if the Network Launch does not occur or if the MedChain blockchain is not widely adopted, Investors may lose all of their investment. The regulatory regime governing the blockchain technologies, cryptocurrencies, tokens and token offerings such as MedChain and the Tokens is uncertain, and new regulations or policies may materially adversely affect the development of the MedChain Network and the utility of the Tokens. Regulation of tokens (including MedCoins) and token offerings such as this, cryptocurrencies, blockchain technologies, and cryptocurrency exchanges currently is undeveloped and likely to rapidly evolve, varies significantly among international, federal, state and local jurisdictions and is subject to significant uncertainty. Various legislative and executive bodies in the United States and in other countries may in the future, adopt laws, regulations, guidance, or other actions, which may severely impact the development and growth of the MedChain Network and the adoption and utility of the Tokens. Failure by the Company, or certain users of the MedChain Network to comply with any laws, rules and regulations, some of which may not exist yet or are subject to interpretation and may be subject to change, could result in a variety of adverse


consequences, including civil penalties and fines. As blockchain networks and blockchain assets have grown in popularity and in market size, federal and state agencies have begun to take interest in, and in some cases regulate, their use and operation. In the case of virtual currencies, state regulators like the New York Department of Financial Services have created new regulatory frameworks. Others, as in Texas, have published guidance on how their existing regulatory regimes apply to virtual currencies. Some states, like New Hampshire, North Carolina, and Washington, have amended their state's statutes to include virtual currencies into existing licensing regimes. Treatment of virtual currencies continues to evolve under federal law as well. The Department of the Treasury, the Securities Exchange Commission, and the Commodity Futures Trading Commission, for example, have published guidance on the treatment of virtual currencies. The IRS released guidance treating virtual currency as property that is not currency for US federal income tax purposes, although there is no indication yet whether other courts or federal or state regulators will follow this classification. Both federal and state agencies have instituted enforcement actions against those violating their interpretation of existing laws. The regulation of non-currency use of blockchain assets is also uncertain. The CFTC has publicly taken the position that certain blockchain assets are commodities, and the SEC has issued a public report stating federal securities laws require treating some blockchain assets as securities. To the extent that a domestic government or quasi-governmental agency exerts regulatory authority over a blockchain network or asset, the MedChain Network and the Tokens may be materially and adversely affected. Blockchain networks also face an uncertain regulatory landscape in many foreign jurisdictions such as the European Union, China and Russia. Various foreign jurisdictions may, in the near future, adopt laws, regulations or directives that affect MedChain. Such laws, regulations or directives may conflict with those of the United States or may directly and negatively impact our business. The effect of any future regulatory change is impossible to predict, but such change could be substantial and materially adverse to the development and growth of MedChain and the adoption and utility of the Tokens. New or changing laws and regulations or interpretations of existing laws and regulations, in the United States and other jurisdictions, may materially and adversely impact the value of the currency in which the Tokens may be exchanged, the liquidity of the Tokens, the ability to access marketplaces or exchanges on which to trade the Tokens, and the structure, rights and transferability of Tokens. MedChain may not successfully develop, market and launch the Minimum Viable Product and Investors may not receive Tokens. The MedChain blockchain has not yet been developed by the Company and will require significant capital funding, expertise of the Company’s management, time and effort in order to develop and successfully launch the MedChain blockchain. The Company may have to make changes to the specifications of the MedChain blockchain protocol or Tokens for any number of legitimate reasons or the Company may be unable to develop the MedChain blockchain in a way that realizes those specifications or any form of a functioning network. It is possible that the Tokens and the MedChain blockchain may not ever be released and there may never be an operational Token or that the blockchain launch will not occur. The MedChain blockchain or Tokens, if successfully developed and maintained, may not meet investor expectations at the time of purchase. Furthermore, despite good faith efforts to develop and launch the MedChain blockchain and subsequently to develop and maintain the MedChain blockchain, it is still possible that the MedChain blockchain will experience malfunctions or otherwise fail to be adequately developed or maintained, which may negatively impact the MedChain blockchain and Tokens. The Company will use the proceeds of this Offering to make significant investments to develop and launch a viable MedChain Network and subsequently to build a fulsome network upon which users


can realize utility and value. The Company may not have or may not be able to obtain the technical skills and expertise needed to successfully develop the MedChain blockchain and progress it to a successful Network Launch. While the Company has sought to retain and continue to competitively recruit experts, there is a general scarcity of management, technical, scientific, research and marketing personnel with appropriate training to develop and maintain MedChain and the MedChain Network. If the Company is not successful in its efforts to demonstrate to users the utility and value of the MedChain Network, there may not be sufficient demand for the Tokens for the Company to proceed with the Network Launch. As a result, or if the Network Launch does not occur, Investors may lose all of their investment. “Network Launch” means the release of software that allows buyers and sellers to exchange storage, using the technologies and market incentives described above in Company Overview.

For additional risk factors, please refer to the offering documents associated with any current MedChain Token sale or Coin Offering.


Conclusion MedChain is uniquely positioned to solve the problems of Electronic Medical Records and electronic Protected Health Information systems.

Our team has extensive experience in healthcare, IT systems and Blockchain. Our deep understanding of the challenges in healthcare have enabled us to design a solution that provides lasting benefits to patients, providers and other stakeholders in the healthcare ecosystem.

Our solution will improve patient outcomes and reduce healthcare costs by solving the two biggest challenges faced by EMR and ePHI systems: data security and interoperability.

We will achieve this by putting the patient at the center of their own medical records, and using a novel implementation of a Hyperledger Fabric blockchain, a novel implementation of a permissioned Distributed Storage Network, and verification anchoring to the Ethereum Blockchain for transparency and auditability.

MedChain is currently the only ICO to offer a SEC-filed offering with a HIPAA & GDPR-compliant solution for Electronic Medical Records and electronic Protected Health Information systems.

We invite you to join us in our quest to give all patients the medical care they deserve.


Addenda

Definitions

MedChain MedChain, “the company”, “we”, “MedChain blockchain” and “the blockchain” as described in this document is a project of MedChain Inc. A for-profit Delaware incorporated company that is actively developing software based on and revolving around blockchain protocols. MedChain Inc. is owned by Genesis Protocol, a Colorado Limited Liability Company.

The MedChain Security Token The MedCoin Security Token is the valuation of the MedChain infrastructure. MedCoin tokens are intended to be used as a reward system for HIPAA, GDPR and globally compliant storage space providers, distributed mining payment cycles, and federated server reimbursement.

We believe in a token-connected world, where medical and healthcare services can be driven by MedCoin on the MedChain infrastructure.

IPFS (InterPlanetary File System) IPFS is a versioned file system that can take files and manage them and also store them somewhere and then tracks versions over time. IPFS also accounts for how those files move across the network so it is also a distributed file system. IPFS has rules as to how data and content move around on the network that are similar in nature to bittorrent.

Record Tokens The MedChain internal token, the Record Token will be purchasable with USD for a flat value of $0.001 US through MedChain. This prevents the value of the external token having a prohibitive effect on the cost of entry into the Blockchain. Internal tokens will be tied to an account or user ID, preventing use by any other party. This renders them unlikely targets for theft as they serve no purpose outside the initial purchasers account.

Blockchain technology Blockchain technology is used to share a ledger of transactions across a business network without control by any single entity. The distributed ledger makes it easier to create cost-efficient commercial relationships where virtually anything of value that can be tracked and traded without requiring a central point of control. The technology puts privacy and control of data in


the hands of the individual. Trust and integrity is established without reliance on third-party intermediaries.

Ethereum The MedChain Security Token is currently set to be deployed as an ERC-20 (or similar) token on the Ethereum blockchain. The MedChain blockchain is being developed around Hyperledger Fabric, and is likely to be utilizing the Ethereum blockchain for transparency through anchoring.

HIPAA Regulations and Compliance The Health Insurance Portability and Accountability Act privacy regulations require healthcare providers and organizations, as well as their business associates, to develop and follow procedures that ensure the confidentiality and security of protected health information(PHI) when it is transferred, received, handled, or shared. This applies to all forms of PHI, including paper, oral, and electronic, etc. Furthermore, only the minimum health information necessary to conduct business is to be used or shared. 27

GDPR The General Data Protection Regulation (GDPR) (EU) is a regulation in EU law on data protection and privacy for all individuals within the European Union. It also addresses the export of personal data outside the EU. The GDPR aims primarily to give control to citizens and residents over their personal data and to simplify the regulatory environment for international business by unifying the regulation within the EU.

27 “Summary of the HIPAA Security Rule”, U.S. Department of Health & Human Services, July 2013


white paper v1 - medchain whitepaper v1.0.pdf · 2018-06-04 · blockchain market, our sec-filed...

Documents