AU2020101898A4 - MHOC- Blockchain Technology: Medicine and Healthcare Observation Care using Blockchain Technology - Google Patents

Abstract

Patent Title: MHOC- Blockchain Technology: Medicine and Healthcare Observation Care using Blockchain Technology. ABSTRACT My Invention "MHOC- Blockchain Technology "is a Medicine and Healthcare Observation Care using Blockchain Technology and methods are presented. Healthcare Healthcare Observation, transactions associated with a stakeholder are compiled into a chain of healthcare Observation/ transaction blocks. The chain can be considered a chronicle of person's healthcare path through life. When a Health Observation, Transaction is conducted, the corresponding healthcare parameters (e.g., inputs, outputs, clinical evidence, outcomes, testing value, location immunity, person age, etc.) are sent to one or more validation devices. The devices establish a validity of the Health Observation, transaction and generate a new block via a proof-of-work principle. Once the new block has been calculated it can be appended to the stakeholder's health care blockchain. The invention secure flexible access to the healthcare information resources (HIR) contained within electronic health records (EHR) systems. By managing access permissions with certified self-sovereign identities and distributed ledger techniques, HIR may be secured. The all medical member, Patients and other users may be registered to access a distributed ledger, such as a healthcare blockchain, employed to set patients host and adjudicate permissions to access HIR. Authorized owners and patients with rights to their own HIR may be able to grant fine-grained and conditional access permissions to third parties. Information Transfers and Observation transactions occurring according to these permissions may be logged within smart contracts incorporated in the healthcare blockchain. 32 Prof.(Dr). Hari Om Sharan (Dean Faculty of Engineering and Technology) Dr. Sanjeev Kumar (Associate Professor & Additional HOD) Prof.(Dr.) Pawan Kumar Bharti (Vice Chancellor) Mr. Santosh Gopal Nagpure (Assistant Professor) Dr. Yashpal Singh (Professor) Mr. Bhupendra Kumar (Assistant Professor) Mr. Mukesh Kumar Tripathi Mr. Shivendra shivastava Dr. Soumitra Das (Associate Professor) Prof.(Dr.) Beg Raj Singh (Director) TOTAL NO OF SHEET:04 NO OF FIG: 04 Stakeholder 100 . Ncnce N once .Tx A •Tx 8 Peer 0 Etc. Etc, (co s - Device, ----------a L---- ---- -J Computer, Eta.) 120A 130 Healthcare Teomas * Inputs FG SyAStoms NetwRrkA a Test Results (Irdernet, WAN, LAN, o itn, VPN, Fabrdc. Etc.) * Outputs " Diagnees oEtc. Peer poor 1200 ExpenSystem) Valikity Block ($lock N) 3M Peer •Prev. Bilk mash (Doctor) NM. 120D eTrarzsacllen A: Trans IDA o Trme Stamp o Health careTolkens :0 Valdalor S1gnalure o V aNdtty Talken (Agree. 0 peer Olssipse) (Payer) oEta. 120M •Transaction 8: Trans Or, Peer dasatin Devices 1an FIG. 1: IS A SCHEMATIC OVERVIEW OF A HEALTHCARE TRANSACTION ECOSYSTEM.

Description

Prof.(Dr). Hari Om Sharan (Dean Faculty of Engineering and Technology) Dr. Sanjeev Kumar (Associate Professor & Additional HOD) Prof.(Dr.) Pawan Kumar Bharti (Vice Chancellor) Mr. Santosh Gopal Nagpure (Assistant Professor) Dr. Yashpal Singh (Professor) Mr. Bhupendra Kumar (Assistant Professor) Mr. Mukesh Kumar Tripathi Mr. Shivendra shivastava Dr. Soumitra Das (Associate Professor) Prof.(Dr.) Beg Raj Singh (Director) TOTAL NO OF SHEET:04 NO OF FIG: 04

Stakeholder 100

. Ncnce N once .Tx A •Tx 8 Peer 0 Etc. Etc, (co s - Device, ----------a L---- ---- -J Computer, Eta.) 120A 130

Healthcare Teomas

* Inputs FGSyAStoms NetwRrkA a Test Results (Irdernet, WAN, LAN, o itn, VPN, Fabrdc. Etc.) * Outputs " Diagnees oEtc.

Peer poor 1200 ExpenSystem) Valikity Block ($lock N) 3M Peer •Prev. Bilk mash (Doctor) NM. 120D eTrarzsacllen A: Trans IDA o Trme Stamp o Health careTolkens :0 Valdalor S1gnalure o V aNdtty Talken (Agree. 0 peer Olssipse) (Payer) oEta. 120M •Transaction 8: Trans Or,

Peer dasatin Devices 1an

FIG. 1: IS A SCHEMATIC OVERVIEW OF A HEALTHCARE TRANSACTION ECOSYSTEM.

Australian Government IP Australia Innovation Patent Australia Patent Title: MHOC- Blockchain Technology: Medicine and Healthcare Observation Care using Blockchain Technology.

Name and address of patentees(s):

Prof.(Dr). Hari Om Sharan (Dean Faculty of Engineering and Technology) Address: Rama University, Kanpur, UP-209217, India. E-mail: drsharan.hariom@gmail.com Dr. Sanjeev Kumar (Associate Professor & Additional HOD) Address: Department of Computer Science & Engineering, KIET Group of Institutions, Ghaziabad- 201206, UP, India. Prof.(Dr.) Pawan Kumar Bharti (Vice Chancellor) Address: A-905, Gaur Atulyam Society Omicron-1, Greater Noida, UP-201310, India. E-mail: padutt@gmail.com, vc@svu.edu.in Mr. Santosh Gopal Nagpure (Assistant Professor) (Electronics & Telecommunication Engineering Department) Address: Bhagya Jyot, Sahyadri Colony, Jijamata Chowk, Gurudwara-Walhekarwadi Road, Near Akurdi Railway Station, Chinchwad, Pune-411033, MH, India. E-mail: sgbpune@gmail.com Dr. Yashpal Singh (Professor) (Computer Science & Engineering) Address: Village & Post Office Bhalout, Tehsil and District Rohtak, Haryana, India 124401. E-mail:yashpalsingh009@gmail.com Mr. Bhupendra Kumar (Assistant Professor) (Computer Science & Engineering) Address: A-41, Mahindra Enclave Shastri Nagar Ghaziabad Uttar Pradesh, India 201002. E-mail: bhadana.imt@gmail.com Mr. Mukesh Kumar Tripathi Address: Bhagya Jyot, Sahyadri Colony, Jijamata Chowk, Gurudwara-Walhekarwadi Road, Near Akurdi Railway Station, Chinchwad, Pune-411033, India. E-Mail: phdinvtu@gmail.com Mr. Shivendra shivastava Address: Village Karhansi Post Karhansi Ps Buxar Muffasil Dist. Buxar Bihar-802102, India. E-mail: srivastavashivendra29@gmail.com Dr. Soumitra Das (Associate Professor) Address: Flat No. E-202, Prime Plus Society, Pimple Saudagar, Pune-411027, MH, India. E-mail: soumitra-das@yahoo.com Prof.(Dr.) Beg Raj Singh (Director) Address: Ashoka Institute of Technology and Management, Ashoka Engineering Chauraha, Paharia- Sarnath Road, Paharia Rd, Sarnath, Varanasi, Uttar Pradesh 221007, India. E-mail:begrajsingh2005@yahoo.in Complete Specification: Australian Government

FIELD OF THE INVENTION

My Invention "MHOC- Blockchain Technology" is related to Medicine and Healthcare Observation Care using Blockchain Technology.

BACKGROUND OF THE INVENTION

Healthcare records containing vital information resources may be generated by a variety of entities, such as healthcare providers, pharmacies, patients, and others. These healthcare records, even if in electronic health record (EHR) form, may reside in a variety of locations, and may not be easily accessible to a variety of applications, current stakeholders, and/or other users of those healthcare records. At the same time, different systems for storing healthcare records may utilize their own mechanism for controlling and disbursing the health information resources (HIR) that are stored within their various EHRs. This may cause confusion among patients and other users of the healthcare data, as well as difficulty in accessing the healthcare data itself. In many cases, patients may have little to no control of their EHRs and/or HIRs that pertain to them. In some cases, new applications development that could benefit from accessing and managing HIR data may be effectively restricted within legacy EHR environments.

Additionally, there are regulations and laws directed to the privacy of healthcare data. For example, regulations embodied in the Health Insurance Portability and Accountability Act (HIPAA) of 1996 regulates the extent to which certain kinds of patients' protected health information (PHI) may be shared with third- parties and/or otherwise utilized without the patient's permission. As a result, entities that store healthcare records containing PHI have implemented proprietary mechanisms for compliance to these regulations and for managing them. Accordingly, there are a variety of different systems for managing EHRs, most of which are not easily interoperable with each other.

Furthermore, due to potential liability resulting from non-compliance with PHI handling regulations, practicing health systems (e.g., hospitals) often choose to control the full lifecycle of their EHRs, from birth to destruction of the HIR data within them. Thus, the HIRs, or the presentation thereof, may not be readily customized or otherwise accessible to patient needs or the needs of the users of the data. Further still, caretakers of the healthcare data, such as care providers within healthcare systems, may be burdened with the liability of managing and disbursing healthcare data, in many cases, distracting those entities from their core competencies, such as providing healthcare.

