AU2020102115A4 - MCHO- Blockchain Technology: MEDICINE, CLINICAL TEST AND HEALTHCARE OBSERVATION USING BLOCKCHAIN TECHNOLOGY - Google Patents

Abstract

Our Invention "MCHO- Blockchain Technology "is a system and technology for matching and mapping patients with clinical trials and previous data set record under block-chain process to prequalifying patients for clinical trials and previous data set record and providing information to patients to allow them to inform themselves about available clinical trials and previous data set record. The method and technology sequential comprises receiving patient old and new profile information for a patient at a data base and local server connected to a computer network with defined IP- address and ID- no, the patient profile information fetch by using block chain technology and submitted by a user at a terminal connected to the network, comparing the patient profile information with acceptance criteria for clinical trials stored in a database. The invented technology comparison performed by the local and global server, determining whether the patient prequalifies for any of the clinical trials, and notifying the user and the previous data set record whether the patient has prequalified for any clinical trials. The invented medical system includes a network one or more medical data collection appliances coupled to the network each appliance transmitting data conforming to an interoperable format and a local and global server coupled to the network to store data for each individual in accordance with the interoperable format and also format as per required data can change. The invented system and technology for a decentralized autonomous healthcare economy platform are provided and also the system and technology aggregates all of the healthcare data into a global graph-theoretic topology and processes the data via a hybrid federated and peer to peer distributed processing architectures. , t USER REOISTERS WITH THE EMEROINGMED.COM WEB SITE USER STARTS CLStCAL TRIAL SPARCHPROCESS 201 BEGIN BUILDING PATIENT PROFELB BY ASKING STATIC QUSTECNS ABOUT PATEN 202 ASKCOVNAKIwiC 29STIOMBABOUTPATIENT 204 BEOrN TRIAL MATCHING PROCESS BY OMPARING PATIENTS NIEDICAL PROFILE WITH ACPEANCEirEFTEA Pt OR AVALABLE CLINICAL TRIALS MAKE A PRELIMIARY DBTER.drNATION WHETHER PATIENT QUALIFIESFORL ANY AVAILABLE CLINICAL TRItALS 208 IPTEPATIENT SATISIFES PRBLIMIARY QUALIFICATION, ASK TARGETED 250 QVE)ISTISP8ECIFIC TOPACH CLIICAL TRIAL MA KBA PIA LDETERMIATI ON WHBTHBRPATIENT QUALI FtBS FOPTHE CLTHICA L IRAuS BASED ON RESPONSESB1OTARGETMDQUESTIONS 212 JP[::SPAT:ENTQUALIFIESPFOR ANY CLINICAL TRIAL% ALLOW PATIENTTO SUBMIT ONLINE APPLICATJONSlFOIL THESE TIALS 214- - - - - - FORWARD APLCATJONAND PATIEhMSMEtDAL PROPNLBTOGAPPLICABLE TRNAL HOST SITE IRUAL Srit PERSONNEL EVALDATE AP#LECATION AND ACCEPTiRA REJECT PATIENT FOR CLTNJCAL TJUAL 22lOTIFY PATIENT WHETHER ACCEPTEDORPREECTED FOR CLICAL TRIAL FIG. 2-A: DEPICTS A FLOWCHART ILLUSTRATING A METHOD OF MATCHING A PATIENT WITH AVAILABLE CLINICAL TRIAL SITES AND PREQUALIFYING PATIENTS FOR CLINICAL TRIALS.

Description

, t USER REOISTERS WITH THE EMEROINGMED.COM WEB SITE

USER STARTS CLStCAL TRIAL SPARCHPROCESS 201 BEGIN BUILDING PATIENT PROFELB BY ASKING STATIC QUSTECNS ABOUT PATEN

202 ASKCOVNAKIwiC 29STIOMBABOUTPATIENT 204 BEOrN TRIAL MATCHING PROCESS BY OMPARING PATIENTS NIEDICAL PROFILE WITH ACPEANCEirEFTEA Pt OR AVALABLE CLINICAL TRIALS

MAKE A PRELIMIARY DBTER.drNATION WHETHER PATIENT QUALIFIESFORL ANY AVAILABLE CLINICAL TRItALS 208

IPTEPATIENT SATISIFES PRBLIMIARY QUALIFICATION, ASK TARGETED TRIAL 250 QVE)ISTISP8ECIFIC TOPACH CLIICAL

MA KBA PIA LDETERMIATI ON WHBTHBRPATIENT QUALI FtBS FOPTHE CLTHICA L IRAuS BASED ON RESPONSESB1OTARGETMDQUESTIONS 212

