LifeRhythm Medical Services LLC He al th Co r e P la tfo rm instagram/liferhythmlabs www.liferhythmlabs.com Support@ liferhythmlabs.com 2 ~ Over view & Syno psis ~ T he industry of Medical information serves as the apex metric to gain insight into the population's global health and well-being. Given how critical of a role this industry plays it comes as a shock & a disappointment that this industry is heavily reliant on con-current industries to guarantee + Privacy - is all sensitive information obfuscated to a satisfactory level + Authority - how can we validate and segment control rights to the data. Who can access the data & when can they access it. + Accessibility - how can we guarantee that only those who are authorized to access data actually access it when needed and not someone else. + Regulation - different governments have different frameworks in place as to the structure of information in relation to public good and services. The Purpose of this paper is to present the HealthCore platform, a multi-layer blockchain & crypto-based environment focused on the provision of a complete suit of proper applications and service functions for the medical records Industry. The HealthCore project has been given names of biological micro-elements (Hydrogen, Carbon, Nitrogen & Oxygen) to reflect the role it plays within the greater medical Ecosystem. Being built on blockchain technology the HealthCore platform is intended to be progressively decentralized over time. However, from inception the project will leverage a hybrid governance environment for the provision of necessary services. This document has been composed to service the general public as well as industry professionals with a high level understanding of the topic. After acclimating themselves with this document the reader will become acquainted with the proposition presented by LifeRhythm Medical Services LLC in the provision of the HealthCore project All independant layers of the HealthCore project [1, 2, 3, & 4-of-4] are readily available through accompanying documentation. Let the reader be advised that all related concurrent documentation is formatted to be chrono-neutral (read in any order) but reflects the core ideas expressed in this paper. The HealthCore ecosystem is a software deployed to the hyperledger fabric blockchain as a series of smart contracts focused on the provision & storage of medical data. LifeRhythm Medical Services LLC. is the ambitious medical arm of LifeRhythm Labs INC.; an organization that provides a full suite of software technologies for the decentralized digital age of WEB 3.0. HealthCore WhitePaper Version 0.2 3 ~ Terminology ~ 2FA: Two-Factor-Authentication; an added layer of protection for accounts typically utilized during sign-in sessions, withdrawals, posts, and accessing private information. API: acronym : A pplication P rogramming I nterface, a system to system interface component that allows disparate technologies to share data & communicate Blockchain: a structure of record keeping which is immutable, proovable, transparent, traceable, and censorship resistant. ClearingHouse: a random group of trusted validators used for the processing of events & activity on the HealthCore-Chain. Dapp: Decentralized Application; an application that is not hosted on a single server, thereby becoming much more redundant to failures and censorship. DID: Decentralized-Identity; a formal form of identity that is not susceptible to manipulation from any centralized party. Ethereum: a turing complete blockchain based smart contract platform EVM: Ethereum Virtual Machine, computational hyperspace for blockchain applications based on ETH Fungible: state where two items are interchangeable and indistinguishable from one another (ex. 1USD = 1USD) HCC: Abbreviation for HealthCore-Chain & the name of the native HealthCore blockchain environment. HC-1: Token standard that is developed on the HealthCore Chain HealthCore - The name of the medical application suite being developed by Liferhythm Medical Services LLC. Hyperledger Fabric: highly modular, enterprise grade blockchain software environment & library provided by HyperLedger foundation & powered by its own novel HackSaw consensus mechanism. Ledger: a log of all information pertaining to a subject which acts as a single source of truth (ex: a medical journal where all licensed heart surgeons must be listed) Machine Learning: The specific branch of artificial intelligence dealing with the recurrent self-sovereign-education of a mechanical non human entity. Maturing/Maturation: the event of converting $CRBN tokens into $HYDRO tokens through a coin burn. MetaData: “data about data”; metadata is information that provides abstract insight and information into other data Settlement: the irreversible final state of a transaction UI / User Interface: User-Interface is the appearance of an application; it is the frameworks that empower the way that people interact with a computer system. UX / User Experience: User-Experience is the total satisfaction & ease with which a user interacts with an application; largely considered one of the (if not the) most important aspects in the development of an application. WEB 3.0: Term used to refer to the future of connective technologies. HealthCore WhitePaper Version 0.2 4 [Layer 1-of-4] Data Layer & Ledger HealthCore WhitePaper Version 0.2 5 Hydrogen (Data Aggregation) At a high-level Hydrogen is the first layer of a multi-layer project intent on providing a software ecosystem built leveraging blockchain technology for the purposes of providing a distributed, trusted, private, secure, & robust environment for the storage and management of the medical records & services. The application & its ecosystem will exist in the HyperLedger Fabric, a highly modular, highly secure, stable, and scalable consortium style distributed ledger technology. Being WEB3.0 compatible, the Hydrogen core system is maintained through a dual-token structured consensus mechanism. The overarching goal of the Hydrogen layer is to be able to introduce and maintain as many initial independent actors into the ecosystem as quickly as possible; while guaranteeing accuracy, privacy, and security for their information. The Hydrogen layer is essentially broken down into 3 core objective: 1) → Data Aggregation 2) → Data Management & Protection 3) → Token Dissemination Data aggregation means two things within itself: 1. the introduction of as many new agents into the ecosystem as quickly as possible 2. Uniting as much medical information as possible. Data management and protection revolves around the more intimate principles of how data is handled once it is pushed onto the platform. Finally, Token Dissemination references two concepts as well: 1. The Creation of as many NFT’s as possible 2. Having every account/NFT circulate at least 2,500 tokens over the course of a year. The HealthCore ecosystem leverages a three-tier token incentive mechanism for its operations, a Non-fungible ERC-721 token for identity that is coupled with an ERC-20 token for governance $HYGN / $HYO & the HC-1 coin for the provision of economic settlements known as $CRBN (please refer to Phase 2 documentation). HealthCore WhitePaper Version 0.2 6 Taking into account that the very core problem of the medical data industry has to do with availability & accessibility (who, when, and how fast can information be obtained), Hydrogen has been designed to deal with just that. The Hydrogen ecosystem addresses verticals of the Medical industry pertaining to: Medical data storage & management, privacy of sensitive information, insurance, payments, & predictive pharmacology. The Hydrogen application layer has been equipped with a data framework for Medical Professionals to participate in. It is capable of handling radically varying structures of data and harmonizing them into a standard which is capable of communicating not only across blockchains but across disparate technological environments as well. At launch, Hydrogen is intent on targeting as wide an audience of medical professionals as possible. Factions of the medical industry from General Family Practitioners, Dental providers, Optometrists & Dermatologists to Heart Surgeons, Neurologists, Psychologists & beyond; in the event of alternative specialists signing onto the network, there is a man-maintained back-system which process them off-chain. All participants of the ecosystem that are Medical Providers will undergo a robust verification process: uploading their certifications as well as proving pre-existing field experience, peer verification, their listings medical journalism etc. At a later point, Hydrogen will be integrated into the existing legacy system to provide a fluid informational onramp for professionals; ideally the process will become as simple as connecting a Google+ account with a Facebook account & provide security measures of military-grade financial institutions. After registering and once their claims have been verified, the practitioners will gain the rights to read and write to the dedicated listing ledger. The listing ledger is where regular users are able to source their medical professionals from; this can be thought of in terms of already familiar examples with systems like ZocDoc, Yelp, etc. Every MP (Medical Professional) account comes with expanded token functionality of staking. Medical professionals cannot buy $HYGN tokens, they are only able to accrue them through maintaining their reputation according to how many end users are willing to validate their practices by delegating tokens to their preferred MP’s HealthCore WhitePaper Version 0.2 7 Hydrogen (Data Management & Protection) Blockchains are notorious for their data permanence and availability. Once something has been introduced into a blockchain it cannot be removed, and if removal is attempted then that action of removal is recorded and appended. Moreover, that data can always be requested for or checked on. This causes distress for individuals; why would somebody want some kind of personal medical information existing in digital hyperspace? The most obvious and direct answer can be found somewhere on the spectrum between emergency situations and information availability. To put things into perspective one needs to image themselves in a situation; traveling around the world with allergies. Barry, born in the United States, was born with peanut allergies. He turns 27 years old and heads out to explore the world. Landing in Mumbai India after his long flight from Tokyo, Barry decides to go grab some street food. Biting into a juicy piece of Curry Chicken he all of a sudden realizes his breathing is getting difficult and his throat is swelling. Right before he passes out he yells out HEALTHCORE APPLICATION. Rushing him to the emergency room, the Nurse, Raj, cannot figure out what is causing this reaction. The journey to the hospital is 30 minutes and if Barry isn’t treated with something in the next 10, he might not make it. Now traditionally to get medical patient records the hospital would have to call the US embassy, that would have to call some health organization, who would call his personal provider, who would then give them a hard time accessing the records because of fraud & security reasons. Luckily, when Barry yelled out HEALTHCORE he activated the widget, which will ping a flashing signal to inform Raj that there is some information available. Seeing this Raj signs into the platform and requests emergency information on Barry by scanning his fingerprint - the response from the platform does not forfeit any sensitive data, rather it simply states that this is a person with XXX Allergies to food/medicines & XXX neural conditions. The entire process that traditionally takes 5+ parties and no less than 30 minutes has been addressed in a matter of seconds. Raj injects some antihistamines into Barry. Barry regains consciousness thanks Raj and asks where the closest food trolly WITHOUT peanuts in their curry sauce can be found. The HealthCore platform very carefully segregates information by sensitivity; where emergency data is presented in an abstract format and must be requested through a multi-signature scheme. The Multi-sig scheme is bound with a tiered 5-factor approach, HealthCore WhitePaper Version 0.2 8 Application ←→ Device ←→ Biometrics ←→ Wallet ←→ Password In this 4 factor scheme, any combination of requests creates its own specific level of accessibility permission; where 3-of-5 will provide abstract meta-data and 5-of-5 will provide almost any request depth. Moreover, understanding the consumers need for peace of mind, data that is pushed through the application will exist only within the local application space (device drive) for a certain period, after which it will be pushed to the HCC blockchain permanently; once there it cannot be taken down. Extending the measure of protection all the more, every piece of data is sharded into 31 components and randomly sent throughout the network. No one piece can register any data without the remaining pieces, moreover, even if 31 pieces are to be united it cannot unlock the information hidden within them unless a handshake is established between the data & its according device & wallet, confirmed by the passphrase and a biometric thumb scan. $HYO & $HYGN (Token Dissemination & tokenomics) The Hydrogen application and its constituent following 3 ecosystems are maintained and governed through a dual-token consensus structure. The Hydrogen phase is of utmost importance given that it will serve as the point of initial dissemination of the $HYO/$HYGN tokens. For medical patients, the token serves as a formal identifier within the ecosystem; as well as providing a Sybil mechanism (a form of extended security against malicious actors [specifically spam]). Token Name: Hydrogen Token Symbol: $HYGN / $HYO Supply: X:1 + reputation variable / 500,000,000 +mint & Burn Blockchain: Hyperledger/ Ethereum Standard: ERC-721/ ERC-20 Function: Access Rights & Governance HealthCore WhitePaper Version 0.2 9 The tokens will initially be deployed on top of the Ethereum Blockchain as ERC standard assets. This has been decided upon as so due to the widespread recognition of the ERC as the global token standard; interoperability is key in the long term suitability of the HealthCore project. The first token is called the $HYGN token; HealthCore’s solution to the industry problems of accessibility and authority. Within the HealthCore ecosystem, the $HYGN token acts as an identifier. Every new account that is created on the Hydrogen platform is immediately issued a “digital twin” in the form of an NFT (non-fungible token). That digital twin represents the identity of the patient or medical professional; once issued it becomes permanently tied to the requesting wallet and begins to establish a reputational metric (which later impacts the supply side of the $CRBN token (please refer to the Phase 2-of-4 documentation). The NFT grows and develops as would a profile on social media or an avatar in a game, going through levels of advancement and obtaining social validation. Wallets that do not have the ERC-721 $HYGN are not able to interact with the Hydrogen environment. The more complete an NFT becomes, the more data that is associated with it, the more weight it acquires in global decision making events (a.k.a Governance pressure). In addition to every account having its own according NFT token for accessing information and helping in the governance processes, every account is balanced with an appropriate amount of ERC-20 $HYO tokens. From launch, the $HYO tokens are capped at 500,000,000 tokens. The token acts as a vehicle to capture “credibility” and its fluctuations depending on resource availability as well as governance. The tokens can be consumed immediately for some platform services (primarily establishing trusted communication channels). If not consumed, they can be lent out to other entities (delegated) in return for some micro-financial gain [{to be denoted in $CRBN}]. $HYO token balancing follows a logarithmic distribution model; the more reputation an account has the more $HYO it produces and the more it can hold. However, the more $HYO a wallet has the less and less it produces over time. The supply elasticity is further exacerbated with the introduction of a global state cap variable; there cannot be more than 2,500 tokens in any given balance at any time At some point in the not too distant future, the $HYO token will be considered being made available for open market trading. Moreover, the HealthCore team is exploring the expansion of the $HYGN non-fungible token, leveraging its reputational & identity capabilities to service the greater LifeRhythmLabs ecosystem as a form of Decentralized Identity. HealthCore WhitePaper Version 0.2 10 [Layer 2-of-4] Clearinghouse & Settlements Layer HealthCore WhitePaper Version 0.2 11 Welcome to Carbon, a value transmission layer technology designed to act as the native settlement clearinghouse for the HealthCore medical ecosystem. The first technology of its kind designed to keep all resources native within one ecosystem. Consensus The Carbon layer of the HealthCore ecosystem is where the economic consensus is found. Known as Clearinghouse-Consensus, Carbon employs a novel approach to PoS [called Open-Proof-of-Stake] where weight distribution and selection in the environment is driven by three factors: reputation, availability, and randomness. In order for ecosystem participants to become a consensus node, they must first obtain the satisfactory threshold of “High enough” reputation; at which point they automatically get plugged into a queue to participate in consensus. Once in the queue, the participant node is evaluated across multiple dimensions of availability; The frequency of activity on the platform, the quality of activity on the platform, their willingness to pledge an absolutely minimal amount of their devices computational capabilities (mobile friendly) and a few other metrics that are kept proprietary in order to avoid gaming of the system. Finally, at the core of consensus lies the randomness engine that will dictate the amount of participants and whom those participants are at the start of each verification round. Alongside the introduction to consensus there also exists the expulsion from it; should there be any malicious activity confirmed by a consensus participant, a 3 severity punishment mechanism is engaged. Severity level 1 A temporary removal from consensus and temporary freezing of all associated assets is conducted (Up to 7 days) {reputation is minimally impacted} Severity level 2 A prolonged removal from consensus (up to 180 days), A small [~17%] slashing in token holdings its conducted (slashed tokens are permanently removed from circulation via burn) temporary freezing of remaining associated assets is conducted (Up to 90 days). {reputation is moderately impacted} Severity level 3 A permanent removal from consensus, A coin slashing of up to [~97%] is conducted (slashed tokens are permanently removed from circulation via burn). {reputation is maximally impacted} An option to opt out of consensus participation will be made available, however it will be penalized in the form of reduced incentive rewards. HealthCore WhitePaper Version 0.2 12 Figure 2.1 Simplified Consensus Engine HealthCore WhitePaper Version 0.2 13 Layer Objectives Carbon will be developed and pursued in parallel to other layers of the project. This layer is composed of 4 strategic objectives : 1) → Provide Clearinghouse Parameters 2) → Carbon Generation 3) → Streamline Interoperability 4) → Secured Storage 1) Provide Clearinghouse Parameters Rather than leaving a medical ecosystem susceptible to the uncertainties that are present in Proof-of-Work environments; LifeRhythm Medical Services has chosen to opt for a more deterministic Open-Proof-Of-Stake {[O-PoS]} system (based on the ERC-20 governance $HYO tokens which are distributed initially in phase 1). However, in order for computation to take place on-chain, nodes that are participating do allocate an absolutely minimal amount of their device's resources (as in the case with PoW based consensus mechanisms). Everytime a settlement or transaction takes place on the HealthCore platform, a random segment of participants (random in node count and identity) are selected to act as the Clearinghouse agents for that event to take place. Everytime a user participates in the clearinghouse consensus they are rewarded with newly minted $CRBN tokens, an amount that will be defined at a later date in accordance with the overall system's capacities. If the tokens remain untouched for X amount of time (30 days) they mature into $HYO tokens. ($HYO tokens have a fixed base supply and new tokens can only be created through the Clearinghouse Maturation method). This systematic approach has been defined as the most pragmatic for a healthy & sustainable form of progrssive decentralization to take place. Throughout the first year of operations, the parameters of selection and reputational criteria will be dynamic; once a satisfactory state is identified the ecosystem will participate in the governance process of “locking-in” the HealthCore WhitePaper Version 0.2 14 clearinghouse parameters for a minimum of 6-months; after which new proposals can be submitted for the change in parameters. 2) Carbon Generation The generation of $CRBN coins is at the core of phase-2 plan of action. Generation of the supply can only begin with the presence of a base $HYDRO token holder group defined & @lpha -clearinghouse parameters in place. Initially, the ratelimit of production & supply capacity is left undefined. The platform will decide on the rate in accordance to the following metrics: ● Supply ● Demand ● User Base ● User Activity ● Computational Availability ● Data-Density (Medical Records on Chain) 3) Streamline Interoperability Interaction between the token sets ($CRBN ← $HYGN → $HYO) is predicated on the HealthCore Chain being able to communicate with the Ethereum Chain; this is accentuated beyond EVM compatibility due to the complexities associated with NFT (non-fungible tokens) being cross-chain communicative. Traditional medical record systems are void of blockchain & crypto token structures, however for the importing of records onto the HealthCore platform there will be the need for both forms of technology to communicate & pass data to one another. Whenever data is passed into the HealthCore Chain it will demand $CRBN tokens to be consumed (as a measure against DOS/DDOS of the system). Moreover, within and of itself, Carbon will not have its own separate application, rather it will be integrated into the user facing Hydrogen application. In doing so, the user experience becomes much cleaner and more organized. 4) Secured Storage The Carbon token will have to be stored somewhere & in the nature of public blockchain technology LifeRhythm Medical Services LLC has chosen to give full sovereignty over the $CRBN coin to its direct owners. Thereby making LifeRhythm Medical Services LLC NON-CUSTODIAL {[ however there will be extended custodial solutions offered at some point]}. HealthCore WhitePaper Version 0.2 15 However, in the provision of self sovernged storage comes the overly un-user friendly experience of key management. As a solution, at the beginning 3rd party non-custodial solutions will be integrated into the Application. Additionally, once a native wallet is introduced, its source code will be made publicly available for developers & community members to verify its airtight design and build new solutions. $ C R B N (Token omics) The $CRBN coin will be deployed on & integrated into the native HealthCoreChain blockchain platform; thereby immediately allowing for enterprise clients to connect and participate in the Carbon ecosystem Token Name: Carbon Coin Token Ticker: $CRBN Token Supply: NitroBase + Census Co E -Velocity-Demand Decimal Points: 18 Platform: HealthCoreChain Token Standard: HC-1 Token Function: Accountancy & Settlement Token Class: Utility Name & Standard: $CRBN is defined as a coin rather than a token due to its naturally designed capacity to have other coins/tokens built on it as well as it serving as the exclusive means of accommodating the HealthCoreChain network fees. (HC-1 standard) Function: The $CRBN coin serves 2 distinct functions within the HealthCore environment: Accountancy: whenever we consume food we denominate its impact on the human body in calories; whenever we make a purchase in the United States of America we denominate it in USD; likewise the $CRBN coin is intended to serve as the native denomination of medical service consumption. HealthCore WhitePaper Version 0.2 16 Settlements: guaranteeing finality remains to be one of the most complex components in any financial environment, specifically regarding returns, fraud, costs, finality and time requirements; taking into account that the $CRBN coin will leverage the computational consensus capabilities of the HealthCore Chain, the LifeRhythm Medical Services has identified the optimal parameters for finality in medical services. Supply The Supply of $CRBN is defined though a data-driven supply/demand dynamic, with no lower bound (positive integers only {no-debt system} ) or upper bound. Just as in biologic life that more people on earth means more carbon emission, The production of $CRBN in the HealthCore ecosystem is contingent on the population within the ecosystem and the specific demands of each participant. At a high level $CRBN is introduced into the ecosystem in 2 ways: 1.) Data Record Demands 2.) ClearingHouse Consensus As medical records come into the HealthCore system, the network will emit $CRBN to accommodate the storage and computational bandwidth each record requires. The emission is deposited into a time-locked vault for validation of uploading parties intentions. Once cleared the $CRBN is given to the uploading party, empowering that party to make write requests to the HealthCore Chain Participating in the platform’s consensus entitles the participant to rewards denominated in $CRBN. The supply emission rate is a constantly moving target in the HealthCore ecosystem. Users that have high reputation and activity standards will produce greater amounts of $CRBN while those with lower standards produce less. As of last, no cap has been placed on individual production, however, the possibility of one being imposed at some point in time remains open. HealthCore WhitePaper Version 0.2 17 Figure 2.2 3rd party Settlement Process HealthCore WhitePaper Version 0.2 18 [Layer 3-of-4] Application & Utilities Layer HealthCore WhitePaper Version 0.2 19 Welcome to Nitrogen, the application and utilities layer technology of the HealthCore medical ecosystem. Within this layer all necessary remote medical functionalities of the platform exist. Nitrogen can be thought of as the prompt to the underlying first and second layers; information that is pushed from layer 3 dictates the computational complexity & in turn the costs that fall onto the system. For the first few years of operations, the HealthCore ecosystem will be leveraging industry standard Application Programing Interfaces for the provision of its applications functions. While the team over at LifeRhythm Medical Services LLC does understand that current industry standard API providers are centralized actors, using their services will not expose the overall architecture to any central point of failure. In fact, each application function that is offered will be protected with multi-level backdrops; in the event of an application failure there will be another API that will be taking its place. Staying in line with the HealthCore progressive decentralization method of approach to its platform design; once the entire structure is operational and attains a satisfactory threshold of medical records data and participant count; the Nitrogen layer will be lifted and mirrored onto the HealthCoreChain. Once on the HealthCoreChain the centralized API Nitrogen applications will be shed and reconstructed as {De}centralized applications (otherwise known as Dapps). When in the transitive state of [application → decentralized application] adaptation an enhanced incentive system will be made available. Each {D}application will serve a dual function, front facing service provision & consensus driven incentiviation. Each {D}application will have its own tokenized ecosystem that will be upheld by reputable members of the HealthCore ecosystem. LifeRhythm Medical Services LLC strongly believes that by introducing operational tokenized micro-communities into the greater HealthCore ecosystem, a much more complete end-to-end governance, incentive, and decentralization structure exists. Moreover with native Dapps, the core currencies ($HYO & $CRBN) become more sought after in order to participate, thus creating a reflexive feed of heightened demand vs stable supply. HealthCore WhitePaper Version 0.2 20 ~ Nitro gen Funct ionality Sta ck ~ Whenever inspecting what is required of a digital medical ecosystem from the standpoint of a consumer/patient as well as a medical service provider/professional a plethora of utilities come to mind. However, whenever a platform's user is given far too many options cognitive dissonance might take place; cognitive dissonance is an overwhelming feeling of indecisiveness or decision exhaustion. Knowing that in order to become the world's default medical environment the most important aspect will be the completeness and satisfaction in the users experience. Hence, the application stack in Nitrogen has been defined as follows: Nitrogen is a development & user testing heavy phase, therefore it will be pursued in tandem with other phases of the HealthCore project. HealthCore WhitePaper Version 0.2