For example, the EMR(s) exist as islands of information with little or no connectivity between the plethora of product offerings. This has been further exacerbated with the usage of Electronic Data Interchange "standards" such as ASC 4010/5010 X12 (further details of which are found at htt : //www. x 12. org/ which is incorporated herein by reference.) Further, the process deepens within the same hospital system and what connectivity has been implemented has been a largely manual effort with significant costs in implementation and maintenance, further exacerbating the situation. This scenario gives way to an Application Programming Interface (API) system that is REST based and that is multi-tenancy. Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers. Each customer is called a tenant. With multi-tenancy, scaling has far fewer infrastructure implications for vendors (depending on the size of the application and the amount of infrastructure required). Further, a multitenant software system is a system that supports any number of customers within a single application instance. Typically, that single instance makes use of a shared data set(s), where a customer's data is properly separated from another's. While data separation is a crucial aspect of a multitenant application, there may be system-wide (e.g. global) computations that require the consumption of all customer data (or some subset thereof). If no such global operations are required, then a multitenant application would instead be a multi-instance application, where each customer's data is contained in its own isolated silo.

The background description includes information that may be useful in understanding the present invention. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art. Cryptocurrencies have risen over the last few years. The most famous cryptocurrency is Bitcoin, launched in 2009, as described in the original paper openly published on May 24, 2009, by Nakamoto and titled "Bitcoin: A Peer-to-Peer Electronic Cash System" (see URL en. bitcoin.it/wiki/Bitcoin-white-paper).

Cryptocurrencies operate on the principle of applying proof-of-work (POW) principles to process Bitcoin transactions that are bound together in large blocks of data. The device that successfully meets the proof-of-work requirements (i.e., generating a double hash value with a required number of leading zero bits) for the transaction block and has their block accepted by peers receives a reward in the form of Bitcoins. Although Bitcoin is probably the most famous application of POW, many others have applied POW to other areas of technology. For example, U.S. Pat. No. 7,356,696 to Jakobsson et al. titled "Proofs of Work and Bread Pudding Protocols", filed Aug. 1, 2000, describes re-using stale computations of a POW to continue minting digital currency.

Another example of using POW further afield from cryptocurrency includes U.S. Pat. No. 7,600,255 to Baugher titled "Preventing Network Denial of Service Attacks Using an Accumulated Proof-of-work Approach", filed Apr. 14, 2004. Baugher requires a computer client to generate a POW to access a service where the POW could include hashing a message until a desired number of leading bit-level zeros is found, similar to the POW of Bitcoin. In a somewhat similar vein to Baugher, U.S. Pat. No. 8,412,952 to Ramzan et al. titled "Systems and Methods for Authenticating Requests from a Client Running Trialware Through a Proof of Work Protocol", filed May 6, 2009, also uses POW to grant access to services. Ramzan describes generating a cryptographic puzzle if no authentication token is included with a service request to run trialware. The client making the request must solve the cryptographic puzzle in order to receive authentication to proceed with running the trialware.

All publications identified herein are incorporated by reference to the same extent as if each individual publication or patent application were specifically and individually indicated to be incorporated by reference. Where a definition or use of a term in an incorporated reference is inconsistent or contrary to the definition of that term provided herein, the definition of that term provided herein applies and the definition of that term in the reference does not apply.

The following description includes information that may be useful in understanding the present invention. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art. The numbers expressing quantities of ingredients, properties such as concentration, reaction conditions, and so forth, used to describe and claim certain embodiments of the invention are to be understood as being modified in some instances by the term "about." Accordingly, in some embodiments, the numerical parameters set forth in the written description and attached claims are approximations that can vary depending upon the desired properties sought to be obtained by a particular embodiment. In some embodiments, the numerical parameters should be construed in light of the number of reported significant digits and by applying ordinary rounding techniques. Notwithstanding that the numerical ranges and parameters setting forth the broad scope of some embodiments of the invention are approximations, the numerical values set forth in the specific examples are reported as precisely as practicable. The numerical values presented in some embodiments of the invention may contain certain errors necessarily resulting from the standard deviation found in their respective testing measurements.

Unless the context dictates the contrary, all ranges set forth herein should be interpreted as being inclusive of their endpoints and open-ended ranges should be interpreted to include only commercially practical values. Similarly, all lists of values should be considered as inclusive of intermediate values unless the context indicates the contrary. As used in the description herein and throughout the claims that follow, the meaning of "a," "an," and "the" includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein, the meaning of "in" includes "in" and "on" unless the context clearly dictates otherwise.

The recitation of ranges of values herein is merely intended to serve as a shorthand method of referring individually to each separate value falling within the range. Unless otherwise indicated herein, each individual value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g. "such as") provided with respect to certain embodiments herein is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention otherwise claimed. No language in the specification should be construed as indicating any non-claimed element essential to the practice of the invention.

Groupings of alternative elements or embodiments of the invention disclosed herein are not to be construed as limitations. Each group member can be referred to and claimed individually or in any combination with other members of the group or other elements found herein. One or more members of a group can be included in, or deleted from, a group for reasons of convenience and/or patentability. When any such inclusion or deletion occurs, the specification is herein deemed to contain the group as modified thus fulfilling the written description of all Markush groups used in the appended claims.

PRIOR ART SEARCH US5835897C11995-06-222002-02-19Symmetry Health Data Systems Computer implemented method for profiling medical claims. US6279041B11998-11-132001-08-21International Business Machines Corporation Methods, systems and computer program products for differencing data communications using a message queue. US20020022973A12000-03-242002-02-21Jianguo Sun Medical information management system and patient interface appliance. US20020038233A12000-06-092002-03-28Dmitry Shubov System and method for matching professional service providers with consumers. JP2002189909A2000-12-222002-07-O5Nec Corp Reservation processing method, method and device for data processing, data communication system, and information storage medium. US20040143446A12001-03-202004-07-22David Lawrence Long term care risk managementclearinghouse. US7734656B21998-02-242010-06-08Luc Bessette System and method for electronically managing medical data files in order to facilitate genetic research. US7356696B12000-08-012008-04-08Lucent Technologies Inc. Proofs of work and bread pudding protocols. US7600255B12004-04-142009-10-06Cisco Technology, Inc. Preventing network denial of service attacks using an accumulated proof-of-work approach. CA2630962A12005-07-272007-02-OlMedecision, Inc. System and method for health care data integration and managemen.t US20090076855A1*2007-09-132009-03-19Mccord Matthew Apparatus, method and system for web-based health care marketplace portal. JP2009140057A2007-12-042009-06-25Fujitsu Ltd Medical care record management system, medical care record management program and medical care record management method. US8412952B12009-05-062013-04-02Symantec Corporation Systems and methods for authenticating requests from a client running trialware through a proof of work protocol.

OBJECTIVES OF THE INVENTION 1. The objective of the invention is to a Medicine and Healthcare Observation Care using Blockchain Technology and methods are presented and also Healthcare Observation, transactions associated with a stakeholder are compiled into a chain of healthcare Observation/ transaction blocks. The chain can be considered a chronicle of person's healthcare path through life. 2. The other objective of the invention is to the Health Observation, Transaction is conducted, the corresponding healthcare parameters (e.g., inputs, outputs, clinical evidence, outcomes, testing value, location immunity, person age, etc.) are sent to one or more validation devices. 3. The other objective of the invention is to establish a validity of the Health Observation, transaction and generate a new block via a proof-of-work principle.

Once the new block has been calculated it can be appended to the stakeholder's health care blockchain. 4. The other objective of the invention is to the invention secure flexible access to the healthcare information resources (HIR) contained within electronic health records (EHR) systems. By managing access permissions with certified self-sovereign identities and distributed ledger techniques, HIR may be secured. 5. The other objective of the invention is to the all medical member, Patients and other users may be registered to access a distributed ledger, such as a healthcare blockchain, employed to set patients host and adjudicate permissions to access HIR. Authorized owners and patients with rights to their own HIR may be able to grant fine-grained and conditional access permissions to third-parties. Information Transfers and Observation transactions occurring according to these permissions may be logged within smart contracts incorporated in the healthcare blockchain. 6. The other objective of the invention is to wherein the CSI is a first CSI, the first CSI corresponding to a first user, the method further comprising: receiving a request to grant a permission to access a health information resource to a second user, the second user having a second CSI; determining, based at least in part on the first CSI, that the first user is authorized to set permissions to access the health information resource; and instructing, a blockchain system, to include a smart contract corresponding to the grant of the permission to the second user to access the health information resource. 7. The other objective of the invention is to wherein the grant of the permission to access the health information resource comprises one or more conditions under which the second user is permitted to access the health record. 8. The other objective of the invention is to wherein the client system is a first client system, and wherein the smart contract comprises instructions to issue an access token to the second user, the access token allowing a second client system corresponding to the second user to receive the health information resource from a resource server.

SUMMARY OF THE INVENTION

The technologies disclosed herein provide functionality for enabling electronic access to protected health information (PHI) according to the wishes of a patient and/or other authorized parties including, but not limited to, the healthcare provider to whom the healthcare data may belong or is otherwise authorized under existing regulation. The patient or provider may designate who (e.g., individuals, entities, applications, etc.) may have permission to access his or her PHI and/or other health information resources (HIRs), and may further place conditional stipulations (e.g., time periods, redactions, locations, number of views, device types, anonymity, etc.) by which a designee may access authorized PHI and/or other HIRs.

According to example embodiments, electronic healthcare records (EHRs) may reside at a resource system of an entity that has generated the healthcare record or has received the healthcare record, such as a hospital's resource system(s) for managing EHRs. These resource systems may be configured to provide PHI and/or other HIRs to an authorized user application according to a predefined standard. An application program interface (API) may reside on a front-end of the resource system to provide this predefined format for granular HIRs to a requesting and authorized user's client system.

According to example embodiments of the disclosure, a user (e.g., patient) may be able, via an application executing on his or her client system, set conditional permissions for his or her HIR. Through a user interface of the application, the user may be able to designate conditional permissions for a particular HIR, or collection of resources such as those typically contained in an existing EHR. These conditional permission(s) may be used to generate a permission grant that may be sent to a distributed ledger, or healthcare blockchain system, to invoke an executable smart contract within a healthcare blockchain. If the user is authorized to cause permissions to be written onto the blockchain' s smart contracts, then the blockchain systems may incorporate (e.g., hash with prior blocks) a new block containing new and/or modified permissions, such as in the form of one or more smart contracts.

Smart contracts contained within the healthcare blockchain may operate using any suitable protocols to adjudicate and/or enable agreements between parties to execute according to those agreements as prescribed, specified, codified, verified, and/or enforced. These same smart contracts may be both self-executing and or self- enforcing. In example embodiments, a smart contract is used to determine whether access to an HIR should be granted to a requesting party. In this case, the smart contract may make this determination based upon, among other factors, the verification of a certified self sovereign identity (CSI) of the requesting party, a CSI of the party owning the information, and permissions previously provided by the owning party.