JP[::SPAT:ENTQUALIFIESPFOR ANY CLINICAL TRIAL% ALLOW PATIENTTO SUBMIT ON LINE APPLICATJONSlFOIL THESE TIALS 214- - - - - -

FORWARD APLCATJONAND PATIEhMSMEtDAL PROPNLBTOGAPPLICABLE TRNAL HOST SITE

IRUAL Srit PERSONNEL EVALDATE AP#LECATION AND ACCEPTiRA REJECT PATIENT FOR CLTNJCAL TJUAL

FOR CLICAL TRIAL 22lOTIFY PATIENT WHETHER ACCEPTEDORPREECTED

FIG. 2-A: DEPICTS A FLOWCHART ILLUSTRATING A METHOD OF MATCHING A PATIENT WITH AVAILABLE CLINICAL TRIAL SITES AND PREQUALIFYING PATIENTS FOR CLINICAL TRIALS.

MCHO- Blockchain Technology: MEDICINE, CLINICAL TEST AND HEALTHCARE OBSERVATION USING BLOCKCHAIN TECHNOLOGY

FIELD OF THE INVENTION Our invention "MCHO- Blockchain Technology" is related to medicine, clinical test and healthcare observation using blockchain technology and also method for quickly and efficiently matching patients with clinical trials and clinical trial sites over a computer network.

BACKGROUND OF THE INVENTION

The healthcare industry currently has a number of issues that need to be resolved including.

1. The speed at which basic transactions occur in health information networks. 2. The siloed nature of information contained within these health information networks. 3. The ability for the consumer to gain access to the flow of health information contained in these networks. 4. The reliability and traceability of transactions in health information networks.

The need for seamless interoperability within the Health industry is of utmost concern. This includes all aspects of the consumer, payer and provider landscape. Healthcare enterprise applications (e.g. Electronic Medical Record systems (EMRs), Electronic HealthCare Records (EHRs), Practice Management systems (PMs) and payor solutions) have been created within many areas of healthcare information technology to supposedly address specific end user (consumer) requirements. However, these applications do not allow for interoperability and transparency of data operations.

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.

According to the Healthcare Information and Management Systems Society (FflMSS details of which are at htt : //www, himss . org/ which is incorporated herein by reference), analytics organization, larger countries (such as the United States, Canada, Germany, France, Italy and Spain) are behind several smaller European countries (such as Denmark, Holland and Sweden) in reaching the highest level of paperless data sharing, storage and decision support according to Uwe Buddrus, HIMSS Analytics Europe, personal communication. The number of faxes per year in healthcare in the United States alone approach 15(million) annually. There is a hard line requirement to reduce the paper interactions and move to more fluid electronic formats. Brief Description of the Drawings

Patients who have been diagnosed with a disease are often in need of finding appropriate clinical trials for new drugs, medical devices, or treatments to treat their disease. Patients with serious diseases may only have weeks or months to live, and thus the ability to find available clinical trials and information about those trials quickly and efficiently is invaluable. Unfortunately, today, there is no effective system for quickly matching patients with clinical trials. Doctors are often not aware of all the clinical trials that are being performed in different geographic regions. Clinical trial sponsors have difficulty finding suitable patients for their trials because there is a lack of up-to-date listings of clinical trials, patients are geographically dispersed, many clinical trials require screening large segments of the population, and patients lack insurance coverage. Additionally, patients seeking on their own to find clinical trials which may help them often suffer from consumer confusion with regard to medical terminology and protocol information, and thus have a difficult time identifying appropriate clinical trials.

Clinical trial sponsors are also hurt by this problem, since the inability to quickly find acceptable patients to enroll in their trials delays development of their new drugs or devices and delays FDA approval. What is needed is a method of quickly and efficiently matching qualifying patients with appropriate clinical trials. What is also needed is a system that can match patient medical profiles and patient characteristics with clinical trial acceptance criteria for a wide range of clinical trials in dispersed geographic areas. What is also needed is a source of comprehensive information about diseases, drugs, medical devices, and clinical trials to provide patients, family, friends and health care professionals the necessary information to make informed decisions about which clinical trials are useful for treating various conditions, and other related information such as risks, benefits, insurance coverage, and other similar information.

This invention relates generally to methods and systems for monitoring a person. The present invention relates to interoperability of medical devices.

Medical devices are essential to the practice of modern medicine. Physiologic measurements like blood pressure and temperature, x-ray and ultrasound imaging, administration of intravenous medications, and support of critical life functions are all routine procedures that use medical devices. However, at present, each device is designed to stand alone as an island. It is difficult to bring together multiple devices into interoperable (inter-connected) systems to improve patient care and avoid unnecessary accidents.

To address this issue, the Institute of Electrical and Electronics Engineers Inc. (IEEE) is developing two new point-of-care medical device standards. IEEE P1073.2.2.0 Health Informatics-Point-of-Care Medical Device Communication-Application Profile-Association Control Function-will provide for the establishment, release and disconnection of an association between a medical device agent and a system acting as a manager. In medical device communications, manager systems indicate a set of desired capabilities when requesting an association. Agent systems respond by stating the capabilities they support across the connection. Once an association is established, mechanisms must be in place to break the link. IEEE P1073.2.2.0 is referenced by other application-profile mode standards within the ISO/IEEE 11073 family. The second standards project, IEEE P1073.2.2.1-Health Informatics-Point Of-Care Medical Device Communication-Application Profile-Polling Mode-will define a method for retrieving application data with medical devices that communicate through polling protocols. IEEE P1073.2.2.1 will enable "plug-and-play" interoperability for simple medical devices that use polling protocols for management systems to query devices for all information to be communicated.

PRIOR ART SEARCH US5572421A*1987-12-091996-11-05Altman; Louis Portable medical questionnaire presentation device. US5734883A1995-04-271998-03-3lMichael Umen & Co., Inc. Drug document production system. W01998039720A11997-03-031998-09-llUniversity Of Florida Method and system for interactive prescription and distribution of drugs in conducting medical studies. W01998049647A11997-04-301998-11-05Medical Science Systems Inc. Integrated disease information system. US5898586A1994-11-041999-04-27Eli Lilly And Company Method for administering clinical trial material. EP0936566A2 *1998-02-111999-08-18Siemens Aktiengesellschaft System for carrying out medical trials. US6081786A1998-04-032000-06-27Triangle Pharmaceuticals, Inc. Systems, methods and computer program products for guiding the selection of therapeutic treatment regimens. US20160132647A1*2013-08-152016-05-12Universal Research Solutions, Llc Patient-to-Patient Communities.

US20160132716A1*2014-11-122016-05-12Ricoh Company, Ltd. Method and device for recognizing dangerousness of object. US9339209B22010-04-192016-05-17Sotera Wireless, Inc. Body-worn monitor for measuring respiratory rate. US9339204B2*2014-06-052016-05-17Guangren CHEN Systems and methods for detecting ECG sub wave forms. W02016076742A1*2014-11-142016-05-19MBRAINTRAIN LLC Belgrade Remote electrophysiological monitoring system for intensive care units. US9349098B1*2015-05-142016-05-24James Albert lonson Cognitive medical and industrial inspection system and method. US9360874B22009-08-212016-06-07Allure Energy, Inc. Energy management system and method. US20160164949A1*2010-03-232016-06-09Nabto Aps Method for providing data from a resource weak device to a computer client.

OBJECTIVES OF THE INVENTION 1. The objective of the invention is to the system and technology for matching and mapping patients with clinical trials and previous data set record under block-chain process to prequalifying patients for clinical trials and previous data set record and providing information to patients to allow them to inform themselves about available clinical trials and previous data set record. 2. The other objective of the invention is to the method and technology sequential comprises receiving patient old and new profile information for a patient at a data base and local server connected to a computer network with defined IP- address and ID- no, the patient profile information fetch by using block -chain technology and submitted by a user at a terminal connected to the network, comparing the patient profile information with acceptance criteria for clinical trials stored in a database. 3. The other objective of the invention is to the invented technology comparison performed by the local and global server, determining whether the patient prequalifies for any of the clinical trials, and notifying the user and the previous data set record whether the patient has prequalified for any clinical trials. 4. The other objective of the invention is to the invented medical system includes a network one or more medical data collection appliances coupled to the network each appliance transmitting data conforming to an interoperable format and a local and global server coupled to the network to store data for each individual in accordance with the interoperable format and also format as per required data can change. 5. The other objective of the invention is to the invented system and technology for a decentralized autonomous healthcare economy platform are provided and also the system and technology aggregates all of the healthcare data into a global graph-theoretic topology and processes the data via a hybrid federated and peer to peer distributed processing architectures. 6. The other objective of the invention is to wherein the server transmits a plurality of questions over the Internet, the server also transmits a plurality of answer choices for each question, the server receives responses, and the server builds a patient profile based on the responses and also the invention is to wherein the server retrieves a disease/sub-disease record corresponding to a received disease/sub-disease, the disease/-sub-disease record containing links to question records, the server retrieving the question records to access questions. 7. The other objective of the invention is to wherein the completed application is submitted to the server and also the invention is to further comprising the server forwarding to the completed application to the clinical trial site. The invention is to further comprising the server forwarding the registration information to the clinical trial site with the completed application. 8. The other objective of the invention is to comprising an in-door positioning system coupled to one or more mesh network appliances to provide location information and also the invention is to comprising a call center coupled to the appliance to provide a human response. The invention is to wherein the server is coupled to a a wireless mesh network where data hops through neighboring nodes of the mesh network to reach a final destination. 9. The other objective of the invention is to the invention is to comprising a wireless router coupled to a mesh network and wherein the wireless router comprises one of: 802.11 router, 802.16 router, WiFi router, WiMAX router, Bluetooth router, X10 router and also the comprising a mesh network appliance coupled to a power line to communicate X10 data over a mesh network. The comprising a bio impedance analyzer to determine one of: total body water, compartmentalization of body fluids, cardiac monitoring, blood flow, skinfold thickness, dehydration, blood loss, wound monitoring, ulcer detection, deep vein thrombosis, hypovolemia, hemorrhage, blood loss, heart attack, stroke attack. 10. The other objective of the invention is to wherein the appliance transmits and receives voice from the person over the mesh network to one of: a doctor, a nurse, a medical assistant, a caregiver, an emergency response unit, a family member. The invention is to comprising code to store and analyze patient information including medicine taking habits, eating and drinking habits, sleeping habits, or excise habits.

SUMMARY OF THE INVENTION

The invention is a system and method for matching patients with clinical trials and trial sites, prequalifying patients for clinical trials and trial sites, and providing information to patients to allow them to inform themselves about available clinical trials and trial sites. The method of the present invention comprises receiving patient profile information for a patient at a server connected to a computer network such as the Internet. The patient profile information is submitted by a user at a terminal connected to the network. A server compares the patient profile information with acceptance criteria (including geographic location) for clinical trials and trial sites stored in a database. The server determines whether the patient qualifies for any of the clinical trials, and notifies the user whether the patient has prequalified for any clinical trials.

The patient's profile is built by asking the user a series of questions and then creating the patient profile based on the user's responses. The questions can include static and dynamic questions. The user is also asked a series of questions targeted to a specific clinical trial or trial site after determining that the patient meets the preliminary acceptance criteria for the specific clinical trial or trial site. The final determination of whether the user prequalifies is based on the user's response to the targeted questions.

When the user is provided with a question, the user is also provided with a set of answer options. The user responds to the question by choosing one or more of the answer options. Alternatively, the user can type in an answer to the question.

Once the user has prequalified for a clinical trial/trial site, the user is provided with an application. The user fills out the application and can submit the application on line. The application and the patient's medical profile are sent to the appropriate trial site. The patient's application and medical profile do not include the patient's name, social security number or other identifying information. This protects the patient's privacy. If the patient is accepted by the trial site, the patient is notified and provided with trial site contact information. The patient can contact the trial site to enroll in the clinical trial.

An interoperable health-care system includes a network; one or more medical data collection appliances coupled to the network, each appliance transmitting data conforming to an interoperable format; and a computer coupled to the network to store data for each individual in accordance with the interoperable format.

The user can take his/her weight, blood pressure, and cholesterol measurement daily, and the data is sent from a health base station to a monitoring service at his doctor's office. Periodically, the user gets an automated health summary generated by a service at his doctor's office as well as information to help him maintain a healthy lifestyle. The health information can be stored in an external HIPAA compliant health storage database so that the user and his doctor can access his health information over the web. The system extends health care system into the home and can record personal health data on a systematic periodic basis. Appointments can be automatically scheduled with providers. Long-term data for medical baseline can be collected. The system can also provide predictive alerts for high-risk conditions. The system can perform initial triage utilizing biosensors, images, e-mail/chat/video.

Advantages of the system may include one or more of the following. The system empowers people with the information they need to better manage their health and the health of their loved ones. The interoperability enables disparate industries to work together to combine their products and services through connectivity standards and provide millions of people with the tools they need to better manage their health and the health of their families. The system can perform chronic disease management, monitoring the health and healthcare needs of aging people and proactive health and fitness. The interoperable system can address the data storage requirements for health and wellness management, chronic disease management or patient recovery, medication management, and fitness and workout tracking. For example, using a blood pressure sensor, a weight scale or a cholesterol monitor, the user regularly collects health data that is then reviewed by the patient's caregiver for remote monitoring and health management of the patient. The system can provide remote monitoring of multiple patients, seamless device replacement and support for clinical trials. The Medical Device Profile will be compliant with the US Health Insurance Portability and Accountability Act (HIPAA) and other international data privacy requirements.

By enabling a network of readily connected health and medical devices, people with diabetes or other chronic diseases will be able to share vital sign information such as blood pressure and glucose level with their doctors. Adult children will be able to remotely watch over their aging parents and proactively help them manage safely in their own homes. Diet and fitness conscious individuals will also be able to seamlessly share their weight and exercise data with fitness consultants through the Internet.

The above system forms an interoperable health-care system with a network; a first medical appliance to capture a first vital information and coupled to the network, the first medical appliance transmitting the first vital information conforming to an interoperable format; and a second medical appliance to capture a second vital information and coupled to the network, the second medical appliance converting the first vital information in accordance with the interoperable format and processing the first and second vital information, the second medical appliance providing an output conforming to the interoperable format.

The appliances can communicate data conforming to the interoperable format over one of: cellular protocol, ZigBee protocol, Bluetooth protocol, WiFi protocol, WiMAX protocol, USB protocol, ultrawideb and protocol. The appliances can communicate over two or more protocols. The first medical appliance can transmit the first vital information over a first protocol (such as Bluetooth protocol) to a computer, wherein the computer transmits the first vital information to the second medical appliance over a second protocol (such as ZigBee prototocol).

The computer can then transmit to a hospital or physician office using broadband such as WiMAX protocol or cellular protocol. The computer can perform the interoperable format conversion for the appliances or devices, or alternatively each appliance or device can perform the format conversion. Regardless of which device performs the protocol conversion and format conversion, the user does not need to know about the underlying format or protocol in order to use the appliances. The user only needs to plug an appliance into the network, the data transfer is done automatically so that the electronic "plumbing" is not apparent to the user. In this way, the user is shielded from the complexity supporting interoperability.

A monitoring system for a person includes one or more wireless nodes and a stroke sensor coupled to the person and the wireless nodes to determine a medical problem, for example a stroke attack. The stroke monitoring system is interoperable with emergency vehicle and/or hospital systems and provides information to quickly treat stroke once the patient reaches the treatment center.

A monitoring system for a person includes one or more wireless nodes and an electromyography (EMG) sensor coupled to the person and the wireless nodes to determine a medical issue such as a stroke attack.

A health care monitoring system for a person includes one or more wireless nodes forming a wireless mesh network; a wearable appliance having a sound transducer coupled to the wireless transceiver; and a bioelectric impedance (BI) sensor coupled to the wireless mesh network to communicate BI data over the wireless mesh network.

A heart monitoring system for a person includes one or more wireless nodes forming a wireless mesh network and a wearable appliance having a sound transducer coupled to the wireless transceiver; and a heart disease recognizer coupled to the sound transducer to determine cardiovascular health and to transmit heart sound over the wireless mesh network to a remote listener if the recognizer identifies a cardiovascular problem. The heart sound being transmitted may be compressed to save transmission bandwidth.

A monitoring system for a person includes one or more wireless nodes; and a wristwatch having a wireless transceiver adapted to communicate with the one or more wireless nodes; and an accelerometer to detect a dangerous condition and to generate a warning when the dangerous condition is detected.

A monitoring system for a person includes one or more wireless nodes forming a wireless mesh network; and a wearable appliance having a wireless transceiver adapted to communicate with the one or more wireless nodes; and a heartbeat detector coupled to the wireless transceiver. The system may also include an accelerometer to detect a dangerous condition such as a falling condition and to generate a warning when the dangerous condition is detected.

Implementations of the above aspect may include one or more of the following. The wristwatch determines position based on triangulation. The wristwatch determines position based on RF signal strength and RF signal angle. A switch detects a confirmatory signal from the person. The confirmatory signal includes a head movement, a hand movement, or a mouth movement. The confirmatory signal includes the person's voice. A processor in the system executes computer readable code to transmit a help request to a remote computer. The code can encrypt or scramble data for privacy.

The processor can execute voice over IP (VOIP) code to allow a user and a remote person to audibly communicate with each other. The voice communication system can include Zigbee VOIP or Bluetooth VOIP or 802.XX VOIP. The remote person can be a doctor, a nurse, a medical assistant, or a caregiver. The system includes code to store and analyze patient information. The patient information includes medicine taking habits, eating and drinking habits, sleeping habits, or excise habits. A patient interface is provided on a user computer for accessing information and the patient interface includes in one implementation a touch screen; voice-activated text reading; and one touch telephone dialing. The processor can execute code to store and analyze information relating to the person's ambulation.

A global positioning system (GPS) receiver can be used to detect movement and where the person falls. The system can include code to map the person's location onto an area for viewing. The system can include one or more cameras positioned to capture three dimensional (3D) video of the patient; and a server coupled to the one or more cameras, the server executing code to detect a dangerous condition for the patient based on the 3D video and allow a remote third party to view images of the patient when the dangerous condition is detected.

In another aspect, a monitoring system for a person includes one or more wireless bases; and a cellular telephone having a wireless transceiver adapted to communicate with the one or more wireless bases; and an accelerometer to detect a dangerous condition and to generate a warning when the dangerous condition is detected.

A monitoring system includes one or more cameras to determine a three dimensional (3D) model of a person; means to detect a dangerous condition based on the 3D model; and means to generate a warning when the dangerous condition is detected. A method to detect a dangerous condition for an infant includes placing a pad with one or more sensors in the infant's diaper; collecting infant vital parameters; processing the vital parameter to detect SIDS onset; and generating a warning.

Advantages of the system may include one or more of the following. The system detects the warning signs of stroke and prompts the user to reach a health care provider within 2 hours of symptom onset. The system enables patent to properly manage acute stroke, and the resulting early treatment might reduce the degree of morbidity that is associated with first-ever strokes. Other advantages of the invention may include one or more of the following. The system for non-invasively and continually monitors a subject's arterial blood pressure, with reduced susceptibility to noise and subject movement, and relative insensitivity to placement of the apparatus on the subject. The system does not need frequent recalibration of the system while in use on the subject.

It allows patients to conduct a low-cost, comprehensive, real-time monitoring of their vital parameters including blood pressure. Using the web services software interface, the invention then avails this information to hospitals, home-health care organizations, insurance companies, pharmaceutical agencies conducting clinical trials and other organizations. Information can be viewed using an Internet-based website, a personal computer, or simply by viewing a display on the monitor. Data measured several times each day provide a relatively comprehensive data set compared to that measured during medical appointments separated by several weeks or even months. This allows both the patient and medical professional to observe trends in the data, such as a gradual increase or decrease in blood pressure, which may indicate a medical condition. The invention also minimizes effects of white coat syndrome since the monitor automatically makes measurements with basically no discomfort; measurements are made at the patient's home or work, rather than in a medical office.

The wearable appliance is small, easily worn by the patient during periods of exercise or day-to-day activities, and non-invasively measures blood pressure can be done in a matter of seconds without affecting the patient. An on-board or remote processor can analyze the time-dependent measurements to generate statistics on a patient's blood pressure (e.g., average pressures, standard deviation, beat-to-beat pressure variations) that are not available with conventional devices that only measure systolic and diastolic blood pressure at isolated times.

The wearable appliance provides an in-depth, cost-effective mechanism to evaluate a patient's cardiac condition. Certain cardiac conditions can be controlled, and in some cases predicted, before they actually occur. Moreover, data from the patient can be collected and analyzed while the patient participates in their normal, day-to-day activities.

In cases where the device has fall detection in addition to blood pressure measurement, other advantages of the invention may include one or more of the following. The system provides timely assistance and enables elderly and disabled individuals to live relatively independent lives. The system monitors physical activity patterns, detects the occurrence of falls, and recognizes body motion patterns leading to falls. Continuous monitoring of patients is done in an accurate, convenient, unobtrusive, private and socially acceptable manner since a computer monitors the images and human involvement is allowed only under pre-designated events.

The patient's privacy is preserved since human access to videos of the patient is restricted: the system only allows human viewing under emergency or other highly controlled conditions designated in advance by the user. When the patient is healthy, people cannot view the patient's video without the patient's consent. Only when the patient's safety is threatened would the system provide patient information to authorized medical providers to assist the patient. When an emergency occurs, images of the patient and related medical data can be compiled and sent to paramedics or hospital for proper preparation for pick up and check into emergency room.

The system allows certain designated people such as a family member, a friend, or a neighbor to informally check on the well-being of the patient. The system is also effective in containing the spiraling cost of healthcare and outpatient care as a treatment modality by providing remote diagnostic capability so that a remote healthcare provider (such as a doctor, nurse, therapist or caregiver) can visually communicate with the patient in performing remote diagnosis. The system allows skilled doctors, nurses, physical therapists, and other scarce resources to assist patients in a highly efficient manner since they can do the majority of their functions remotely.

Additionally, a sudden change of activity (or inactivity) can indicate a problem. The remote healthcare provider may receive alerts over the Internet or urgent notifications over the phone in case of such sudden accident indicating changes. Reports of health/activity indicators and the overall wellbeing of the individual can be compiled for the remote healthcare provider. Feedback reports can be sent to monitored subjects, their designated informal caregiver and their remote healthcare provider. Feedback to the individual can encourage the individual to remain active. The content of the report may be tailored to the target recipient's needs, and can present the information in a format understandable by an elder person unfamiliar with computers, via an appealing patient interface. The remote healthcare provider will have access to the health and well-being status of their patients without being intrusive, having to call or visit to get such information interrogatively. Additionally, remote healthcare provider can receive a report on the health of the monitored subjects that will help them evaluate these individuals better during the short routine check up visits. For example, the system can perform patient behavior analysis such as eating/drinking/smoke habits and medication compliance, among others.

The patient's home equipment is simple to use and modular to allow for the accommodation of the monitoring device to the specific needs of each patient. Moreover, the system is simple to install. Regular monitoring of the basic wellness parameters provides significant benefits in helping to capture adverse events sooner, reduce hospital admissions, and improve the effectiveness of medications, hence, lowering patient care costs and improving the overall quality of care. Suitable users for such systems are disease management companies, health insurance companies, self-insured employers, medical device manufacturers and pharmaceutical firms.

The system reduces costs by automating data collection and compliance monitoring, and hence reduce the cost of nurses for hospital and nursing home applications. At home vital signs monitoring enables reduced hospital admissions and lower emergency room visits of chronic patients. Operators in the call centers or emergency response units get high quality information to identify patients that need urgent care so that they can be treated quickly, safely, and cost effectively. The Web based tools allow easy access to patient information for authorized parties such as family members, neighbors, physicians, nurses, pharmacists, caregivers, and other affiliated parties to improve the Quality of Care for the patient.

A method for providing patient access to medication includes collecting patient medical information from a patient computer; securing the patient medical information and sending the secured patient medical information from the patient computer to a remote computer; remotely examining the patient and reviewing the patient medical information; generating a prescription for the patient and sending the prescription to a pharmacy; and performing a drug interaction analysis on the prescription.

Implementations of the on-line pharmacy aspect may include one or more of the following. The medical information can include temperature, EKG, blood pressure, weight, sugar level, image of the patient, or sound of the patient. Responses from the patient to a patient medical questionnaire can be captured. The doctor can listen to the patient's organ with a digital stethoscope, scanning a video of the patient, running a diagnostic test on the patient, verbally communicating with the patient. The digital stethoscope can be a microphone or piezoelectric transducer coupled to the Zigbee network to relay the sound. A plurality of medical rules can be applied to the medical information to arrive at a diagnosis. Genetic tests or pharmacokinetic tests can be run on the patient to check compatibility with the prescription. Approval for the prescription can come from one of: a doctor, a physician, a physician assistant, a nurse. The system can monitor drug compliance, and can automatically ordering a medication refill from the pharmacy.

For pharmacy applications, advantages of the pharmacy system may include one or more of the following. The system shares the patient's medical history and can be updated by a remote physician and the remote dispensing pharmacy. As the doctor and the pharmacy have the same access to the patient medical history database, patient data is updated in real time, and is as current and complete as possible. The patient, doctor, pharmacy, and third party testing entities benefit from a uniform pricing structure that is based on the diagnosis and treatment. The patient only pays for standard medical treatments for his or her illness. The physician is paid a standard fee which covers the average work spent with a patient with the specific type of medical situation. The dispensing pharmacy is able to provide the highest level of service, since it is able to double check all medications dispensed to each patient along with the optimal way to detect anticipated negative drug interactions.

The pricing structure is competitive as physicians do not need to be distributed physically, and those with specialty areas may remain centrally located and yet be able to interact electronically with patients. The system still provides physical access to specialists since the patients which are evaluated can be directed to visit a specialist physically, when remote review and contact is ineffectual. The on-line pharmacy tracks the specific needs and medical history of each patient and can provide an expert system to advise the patient on proper drug usage and potential drug interactions. The system automates the purchasing of drugs, pricing the prescription or submission of the claims to a third party for pricing, entering the complete prescription in their computer system, and auditing from third parties which provide payment.

The on-line pharmacy provides detailed multimedia guidance or assistance to the patient regarding the filled prescription. The patient can freely search for answers regarding the use of the filled prescription, its possible side effects, possible interactions with other drugs, possible alternative treatments, etc. The patient can communicate using video or VOIP with a remote pharmacist regarding any number of questions, and be counseled by the local pharmacist on the use of the filled prescription. Thus, the system minimizes the danger from harmful side effects or drug interactions by providing patients with full access to information. The system allows a patient to enjoy the selection and price of a mail-order pharmacy without subjecting the patient to dangerous interactions or side effects which may occur in unsupervised prescription purchases. The on-line pharmacy offers the selection and benefits of a "central fill" pharmacy method without requiring the local pharmacy to purchase drugs to fill each prescription, price each prescription, or be subjected to audits from third parties who provide payment.

A wireless housing provides one or more bioelectric contacts conveniently positioned to collect bioelectric patient data. The housing can be a patch, a wristwatch, a band, a wristband, a chest band, a leg band, a sock, a glove, a foot pad, a head-band, an ear clip, an ear phone, a shower-cap, an armband, an ear-ring, eye-glasses, sun-glasses, a belt, a sock, a shirt, a garment, a jewelry, a bed spread, a pillow cover, a pillow, a mattress, a blanket or a sleeping garment such as a pajama. The bed spread, pillow cover, pillow, mattress, blanket or pajama can have bioelectrically conductive contacts in an array so that the patient can enjoy his/her sleep while vital parameters can be captured. In one embodiment, an array of parallel conductive lines can be formed on the housing side that faces the patient and the electrical signal can be picked up. The data captured by the contacts are transmitted over the mesh network such as ZigBee to a base station.

BRIEF DESCRIPTION OF THE DIAGRAM

FIG. 1-A: depicts a block diagram illustrating the system of the present invention.

FIG. 2-A: depicts a flowchart illustrating a method of matching a patient with available clinical trial sites and prequalifying patients for clinical trials.

FIGS. 3A-3D: is a Depict block diagrams illustrating some exemplary links between various records in data storage device 120.

FIG.1: is a system for decentralized healthcare that has a peer to peer architecture.

FIG.1-B: is an example of a computer system implementation of the decentralized system.

FIG.2: is an example of a healthcare blockchain application that is part of the decentralized system.

FIG.3: is an example of a healthcare blockchain.

FIG.4: is an example of a referral workflow of the decentralized healthcare block chain system.

FIG.5: is an example of a process for patient behavior health plan.

FIG. 6: is as patient and provider data sharing process of the of the.

DESCRIPTION OF THE INVENTION FIG. 1-A: depicts a block diagram illustrating the system of the present invention. An EmergingMed.com server 102 is connected to a network 116. Network 116 can be any network connecting computers such as the Internet. Sponsors of clinical trials utilize a clinical trial sponsor terminal 104 to access EmergingMed.com server 102 and to communicate with other terminals connected to network 116. Clinical trial sponsor terminal 104 is running browser program 106 which allows terminal to access remote servers and communicate with other terminals via network 116.

Patients and other individuals can access EmergingMed.com server 102 by using patient terminal108which is running browser program110. Healthcare professionals can access EmergingMed.com server102by using health care professional terminal 112 running browser program 114. Clinical trial investigators can access EmergingMed.com server 102 by using clinical trial investigator terminal 105. Other individuals can similarly access EmergingMed.com server 102 by using any terminal connected to network 116.

EmergingMed.com server 102 includes a CPU 122 which is running a program which operates the method of the present invention. CPU 122 accesses RAM 118, ROM 120, and data storage device 124. Data storage device 124 can be any magnetic or optical media, or any other medium for storing electronic data. As will be understood by one of skill in the art, EmergingMed.com server 102 can comprise multiple servers working together, and data storage device 124 can similarly comprise multiple storage devices.

Data storage device 124 contains a database 142. Database 142 contains information organized into records. Some exemplary records are shown in FIG. 1. Disease/sub disease records 126 contain information related to specific diseases. These records are organized both by disease and sub-disease. An example of a disease is "cancer" and an example of a sub-disease is "skin cancer." Disease/sub-disease records 126 contain information about the disease such as description of the disease, symptoms, treatment, history, and other pertinent information. Each disease/sub disease record 126 also includes links to other related records in database 142 such as drug records 128 (e.g. drugs used to treat the disease), content records 130, clinical trial site records 132, question records 134, and device records 136. The links between records are described in more detail with respect to FIG. 3.

Drug records 128 contain information about various drugs. Such information includes the purpose of the drug, compound name, generic name, brand names, instructions for taking the drug, warnings, side effects, and any other pertinent drug information. Each drug record 128 contains links to other records in database 142. Content records 130 contain various kinds of content such as newspaper and journal articles, research reports, frequently asked questions, standard therapies, alternate medicine, case studies, and various other types of medical information that would be of interest to someone seeking information about diseases and treatments. Content records 130 contain links to other records in database 124.

Clinical trial site records 132 contain information pertaining to various clinical trial sites. Clinical trials are performed for various reasons such as to test the efficacy of a new drug, a new medical device, or a new therapy. Clinical trials are often performed prior to obtaining FDA approval. One clinical trial may take place at multiple clinical trial sites. Each clinical trial site preferably has its own record in clinical trial site records 132. A clinical trial is conducted by an investigator on behalf of a sponsor at a clinical trial site. Clinical trial site records 132 contain information about the clinical trial site such as the sponsor's name and information, investigator's name and information, location, number of patients admitted, number of patients allowed, open or closed status, drug or device being tested, names of staff, duration of trial, phases of the trial, purpose of the trial, trial methodology, and any other information relevant to the clinical trial being performed. Clinical trial site records 132 contain links to otherrecordsin database 142.

Question records 134 contain questions that are asked to users who are seeking to join clinical trials. As explained in detail with respect to FIG. 2-A, patients who are seeking to join clinical trials are asked a series of questions about their disease, their prior treatment, and their medical history. The answers to these questions are used to build a patient profile. If the answers to these question match the acceptance criteria for a specific clinical trial, then the patient becomes eligible to apply for that clinical trial. Question records 134 contain links to other records in database 142. Device records 136 contain information about various medical devices such as the device manufacturer name, the diseases and conditions treated, instructions for using the device, warnings, and other pertinent device information. Device records 136 contain links to other records in database 142.

User registration records 140 contain user information about the various users authorized to access EmergingMed.com server 102. User registration records 140 contain information such as user name, user ID number, login name, password, access privileges, customized user preferences, mail accounts, links to patient profiles, and any other similar user information. Patient profile records 138 contain various types of medical information about patients including their gender, age, medical histories, diseases, symptoms, and any other relevant medical information. Patient profile records are created by asking the patient a series of questions. The responses are used to build the patient's profile. The responses can be entered by a health care professional or by the patients themselves.

The invention, patient profile records 138 do not contain the user's name, but instead only contain the user's ID number. In other words, the patient's medical information is kept separate from the patient's identifying information. This maintains the user's medical privacy and anonymity. As will be described in more detail with respect to FIG. 2-A, every patient is assigned a user ID number. The user's name and identifying information is stored in the user's registration record 140 along with the user's ID number. The patient's medical information is stored in a patient profile record 138 along with the patient's user ID number. In this way, the patient's profile record 138 can be sent to a third party without revealing the patient's identity to the third party. In this way, EmergingMed.com has access to the patient's identifying information, but third parties do not. Additional records can be added to database 142 for various other purposes. Also, the organization of the records shown in FIG. 1-A is by example only, and different organizations and groupings of records is possible.

FIG. 2-A depicts a flowchart illustrating a method of matching a patient with available clinical trials. In step 200, a user registers with the EmergingMed.com web site. The user could be a patient, a health care professional such as a doctor, a representative from a clinical trial sponsor, an investigator, a representative from a health care facility or clinical trial site, or any other individual or entity involved in the clinical trial process. When a user registers, the user selects a user name and a password. The user can also submit an e-mail address. This information is stored in a user registration record 140. The user is also assigned a user ID number. This user ID number is attached to the user's profile records/medical information in order to keep the user-patient's identity anonymous.

In step 201, a user interested in searching for available clinical trials accesses the EmergingMed.com web site by entering an appropriate URL such as http://www.emergingmed.com. The user then clicks on a link or a series of links that directs the user to the clinical trial search process. One type of user that might be interested in searching for an available clinical trial is simply a patient or a relative or friend of a patient. The user could also be a health care professional such as the patient's doctor. The first step in finding appropriate clinical trials is creating a patient profile for the patient. The patient profile will contain the patient's medical information and any of the patient's characteristics that would be useful in determining whether a patient was suitable for a particular clinical trial.

The patient profile is created by asking the user a series of questions. In step 202, the user is asked a series of "static" questions. Static questions are a series of pre-defined questions that are asked about every patient. Examples of static questions include the patient's gender, age, height, weight, name of disease, name of sub-disease, smoker (yes/no), willing to travel (yes/no), and any other pertinent medical or patient information. The user can select a disease and sub-disease from a set of menus. For example, the user could select the disease "cancer" and the sub-disease "skin cancer." Optionally, the user can select the types of trials for which he or she is interested. For example, the user can select the trial sponsor type, trial modality, trial type of study, and drug or compound name.

FIG. 3: depicts a block diagram illustrating some exemplary links between various records in data storage device 120. These links allow a user to navigate the web site and efficiently find medical information relevant to their particular medical condition. The user can also search for relevant information by entering keyword queries. For example, a user searching for particular information about a particular disease would enter the name of a disease and sub-disease such as "cancer/skin cancer." This would retrieve disease/sub-disease record 300 for skin cancer. Disease/sub-disease record 300 would contain information about skin cancer which would be provided to the user. When the user accesses disease/sub-disease record 300, the user is provided with all of the information contained in record 300 as well as links to records 302, 304, 305, and 306. The user can then click on one of these links to access the linked record.

Disease/sub-disease record 300 contains links to related drug/device records 302. These drug/device records are associated with drugs and medical devices used to treat the disease/sub-disease associated with disease/sub-disease record 300. The drug/device records 302 contain information about their associated drug or device such as instructions for taking a drug or using a medical device, warnings, side effects, and similar information. Disease/sub-disease record 300 also contains links to content records 304. Content records 304 contain additional information about the disease/sub-disease such as related news and journal articles, standard therapies, therapies in development, case studies, alternative treatments, and frequently asked questions.

Disease/sub-disease records 300 also contain links to clinical trial records 304. Clinical trial records 304 contain information about various clinical trials which address the specific disease/sub-disease such as the clinical trial sponsor type, trial site locations, acceptance criteria, number of people admitted, and so on. Disease/sub-disease records 300 also contain links to related question records 306. These are questions that are asked to users who are seeking to qualify for clinical trials. These questions are asked in step 204 in FIG. 2-A

FIG. 3B shows another set of links emanating from drug or device record 308. A user can access a drug or device record 308 to find out information about that drug or device. The user will be presented with links to related content records 312 which provide content related to that drug or device. The user will also be presented with links to related clinical trial records 314. The user will also be presented with links to related disease/sub-diseases records 316.

FIG. 3C shows another set of links emanating from content record 318. Content record 318 could be a news or journal article, or some other piece of information. Content record 318 contains links to related drug records 320, related clinical trial records 322, and related disease/sub-disease records 324.

FIG. 3D depicts another set of links emanating from clinical trial record 326. Clinical trial record 326 contains links to related drug records 328, related content records 330, and related disease/subdisease records 332. Clinical trial record 326 also contains links to related question records 334. These questions are asked to users in step 210 of FIG. 2 to determine if they qualify for the specific clinical trial. Another method of the present invention is to allow third party web sites to perform the trial matching and prequalification of the present invention. For example, suppose a drug company has its own web site www.DrugCompany.com. DrugCompany.com has a contract with EmergingMed.com to allow users of DrugCompany.com to perform trial matching and prequalification.

When a user visits DrugCompany.com, the user is provided with a link or group of links which allows the user to search for clinical trials. There are various methods that can be used to allow DrugCompany.com to interface with EmergingMed.com server 102. In a first method, the DrugCompany.com server relays all of the data entered by the user to the EmergingMed.com server 102. The DrugCompany.com server then receives the data sent by EmergingMed.com server 102 and forwards it to the patient. DrugCompany.com thus acts as an intermediary or proxy server for the EmergingMed.com server. Another method is to provide DrugCompany.com with all of the software necessary to ask the patient's questions to build a patient profile. DrugCompany.com could then relay the information to EmergingMed.com server 102. EmergingMed.com server 102 could search database 124 and forward the results to DrugCompany.com. A variety of other well-known methods could be used to access EmergingMed.com server 102 via DrugCompany.com.

The system and method described below aggregates all of the healthcare data into a global graph-theoretic topology and processes the data via a hybrid federated and peer to peer distributed processing architecture (which are further details of which are described at https://en.wikipedia.org/wiki/Peer-to-peer and h tp:// n. wikip ds% onyvYskl/Peer--i%- peer which are incorporated herein by reference.) Some of the data contained in these processes may include but are not limited to:

1. Patient records in a multitenant electronic health record system can be separated to ensure patient confidentiality. However, collective de-identified statistics can be gleaned from the global data set in order to allow data analysts/scientists to study population- wide health concerns. 2. Claims, benefits and referral information 3. Wearable data such as BMI and heart rate 4. Amount billable or bill to information concerning transactions for the respective corporation 5. Gives the consumer the ability to truly control their medical and health information via a single permanent ledgered identity managed system. 6. The system and method may implement the models of Electronic Data Interchange (EDI) under ASC XI 2 in several differing manners and programmatic methodologies. The following are some of the hurdles: 7. Most hospitals still have obsolete or proprietary standards or protocols running as their critical applications. 8. Healthcare standards are under constant development and improvements. 9. Divergent not convergent HealthCare standards are such as: 1. HL7 v2.x, v3 (further details of which are described at 2. http://www.hl7.org/ which is incorporated herein by reference) 3. CEN TC/251 (further details of which are described at 4. hi%%7%r= WAks ed A .org \ iki CE'. CJ25) which is incorporated herein by reference) o open EHR (further details of which are described at ht.1 p,//vvv wxrpenyhr.of,t / which is incorporated herein by reference) 5. ASC X12 4010/5010 (further details of which are described at h.ttp; my^ which is incorporated herein by reference) 6. SNOW-MED (further details of which are described at 7. (hltp://www.nlm.nih.govA/seiarck/nls/Snomed/snomedmain.htrnl which is incorporated herein by reference)

8. FHIR (further details of which are described at 9. ht; p://wiki h17 i? ¾/ide% php? t: tlg:::f H1R which is incorporated herein by reference) 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.

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.

Table 1.0 block structure of top level data - The Block:

Field Description Size (B)

blockid block identifier 4

blocksize number of bytes following 4

blockversion block version 4

hash_prev_block 256 bit hash of previous block 32

hashmerkle_root 256 bit hash of this block 32

Timestamp seconds since 1970-01- 4 OITOO:00 UTC

Target 256 bit number that hash must 32 be less than

Nonce 32 bit 4

transactioncounter #of transactions 1-9 (B)

transactiondata transaction record data variable

To verify that inputs are authorized to collect the values of referenced outputs, a built- scripting language is used. This scripting language is Turing-complete, stack based and processed from left to right. The script language is typically written in a high level language (for example, solidity https: //ethereiim. ithufa. io/solidity/docs/home/) and then compiled into the raw opcodes included in the blockchain transaction (pseudo-code representing this high-level language is used throughout this document in example transactions). The transaction inputs are authorized if the executed script returns true. Through the scripting system, the sender can create very complex conditions that actors in the system must meet in order to claim the output. In this way any automated system of checks, authorizations, actions or even external events can be involved and validated as part of the transaction.

The transaction data may consist of a Colored Coin implementation (described in more detail at https://en.bitco in.it/wiki/ColoredCoins which is incorporated herein by reference), based on Open Assets (described in more detail at tt s £ife protocol/blob/master/specification. media viki which is incorporated herein by reference), using on the OPRETURN operator. Metadata is linked from the Blockchain and stored on the web, dereferenced by resource identifiers and distributed on public torrent files. The colored coin specification provides a method for decentralized management of digital assets and smart contracts (described in more detail at https: //gith ub. com/ ethereum/wiki/wiki. /White-Paper which is incorporated herein by reference.) For our purposes the smart contract is defined as an event- driven computer program, with state, that runs on a blockchain and can manipulate assets on the blockchain. So a smart contract is implemented in the blockchain scripting language in order to enforce (validate inputs) the terms (script code) of the contract.

The digital assets are managed, transferred or involved in a smart contract. Payers issue assets such as a benefits data, or eligibility information. Providers issue assets for clinical documents, health records which the consumer may receive and grant access to through the use of smart contracts. Table 1.1 block structure of the transaction Field Description Ske OPREl'URN ©peasd e The OPRETUK opcode (Ox6a). 1 byte PUSHD ATA opcode 8 i The PUSHD ATA opcode required to push the 1-5 bytes \ full payload onto the stack (OxO1 to x4e, \ deps snding on the size of the payload). Ope as ssets 1%yl@%« 1 See below. Variable The transaction payload may contain the following data types and fields:

Field Description Size

OAP Marker A tag indicating that this transaction is an 2 bytes Open Assets transaction. It is always 0x4f4,

Version number The major revision number of the Open Assets 2 bytes Protocol. For this version, it is1 (OxO100),

Asset quantity count A v-integer representing the number of items 1-9 bytes in the asset quantity list field.

Asset quantitylist Alist of zero ormoreLEB -en oded Variable unsigned integers representing the asset quantity of every output in order (excluding the marker output).

Metadata length The var-integer encoded length of the metadata 1-9 bytes field.

Metadata Arbitrary metadata to be associated with this Variable transaction. This can be empty

Usage Scenarios The above block chain processing and system shown in Figures 1.0, 2.0 and 3.0 may be used to process various health data and health transactions.

The system specifically deals with utilizing "side chaining" to process the private or semi-private smart contracts between the seller and buyers. A sidechain is a blockchain that validates data from other blockchains. These are implemented via "pegging." A pegged sidechain is a sidechain whose assets can be imported from and returned to other chains; that is, a sidechain that supports two-way pegged assets. Two-way peg refers to the mechanism by which (in our case) assets are transferred between sidechains and back at a fixed or otherwise deterministic exchange rate which is based on contextual rate of transfer or value in the case of our trade or arbitrage asset environment.

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 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 of1/2 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 buyer's 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.

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.

The pseudo code for the smart contract to implement the typical ASC XI 2 referral transaction is as follows. Eligibility transaction user info = transaction. data. user input payer = transaction. data. payer input if payer. fee <= 0 then eligibility payer invoke(user return eligibility_ output PHR transaction userinfo =transaction. data. userinput provider =transaction. data. provider-input if provider. is authorized(user-info) then phr-output = provider. get-user-phr(user-info) return phr_ utput Referral transaction, receives inputs of outputs from Eligibility and PHR transactions

.. . .. . . . .. . .. . ...................................................................................

specialty =transaction. data. provider. specialty input if eligibility-data.isvalid() and phr-data,is-valid() and specialty > "ENT" then transaction. Data. provider. referral. invoke (eligibility, data, phr-data) Patient Behavior and Risk Pool Rated Health Plans With the advent of personal health trackers, new health plans are rewarding consumers for taking an active part in their wellness. Similar to car insurance plans that offer discounts for installing a driving monitor, e.g. Progressive Snapshot@

(https://www.progressive.com/auto/snapshot/), these plans are typically facilitated by the manufacturers of fitness tracking devices and partnerships have been formed, e.g. Fitbit Wellness Partners (hti : //www, fitbit. com/fit bit- wellness/partners. ) The Health Blockchain network will facilitate a more open distribution of the consumer's wellness data and protect it as PHR must be, and therefore prevent lock-in of consumers, providers and payers to a particular device technology or health plan. In particular, since PHR data is managed on the blockchain a consumer and/or company can grant access to a payer to this data such that the payer can perform group analysis of an individual or an entire company's employee base including individual wellness data and generate a risk score of the individual and/or organization. Having this information, payers can then bid on insurance plans tailored for the specific organization. Enrollment then, also being managed on the blockchain, can become a real-time arbitrage process as shown in Figure 5.0 instead of the now typical yearly administrative overhead process. The pseudo code for the smart contract to implement a patient behavior based health plan is as follows. phrifo]=transctin~dataphrinputs claimi4f1 . tX4rsaction. data.caiinputs enwrollment_no] transactin data,enrollmentinputs consumer « keys(phriinfo,dliminfo,*enolmentinfo) for each cnu i conquers risk_scre±+=calculate_risk_forcnsumer) plandetail =calculateplanjfor(risk score) returnsubmittransaction (consumers,plandetail) Patient and Provider Data Sharing A patient's Health Blockchain wallet stores all assets, which in turn store reference ids to the actual data, whether clinical documents inHL7 orFHIR format, wellness metrics of activity and sleep patterns, or claims and enrollment information. These assetsand control of grants ofaccesstothemisafforded tothepatientalone.Given theopendistributionofthe Health.

Block Chain, any participating provider can be given full or partial access to the data instantaneouslyandautomatically viaenforceablerestrictionsonsmartcontracts.In today's typicaldoctor visitscenariowhere anew patient arrives for the first timethe attending physician haslno priorhistory except forwhat isndocumentedinthe paperwork completedbythepatient while waiting tobeseen. This istime consuming andtakes away from the purposeofthevisit.

Utilizing the Health Block Chain, the access to a patient's PHR can be granted as part of scheduling an appointment, during a referral transaction or upon arrival for the visit. And, access can just as easily be removed, all under control of the patient.

A scenario where upon arrival at the doctor's office a Bluetooth proximity sensor can identify a patient running a mobile application on their personal bluetooth capable device which is a proxy for the patient's Health Block Chain wallet is shown in Figure 6.0. This mobile wallet proxy can be configured to automatically notify the provider's office of arrival and grant access to the patient's PHR. At this point the attending physician will have access to the patient's entire health history.

The pseudo code for the smart contract to implement a patient and provider data sharing is as follows. patientsensorstatematransactiondatapatientsensorinput provider~sensor~state trans action .dat a.providertsensorinput phrjdata atranisaction~dataphrinput claim~,data =transaction~ata. claiminput enroliment-data'a transaction. dataenrollmenitinput pat:tient = transaction~data-patientinput provider transaction~data.provider input if patientsensor_state is ONand providersensorstate is ;oNtthen ifppvieisinpatient-trustedsroviderlihst() patient.grantaccesst(provider) return phrdata,'claicfdata',enrollment-data Patient Data Sharing Patient's PH Rdata is valuable information for their personal health profile in order to provide Providers (Physicians) the necessary information for optimal health care delivery. In addition, this clinical data is also valuable inan aggregate scenario of clinical studies where this information is analyzed for diagnosis, treatment and outcome. Currently this information is difficult to obtain due to the siloed storage of the information and the difficulty on obtaining patient permissions.

Given apatient Health Block Chain wallet that stores all assets as reference ids to the actual data. These assets can be included inan automated smart contract for clinical study participation or any other data sharing agreement allowed by the patient. The assets can be shared as aninstance share by adding tothe document arandomized identifier or nonce, similar to aone-time use watermark or serial number, aunique asset (derived from the original source) is then generated for a particular access request and included in a smart contract as an input for a particular request for the patient's health record information.

A patient can specify their acceptable terms to the smart contract regarding payment for access to PHR, timeframes for acceptable access, type of PHR data to share, length of history willing to be shared, de- identification thresholds or preferences, specific attributes of the consumer of the data regarding trusted attributes such as reputation, affiliation, purpose, or any other constraints required by the patient. Attributes of the patient's data are also advertised and summarized as properties of the smart contract regarding the type of diagnosis and treatments available. Once the patient has advertised their willingness to share data under certain conditions specified by the smart contract it can automatically be satisfied by any consumer satisfying the terms of the patient and their relevance to the type of PHR needed resulting in an automated, efficient and distributed means for clinical studies to consume relevant PHR for analysis. This process shown in Figure 7.0 turns a clinical study into an automated execution over the Health Block Chain for any desired time period that will terminate at an acceptable statistical outcome of the required attained significance level or financial limit.

The pseudo code for the smart contract to implement automated patient data sharing is as follows.

rtur ...ph datt

Health Block Chain Data Elements.

Theactualdata,assets,contracts, P, etc. stored on the blockchain are actually resource identifiers which uniquely identify the data, location and access thereof as shown in Figure 1.0. An application participating in the Health Block Chain that fully implements all of the features and stores and distributes actual data elements pointed to by the resource identifiers isshown inFigure 2.0.This HealthBlock Chain application stack can also proxy through aggregation methods access to resource ids where data is stored inlegacy PHR/PM/EMR/E HR and XI 2EDI systems. An example of animplementationofthedatastructurefortheblockchainreducestothe following information: Patients Basic demographics •*First Name •*Last Name •*Middle Name •*Prefix

* Suffix *Gender " Birth Date *Address * Phone(s) • Email(s) Insurance Information " Member ID " Group ID • Total deductible " Remaining deductible • Dependents Health Records " Continuity of Care Document " Consultation Note " Discharge Summary " History and Physical Note " Operative Note " Procedure Note " Progress Note " Unstructured Documents " Claims History " Eligibility History Marketplace Interactions " Specialties Searched " Conditions Searched • Purchases made " Log in frequency • Providers rated/reviewed Self reported Health Statistics via Wearable APIs " BMI • Smoker status " Activity Level • Wellness program memberships Financial Information " FICO Credit Score " Credit reports " Assets/Debts - Lending data from Lending Club Social Network interaction data * twitter, Facebook, linked Wearable API Data •Measured activity level -Sleep cycles Providers Provider Demographics " First Name " Last Name -Middle Name

* Prefix • Suffix *Gender " Birth Date -Address •Phone(s) •Email(s) •Licensing Medical Education -Where and when they went to medical school •Graduation date •Where and when they did their residencies/fellowships •Specialties •Credentials -Certifications Hospital affiliations Pricing " Submitted and paid prices from medicare " Cash prices " Services listed on the marketplace " Responses to requests for quote Ratings, Reviews, Recognitions " Reviews and ratings from marketplace " Malpractice Sanctions from state licensure bodies we receive from the American Medical Association * Ratings and Reviews Claims Statistics • Number of claims submitted, submitted price, reimbursed price per procedure • Number of rejected claims per procedure Pavers (aka Insurance Carriers, Trading Partners) With the processing of XI 2 health transactions, the system can easily obtain the following information: " Payment Statistics: How much does payer X pay on average for procedure Y. • Statistics about time taken to process claims (i.e. average processing time, average time per procedure, etc.) * Statistics about rejected claims. Analysis of claims in general and claims segmented by payer will probably allow us to build predictive models for determining the probability that a claim will be rejected.

The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the disclosure and its practical applications, to thereby enable others skilled in the art to best utilize the disclosure and various embodiments with various modifications as are suited to the particular use contemplated.

The system and method disclosed herein may be implemented via one or more components, systems, servers, appliances, other subcomponents, or distributed between such elements. When implemented as a system, such systems may include an/or involve, inter alia, components such as software modules, general-purpose CPU, RAM, etc. found in general- purpose computers. In implementations where the innovations reside on a server, such a server may include or involve components such as CPU, RAM, etc., such as those found in general- purpose computers.

Additionally, the system and method herein may be achieved via implementations with disparate or entirely different software, hardware and/or firmware components, beyond that set forth above. With regard to such other components (e.g., software, processing components, etc.) and/or computer-readable media associated with or embodying the present inventions, for example, aspects of the innovations herein may be implemented consistent with numerous general purpose or special purpose computing systems or configurations. Various exemplary computing systems, environments, and/or configurations that may be suitable for use with the innovations herein may include, but are not limited to: software or other components within or embodied on personal computers, servers or server computing devices such as routing/connectivity components, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, consumer electronic devices, network PCs, other existing computer platforms, distributed computing environments that include one or more of the above systems or devices, etc.

In some instances, aspects of the system and method may be achieved via or performed by logic and/or logic instructions including program modules, executed in association with such components or circuitry, for example. In general, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular instructions herein. The inventions may also be practiced in the context of distributed software, computer, or circuit settings where circuitry is connected via communication buses, circuitry or links. In distributed settings, control/instructions may occur from both local and remote computer storage media including memory storage devices. The software, circuitry and components herein may also include and/or utilize one or more type of computer readable media. Computer readable media can be any available media that is resident on, associable with, or can be accessed by such circuits and/or computing components. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media.

Computer storage media includes volatile and nonvolatile, removable and non removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and can accessed by computing component. Communication media may comprise computer readable instructions, data structures, program modules and/or other components. Further, communication media may include wired media such as a wired network or direct- wired connection, however no media of any such type herein includes transitory media. Combinations of the any of the above are also included within the scope of computer readable media.

In the present 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.

Claims (10)

WE CLAIM

1. Our Invention "MCHO- Blockchain Technology "is a system and technology for matching and mapping patients with clinical trials and previous data set record under block-chain process to prequalifying patients for clinical trials and previous data set record and providing information to patients to allow them to inform themselves about available clinical trials and previous data set record. The method and technology sequential comprises receiving patient old and new profile information for a patient at a data base and local server connected to a computer network with defined IP- address and ID- no, the patient profile information fetch by using block -chain technology and submitted by a user at a terminal connected to the network, comparing the patient profile information with acceptance criteria for clinical trials stored in a database. The invented technology comparison performed by the local and global server, determining whether the patient prequalifies for any of the clinical trials, and notifying the user and the previous data set record whether the patient has prequalified for any clinical trials. The invented medical system includes a network one or more medical data collection appliances coupled to the network each appliance transmitting data conforming to an interoperable format and a local and global server coupled to the network to store data for each individual in accordance with the interoperable format and also format as per required data can change. The invented system and technology for a decentralized autonomous healthcare economy platform are provided and also the system and technology aggregates all of the healthcare data into a global graph-theoretic topology and processes the data via a hybrid federated and peer to peer distributed processing architectures.

2. According to claim# The invention is to a system and technology for matching and mapping patients with clinical trials and previous data set record under block-chain process to prequalifying patients for clinical trials and previous data set record and providing information to patients to allow them to inform themselves about available clinical trials and previous data set record. The invention is to the method and technology sequential comprises receiving patient old and new profile information for a patient at a data base and local server connected to a computer network with defined IP- address and ID- no, the patient profile information fetch by using block -chain technology and submitted by a user at a terminal connected to the network, comparing the patient profile information with acceptance criteria for clinical trials stored in a database.

3. According to claiml,2# The invention is to the invented technology comparison performed by the local and global server, determining whether the patient prequalifies for any of the clinical trials, and notifying the user and the previous data set record whether the patient has prequalified for any clinical trials.

4. According to claim,2,3# The invention is to the invented medical system includes a network one or more medical data collection appliances coupled to the network each appliance transmitting data conforming to an interoperable format and a local and global server coupled to the network to store data for each individual in accordance with the interoperable format and also format as per required data can change.

5. According to claim,2,4# The invention is to the invented system and technology for a decentralized autonomous healthcare economy platform are provided and also the system and technology aggregates all of the healthcare data into a global graph-theoretic topology and processes the data via a hybrid federated and peer to peer distributed processing architectures.

6. According to claim,2,4# The invention is to wherein the server transmits a plurality of questions over the Internet, the server also transmits a plurality of answer choices for each question, the server receives responses, and the server builds a patient profile based on the responses and also the invention is to wherein the server retrieves a disease/sub-disease record corresponding to a received disease/sub-disease, the disease/-sub-disease record containing links to question records, the server retrieving the question records to access questions.

7. According to claiml,2,5# The invention is to wherein the completed application is submitted to the server and also the invention is to further comprising the server forwarding to the completed application to the clinical trial site. The invention is to further comprising the server forwarding the registration information to the clinical trial site with the completed application.

8. According to claiml,2,6# The invention is to comprising an in-door positioning system coupled to one or more mesh network appliances to provide location information and also the invention is to comprising a call center coupled to the appliance to provide a human response. The invention is to wherein the server is coupled to a a wireless mesh network where data hops through neighboring nodes of the mesh network to reach a final destination.

9. According to claim1,2,3,5# The invention is to The invention is to comprising a wireless router coupled to a mesh network and wherein the wireless router comprises one of: 802.11 router, 802.16 router, WiFi router, WiMAX router, Bluetooth router, X10 router and also the comprising a mesh network appliance coupled to a power line to communicate X10 data over a mesh network. The comprising a bio impedance analyzer to determine one of: total body water, compartmentalization of body fluids, cardiac monitoring, blood flow, skinfold thickness, dehydration, blood loss, wound monitoring, ulcer detection, deep vein thrombosis, hypovolemia, hemorrhage, blood loss, heart attack, stroke attack.

10. According to claim,2,9# The invention is to wherein the appliance transmits and receives voice from the person over the mesh network to one of: a doctor, a nurse, a medical assistant, a caregiver, an emergency response unit, a family member. The invention is to comprising code to store and analyze patient information including medicine taking habits, eating and drinking habits, sleeping habits, or excise habits.

FIG. 1-A: DEPICTS A BLOCK DIAGRAM ILLUSTRATING THE SYSTEM OF THE PRESENT INVENTION.

FIG. 2-A: DEPICTS A FLOWCHART ILLUSTRATING A METHOD OF MATCHING A PATIENT WITH AVAILABLE CLINICAL TRIAL SITES AND PREQUALIFYING PATIENTS FOR CLINICAL TRIALS.

FIGS. 3A-3D: DEPICT BLOCK DIAGRAMS ILLUSTRATING SOME EXEMPLARY LINKS BETWEEN VARIOUS RECORDS IN DATA STORAGE DEVICE 120.

FIG.1: IS A SYSTEM FOR DECENTRALIZED HEALTHCARE THAT HAS A PEER TO PEER ARCHITECTURE.

FIG.1-B: IS AN EXAMPLE OF A COMPUTER SYSTEM IMPLEMENTATION OF THE DECENTRALIZED SYSTEM.

FIG.2: IS AN EXAMPLE OF A HEALTHCARE BLOCKCHAIN APPLICATION THAT IS PART OF THE DECENTRALIZED SYSTEM.

FIG.3: IS AN EXAMPLE OF A HEALTHCARE BLOCKCHAIN.

FIG.4: IS AN EXAMPLE OF A REFERRAL WORKFLOW OF THE DECENTRALIZED HEALTHCARE BLOCK CHAIN SYSTEM.

FIG.5: IS AN EXAMPLE OF A PROCESS FOR PATIENT BEHAVIOR HEALTH PLAN.

FIG. 6: IS AS PATIENT AND PROVIDER DATA SHARING PROCESS OF THE OF THE.