According to example embodiments of the disclosure, permissions may be expressed within one or more smart contract(s) in the blockchain that designates and/or enables the per missioning of others, such as in a conditional manner, to access the HIR for which the permissions in the blockchain were generated. Once incorporated into the healthcare blockchain, the smart contract(s) may generate and/or send an indication to a client system of a permissioned party that he, she or it may access the HIR for which permissions have been granted. In example embodiments, only the most recent permission states, as incorporated in the healthcare blockchain, may be able to authorize access tokens. As a result, an immutable record of all activity may recorded in the blockchain while preserving near real-time patient control and/or ability to correct any mistakes of information transfer to client and other systems.

Upon receiving an indication that a user (e.g., doctor, pharmacy, insurance company, researcher, etc.) or user application is authorized to access particular HIR, that user application may request HIR for which permissions have been granted, according to example embodiments of the disclosure. In other example embodiments, a user may attempt unprompted access, such as without knowing if he or she already has access to the particular HIR. In either case, the client system of the permissioned user, via an application operating thereon, can cooperate with other entities to arrange the issuance of an access token, using which, the HIR may be obtained. In example embodiments, the access token may be generated by smart contracts, as incorporated in the healthcare blockchain, and representing permissions granted for the particular HIR being requested. In example embodiments, the creation of the access token may be recorded within the healthcare blockchain, thus maintaining an immutable journal of all access token creation and issuance events.

The access token, as received by a client system associated with a permissioned user, may then be sent, by the client system, to a resource system where the PHI resources and other HIR resides. Responsive to receiving the access token, the resource system may provide the requested HIR to the client system of the requesting user. When a client system receives an HIR, the client system may confirm receipt of the transaction brokered by the blockchain. Using the confirmation, the blockchain may maintain a record, such as an immutable record, of transactions of healthcare resources, as well as metadata pertaining to requests, permissions, and access tokens granted, or the like.

A client system may be configured to interact with other systems of the HIR delivery infrastructure to establish certified self-sovereign identification (CSI) key pairs (e.g., unique public, private and symmetric keys operating isochronously on both client and server systems, etc.) for accessing the healthcare blockchain, as well as other systems. In some cases, the access, as allowed by the CSI infrastructure may be pseudonymous. This process may include the client system being directed to one or more value-added certificate authorization system(s) with which the client system, and a user thereon, interacts. The value-added certificate authorization system(s) may request information about a user for whom the CSI is to be established. This information, in some cases, may include his or her current or anticipated healthcare providers' identification. The value added certificate authorization system(s) may receive information about the user and/or his or her current or anticipated health providers' identification from the client system, as enteredby the user thereon.

The value-added certificate authorization system(s) may verify the information about the user from an independent identity authority system. Based at least in part on the comparison of personal identity information supplied from the client system about the user and the corresponding information from and or other collaboration with the independent identity authority system, the value-added certificate authorization system(s) may deem that the user or entity is verified to be who he, she, or it claims to be. If the user is verified, then the value-added certificate authorization system(s) may digitally sign a self-sovereign identity certificate (SIC) of the user to generate the user's certified self-sovereign identity (CSI). The value-added certificate authorization system(s) may then register the CSI's public key. The CSI public key and other CSI certificate information may be registered with and/or hashed as a transaction onto the healthcare blockchain. The CSI key pair may include a private CSI key that may be generated and stored on the client system associated with the user.

The CSI is to be used subsequently by the client system and the user thereon to access HIRs to which the user may be entitled. In some cases, the access to the HIR, using the CSI may be pseudonymous. After the CSI is established, the value- added certificate authorization system(s) may direct the client system to an application download system and/or an application store to download a healthcare application onto the client system.

A client system may be configured to download and install a healthcare application from an application download system that the client device may access directly or be redirected from one or more other entities. The application download system may cooperate with the value-added certificate authorization system(s) to bind the public CSI of the user of the client system to the application that is downloaded and installed on the client system. This process may involve the application download system requesting verification of the user's access to the healthcare blockchain from the blockchain systems. Upon verification of the user's access to the blockchain system, the application download system may request the value-added certificate authorization system(s) to set-up the health care application.

After the CSI establishment process, a process for binding a user, and his or her CSI, to the client system may be commenced. In some example embodiments, this process may involve various biometric and/or other multi-factor identification techniques and may result in the user being bound to the client device, and the user, with his or her CSI, bound to the healthcare blockchain. At this point, granting access to HIRS associated with the CSI of the user may be controlled by smart contracts, such as smart contracts residing on the healthcare blockchain.

The healthcare application may be installed on the client device and bound to the CSI of the user. This may entail storing the CSI key pair, hash thereof, and/or other identifying information about the user in a digital wallet and/or other modules on the client device. Once the CSI is stored and bound to the healthcare application, the healthcare application operating on the client device may interact with the value- added certificate authorization system(s) to establish permissions for healthcare resources for which the user owns rights (e.g., the user's patient data). The permissions may, in some cases, be granulated and/or with conditions and/or stipulations. When permissions are established, a permission command indicating the permissions may be generated and sent to the blockchain systems for incorporation into the appropriate smart contract permission held within the healthcare blockchain. In some example embodiments, the establishment of permissions may be communicated to other entities, such as resource system(s) that have the HIRs for which permissions were established, as well as the value-added certificate authorization system(s), and/or other client systems associated with other users that have been granted permissions to the healthcare records.

In example embodiments, the permissions granted by a patient to access specific HIR may be highly granular, and may allow for conditions and/or stipulations. For example, the permissions may not only indicate who or what is allowed to access particular medical records' resources (e.g., HIRs), but also when those records may be accessed, if any parts must be redacted, if those records are to be anonymized, etc.

According to further example embodiments of the disclosure, the HIR, as provided from the resource system to the client system, may be relatively granular and adhere to a pre designated format. The resource systems, in example embodiments, may have a front-end application programming interface (API) that may be universal and known to application developers, so that different application developers may develop healthcare applications for the client devices that may be able to interface with the resource systems in a pre established manner. This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify all essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.

All of these standards have intended semantics, however they do not follow the standard(s) with respect to the meanings of the data structure(s), thus defeating the purpose of said standards and therefore interoperability. For example, data is embedded in comment fields in an unstructured manner rather than using the prescribed data elements and structure. Healthcare standards formatted in Extensible Markup Language (XML) and XSDs solve the integration or interoperability problem at a syntactic level, but domain specific solutions are required to achieve meaningful integration however the actual interchange, maintainability and scale are sub-optimal. They are also not scalable. JavaScript Object Notation (JSON) has resulted in a better readable standard however the data model and schemas from the standards above are constantly shifting.

Thus, current healthcare enterprise applications need greater flexibility and scalability to meet the challenges of heterogeneity of healthcare systems at all levels - data, process, services, and payments. The architecture of any integration system holds the key to offer a dynamic, flexible and scalable solution. The system and method uses an Agent/Actor model for data processing and observations (further details of which are described at ht p:/7c2.com/cgi/wiki'? Actor Vs Agent which is incorporated herein by reference.) The agent/actor model includes vendors, standards, legacy systems, and information systems all of which must interoperate to provide healthcare services. The system and method provide an interoperability solution without imposing any constraint on existing or proposed health systems. The major advantage of our approach is that it is a hybrid federated and decentralized system that is resilient and autonomous and requires no pre approved or administrative overhead for participating in the HealthCare network. Further it affords payors, providers and consumers the ability to have access to the consumer's data, given the consumer's granted consent, as well as provide the consumer the ability to maintain real time access and control of their personal health record (PHR).

Ideally, EHR/EMRs capture and integrate data on all aspects of care over time, with the data being represented according to relevant data structures and provide in real time the consumer access to the PHR. Currently this is not the case. The system and method and its processing architecture and model of data access will allow accurate data to flow within the system and provide transparent behaviors and access across the system.

Much of the data that is captured in EHR/EMR systems serve administrative purposes, such as monitoring hospital activity and performance, and government or insurance reimbursement. Even simple EHR/EMR systems will typically capture demographic patient information such as age, gender, ethnicity and address, as well as structured information about a given encounter in the form of dates and CPT (Current Procedural Terminology) and ICD (International Classification of Diseases) encoded services and diagnoses (often referred to as billing codes for both inpatient and outpatient). Most often these coding schemas are not automated and are prone to user error as well as double charge processes. This double charge process is often the culprit when processing claims information. Further the double charge in a ledger is also an artifact and error of processes within historical electronic banking systems whereas the ledger does not de duplicate the ledger of record. The system and method provide and use identity management that allows immediate access to the consumers PHR that could integrated with various different health applications, such as for example, Fit-Bit, Jawbone, Apple Health Kit or PayPal. The system and method also provide peer to peer autonomous accurate health information exchange and transactional processing that will allow real time processing as well as immediate access and interoperability. Exemplary ImplementationOverview

Figure 1.0 illustrates a system 100 for decentralized healthcare that has a peer to peer architecture. A functional graph topology describes the semantics required for interaction between respective systems, based on the interaction events within healthcare standards which in our case is various standard data structures such as HL7, SNOW-MED, opener, FFflR and ASC X12 4010/5010 to provide domain based workflows between systems. The peer to peer taxonomy defines the transactional semantics associated with healthcare messages and interactions required to be exchanged for data interoperability between various systems.

Differences in these specifications are resolved by peer to peer data mapping techniques as described below. The adapter framework receives the provenance rules developed at design-time and executed at run-time in an arbitrage fashion. An architecture that defines this model is termed blockchain. Blockchain was first discussed in the paper Bitcoin: A Peer-to-Peer Electronic Cash System by Satoshi Nakamoto (that is described in more detail at ips: //en, bitcoin. it wallet which is incorporated herein by reference. The system has a model of electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party. The system leverages upon the basic concepts which allow a system to utilize the block chain topology in four basic fashions:

All Business Associate Agreement FflPAA compliant information data is updated via the blockchain ledger process Data structures referenced within the block chain are written and updated via a distributed file process Personal Health Record information is stored in the person's 'bitcoin based' wallet architecture Arbitrage or bid/ask mechanics for connections to services that the respective data modules need from an agent based solution.

As shown in Figure 1.0, the system 100 may have one or more applications 102 that need to access a backend system 104 over a communications path 106 wherein the backend system 104 may have one or more health block chain network components 104 A, 104B,, 104N for example and the one or more applications access the one or more health block chain network components. Each application 102 may be executed by a computing device. Each computing device may be a processor based device that is able to connect to and interact with the backend 104 over the communications path 106 using known communications and data protocols and APIs. For example, each computing device may be a smartphone device such as an Apple iPhone or Android operating system based device, a personal computer, a laptop computer, a server computer, a terminal and the like that is able to execute the application 102 and perform the interactions with the health block chain network components.

The specific nature of implementation of the system and method are based upon a networked graph based structure that is input into the "Health Block Chain" distributed process. This networked environment also allows for the basis of exchange models based on exchange theory. The algorithms sub-divides our graph of the distributed network into sub-graphs: those in which a set of sellers are collectively linked to a larger set of buyers (sellers obtain payoffs in a game-theoretic sense close to 1) and buyers receive payoffs near 0; those in which the collective set of sellers is linked to a same size collective set of buyers (each receive a payoff of about ½); and those in which sellers outnumber buyers (sellers receive payoffs near 0 and buyers obtain payoffs close to 1).

With respect to the architecture and data processes, the system updates using an exchange process based on former work by Corominas-Bosch and which processes exchange mechanics link patterns represent the potential transactions, however, the transactions and prices are determined by an auction rather than bargaining. In the case of the general model there are n sellers and m buyers of a homogenous good for which all sellers have reservation value 0 and all buyers have reservation value 1. Each buyer desires only one unit of the good, and each seller can supply only one unit. Is the price dependent only on the relative sizes of n and m, and will all trades take place at the same price? Here buyers (sellers) bargain with a pre-assigned subset of all sellers (buyers); links are non-directed, which means that A is linked to B if and only if B is linked to A. Any buyer may be connected to multiple sellers and vice versa. The network structure is common information, as are all proposals and acceptances. In our case of the reduction to practice our homogenous good is the respective connections, business agreements or service level agreements with respect to accessing said data within the blockchain.

In particular, prices rise simultaneously across all sellers. Buyers drop out when the price exceeds their valuation (as they would in an English or ascending oral auction). As buyers drop out, there emerge sets of sellers for whom the remaining buyers still linked to those sellers is no larger than the set of sellers. Those sellers transact with the buyers still linked to them. The exact matching of whom trades with whom given the link pattern is done carefully to maximize the number of transactions. Those sellers and buyers are cleared from the market, and the prices continue to rise among remaining sellers, and the process repeats itself. When the market price is cleared the agent updates the graph or subgraph and the ledger or ledgers in the blockchain are updated. The main agent based graph process splits the links into sub-graphs allowing faster processing and the payoffs in the network are based on game-theoretic probabilities as follows:

Step la: Identification of two or more sellers who are all linked to the same prospective buyer. Regardless of the buyer's other links within the graph the method eliminates that set of sellers and buyer; the buyer then obtains a payoff or 1 and the sellers receive payoff of 0. Steplb: Of the remaining network repeat step la with buyers and sellers reversed to balance the network.

Step k: Proceed inductively in-k, each time making identifications within the sub graphs of the subsets of at least k sellers are you collectively linked to some set of fewer-than-k buyers or some collection of at least k buyers who linked within the graph to some set of fewer- than-k sellers, k is the max of the network node processes in our case.

End: When the method iterates through and identify all of the subgraphs and remove them the buyers and sellers in the remaining network are such that every subset of sellers and buyers is linked to as many buyers and vice versa where the buyers and sellers in that subnetwork reach agreement and achieve a Nash Equilibrium of M payoff each within the subnetwork. This we believe also results Pareto Optimality.

With respect to our network, it has a very simple process for finding the equilibrium in the market such that the ledger clears and makes the market price in our case:

A buyer purchasing from multiple sellers sees the same price from each of the respective sellers.

The price of given seller is found by computing for each buyer the faction of the buyers total purchases that come from that seller and then summing across buyers.

The price of a given seller is no higher than the seller's degree centrality within the network and no lower than 1/min degree(num-buyers) connected to the seller.

Health care EDI transactions (ASC X12 4010/5010)

Processing health care transactions currently consists of manual agreements covering point-point solutions. These connections take significant effort from technical and administrative personnel to setup and maintain. In this scenario the proposed public blockchain solution can facilitate an automatic smart contract to cover a transaction as well as automatic service-level- agreement based selection of a trading partner to fulfill a request.

An example of a typical workflow for a referral is shown in Figure 4.0. This scenario is fulfilled by several blockchain transactions where the assets of an individual's personal health record (PHR) and an eligibility check and response (XI 2 270/271) are combined with a provider's specially as input to the referral (XI 2 278). Using the Health BlockChain network these transactions can be advertised as transactions with pending inputs. Providers participating in the network can satisfy the pending inputs with appropriate providers (assets) having necessary specialties. Payers, or clearinghouses acting on behalf of a payer under a smart contract, can satisfy pending inputs of necessary eligibility inputs (assets). Once the pending inputs are all satisfied the transactions will be validated and committed to the next block in the permanent blockchain ledger.

Interestingly, the above known proof-of-work (POW) systems have only focused on transaction processing or authentication. It has yet to be appreciated that POW systems could be deployed in other areas. One market that is fraught with issues includes healthcare systems that manage large volumes of electronic medical records (EMR).

Example issues include enforcing privacy, standards compliance, interoperability, data format conversion, ensuring proper treatment applied to a patient, and especially the difficulty maintaining a continuity of treatment records for individuals. As a representative example of the state of the art, consider U.S. Pat. No. 8,615,532 to Bessette titled "System and Method for Electronically Managing Medical Data Files", filed Sep. 12, 2012. Bessette discusses one of myriad possible ways in which medical records can be updated assuming proper authentication.

Even with the countless healthcare management or EMR systems available, the systems lack the ability to properly construct a history of health transaction across various entities. A more ideal system would create of chain of transactions from various entities where each transaction is validated via a POW approach. Such a validation approach ensures that all entities are held responsible for their transactions by peer review while also preserving a record of healthcare transactions. Thus, there remains a need validating healthcare transactions.

The inventive subject matter provides apparatus, systems and methods in which a proof of-work system can be employed to track or validate healthcare transactions. One aspect of the inventive subject matter includes a method of validating healthcare transactions. The disclosed methods can include receiving, by one or more validation devices, a healthcare transaction that includes a set of healthcare tokens that represent healthcare actions taken with respect to a stakeholder. For example, the healthcare tokens might include test results for a patient and a corresponding diagnosis from a doctor. The validation device continues executing the method by obtaining a historical block identifier of the stakeholder's healthcare historical blockchain. The healthcare historical blockchain represents a chronicle of healthcare activities in the form of a substantially linear set of healthcare transactions for the particular stakeholder (e.g., patient, doctor, insurance company, hospital, etc.). The method also includes receiving a validity requirement with respect to the healthcare actions indicating criteria that must be met in order for the system to accept a validation event with respect to the transaction.

The validation device continues to validate the healthcare actions by obtain a digital signature of a validator, perhaps another healthcare provider's public key or an expert system identifier. In addition, the method includes obtaining a validity token indicating the validity of the healthcare actions (e.g., valid action, invalid action, indeterminate, etc.). Once the various pieces of information has been collected, the validation device calculates a validity block based on the transaction and according the validity requirements as a function of the healthcare action parameters: the validity token, historical block identifier, the set of healthcare tokens, and the digital signature. Should the validity requirements be met, the validation device can cause the healthcare historical blockchain to be updated, possibly by appending the validity block to the chain. In some embodiments, proof-of work methods are not necessarily employed. In some embodiments, proof-of-stake methods are used to authenticate a validity block to be appended to a stakeholder's healthcare historical blockchain.

BRIEF DESCRIPTION OF THE DIAGRAM

FIG. 1: is a schematic overview of a healthcare transaction ecosystem.

FIG. 2:is a method of validating a healthcare transaction.

FIG. 3: is a further details of processing carried out by one of the steps of FIG. 2.

FIG. 4: is an example of a computer system (one or more of which may provide the components shown in FIG. 1) that may be used to execute instruction code contained in a computer program product in accordance with an embodiment of the present invention.

DESCRIPTION OF THE INVENTION

The invention description, the terms component, module, device, etc. may refer to any type of logical or functional software elements, circuits, blocks and/or processes that may be implemented in a variety of ways. For example, the functions of various circuits and/or blocks can be combined with one another into any other number of modules. Each module may even be implemented as a software program stored on a tangible memory (e.g., random access memory, read only memory, CD-ROM memory, hard disk drive, etc.) to be read by a central processing unit to implement the functions of the innovations herein. Or, the modules can comprise programming instructions transmitted to a general purpose computer or to processing/graphics hardware via a transmission carrier wave. Also, the modules can be implemented as hardware logic circuitry implementing the functions encompassed by the innovations herein.

Finally, the modules can be implemented using special purpose instructions (SIMD instructions), field programmable logic arrays or any mix thereof which provides the desired level performance and cost. As disclosed herein, features consistent with the disclosure may be implemented via computer-hardware, software and/or firmware. For example, the systems and methods disclosed herein may be embodied in various forms including, for example, a data processor, such as a computer that also includes a database, digital electronic circuitry, firmware, software, or in combinations of them. Further, while some of the disclosed implementations describe specific hardware components, systems and methods consistent with the innovations herein may be implemented with any combination of hardware, software and/or firmware. Moreover, the above-noted features and other aspects and principles of the innovations herein may be implemented in various environments.

Such environments and related applications may be specially constructed for performing the various routines, processes and/or operations according to the invention or they may include a general-purpose computer or computing platform selectively activated or reconfigured by code to provide the necessary functionality. The processes disclosed herein are not inherently related to any particular computer, network, architecture, environment, or other apparatus, and may be implemented by a suitable combination of hardware, software, and/or firmware. For example, various general-purpose machines may be used with programs written in accordance with teachings of the invention, or it may be more convenient to construct a specialized apparatus or system to perform the required methods and techniques.

Aspects of the method and system described herein, such as the logic, may also be implemented as functionality programmed into any of a variety of circuitry, including programmable logic devices ("PLDs"), such as field programmable gate arrays ("FPGAs"), programmable array logic ("PAL") devices, electrically programmable logic and memory devices and standard cell-based devices, as well as application specific integrated circuits. Some other possibilities for implementing aspects include: memory devices, microcontrollers with memory (such as EEPROM), embedded microprocessors, firmware, software, etc. Furthermore, aspects may be embodied in microprocessors having software-based circuit emulation, discrete logic (sequential and combinatorial), custom devices, fuzzy (neural) logic, quantum devices, and hybrids of any of the above device types. The underlying device technologies may be provided in a variety of component types, e.g., metal-oxide semiconductor field-effect transistor ("MOSFET") technologies like complementary metal-oxide semiconductor ("CMOS"), bipolar technologies like emitter coupled logic ("ECL"), polymer technologies (e.g., silicon-conjugated polymer and metal conjugated polymer-metal structures), mixed analog and digital, and so on.

It should also be noted that the various logic and/or functions disclosed herein may be enabled using any number of combinations of hardware, firmware, and/or as data and/or instructions embodied in various machine-readable or computer-readable media, in terms of their behavioral, register transfer, logic component, and/or other characteristics. Computer-readable media in which such formatted data and/or instructions may be embodied include, but are not limited to, non- volatile storage media in various forms (e.g., optical, magnetic or semiconductor storage media) though again does not include transitory media. Unless the context clearly requires otherwise, throughout the description, the words "comprise," "comprising," and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of "including, but not limited to." Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words "herein," "hereunder," 'above," "below," and words of similar import refer to this application as a whole and not to any particular portions of this application. When the word "or" is used in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list and any combination of the items in the list.

Although certain presently preferred implementations of the invention have been specifically described herein, it will be apparent to those skilled in the art to which the invention pertains that variations and modifications of the various implementations shown and described herein may be made without departing from the spirit and scope of the invention. Accordingly, it is intended that the invention be limited only to the extent required by the applicable rules of law.

FIG. 1: presents an overview of healthcare transaction validation system 100 where peers in a healthcare network are configured or programmed to manage healthcare transactions in the form of healthcare historical block chains 130. Each block in the chain includes one or more healthcare transactions that further incorporate validation information representing the validity of the transaction as assessed by peer validation devices 120 (e.g., peers 120A through 120N), collectively referred to as peers 120. In some embodiments, peers 120 operate collectively in a peer-to-peer network. Further the device can exist within a clinical operating system ecosystem; possibly based on the cOST" services offered by Nan health, LLC (see URL nanthealth.com/cos-clinical-operating system).

Stakeholder 110 represents an entity that has a stake in a healthcare management lifecycle. A shown, stakeholder 110 could be a patient. However, stakeholder 110 could represent other types of entities. In some embodiments, stakeholder 110 could be another person, possibly a doctor, a nurse, a technician, a care provider, a guardian, a parent, a broker, or other individual. Further, stakeholder 110 could also include other types of entities including a company, an affiliation, a hospital, an organization, a demographic, a community, or other type of entity of particular interest with respect to the inventive subject matter is that each stakeholder 110 could have associated healthcare historical blockchain (HHBC) 130. HHBC 130 represents a chronicle or ledger (e.g., public ledger, private ledger, protected ledger, etc.) of healthcare transactions for stakeholder 110. With respect to a patient, HHBC 130 might start with an initial block or genesis block created at birth that includes information associated with the patient's birth (e.g., parent information, attending physician, Apgar score, etc.). Each subsequent healthcare transaction for the patient can be combined with HHBC 130 as a new block, possibly until the HHBC becomes terminated at the death of the patient. It should be appreciated that each entity can have its own blockchain in the disclosed ecosystem rather than the complete ecosystem having a single chain covering all transactions as is done with cryptocurrencies.

HHBC 130 could comprise any number of blocks. For a healthy patient, HHBC 130 might only increase in size by one block per year based on annual visits to the doctor. However, when stakeholder 110 comprises a surgeon, the surgeon's HHBC 130 might represent performed surgeries where the surgeon's HHBC might increase in size by several blocks per day. Even further, when stakeholder 110 is a hospital, HHBC 130 could increase by hundreds of blocks per day. Large scale insurance companies might have HHBCs 130 that increase by thousands of blocks per day. Returning to the example shown where a patient interacts with a doctor; the doctor works to understand the circumstances of the patient. Such information can be considered to represent input information related to the healthcare transaction in progress. Based on the information, the doctor preforms one or more actions; possibly including applying treatment, generating a diagnosis, establishing a prognosis, or other types of actions. The actions taken by the doctor can be considered outputs to or outcomes of the healthcare transaction.

The various attributes or properties of the inputs and outputs can be represented by healthcare tokens 132. Healthcare tokens 132 represent the information defining the nature of the healthcare transaction associated within stakeholder 110. In more preferred embodiments, healthcare tokens 132 adhere to a defined, possibly standardized, healthcare namespace. For example, the healthcare namespace might include standardized codes (e.g., ICD 9, ICD 10, CPT, DSM, etc.) that categorize the inputs and outputs. Use of a common healthcare namespace aids in creating a common reference frame or nomenclature among peers 120 as they process or validate the healthcare transactions. Such an approach ensures all peers 120 or stakeholders 110 represent information according to a common language, which ensures that the transactions are processed in a uniform, repeatable, and verifiable manner. More preferred healthcare namespaces include normalized terms, especially in circumstances where conflicting codes might exist (e.g., ICD-9 codes 290-319 for mental disorders versus DSM-IV codes for mental disorder; although some harmonization exists between these two schemes).

Peer 120A, perhaps the doctor's EMR system, can package healthcare tokens 132 for delivery to one or more validation devices; peers 120B through 120M for example. For example, healthcare tokens 132 can be packaged in an XML, JSON, or other formats suitable for exchanging data over network 115. The phrase "tokens" herein is used in the broader sense of parsing data into tokens (useful groupings of data) rather than in the narrow data security context. In other words, healthcare tokens and validity tokens referenced herein are not necessarily hashed or otherwise processed to make the underlying data unrecoverable.

In the example shown, peer 120B obtains healthcare tokens 132 and attempts generate validity block 135 that comprises the healthcare transaction represented by healthcare tokens 132 among other pieces of information. For example, the transaction could include a transaction ID, a time stamp, validator digital signature, or other data. Of especial interest, the transaction validity blocks 135 also incorporates a validity token that represents the validator's perspective on the validity of the interaction between the patient and the doctor. The validity token could include simple information such as "agree" or "disagree". A more complex validity token could include alternative information such as suggestions or recommendations on improving the transaction; perhaps an alternative diagnosis for example.

Peer 120B generates validity block 135 according to validity requirement. It should be appreciated that the other peers can, at the same time, also process the same transaction. The validity requirement can be considered a proof-of-work requirement related to the healthcare transactions. Further, the validity requirement can incorporate other criteria that should be satisfied before the transactions are considered properly processed. Peer 120B builds validity block 135 from one or more transactions as shown. For a single patient visiting a doctor office, validity block 135 will likely have only a single transaction. For a more active stakeholder 110 (e.g., a hospital, etc.), validity block 135 could comprise multiple transactions.

Validity block 135 is processed by combining previous block information (e.g., a hash of a block header) from HHBC130 with additional information, thereby linking validity block 135 with the blockchain. As discussed previously, the additional transaction information can include time stamp, healthcare tokens 132, validator digital signature, and especially the validity token. Peer 120B can re-calculate a value for validity block 135, typically a hash of the validity block's header along with hash information from the transactions, until the resulting value satisfies the validity requirement. For example, in embodiments where validity block 135 is processed via a hash function (e.g., SHA256, Scrypt, etc.), peer 120B can increment a nonce value until a hash is generated having the desired proof-of-work characteristics, perhaps a number of leading zero bits among other factors. Once validity block 135 has been properly calculated and/or validated by the peers, it can be sent to other peers 120 in ecosystem 100 so that validity block 135 will be appended to HHBC130. Thus, validity block135becomes part of the chronicled healthcare history of stakeholder 110. Validity block 135 an be considered accepted as part of the HHBC 130 once other peers 120 pickup and integrate it into their own copies ofthe HHBC130.

FIG. 2: provides a more detailed perspective of method 200 of validating healthcare transactions. Method 200 details the steps of providing validation information with respect to a healthcare transaction represented by healthcare tokens and a validity token among other items. The steps of method 200 are executed by one or more validation devices (e.g., computer clients, computer servers, web servers, mobile devices, clouds service servers, etc.). The validation devices are considered part of healthcare transaction ecosystem. For example, all the devices could be subscribers to a clinical operating system and electronic medical record exchange ecosystem. Although the following steps are described from the perspective of a single validation device, it should be appreciated that multiple devices could be operating together to fulfill the roles or responsibilities described by the steps.

Step 210 includes receiving a healthcare transaction comprising a set of healthcare tokens representative of healthcare actions taken with respect to a healthcare stakeholder. The healthcare tokens can be received over a network, via a web service, through an API call, or other techniques through which data can be exchanged. For example, in a peer-to-peer network, the validation device can receive a broadcast from a peer device where the broadcast comprises serialized healthcare tokens, perhaps in a JSON, XML, or YAML format. The healthcare tokens can represent the inputs or outputs of a healthcare transaction between a stakeholder (e.g., a patient) and another entity (e.g., doctor, insurance company, pharmacy, etc.). Example healthcare tokens could include a test result, a genetic sequence, a diagnosis, a prognosis, a patient identifier, a caregiver identifier, a fee, a payer identifier, or other type of information. More preferred healthcare tokens comprise standardized codes so that all peers can reference healthcare transactions in a uniform manner. Example standardized codes that could be leveraged with the disclosed system include ICD codes, CPT codes, DSM codes, or other known coding standards or those yet to be defined.

Step 220 comprises the validation device obtaining a historical block identifier from a healthcare historical blockchain representative of historical actions taken with respect to the stakeholder. The historical block identifier preferably represents a link to the stakeholder's HHBC. The historical block identifier could comprise a hash value of a previous block header in the HHBC, possibly the last block added to the HHBC. Such an approach is considered advantageous because the hash value incorporates all previously processed blocks, which mitigates the risk of fraud by participants that seek to inject erroneous information to the HHBC. In such cases the block identifier represents a link of continuity across all blocks in the chain.

In view that the validation devices could exist within a peer-to-peer network, a validation device could obtain at least a portion of the HHBC over network as suggested by step 225. Consider a scenario where a new device has subscribed to the ecosystem or is integrated into a COS environment. Part of the process could include downloading relevant HHBCs, subject to permissions or authorizations, from other peers in the ecosystem. Alternatively, the new peer could download the HHBC or portions thereof directly from a central database. In some scenarios, an HHBC might not yet exist. For example, a newly born baby might require creation of a new HHBC, or stakeholders that newly engage with the ecosystem might require creation of a new HHBC. With reference to the birth of a baby, the method could include the step of creating the HHBC (not shown) from the set of healthcare tokens. In such a case, the healthcare tokens could comprise a birth token, where the genesis block from the newly created HHBC depends on the birth token or other information relating to the birth. Additionally, the newly created HHBC could depend on one or more parent tokens in the set of healthcare tokens. The parent tokens might represent identifiers that uniquely identify the parents of the baby (e.g., social security number, GUID, private or public key, etc.). This approach is considered advantageous because it allows for linking one HHBC of a stakeholder to the origin of another HHBC.

Step 230 includes receiving a validity requirement with respect to the healthcare actions. The validity requirement can take on many different forms depending on the nature of the healthcare actions or how difficult the validation is intended to be. The validity requirement could be packaged with the healthcare tokens as discussed previously. Alternatively, the validity requirements could be obtained via a validation pool manager or a central authority service. The validity requirement can provide a proof-of-work difficulty such as requiring a number of leading zero bits in a hash value generated based on the transaction information. Further, the validity requirement can also include factors beyond proof-of-work. For example, the validity requirement could also include two or more factors that depend on a value of a corresponding validity token. In such cases, the validity token could represent an "agreement" with the transaction or a "disagreement" with the transaction, which could then determine the nature of the validity requirement. If the validator "agrees" with the transaction, then the validity requirement might have a low threshold proof-of-work requirement, while a "disagreement" might require a higher threshold proof-of-work requirement. Thus, the disclosed systems could include asymmetric validity requirements depending on the validity tokens. Still further, the validity requirement might also require presence of additional healthcare tokens should the validity token take on different values. Should the validator disagree, the validator might be required to provide recommendations or suggestions on how to alter or correct the healthcare transaction.

The validity requirement can be considered to comprise rules or criteria that must be satisfied before the validation device is considered to have completed its work in processing a block of transactions. In some embodiments, the validity requirements can be described within a package data structure or a protocol packet having a difficulty code. In other embodiments, the validity requirement could include executable code, which can include software instructions (e.g., hash algorithms, analysis techniques, expert system rules, etc.) or algorithms that should be applied to the healthcare transactions. Step 240 continues by obtaining a digital signature of a validator. The validator can be considered the entity that processes the healthcare tokens to determine if the healthcare transaction should be perceived as being valid or invalid. The digital signature represents a code indicative of the identity of the validator. Although the digital signature could be secured to protect the identity of the validator, there is no requirement that the digital signature be secured. Example digital signatures could include a public key, a private key, an address of the validator peer (e.g., hash-based address, a transaction address, IPv4 address, IPv6 address, GUID, UUID, etc.), or other type of information that identifies the validator. More preferred validator digital signatures exist within a common signature space; peer network addresses for example.

The validator could comprise a human observer or mechanical turk worker that reviews the content of the healthcare tokens. In other embodiments, the validator could comprise an expert system employing one or more rules sets by which the healthcare tokens should be processed. The expert system executing on one peer validation device can be separately or independently programmed from other peers in the network. Such an approach is considered useful because it is expected that a large number of peers will be able process the healthcare tokens from many different perspectives according to their individual rules. For example, the ecosystem could employ one or more kernel functions by which the expert systems evaluate the healthcare tokens for validity. The kernel functions can be distributed across the peers and separately evaluated. Alternatively, the expert systems could employ trained machine learning algorithms (e.g., neural networks, support vector machines, etc.) that have been trained on separate or disparate data sets. This is considered advantageous because it ensures the peers have different, learned perspectives on the subject matter, which mitigates the risk of all peers possibly generating false negatives or false positive results if they are trained exactly on the same data.

Step 250 includes the validation device obtaining a validity token indicative of the validity of the healthcare actions and based on the set of healthcare tokens. The validity token could be obtained as a code from a validity analysis routine where the code could take on binary value (e.g., valid-invalid; agree-disagree, 0-1, etc.), or could take on a range of values. For example, if an expert system is operating as a validator, the validity token could be a score between -1.0 (invalid) and 1.0 (valid), for example, indicating a confidence score with respect to the validity decision; the confidence score could also be between 0 and 10 as another example. In other embodiments, the validity token can be obtained via validator interface. Step 255 suggests the method could further include presenting the validator interface via mobile device where the interface accepts a user selected validity token.

As an example, consider a scenario where a hospital has subscribed to the disclosed ecosystem. Each subject matter expert (e.g., surgeons, pediatricians, gastroenterologists, oncologists, etc.) could be provisioned with a tablet computer configured to operate as the validation device or as the validator interface. As healthcare transactions are taking place within the hospital, the corresponding healthcare tokens can be routed to the appropriate subject matter experts. The tablet displays the necessary healthcare tokens or healthcare transaction information and requests input from the subject matter expert with respect to the validity of the transaction. The tablet could present a list of validity options to the expert who then selects one or more of the options.

Upon establishing one or more validity tokens representing the opinion of the healthcare transaction, the method continues at step 260 by calculating or otherwise generating a validity block for one or more healthcare transactions according to the validity requirement and as a function of the validity token, historical block identifier, the set of healthcare tokens, the digital signature, or other parameters relevant to the healthcare transactions. Calculating the validity block is considering to comprises generation of a value that depends on the history of the HHBC as well as the current transactions being processed. More specifically, the generated value also depends on the validity token.

For example, the function could be a hash function (e.g., SHA, Scrypt, MD5, RIPEMD, WHIRLPOOL, etc.) applied to the concatenation of the various pieces of information in the healthcare transactions, which is then hashed with the validity block's header information. It should be appreciated that step 260 could be iteratively applied until the validity block takes on characteristics that satisfy the validity requirements. For example, in the cases of applying a hash to the healthcare parameters, the hash can also be applied to a nonce and a time-stamp preferably bound within the validity block's header. If the resulting value fails to satisfy the validity requirements, the nonce can be incremented or the time-stamp could be updated and step 260 can be repeated based on the new value.

The resulting validity block comprises more than just the resulting hash value. It also includes the various information elements that gave rise to the hash value. Thus, the validity block represents a chronicle or ledger of the healthcare transactions. Such an approach is advantageous as it ensures the validity block retains a link to other blocks in the HHBC as well as provides a searchable or analyzable data object. Additionally, by providing the information other peers in the network, the peer can validate the proof-of work.

FIG. 3 is a flow diagram showing processing steps carried out, in one embodiment, by step 260 of FIG. 2. As will be described further, the disclosed process allows the flexibility to generate validity blocks including one transaction per block or including multiple transactions per block. This flexibility recognizes that, in the healthcare context, in some instances, it might be useful and efficient to process multiple transactions for a single validity block, whereas in other contexts, it might be more useful to process a single transaction. As one example, a patient visit might generate multiple transactions for that patient or might only generate a single transaction for that patient.

In the former case, processing all transactions together can be efficient and also provide a basis for linking multiple transactions for a patient to a single visit, thereby providing visit information without necessarily requiring a separate "visit" field in a data structure stored in the HHBC. In the latter case, especially if the patient is not expected to generate additional transactions for a significant time period, it might be useful to process validation of the single transaction and generate a validity block to be added to the HHBC for that patient without waiting for additional transactions to accrue. In another example, as previously mentioned, a doctor or other healthcare provider might be associated with many transactions per day and, therefore, it might be more efficient to generate a validity block each day including multiple transactions to be added to that stakeholder's HHBC.

Referring now in detail to FIG. 3, step 301 assembles a candidate validity block including a nonce and the following healthcare parameters: a historical block identifier, one or more healthcare tokens, one or more validity tokens (generated based on a validator reviewing the healthcare tokens), and one or more digital signatures associated with a validator generating the validity tokens. Step 302 applies a first hash to the candidate validity block. Step 303 determines whether the process should only use one hash.

If no, then step 306 applies at least a second hash to the result of the first hash before proceeding to step 304. Step 306 allows the method to, if desired, increase the processing required to achieve proof-of-work. If the result of 304 is yes, then the method proceeds directly to step 304. Step 304 determines whether the result of step 302 (if only one hash applied) or step 306 (if multiple hashes applied) has met the validity requirement. One example of a typical proof-of-work validity requirement in this context is that the hash result has a certain number of leading zeros. However, many variations are possible. If the result of step 304 is no, then step 305 increments the nonce in the current candidate validity block and processing returns to step 302 to recalculate a hash using the new nonce value.

If the result of step 304 is yes, then step 307 determines whether multiple transactions will be added to a single validity block. If the result of step 307 is no, then step 308 sets the current validity block as the validity block provided for step 270 of FIG. 2. If the result of step 307 is yes, then step 309 adds the current validity block to a multi-transaction validity block and step 310 determines whether there are more transactions to process for the multi-transaction validity block. If yes, then the method returns to step 301 to process another transaction. If the result of step 310 is no, then step 311 sets the current multi-transaction validity block as the validity block to be used by step 270 of FIG. 2.

A multi-transaction validity block could be constructed in a variety of ways. In the illustrated example, one or more hash functions are applied to the data for each transaction individually to meet the proof-of-work or other proof requirement (e.g., identifying a nonce that yields the required result), and then multiple validity blocks are concatenated together to form a multiple transaction validity block prior to broadcasting the validity block to peers on the network. However, in another example, multiple proposed validity blocks could be concatenated together prior to applying the hash function. In this scenario, the proof-of-work is carried out for multiple transactions together.

Other scenarios are possible. For example, the hashes of each transaction be can concatenated together to arrive at the final hash value for the transactions which can then be concatenated with the information from the validity block header to arrive at the final hash value. It is not required to repeatedly recalculate hashes of all transactions in such cases. Rather the transactions can be organized according to a Merkle tree, which reduces how often hashes of the transactions in the tree require recalculation.

Returning to FIG. 2, the method continues at step 270 by the validation device causing the HHBC to be updated with the validity block. For example, the newly completed validity block can be appended to the chain in time stamp order. In peer-to-peer environments, the validation device could broadcast the validity block to peers in the validity network as suggested by step 273. Each of the peers can then append the validity block to a locally stored version of the HHBC. Should multiple peers generate completed validity block for the transactions, then the validity blocks forming the longest chain could be adopted as the foundation for future calculations and could represent confirmation of the block.

In view that each of the peers is performing work to render a validity opinion on a transaction, it is possible for the peer to receive compensation for the work. Step 275 could include the validation device receiving a digital redeemable token in exchange for integration of the validity block as part of the HHBC. The digital token could be virtual currency (e.g., a digital coin, Bit Coin, Lite coin, Peer coin, Doge coin, a propriety healthcare coin, etc.), a fiat currency, a coupon, an increase in accreditation score, or even an exchanged service. The disclosed system and methods describe an HHBC for each entity where the HHBC can include information regarding an opinion regarding validity of such transactions. The disclosed systems can also leverage additional features or capabilities that enhance the value of the techniques.

FIGS. 1-3: a validator reviews the health care transactions to confirm that the data makes sense, issues a corresponding validity token, and then a peer in the network puts forth processing effort to validate the blocks via proof-of-work or other proof, and circulates a validity block for the transaction, the validity block being for appending to the HHBC of a corresponding stakeholder. However, as previously discussed, other types of proof-of work can be used, or, instead of using proof-of-work, proof-of-stake or other methods could be used for arriving at an appropriate validity block. In cryptocurrencies, proof-of stake represents currency that is put up as collateral when mining or validating blocks for coins. In the healthcare context, the proof of stake could include evidence of insurance, a monetary cost, an accreditation score, or other value that is indicative of value to the validator. This approach is considered advantageous on the ground that proof of stake requires less computing resources than proof of work.

Still other types of proof that could be leveraged with the disclosed subject matter include proof of trust where others indicate the perceived value of the validators opinion; or proof of evidence where the validator provide evidence on how often they are right with their validation or how often they conform to other validator's opinions. In one alternative, a trusted peer or central authenticator computer can simply confirm that the digital signature or digital signatures associated with the validity tokens belongs to a trusted reviewer, assemble an appropriate validity block, and circulate for appending to the appropriate HHBC. In another example, an entity demonstrates a stake in the transaction, through payment or otherwise, and then generates validity blocks accordingly, perhaps including an appropriate digital signature of the entity generating the validity block.

The HHBC essentially represents a healthcare path taken by a patient through their entire life. Each block in the chain can be reviewed, possibly via a browser, to analyze the path taken by the patient. Each patient can be analyzed individually or collectively for longitudinal studies. Such approaches would be of high value with respect to patients that have been prescribed similar, if not the same, drugs. The healthcare transactions after the prescription is fulfilled can be analyzed to establish correlations of healthcare outcomes across patient populations.

The disclosed approach could be considered semi-secure in the sense that private information can be encoded within various keys. Still, explicit security can be applied to further secure the HHBC by encrypting the HHBC. Once a peer has established its identity, it can be granted a key to decrypt the HHBC information as needed. The HHBCs are dynamic, living objects that evolve over time by adding validity blocks in response to healthcare interactions. In some embodiments, the nature of the evolution of the HHBC can be analyzed to derive one or more trends. For example, the rate of change in the HHBC (e.g., transactions per month) could be a leading indicator of health issues. Further, such information could be correlated with external factors (e.g., environmental conditions, etc.) across stakeholder populations.

Although the disclosed approach relates to healthcare, it should be appreciated that the techniques can also be adapted for other markets beyond healthcare. Such an approach is useful to ensure that those providing service do not take advantage of the stakeholders. Example markets that could leverage such validity information would include the mortgage industry to reduce predatory loans, automotive repairs to reduce unjustified repairs, employee evaluations to ensure those in power are accountable for decisions, credit card expenditures, financial transactions, or other markets.

Yet another interesting aspect of the disclosed subject matter is that each validity block in the blockchain includes data representing each healthcare transaction, which could be read by a browser as discussed above. Such healthcare data can take on a broad spectrum of information beyond the time stamps or tokens discussed previously. In addition, each transaction can comprise pointers to EMRs or genomic data that were used within respect to the transactions. The pointers could include human readable pointers, perhaps a file names, file handles, URLs, URIs, or other type of text-based address. In some scenarios, the pointers could comprise document object identifiers (DOIs; see URL www.doi.org), which point to documents. More preferred pointers represent pointers to permanent references that index to supporting evidence, documents, EMRs, or other types of documents throughout time.

The pointers reference an indexing system, which then resolves the pointer address to the actual location for such documents. The advantage of such an approach is that the documents can be moved from one storage location to another has large amounts of time passes. Through inclusion of document pointers, the HHBC is able to link with EMR systems without requiring supporting a specific or proprietary EMR implementation. The pointers could be a priori encrypted according to the stakeholder's key to further secure the information. Should a current or future analyst need access to such documents, they can request authorization from a central authority or from the stakeholder. Thus, the inventive subject matter is considered to include a HHBC Name Service (HNS) that can resolve HHBC pointers or address to specific network locations. This approach is considered advantageous because it allows for indirect referencing of information from one block or blockchain to another regardless of where the actual data is stored. In distributed systems implemented on torrent protocols, the pointers or addresses of a block could conform to the same address space as used by the computers storing the data.

It should be appreciated that the disclosed approaches allow for analysis of transactions related to clinical or evidence content in an agnostic manner. In view that transactions in the HHBC have document pointers that leverage standardized addresses, there is no requirement that the validation devices understand the formats used to store the clinical data or evidence data. Still, in some embodiments, the validation devices can be configured with application-specific agents or adapters that are able to incorporate the clinical or evidence data in to validity or transaction processing according to the data's respective formats if desired. For example, the validator could request access to supporting clinical or evidence data. Once authorized, the validation device can obtain the requested data and use a local adapter to convert, if necessary, the data from its format to a presentation format (e.g., HTML5, Flash, etc.) that is consumable by the validator (e.g., a doctor, a nurse, etc.).

The validity token can also take on interesting aspects with respect to the inventive subject matter. The examples presented above assume that a peer is operating as a validator of one or more healthcare transaction. It is also possible for the peer to operate as a transaction processing device that obtains the validity token from other validators. Reference back to FIG. 1, peer 120B might process the healthcare transaction from peer 120A while also receiving a corresponding validity token from peer 120D. Peer 120D generates the validity token after receiving the necessary healthcare tokens or references to supporting clinical evidence to render the validity opinion. Such an approach is considered as advantageous because multiple entities, possibly non-affiliated entities, participate in the processing of the healthcare transactions, which further mitigates the risk of fraud.

The disclosed technology could include embodiments that comprise one or more automated veto schemes that operate according to various modes. In some embodiments, the validation device could veto the current healthcare transaction, which would force the healthcare transaction participants to re-evaluate an in-process transaction. Such an approach is useful to pre-adjudicate insurance claims associated with the healthcare transaction. In other embodiments, once the validation device completes its construction of the validity block and submits the block to the peers, the peers could then attempt to verify the validity block from a processing perspective or from a validity perspective. If sufficient peers fail to verify the validity block, perhaps based a vote, the validity block can be vetoed. This approach provides for further peer review and enforcement of treatment care standards.

The disclosed techniques centered on the HHBC also give rise to interesting capabilities with respect to the Internet-of-Things (IOT). Clinical evidences generated from devices or services can be routed to preferred medical data custodians, which can permit access to the data upon proper authentication or authorization. Transactions within the HHBC blocks can then reference such clinical data via corresponding pointers referencing the designated medical data custodian site(s). This approach allows the HHBCs to reference data generated across the broad healthcare lifecycle care including data from the IOT (e.g., sensors, personal area networks, ambient data, etc.), primary care stakeholders (e.g., PCP, etc.), second care stakeholders (e.g., specialists, etc.), tertiary care stakeholders (e.g., hospitals, insurance companies, etc.), quaternary care stakeholders (e.g., post hospitalization, hospice, etc.) no matter the model of care. The models of care (e.g., self care, retail care, remote care, etc.) are therefore able to drive evidence-based data to the medical data custodians while providing access to the data for analysis through HHBCs.

The behavior analytics information as evidenced by HHBC information can be supplied to various market places (e.g., Amazon, Google, etc.). The market places would leverage such personal or demographic information to enable service providers to deliver highly targeted healthcare content to consumers, subject to privacy constraints. For example, medical data custodians can generate one or more healthcare campaigns that are triggered based on features of HHBCs or corresponding behavior metrics. When a consumer interacts with the market places (e.g., purchases products, searches for services, etc.), campaigns can be delivered to the consumer where the campaigns. Such campaigns can be constructed to have attributes or parameters having values that satisfy matching criteria with respect to the consumer's behaviors or their known healthcare transactions as well with respect to the nature of the consumer's interactions with the market place (e.g., non-healthcare related activities, personal preferences, intents, personas, etc.).

The medical data custodians can also use HHBCs as a foundation for offering for-fee data services. The custodians can offer access to the HHBCs in a secure, confidential fashion to one or more analyst entities (e.g., researchers, insurance companies, hospitals, etc.). For example, an insurance company could pay for access to a collection of HHBCs filtered based on demographics, location, time, or other factors. The insurance company could then apply actuarial algorithms to build risk tables. For such an analysis, the insurance company does not necessarily require patient identification or other private information. Rather, such an analysis could only use sanitized data.

The custodians can charge entities for accessing the HHBCs based on many factors, possibly including number of HHBCs accessed, granularity of transactions information, nature of the data, length of time accessed, or other aspects. As an example, consider a scenario where a pharmaceutical company wishes to conduct a longitudinal study on one of their products in the field. The company can purchase rights to access all HHBCs that having transactions that include references to their products as well as a control group having HHBCs of a similar nature but lacking references to the company's products.

The data custodian can grant access to the HHBCs in exchange for a fee while also restricting access private information (e.g., patient names, addresses, phone numbers, etc.) thereby allowing the pharmaceutical company to conduct their desired analysis. Perhaps, the company can filter the HHBCs into demographic groups or age ranges, and attempt to establish correlations between point of prescription and outcomes. The medical data custodian could charge the company based on the level of access according to one or more fee schedules. In some embodiments, the company might be a peer in the HHBC ecosystem and might have copies of the HHBCs. However, they might not be authorized for reviewing the data. In such a case, the medical data custodian could charge the company for a temporary key that unlocks the data within the HHBCs.

FIG. 4 shows an example of a computer system 4000 (one or more of which may provide the components of FIG. 1) that may be used to execute instruction code contained in a computer program product 4060 in accordance with an embodiment of the present invention. Computer program product 4060 comprises executable code in an electronically readable medium that may instruct one or more computers such as computer system 4000 to perform processing that accomplishes the exemplary method steps performed by the embodiments referenced herein. The electronically readable medium may be any non-transitory medium that stores information electronically and may be accessed locally or remotely, for example via a network connection.

The medium may include a plurality of geographically dispersed media each configured to store different parts of the executable code at different locations and/or at different times. The executable instruction code in an electronically readable medium directs the illustrated computer system 4000 to carry out various exemplary tasks described herein. The executable code for directing the carrying out of tasks described herein would be typically realized in software. However, it will be appreciated by those skilled in the art, that computers or other electronic devices might utilize code realized in hardware to perform many or all of the identified tasks without departing from the present invention. Those skilled in the art will understand that many variations on executable code may be found that implement exemplary methods within the spirit and the scope of the present invention.

The code or a copy of the code contained in computer program product 4060 may reside in one or more storage persistent media (not separately shown) communicatively coupled to system 4000 for loading and storage in persistent storage device 4070 and/or memory 4010 for execution by processor 4020. Computer system 4000 also includes I/0 subsystem 4030 and peripheral devices 4040. I/O subsystem 4030, peripheral devices 4040, processor 4020, memory 4010, and persistent storage device 4060 are coupled via bus 4050. Like persistent storage device 4070 and any other persistent storage that might contain computer program product 4060, memory 4010 is a non transitory media (even if implemented as a typical volatile computer memory device). Moreover, those skilled in the art will appreciate that in addition to storing computer program product 4060 for carrying out processing described herein, memory 4010 and/or persistent storage device 4060 may be configured to store the various data elements referenced and illustrated herein.

Those skilled in the art will appreciate computer system 4000 illustrates just one example of a system in which a computer program product in accordance with an embodiment of the present invention may be implemented. To cite but one example of an alternative embodiment, execution of instructions contained in a computer program product in accordance with an embodiment of the present invention may be distributed over multiple computers, such as, for example, over the computers of a distributed computing network.

It should be apparent to those skilled in the art that many more modifications besides those already described are possible without departing from the inventive concepts herein. The inventive subject matter, therefore, is not to be restricted except in the spirit of the appended claims. Moreover, in interpreting both the specification and the claims, all terms should be interpreted in the broadest possible manner consistent with the context. In particular, the terms "comprises" and "comprising" should be interpreted as referring to elements, components, or steps in a non-exclusive manner, indicating that the referenced elements,

WE CLAIMS 1. My Invention "MHOC- Blockchain Technology "is a Medicine and Healthcare Observation Care using Blockchain Technology and methods are presented. Healthcare Healthcare Observation, transactions associated with a stakeholder are compiled into a chain of healthcare Observation/ transaction blocks. The chain can be considered a chronicle of person's healthcare path through life. When a Health Observation, Transaction is conducted, the corresponding healthcare parameters (e.g., inputs, outputs, clinical evidence, outcomes, testing value, location immunity, person age, etc.) are sent to one or more validation devices. The devices establish a validity of the Health Observation, transaction and generate a new block via a proof-of-work principle. Once the new block has been calculated it can be appended to the stakeholder's health care blockchain. The invention secure flexible access to the healthcare information resources (HIR) contained within electronic health records (EHR) systems. By managing access permissions with certified self-sovereign identities and distributed ledger techniques, HIR may be secured. 2. According to claims# the invention is to a Medicine and Healthcare Observation Care using Blockchain Technology and methods are presented and also Healthcare Observation, transactions associated with a stakeholder are compiled into a chain of healthcare Observation/ transaction blocks. The chain can be considered a chronicle of person's healthcare path through life. 3. According to claim,2# the invention is to the Health Observation, Transaction is conducted, the corresponding healthcare parameters (e.g., inputs, outputs, clinical evidence, outcomes, testing value, location immunity, person age, etc.) are sent to one or more validation devices. 4. According to claim,2# the invention is establishing a validity of the Health Observation, transaction and generate a new block via a proof-of-work principle. Once the new block has been calculated it can be appended to the stakeholder's health care blockchain. 5. According to claim1,2,3# the invention is to he invention secure flexible access to the healthcare information resources (HIR) contained within electronic health records (EHR) systems. By managing access permissions with certified self sovereign identities and distributed ledger techniques, HIR may be secured. 6. According to claim,2,4# the invention is to The all medical member, Patients and other users may be registered to access a distributed ledger, such as a healthcare blockchain, employed to set patients host and adjudicate permissions to access HIR. Authorized owners and patients with rights to their own HIR may be able to grant fine-grained and conditional access permissions to third-parties. Information Transfers and Observation transactions occurring according to these permissions may be logged within smart contracts incorporated in the healthcare blockchain. 7. According to claim,2,4# the invention is to wherein the CSI is a first CSI, the first CSI corresponding to a first user, the method further comprising: receiving a request to grant a permission to access a health information resource to a second user, the second user having a second CSI; determining, based at least in part on the first CSI, that the first user is authorized to set permissions to access the health information resource; and instructing, a blockchain system, to include a smart contract corresponding to the grant of the permission to the second user to access the health information resource. 8. According to claim,2,4# the invention is to wherein the grant of the permission to access the health information resource comprises one or more conditions under which the second user is permitted to access the health record. 9. According to claim,2,3# the invention is to wherein the client system is a first client system, and wherein the smart contract comprises instructions to issue an access token to the second user, the access token allowing a second client system corresponding to the second user to receive the health information resource from a resource server.

Date: 19/8/2020 Prof.(Dr). Hari Om Sharan (Dean Faculty of Engineering and Technology)

Dr. Sanjeev Kumar (Associate Professor & Additional HOD)

Prof.(Dr.) Pawan Kumar Bharti (Vice Chancellor)

Mr. Santosh Gopal Nagpure (Assistant Professor)

Dr. Yashpal Singh (Professor) (Computer Science & Engineering)

Mr. Bhupendra Kumar (Assistant Professor) (Computer Science & Engineering)

Mr. Mukesh Kumar Tripathi

Mr. Shivendra shivastava

Dr. Soumitra Das (Associate Professor)

Prof.(Dr.) Beg Raj Singh (Director)

FOR Prof.(Dr). Hari Om Sharan (Dean Faculty of Engineering and Technology) Dr. Sanjeev Kumar (Associate Professor & Additional HOD) Prof.(Dr.) Pawan Kumar Bharti (Vice Chancellor) Mr. Santosh Gopal Nagpure (Assistant Professor) Dr. Yashpal Singh (Professor) Mr. Bhupendra Kumar (Assistant Professor) 19 Aug 2020

Mr. Mukesh Kumar Tripathi Mr. Shivendra shivastava Dr. Soumitra Das (Associate Professor) Prof.(Dr.) Beg Raj Singh (Director) TOTAL NO OF SHEET:04 NO OF FIG: 04 2020101898

FIG. 1: IS A SCHEMATIC OVERVIEW OF A HEALTHCARE TRANSACTION ECOSYSTEM.

FOR Prof.(Dr). Hari Om Sharan (Dean Faculty of Engineering and Technology) Dr. Sanjeev Kumar (Associate Professor & Additional HOD) Prof.(Dr.) Pawan Kumar Bharti (Vice Chancellor) Mr. Santosh Gopal Nagpure (Assistant Professor) Dr. Yashpal Singh (Professor) Mr. Bhupendra Kumar (Assistant Professor) 19 Aug 2020

Mr. Mukesh Kumar Tripathi Mr. Shivendra shivastava Dr. Soumitra Das (Associate Professor) Prof.(Dr.) Beg Raj Singh (Director) TOTAL NO OF SHEET:04 NO OF FIG: 04 2020101898

FIG. 2:IS A METHOD OF VALIDATING A HEALTHCARE TRANSACTION.

FOR Prof.(Dr). Hari Om Sharan (Dean Faculty of Engineering and Technology) Dr. Sanjeev Kumar (Associate Professor & Additional HOD) Prof.(Dr.) Pawan Kumar Bharti (Vice Chancellor) Mr. Santosh Gopal Nagpure (Assistant Professor) Dr. Yashpal Singh (Professor) Mr. Bhupendra Kumar (Assistant Professor) 19 Aug 2020

Mr. Mukesh Kumar Tripathi Mr. Shivendra shivastava Dr. Soumitra Das (Associate Professor) Prof.(Dr.) Beg Raj Singh (Director) TOTAL NO OF SHEET:04 NO OF FIG: 04 2020101898

FIG. 3: IS A FURTHER DETAILS OF PROCESSING CARRIED OUT BY ONE OF THE STEPS OF FIG. 2.

FOR Prof.(Dr). Hari Om Sharan (Dean Faculty of Engineering and Technology) Dr. Sanjeev Kumar (Associate Professor & Additional HOD) Prof.(Dr.) Pawan Kumar Bharti (Vice Chancellor) Mr. Santosh Gopal Nagpure (Assistant Professor) Dr. Yashpal Singh (Professor) Mr. Bhupendra Kumar (Assistant Professor) 19 Aug 2020

Mr. Mukesh Kumar Tripathi Mr. Shivendra shivastava Dr. Soumitra Das (Associate Professor) Prof.(Dr.) Beg Raj Singh (Director) TOTAL NO OF SHEET:04 NO OF FIG: 04 2020101898

FIG. 4: IS AN EXAMPLE OF A COMPUTER SYSTEM (ONE OR MORE OF WHICH MAY PROVIDE THE COMPONENTS SHOWN IN FIG. 1) THAT MAY BE USED TO EXECUTE INSTRUCTION CODE CONTAINED IN A COMPUTER PROGRAM PRODUCT IN ACCORDANCE WITH AN EMBODIMENT OF THE PRESENT INVENTION.