CA3098242A1

CA3098242A1 - Human-centric record system and related methods

Info

Publication number: CA3098242A1
Application number: CA3098242A
Authority: CA
Inventors: Luc Bessette; Yves Leborgne; Francois Desloges; Mathieu Rousseau
Original assignee: Individual
Current assignee: Individual
Priority date: 2020-11-05
Filing date: 2020-11-05
Publication date: 2022-05-05

Abstract

A Human-Centric electronic health record (EHR) system is provided. The Human-Centric EHR system allows for a patient to have a centralized access of his/his health records. The health records associated with the patient may be obtained from multiple sources in an EHR network, where the EHR network comprises multiple nodes storing health records associated with the patient. By obtaining the health records associated with the patient from multiple sources allows for a patient to have a centralized access of his/her health records. Also, a centralized storage of health records associated with a patient also allows for the patient to have certain level of control over his/his health records, such as providing his/her health records to a third-party.

Description

TITLE: Human-Centric health record system and related methods FIELD OF THE INVENTION
The invention generally relates to electronic health record systems and in particular to Human-Centric health record systems and related methods.
BACKGROUND
Medicine has been for a long time a top down activity, where all activities are dictated by the capabilities and restrictions of care providers, and where the patient ends up being a passive voice in the decisions and chain of events. The doctor has the knowledge and the office, the patient has the waiting room. The patient's medical information is gathered and stored in the doctor's or hospital record. The patient must wait to get results and then wait again for a doctor that is part of his health management organization to be available. Pertinent medical data are the product of medical interventions and patient driven medical data is often not deemed contributive.
Physicians are doing medical research ¨ patients are studied.
The data and the power are currently in the hands of the few who are collecting the information.
Cloaked with the screen of confidentiality, the information is not even shared nor aggregated in a cooperative way. For instance, health records associated with a patient may be stored at various locations, such as at an electronic health record (EHR) system associated with a physician, as part of a government regulated or state-owned health record system, pharmacies, health maintenance organizations (HMOs) and the like. A problem with such EHR systems is that a patient's health records are dispersed across multiple sources (e.g., multiple computer systems) and are not easily accessible if a patient wants a comprehensive record of his/her medical history.
As a patient's health records are located at multiple sources, this can further be a problem if a patient visits a new physician outside of the patient's regular physician's office and/or receives care outside of his normally accessible care delivery network, as the new physician does not have a complete understanding of the patient's medical history. Moreover, any medical information regarding the new physician's assessments of the patient is not added to patient's file at the Date Recue/Date Received 2020-11-05 regular physician's office and/or the file that is part of the patient's normally accessible care delivery network.
Another problem with patients' electronic health records (EHRs) is that as these records may contain confidential and/or privileged information, the communication of the health records and gaining access to health information should be done in a risk-free way such that confidentiality is maintained. A process of authentication of a user trying to remotely access health records is, therefore, a key component of the safety of an electronic record system. The process of authentication of the user consists of validating that a user trying to access the confidential and/or privileged data corresponds to the user who is authorized to consult the confidential and/or privileged data and not the unauthorized users. Some authentication systems have tried to remedy this situation and provide safer authentication. However, these authentication processes require a succession of steps (e.g., an increased number of passwords, an increased complexity of passwords, etc.) rendering the process less user-friendly, and not necessarily rendering the authentication significantly safer.
A further problem with patients' health records being located at multiple sources is that if third-parties (e.g., agents) would like access to patient information for various reasons they are required to obtain consent from the patient for each source and then access each of the various sources that store patients' health records separately to obtain a more complete medical history of the patients.
Obtaining consent from patients from multiple sources and then accessing multiple sources can be tedious especially where patient information is desired for a large group of patients.
Moreover, research institutes everywhere are using home-grown, institute specific tools to garner patient consent, and track both the patient and the patient's data as the patient moves from clinical procedure to clinical procedure.
In addition, when patients gets medical results done (e.g., tests, lab work, imaging, etc.) they are typically not informed if their medical results have been processed, completed or reviewed, unless their physician contacts them. This often leaves patients in a state of uncertainty and anxiety regarding their medical results and/or the completion status.
A patient may also make use of various portable and wearable devices, which measure various physical conditions. The data from these various devices are typically stored in a distributed computing environment (e.g., the "cloud") which is separate from the other sources containing

2 Date Recue/Date Received 2020-11-05 health records associated with the patient, which results in yet another source of health records associated with the patient.
In light of the above, there is a need in the industry for providing an improved EHR system and improved methods relating to EHR systems that alleviates, at least in part, the deficiencies with existing EHR systems.
SUMMARY
In accordance with a first broad aspect, a Human-Centric electronic health record (EHR) system is provided. The Human-Centric EHR system may be able to obtain and/or receive various health records associated with one or more patients from one or more EHR networks that includes one or more nodes. The nodes in the EHR network may store health records associated with patients thereon. By accessing the EHR network, which may be done via a practitioner's EHR system, the health records associated with patients stored in the EHR network may be duplicated at least in part to the Human-Centric EHR system.
In accordance with a specific and non-limiting example of implementation of the first broad aspect, a patient via a patient's computing entity may access the Human-Centric EHR system to have access to his/her health record.
In accordance with a specific and non-limiting example of implementation of the first broad aspect, a health related determination mechanism is provided for allowing a patient's health record to be processed by the Human-Centric EHR system to derive a health related determination.
In accordance with a specific and non-limiting example of implementation of the first broad aspect, a third-party access mechanism is provided for allowing a third-party to access and/or process a patient's health record.
In accordance with a specific and non-limiting example of implementation of the first broad aspect, an anonymized health record access mechanism is provided for providing anonymized health records to third-parties.

3 Date Recue/Date Received 2020-11-05 In accordance with a specific and non-limiting example of implementation of the first broad aspect, the Human-Centric EHR system is provided for sharing a patient's health record among a care support group.
.. In accordance with a second broad aspect, a method for populating an electronic health record system with health records associated with respective patients is provided.
The method includes:
(a) querying a centralized health record network storing health records about multiple patients, the querying being performed in the context of a physician dispensing medical services to a first patient of the multiple patients, the querying including accessing the health record of the first patient; (b) copying some or all of the information in the health record of the first patient to the electronic health record system to create health record for the first patient in the electronic health record system; (c) repeating steps (a) and (b) for a second patient of the multiple patients;
and (d) where the physician dispenses medical services to only a subset of patients of the multiple patients.
In accordance with a specific and non-limiting example of implementation of the second broad aspect, the method includes providing an account to the first patient such that the first patient can access the health record associated therewith on the electronic health record system.
In accordance with a third broad aspect, a method for providing health records associated with a patient to an electronic health record system is provided. The method includes: receiving an indication for a request to obtain the health records associated with the patient; requesting the health records associated with the patient from an electronic health record network comprising a plurality of nodes, the health records associated with the patient being distributed amongst the plurality of nodes of the health record network; obtaining the health records associated with the patient, in response to requesting the health records associated with the patient from the electronic health record network; and transmitting the health records associated with the patient to an electronic health record system for centralized storage of the health record.
In accordance with a fourth broad aspect, a method for providing at least one computing device associated with a patient a notice that medical results associated with the patient have been received at an office associated with a physician is provided. The method includes: receiving from an electronic record system associated with the physician an indication that medical results associated with the patient have been received at the office associated with the physician;

4 Date Recue/Date Received 2020-11-05 transmitting to a computing entity associated with the patient an first notice that medical information is available; receiving a request for the medical information from the computing entity associated with the patient, the request including authentication information; and if the authentication information is associated with the patient, transmitting to the computing entity associated with the patient a second notice, the second notice indicating that medical results associated with the patient have been received at the office associated with the physician.
In accordance with a fifth broad aspect, a method for providing medical results associated with a patient to a computing device associated with the patient is provided. The method includes:
receiving medical results associated with the patient from an electronic record system associated with a physician; transmitting to a computing entity associated with the patient an first notice that medical information is available; receiving a request for the medical information from the computing entity associated with the patient, the request including authentication information;
and if the authentication information is associated with the patient, transmitting to the computing entity associated with the patient a second notice, the second notice comprising the medical results associated with the patient.
In accordance with a sixth broad aspect, a method for making a health related determination is provided. The method includes: monitoring data obtained from one or more sensors measuring a physical condition of a patient, the monitoring of the data from the one or more sensors being done over a plurality of time points; storing the data from the one or more sensors in association with medical records associated with the patient; and processing the data from the one or more sensors against the medical records associated with the patient to make a health related determination, the medical records being obtained from a plurality of electronic health record systems.
In accordance with a seventh broad aspect, a method for providing a third-party with health records associated with a patient is provided. The method includes: receiving a request to provide the third-party with the health records associated with the patient;
authenticating the request with a computing device associated with the patient; and providing a third-party computing device with access to the health records associated with the patient.
In accordance with a eighth broad aspect, a method of providing health records to an agent is provided. The method includes: receiving a request for a plurality of health records meeting a

5 Date Recue/Date Received 2020-11-05 specific criteria from a third-party computing entity associated with the agent; obtaining a plurality of health records meeting the specific criteria; and providing to the third-party computing entity the plurality of health records.
These and other aspects of the invention will now become apparent to those of ordinary skill in the art upon review of the following description of embodiments of the invention in conjunction with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
A detailed description of embodiments of the invention is provided below, by way of example only, with reference to the accompanying drawings, in which:
Figure IA illustrates a block diagram of an example Human-Centric electronic health record (EHR) system connected to various other EHR systems and to a computing entity associated with a patient in accordance with an embodiment of the invention.
Figure 1B illustrates a block diagram of an example EHR network comprising a central EHR
system in accordance with an embodiment of the invention.
Figure IC illustrates a block diagram of an example EHR network comprising various EHR
systems and a computing entity associated with a patient connected to the EHR
network in accordance with an embodiment of the invention.
Figure 2A illustrates a block diagram of a Human-Centric EHR system in accordance with a specific example of implementation.
Figure 2B illustrates a block diagram of a physician's EHR system in accordance with a specific example of implementation.
Figures 3A to 3C illustrates examples of data records in accordance with embodiments of the inventions.

6 Date Recue/Date Received 2020-11-05 Figure 4A illustrates a flowchart of a process, which may be implemented by the physician's EHR system of Figures 1A-1C in accordance with a specific example of implementation.
Figure 4B illustrates a flowchart of a process, which may be implemented by the Human-Centric EHR system in accordance with a specific non-limiting example of implementation.
Figure 4C illustrates a flowchart of a process, which may be implemented by central EHR system in accordance with a specific non-limiting example of implementation.
Figure 5A illustrates a block diagram of an EHR network comprising a single EHR system in accordance with a specific non-limiting example of implementation.
Figure 5B illustrates a block diagram of an EHR network comprising a plurality of EHR systems accessible by a server in accordance with a specific non-limiting example of implementation.
Figure 5C illustrates a block diagram of an EHR network comprising a plurality of EHR systems in accordance with a specific non-limiting example of implementation.
Figure 6 illustrates a block diagram of an example of a Human-Centric EHR
system that is able to provide patients with medical results upon authorization in accordance with an embodiment of the invention.
Figure 7A illustrates a flowchart of a process for determining if the Human-Centric EHR system should be notified of receipt of medical results at a physician's office in accordance with a specific non-limiting example of implementation.
Figure 7B illustrates a flowchart of a process for transmitting medical results to the Human-Centric EHR system in accordance with a specific non-limiting example of implementation.
Figure 8A illustrates a flowchart of a process for sending a notice to the patient's computing entity in accordance with a specific non-limiting example of implementation.

7 Date Recue/Date Received 2020-11-05 Figure 8B illustrates a flowchart of a process for sending medical results associated with the patient to the patient's computing entity in accordance with a specific non-limiting example of implementation.
Figure 9 illustrates a block diagram of an example of a Human-Centric EHR
system that is able to receive and obtain auxiliary medical related information in accordance with an embodiment of the invention.
Figure 10 illustrates a flowchart of a process for making a health related determination in accordance with a specific non-limiting example of implementation.
Figure 11 illustrates a block diagram of an example of a Human-Centric EHR
system that provides health records associated with a patient to a third-party EHR system in accordance with an embodiment of the invention.
Figure 12A illustrates a flowchart of a first process for providing one or more health records associated with a patient to a third-party in accordance with a specific non-limiting example of implementation.
Figure 12B illustrates a flowchart of a second process for providing one or more health records associated with a patient to a third-party in accordance with a specific non-limiting example of implementation.
Figure 13A illustrates a block diagram of an example of a Human-Centric EHR
system that provides health records associated with a patient to a third-party EHR system in accordance with another embodiment of the invention.
Figure 13B illustrates a flowchart of a third process for providing one or more health records associated with a patient to a third-party in accordance with a specific non-limiting example of implementation.
Figure 14 illustrates a block diagram of an example of a Human-Centric EHR
system for providing patient anonymized health records to a third-party computing entity in accordance with an embodiment of the invention.

8 Date Recue/Date Received 2020-11-05 Figure 15 illustrates a flowchart of a process for providing patient anonymized health records to a third-party in accordance with a specific non-limiting example of implementation.
Figures 16A, 16B, 16C, 16D, 16E and 16F illustrate specific and non-limiting examples of information that may be displayed on a graphical user interface (GUI) of a patient's computing entity in accordance with specific examples of implementation.
Figures 17A, 17B and 17C illustrate specific and non-limiting examples of notices in accordance with specific examples of implementation.
Figure 18 illustrates a block diagram of an example Human-Centric EHR system connected to various other EHR systems and to a computing entity associated with a patient in accordance with an embodiment of the invention.
Figures 19A, 19B, 19C, 19D and 19E illustrate specific and non-limiting examples of information that may be displayed on a graphical user interface (GUI) of a physician's computing entity in accordance with specific examples of implementation.
.. Figures 20A and 20B illustrate flowcharts of processes for creating a care support group in accordance with a specific non-limiting example of implementation.
Figure 21 illustrates an example of a data structure for the care support group in accordance with a specific non-limiting example of implementation.
Figure 22 is a block diagram showing a system according to another embodiment of the disclosure, allowing a secure user authentication;
Figures 23 to 25D show flowcharts of methods of operation for the system depicted in Figure 22;
Figures 26A to 26D are block diagrams showing variants of the system illustrated in Figure 22;
Figures 27A to 27G show Graphical User Interfaces (GUI) through which users interact with the system of Figure 21, in particular for performing user authentication.

9 Date Recue/Date Received 2020-11-05 Figure 28 is a flowchart describing a method performed by the system of Figure 22;
Figure 29 is a flowchart describing a method according performed by the system of Figure 22, according to a variant;
Figure 30 is a method to implement the system; and Figures 31 to 33D show flowcharts of alternative methods performed by the system of Figure 22;
Figure 34 is a block diagram illustrating a network architecture where the Human-Centric EHR
system interfaces with other networks, which are not interoperable with the Human-Centric EHR
system.
Figure 35 is a flow diagram of a process illustrating the interaction between the Human-Centric EHR system and an external network to communicate medical data;
Figure 36 is flow diagram of a process for accessing medical data from the Human-Centric EHR
system, which resides on an external network;
Figure 37 is a flow diagram illustrating the operation of a software function to generate and dynamically maintain a medical information index;
Figures 38 to 41 are examples of Graphical User Interfaces (GUIs) allowing a patient to set up a data privacy management function at the Human-Centric EHR system;
Figure 42 is a flow diagram of a process for a patient to set up the data privacy settings;
Figure 43 is a block diagram of a user profile of the Human-Centric EHR system Figure 44 is a flowchart illustrating the operation of a theme-based filter to selectively mask medical information to preserve its confidentiality;
Figure 45 is a flowchart of a process for managing the access of authorized users, such as treating physicians to the medical information of the patient;
Date Recue/Date Received 2020-11-05 Figure 46 is a flowchart of a further process for managing the access of authorized users to the medical information of the patient Figure 47 is a block diagram of a machine-readable data structure mapping medical data items to respective identifiers Figure 48 is an example of a user interface where the patient can selectively mask medical information on the basis of certain themes Figure 49 is block diagram of the elements of the Human-Centric EHR system showing a consent manager associated with a user profile Figure 50 is a flowchart of a process to manage requests from external entities to access medical data Figure 51 is flowchart of some specific steps of the process shown at Figure Figure 52 is a diagram showing conceptually the data structure of a consent data element Figure 53 is an example of a user interface to manage consents Figure 54 is a further example of a GUI for managing consents Figure 55 is yet another example of a GUI for managing consents Figure 56 is a flowchart of a process to manage the validity of consents Figure 57 illustrates an options hierarchy to set admissibility criteria Figure 58 is a flowchart of a process to send to a third-party medical data Figure 59 is a process to notify a user if anomalous result is identified in medical data sent to a third party Date Recue/Date Received 2020-11-05 Figure 60 is a flowchart of a process to provide to a user recommendations about the suitability of the user medical data for particular research projects Figure 61 is block diagram of a networked arrangement allowing the Human-Centric EHR system to communicate with research organizations through an online portal Figure 62 is a flowchart of a process that receives the information defining the parameters of a research project and tries to match the research project to individual subscribers Figure 63 is a representation of a GUI allowing a user to manage participation in a research project It is to be expressly understood that the description and drawings are only for the purpose of illustrating certain embodiments of the invention and are an aid for understanding. They are not intended to be a definition of the limits of the invention.
It is to be expressly understood that the description and drawings are only for the purpose of illustrating certain embodiments of the invention and are an aid for understanding. They are not intended to be a definition of the limits of the invention.
DETAILED DESCRIPTION
Current medical systems are neither human-centric, nor patient-driven, nor patient-aware. The scope of this disclosure is to reverse the data ownership paradigms, empowering the patient himself in key data collection and access decisions, and set the ground for a transformation by which the medical system is human-centric, patient-driven and patient aware.
For example, whenever new data is stored in an electronic health record or a health information system, a proxy could alert the key holder. Informed that his laboratory result may be commented by his practitioner before a set time, he may have the possibility to pursue it after that delay or, better, read the comment and initiate a course of action accordingly. If his doctor is not available, he could consult a third-party doctor and give him for a period of time access to his medical information through his private key. Accessing this information, the third-party doctor may carry an on-site or telemedicine consultation with the patient.

Date Recue/Date Received 2020-11-05 A Human-Centric health record infrastructure may allow for the process of separating the nominative (name, address, phone number or any identifying tag) from the content-rich non-nominative information (rich medical data). A Human-Centric health record infrastructure may also allow the ability to ask individually for permission to use non-nominative data for research, such as allowing for the ability to identify query-driven cohort of patients.
Such cohorts could be established from patient records by allowing an agent to find all patients matching certain criteria, and eventually request from each patient permission to access the health records required to conduct further specific health analyses establishing in this way patient membership in a specific research topic. The patient may have the ability to permit/deny his discoverability for cohorts, and also assuming he has authorized discoverability, permit/deny use of his health record in the fulfillment of the intent of the cohort. By definition, a cohort may be non-nominative to protect the privacy of the patient.
Data derived from cohorts of patients is very seldom paid back by users, those being epidemiologists, pharmaceutical companies, biomedical companies, etc. Some users may pay a third party for databanks derived of patient data but patients themselves are for the most part ignored completely when one has to pay for collected data. With the embodiment of the invention, patients may repossess their data and may get some advantage of having their data used either by having a small share of profits derived by the use of their data or some other financial compensation.
These and other aspects should likely become more readily apparent to the person skilled in the art throughout this document.
Human-centric EHR System Figure IA illustrates a block diagram of an example Human-Centric electronic health record (EHR) system 102 connected to various other EHR systems and to a computing entity associated with a patient in accordance with an embodiment of the invention. As illustrated the Human-Centric EHR system 102 is connected to the patient's computing entity 106 (e.g., a computing entity associated with a patient) and to a physician's EHR system 104 (e.g., an EHR system associated with a physician) which is connected to an EHR network 108.
Although in Figure I
only a single Human-Centric EHR system 102, a single physician's EHR systems 104, a single Date Recue/Date Received 2020-11-05 EHR network 108 and a single patient's computing entity 106 are shown, this is for illustration purposes only, as one or more Human-Centric UR systems, one or more physician's EHR
systems, one or more EHR networks and one or more patient's computing entities may be used in implementing the various embodiments described herein.
The various connections between the Human-Centric EHR system 102, the patient's computing entity 106, the physician's EHR system 104 and/or the EHR network 108 may include one or more connections over one or more data networks (e.g., the Internet, local area network (LAN), or a wide area network (WAN), cellular networks, other wired or wireless networks and/or any other suitable data network). In other words, the Human-Centric EHR system 102, the patient's computing entity 106, the physician's EHR systems 104 and/or the EHR network 108 may be nodes in one or more data networks linked by communication paths. The various connections between the Human-Centric EHR system 102, the patient's computing entity 106, physician's EHR systems 104 and/or the EHR network 108 may allow for the communication (e.g., transmission and/or reception) of various information and/or data between the various systems and/or devices. The various information and/or data exchanged may be notices, data records, health records, medical records and/or medical related information. The term "health record" may be used throughout this document to refer to a single data record, health record, medical record and/or other medical or health related information and/or data and the term "health records" may be used throughout this document to refer to a plurality of data records, health records, medical records and/or other medical or health related information and/or data.
Reference to a single "health record" in this document may include reference to a plurality of "health records".
In general terms, the patient centric EHR system 102 allows for a patient to have centralized storage of his/her health records by obtaining the health records associated with the patient from various sources and also allows for the patient to have some control over his/her health records.
In other words, "patient centric" refers to the patient centric EHR system 102 possibly offering a patient with fine-grained control over visibility of health records associated with the patient. The control of the health records associated with the patient may include who can view the health records and/or what health records can be viewed. In particular, some health records may have a 'for your eyes only' nature, and be annotated as such. In that case, the patient centric EHR system 102 may only transmit the information when the patient has identified himself strongly as being the recipient. Furthermore, the 'for your eyes only' annotation may cause the health record being becoming 'invisible' after a set delay after the patient has seen the content.
For instance, the Date Recue/Date Received 2020-11-05 health record may become 'invisible' by revoking any and all access rights that could exist for the record, for other users other than the patient himself/herself. Also, the record may become destroyed from volatile memory and then may only be viewed again if the patient himself/herself requests the records after a two-factor authentication at the device (e.g., finger print and user identifier). These and other aspects of the patient centric EHR system 102 should likely become more readily apparent to the person skilled in the art throughout this document.
Figure 2A illustrates a block diagram of the Human-Centric EHR system 102 in accordance with a specific example of implementation. In general terms, the Human-Centric EHR
system 102 may be a single computing entity or a distributed computing environment (e.g., server arrangements) that stores health records associated with patients. As illustrated, the Human-Centric EHR system 102 comprises at least one processor 202, input/output circuity 210 and at least one computer readable memory 204 comprising at least one database 206 and a Human-Centric EHR program 208 (e.g., program code, application software, etc). The at least one processor 202, input/output circuity 210 and at least one computer readable memory 204 may be connected by various data buses and in the case of a distributed computing environment may be interconnected by one or more data networks. The at least one database 206 stores one or more health records associated with a patient and stores a plurality of health records associated with a plurality of patients. The Human-Centric UR program 208 comprises program code which when executed by the at least one processor 202 causes the Human-Centric EHR system 102 to perform various operations. The input/output circuity 210 may be used to connect the Human-Centric EHR system 102 to one or more data networks and to other peripheral devices (e.g., keyboard, mouse, monitor/display, printer and/or any other suitable device).
Figure 2B illustrates a block diagram of the physician's EHR system 104 (e.g., an EHR system associated with a physician and/or any other health related practitioner) in accordance with a specific example of implementation. In general terms, the physician's EHR
system 104 may be a single computing entity or a distributed computing environment (e.g., server arrangements) that stores health records associated with patients. For instance, the physician's EHR system 104 may be of the type that is typically found in physician's office for maintaining health records of patients but with additional functionality as should likely become more readily apparent to the person skilled in the art throughout this document. As illustrated, the physician's EHR system 104 comprises at least one processor 222, input/output circuity 230 and at least one computer readable memory 224 comprising at least one database 226 and at least one physician's EHR
Date Recue/Date Received 2020-11-05 program 228. The at least one processor 222, input/output circuity 230 and at least one computer readable memory 224 may be connected by various data buses and in the case of a distributed computing environment may be interconnected by one or more data networks. The at least one database 226 stores one or more health records associated with a patient and stores a plurality of health records associated with a plurality of patients. The physician's at least one EHR program 228 comprises program code which when executed by the processor 222 causes the physician's EHR system 104 to perform various operations. The input/output circuity 230 may be used to connect the physician's EHR system 104 to one or more data networks and to other peripheral devices (e.g., keyboard, mouse, monitor/display, printer and/or any other suitable device).
The patient's computing entity 106 (e.g., a computing entity associated with a patient) may be any portable or non-portable computing device, such as a cell-phone, a tablet, a smart watch, a laptop/notebook computer, a computer or any other suitable computing device.
The patient's computing entity 106 may comprise program code that when executed cause the patient's computing entity 106 to perform various operations, such as application software. In some cases, the patient's computing entity 106 runs application software that is associated with the Human-Centric EHR system 102. The application software may include client-side program code used to interact with the Human-Centric EHR system 102 having server-side program code. For example, client-side program code may include JavaScript that invokes AJAX quires to the server-side program code of the Human-Centric EHR system 102. The patient's computing entity 106 may include a display/screen or is connect to a display/screen in which a graphical user interface (GUI) may be provided. The GUI may be conditioned based on the program code (e.g., application software) and/or various data received from the Human-Centric EHR
system 102.
The EHR network 108 may comprises one or more EHR systems. In general terms, an EHR
system may be a single computing entity or a distributed computing environment (e.g., server arrangements) that stores health records associated with patients and the EHR
system typically includes at least one processor, input/output circuity and computer readable memory including a database and program code. For instance, the one or more EHR systems of the EHR network 108 may be similar to the physician's EHR system 104 and/or the Human-Centric EHR
system 102 described elsewhere in this document. The one or more EHR systems of the EHR
network 108 may include one or more systems such as: health maintenance organization's (HMO's) EHR
system; other physicians' EHR systems; EHR systems associated with pharmacies;
EHR systems associated with dentists; EHR systems associated with optometric; EHR systems associated with Date Recue/Date Received 2020-11-05 other medical facilities (e.g., laboratories such as testing and imagining labs); government regulated or state-owned health record system; and/or any other suitable system. By way of example, in Quebec, the government regulated health record system is the DSQ
(Dossier de sante du Quebec) and is some embodiments, the EHR network 108 comprises the DSQ. As such, the EHR network 108 may include a central EHR system 503, as shown in Figure 1B, implemented as a single computing entity or a distributed computing environment (e.g., server arrangements) that typically includes at least one processor, input/output circuity and computer readable memory including a database and program code. It is appreciated that the central EHR system 503 may be a government regulated or state-owned EHR system or HMO's EHR
system and/or any other suitable EHR system.
In some cases the EHR network 108 may comprise a medical information exchange (MIE) or a summary medical record system. MIEs and summary medical record systems are known in the art, such as the type disclosed in Canadian Patent No. 2,329,598 or PCT
International Publication No. WO 2015/031980, both of which are incorporated herein by reference. In other words, the EHR network 108 may be implemented in a distributed nature in a data network including multiple nodes linked by communication paths. That is, the EHR network 108 may be implemented by one or more nodes in a data network linked by communication paths. As various implementation of the EHR network 108 are known in the art, the EHR network 108 does not need to be described in detail because such systems are well within the reach of a person skilled in the art.
Figures 3A to 3C illustrate examples of data records 302 in accordance with embodiments of the invention. It will be understood that the representation is conceptual to facilitate the understanding of the way the information is organized and it is not intended to be limiting in terms of how the data conveying that information is being structured or how the information is shown on a display device.
The data record 302 includes a record identifier 304 and record data 306. The record identifier 304 is used to identify the specific data record 302 and to distinguish it from the data records of other patients. The record data 306 is associated with the record identifier 304 such that information relevant to a specific patient identified by the record identifier 304 is stored in the record data 306 of the data record 302. The record data 306 may be physically stored in one centralized location or may be stored in a distributed fashion with a mechanism to link the various Date Recue/Date Received 2020-11-05 data components together so all the useful information can be retrieved when required. As such, the record data 306 may include data/information and/or may point to locations where data/information may be stored.
By way of example, Figure 3B illustrates a data record 302A having a record identifier 304A and a plurality of records 306A 306B 306c where each of the records 306A 306B 306c includes a respective pointer pointing to respective ones of the data records 302B 302c 302D. Each of the data records 302B 302c 302D has a respective identifier 304B 304c 304D and respective data record 306B 306c 306D. It is appreciated that in these examples that the record data 306 may be a combination of data that is stored in one location and also includes links and/or pointers to data stored in a remote location, which can be accessed when required by downloading the data from the remote location pointed to by the one or more links. Although in Figure 3A
that the data record 302 is shown to only include a single record data 306, it is appreciated that the data record 302 may include a plurality of records of the type of the data record 306, such as shown in Figure 3B.
By way of another example, Figure 3C illustrates an example that is similar to that of Figure 3B, as data record 302A has a record identifier 304A and a plurality of records 306A 306B 306c where each of the records 306A 306B 306c includes a respective pointer pointing to respective ones of the data records 302B 302c 302D. However, as shown in Figure 3C, the data records 302B 302c 302D
are respectively stored on separate EHR systems, namely, a physician's EHR
system 104A, a laboratory EHR system 104B and a hospital EHR system 104c (e.g., such as shown in Figure IC).
The data record 302 may be a health record of the type used (e.g., accessed, stored, obtained, communicated, transmitted and/or received) by the various systems and devices discussed in this document. As such, "health record" may be used to refer to a data record of the type of the data record 302 and "health records" may be used to refer to a plurality of data records of the type of data record 302. The record data 306 of the data record 302 may include links and/or pointers to other data records of the type of the data record 302 by pointing to these other data records' identifiers and where these other data records' record data includes the additional information associated with the data record 302. Reference to a single "data record" in this document may include reference to a plurality of "data records". It is appreciated that the health records may be located at various nodes (e.g., various EHR systems and/or other suitable computer based system) in the EHR network 108.

Date Recue/Date Received 2020-11-05 In the embodiments where the data record 302 is a health record, the data record 302 may include information such as: prescribed medication, delivered medication, laboratory results, pathology reports, consultation reports, imaging reports and images themselves, ECG
(electrocardiogram) reports or the images themselves, surgical or procedure reports with or without images, allergies or medication intolerances, hospitalization summaries, physician summaries and/or any other suitable information. The data record 302 may also include patient identification information such as the patient's name, address, date of birth, health card number, primary physician, the issuing physician that prescribed the medication or medial test, and/or any other suitable information.
The information stored in the data record 302 is not limited to the non-exhaustive list given above, a person skilled in the art would understand that other types of patient health and/or medical information may also be stored in the data record 302 in the various embodiments disclosed in this document.
In some embodiments, where the data record 302 is a health record stored on the EHR network 108, the data record 302 may include a summary component that includes information such as summaries of: Administrative Data, Permanent Biological Data, Significant Antecedents, Current Medical Conditions, Biological Data, Prescribed and/or Delivered Medications, Laboratory Results, Pathology Reports, Consultation Reports, Imaging Reports and Images, ECG reports and/or ECG Images, Surgical or Procedure Reports, Allergies and/or Medication Intolerances, Hospitalization Summaries or Physician Summaries. Furthermore, each summary may be associated with a pointer, which points to more complete information provided by the summary.
By way of a specific and non-limiting example, the ECG reports summary may list pointers to where the ECG images are actually stored. Similarly, different laboratory reports, images, prescribed prescriptions, and so forth, may be at different nodes of the data network and the summary records contains links that point to the different nodes in the network that store the complete information. As such, the person skilled in the art would clearly understand that any number of combinations of different types of data records where some data records are stored on various nodes (e.g., various EHR systems) of the EHR network 108 could exist.
As various implementations of the data records are known in the art, data records do not need to be described in detail because they are well within the reach of a person skilled in the art.
Figure 4A illustrates a flowchart of a process 400A, which may be implemented by the physician's EHR system 104 in accordance with a specific example of implementation. At step Date Recue/Date Received 2020-11-05 401 the physician's EHR system 104 receives an indication (e.g., a request) to obtain health records associated with a patient from the EHR network 108. In some cases, at step 401, the Human-Centric EHR system 102 initiates the process to obtain health records of the patient from the EHR network 108 by transmitting a request to the physician's EHR system 104. In these cases, the patient provides authorization to the Human-Centric EHR system 102 to retrieve the patient's health records from various sources. This may include the patient creating an account with the Human-Centric EHR system 102, which may be done via the patient's computing entity 106. In some cases, the patient uses a web browser running on the patient's computing entity 106 to connect to a website associated with the Human-Centric EHR system 102. In other cases the patient may download an application that runs on the patient's computing entity 106 in order to connect to the Human-Centric EHR system 102 to create an account. In the account creation process, the patient may have to provide information about himself/herself, such information may include: name, address, date of birth, place of birth, health card number, social insurance number, email, user name, password, biometric identifier and/or any other suitable information. The Human-Centric UR system 102 may then use the information received from the patient to authenticate that the person making the account is in fact that person.
Regardless of the means that the patient creates an account with the Human-Centric EHR system 102, upon creation of an account and authorization from the patient, the Human-Centric EHR system 102 may initiate the process of obtaining the health records associated with the patient. Once the account is created, the Human-Centric EHR system 102 may maintain a record associated with the patient, where the record includes an account identifier (e.g., an account name/number, health card number, email and/or any suitable identifier) and a credential which may be used to authenticate the patient (e.g., a password, biometric information and/or any other suitable credential). It is appreciated that each account may have more than one account identifier and/or more than one credential.
In other cases, at step 401, the indication to obtain health records associated with a patient from an EHR network 108 may be initiated by the physician, such as when a patient is at the physician's office and requests for his/her health records to be added to the Human-Centric EHR
system 102. Similar to the case above, an account may be created at the Human-Centric EHR
system 102. For example, the physician may create an account with the Human-Centric EHR
system 102 upon verbal confirmation from the patient. In some cases, the patient may already have an account created with the Human-Centric EHR system 102 and visits the physician so that the physician via the physician's EHR system 104 may request the health records associated with the patient from the EHR network 108. Similar to how the patient has an account with the Date Recue/Date Received 2020-11-05 Human-Centric EHR system 102, physicians may also have accounts with the Human-Centric EHR system 102. For example, a physician may have an account with the Human-Centric EHR
system 102 so that the physician may communicate via the physician's EHR
system 104 with the Human-Centric EHR system 102. In such case, the Human-Centric EHR system 102 would have accounts associated with various physicians, where each account includes at least one identifier and at least one credential, such that a physician via the physician's EHR
system 104 may then use the identifier and/or the credential in connecting to the Human-Centric EHR system 102.
In some instances, the health records of the patient available in the EHR
network 108, such as a HMO and/or government maintained and ran EHR network and/or system, may be extracted when the physician consults the health records of the patent by logging into the EHR network.
When the physician accesses the health records, the data in the records, which is owned by the patient, can be legitimately stored into the Human-Centric EHR system 102. In this fashion, the Human-Centric EHR system 102 is populated with medical data every time the HMO
and/or government managed EHR system is accessed by a physician. Over time, the HMO
and/or government managed EHR system may be completely replicated into the Human-Centric EHR
system 102. In other cases, the Human-Centric EHR system 102 may replicate the index (e.g., a list of pointers that point to specific records in the nodes of the EHR
network 108) of the EHR
network 108. In other words, meta-information may be replicated without replicating the data itself. The EHR network 108 is not limited to HMO and/or government maintained and ran EHR
networks and/or systems, but may be any suitable EHR network(s) and/or system(s) managed by one or more suitable organizations.
The record replication mechanism, which is performed every time the physician accesses the government and/or HMO managed EHR system 108, ensures that the information available in the Human-Centric EHR system 102 is maintained up to date. If changes have been made to the EHR record in the HMO and/or government-managed system, those changes are automatically carried over into the Human-Centric EHR system 102.
.. At step 402, the physician's EHR system 104 requests the health records associated with the patient from the EHR network 108. This may include the physician's EHR system connecting to the EHR network 108, in which the physician has an account with.
For example, the physician may provide his/her username and password and/or hardware token such that the physician's EHR system 104 is able to connect to the EHR network 108. The process of EHR

Date Recue/Date Received 2020-11-05 systems connecting to the EHR network 108 (e.g., MIE) is known in art, for example as is disclosed in PCT International Publication No. WO 2015/031980, the contents of which are incorporated herein by reference. As various means for connecting to the EHR
network 108 are known in the art, the means for connecting by the physician's EHR system 104 to the EHR
network 108 does not need to be described in detail because such means are well within the reach of a person skilled in the art. The requests for the health records associated with the patient from the EHR network 108 may include an identifier associated with the patient, which the EHR
network 108 may use to obtain the health records associated with the patient.
The requests for the health records associated with the patient from the EHR network 108 may also include an identifier of the physician's EHR system 104 making the request.
Even more specifically, the physician accesses the government-managed or HMO-managed UR
system during a consultation, which access includes downloading the medical data to the physician's computer to display it on the physician's display. The software that manages the replication of the medical data makes a copy of the information sent from the EHR government-managed or HMO-managed system to the Human-Centric EHR system. The software can also be designed to parse the information made available when the file access was requested to determine if additional data needs to be obtained such as to obtain a complete copy of the patient record.
For example, if the medical data stored in the government-managed EHR system includes a summary portion that uses links allowing access to additional medical data, the software is configured to parse the file and recognize the links and invoke them such that the additional medical information is also sent by the HMO and/or government-managed EHR
system to the physician. That additional medical information is then also copied and integrated into the Human-Centric EHR system 102.
Figure 5A illustrates a block diagram of an EHR network 108' comprising a single EHR system 502 in accordance with a specific non-limiting example of implementation. The EHR network 108' is a specific non-limiting example of implementation of the EHR network 108 (discussed elsewhere in this document). In this example, the single EHR system 502 stores the health records associated with the patient. In the context of this example, at step 402, the physician's EHR
system 104 requests the health records associated with the patient from the single EHR system 502. In turn, the single EHR system 502 transmits the health records associated with the patient to the physician's EHR system 104.

Date Recue/Date Received 2020-11-05 Figure 5B illustrates a block diagram of an EHR network 108" comprising a plurality of EHR
systems 5051 5052 accessible by a server 504 in accordance with a specific non-limiting example of implementation. The server 504 refers to one or more computing entities (e.g., machines) on which a server program runs that waits for requests from other computing entities (e.g., physician's EHR system 104) and responds to them. The server 504 may be a record aggregation system. The EHR network 108" is a specific non-limiting example of implementation of the EHR network 108 (discussed elsewhere in this document). In this example, the EHR network 108" comprises a plurality of EHR systems 5051 5052, such that the health records associated with the patient is distributed amongst the plurality of EHR systems 5051 5052. In other words, the health records associated with the patient are distributed amongst the EHR
network 108"
such that at least part of the health records associated with the patient are stored on each of the EHR systems 5051 5052. In the context of this example, at step 402, the physician's EHR system 104 requests the health records associated with the patient from the centralized server 504 associated with the EHR network 108". In turn, the server 504 communicates with the plurality of EHR systems 5051 5052 to obtain the requested health records associated with the patient, which may include the server 504 querying the plurality of EHR systems 5051 5052. Then the server 504 transmits the health records associated with the patient to the physician's EHR system 104. The server 504 in some cases may be an EHR system which stores at least part of the health records associated with the patient. More specifically, the server 504 may be the central EHR
system 503.
Figure 5C illustrates a block diagram of the EHR network 108" comprising a plurality of EHR
systems 5061 5062 in accordance with a specific non-limiting example of implementation. The EHR network 108" is a specific non-limiting example of implementation of the EHR network 108 (discussed elsewhere in this document). In this example, the EHR network 108¨ comprises a plurality of EHR systems 5061 5062, such that the health records associated with the patient is distributed amongst the plurality of EHR systems 5061 5062. In other words, the health records associated with the patient is distributed amongst the EHR network 108" such that at least part of the health records associated with the patient is stored on each of the EHR
systems 5061 5062.
In the context of this example, at step 402, the physician's EHR system 104 requests health records associated with the patient from each of the plurality of EHR systems 5061 5062. In turn, each of the plurality of EHR systems 5061 5062 transmits health records associated with the patient to the physician's EHR system 104.

Date Recue/Date Received 2020-11-05 The various EHR systems SO2, 50515052 5061 and 5062 may be of the type of EHR
system that is discussed elsewhere in this document. Although in both Figure 5B and Figure 5C
two EHR
systems 5051 and 5052 or 5061 and 5062 are shown, the EHR network 108 may comprise more than two EHR systems. The configuration of the EHR network 108 illustrated in Figures 5A, 5B
and 5C is intended to not be limiting and various other configurations of the EHR network 108 are possible in other embodiments. Although in Figures 5A, 5B and 5C the physician's EHR
system 104 is shown connecting directly to the EHR network 108, in other examples the Human-Centric EHR system 102 may connect directly to the EHR network 108. Any communication with the EHR network 108 from other systems and/or devices as discussed in this document may .. be communication with any of the systems and/or devices that are included in the EHR network 108, for example, such as those shown in Figures 5A-5C.
Turning back to Figure 4A, at step 404, the physician's EHR system 104 receives the health records associated with the patient from the EHR network 108. In other words, at step 404, the .. physician's EHR system 104 obtains the health records associated with the patient, in response to requesting the health records associated with the patient from the EHR network 108.
At step 406, the health records associated with the patient may then be stored in the physician's EHR system 104. For example, the obtained health records associated with the patient may be stored in the database 226 of the physician's EHR system 104 in association with the patient. In some cases, the database 226 of the physician's EHR system 104 may have additional medical information relating to the patient. In other words, at least part of the health records associated with the patient may be stored in the database 226 of the physician's EHR
system 104 prior to the physician's EHR system 104 making the request to the EHR network 108 to obtain the remaining .. parts of the health records associated with the patient. In other cases, the physician's EHR system 104 and the EHR network 108 may have at least in part duplicate information relating to the health records associated with the patient.
Then at step 408, the health records associated with the patient is transmitted to the Human-Centric EHR system 102. The Human-Centric UR system 102 receives the health records associated with the patient and stores these health records in one or more records in the database 206 in association with the patient. In other words, the health records associated with the patient may be stored in a manner that is associated with the patient's account. Such a configuration, may allow for the patient to access his/her health records by connecting to the Human-Centric EHR

Date Recue/Date Received 2020-11-05 system 102 (e.g., via a web browser or an application running on the patient's computing entity 106) and log into the patient's account. By allowing the patient to access his/her health records on the Human-Centric EHR system 102 the patient may be able to control various aspects of his/her health records. For instance, the patient's account may have a profile associated with it, where the profile has various settings, parameters and/or options that the patient can configure. Moreover, where the health records associated with the patient are obtained from multiple sources (e.g., multiple nodes/systems of the EHR network 108) and then stored in the Human-Centric EHR
system 102, this may allow for a centralized storage of the health records associated with the patient.
Figures 16A-16F illustrate specific and non-limiting examples of information that may be displayed on the GUI of the patient's computing entity 106 in accordance with specific and non-limiting examples of implementation. Figure 16A illustrates an example of account information associated with the patient. Figure 16B illustrates a plurality of medical records obtained from multiple sources. As shown in this example, the plurality of medical records includes laboratory results from ABC Labs, annotations from an appointment with Dr. Smith and annotations from a hospital visit to Hospital XYZ. The patient via the patient's computing entity 106 may be able to connect to the Human-Centric EHR system 102 after step 408 of process 400A and view the plurality of medical records associated with the patient (e.g., as shown in Figure 16B). The patient may also be able receive various notices from the Human-Centric UR
system 102, as shown in Figure 16C and discussed elsewhere in this document. The patient may also be able to control various aspects of the plurality of medical records stored on the Human-Centric EHR
system 102 and associated with the patient for example as is shown in Figures 16D, 16E and 16F.
Figure 4B illustrates a flowchart of a process 400B which may be implemented by the physician's EHR system 104 in accordance with a specific example of implementation. In this example, the physician's EHR system 104 registers with the EHR network 108 this may include registering with the central EHR system 503 (or the server 504, as shown in Figure 5B) or one or more EHR
systems (e.g., such as those shown in Figures 5A and 5C). The registration process may include .. the physician's EHR system 104 providing to the EHR network 108, central EHR system 503 and/or various EHR systems a list of patients, where the list of patients include patients that the physician provides medical services to. The list of patients may include for each patient on the list the patient's name, date of birth, health identifier number and/or any other suitable information.
Once registered, the physician's EHR system 104 is subscribed to receive records associated with Date Recue/Date Received 2020-11-05 the list of provided patients. That is, when the EHR network 108, central EHR
system 503 and/or various EHR systems updates a health record associated with a patient, the updated record and/or information associated with the updated record is transmitted to the physician's EHR system 104.
At step 452, the physician's EHR system 104 receives the health record and then, at step 454, stores the health record in association with the patient's record on the physician's EHR system 104. In other words, the physician's EHR system 104 automatically receives the health records for all of its patients, regardless of where a specific patient is registered with the Human-Centric EHR system 102. The physician's EHR system 104 may then transmit the records of the patients that are registered with the Human-Centric EHR system 102 to the Human-Centric EHR system 102, in a similar manner as discussed elsewhere in this document.
Figure 4C illustrates a flowchart of a process 400C which may be implemented by the central EHR system 503 in accordance with a specific example of implementation. The process 400C is now discussed with reference to Figure 1B. At step 462, the central EHR system 503 receives from one or more EHR systems (e.g., the physician's EHR system 104A, the laboratory EHR
system 104B and the hospital EHR system 104c, etc.) one or more health records. The received health records may be transmitted to the central EHR system 503 upon request from the central EHR system 503 to the one or more EHR systems or may automatically be transmitted to the central EHR system 503 from the one or more EHR systems, for example, when a record is updated or based on a period of time (e.g., on a daily basis). The central EHR
system 503 may process the received records and, at step 464, store the records in association with the corresponding patients that the records correspond thereto in a database of the central EHR
system 503. At step 466, the central EHR system 503 may then transmit health records on the central EHR system 503 to the physician's EHR system 104. For instance, the central EHR
system 503 may have a list of registered EHR systems that are to receive patient records. The central EHR system 503 may then process in response to receipt of the records from step 462 and if any of those records are associated with a patient that is associated with the subscribing physician's EHR system 104, then the central EHR system 503 transmits those records to the subscribing physician's EHR system 104.
Although in the embodiments illustrated above, the Human-Centric EHR system 102 receives the health records associated with the patient via the physician's EHR system 104, in other cases the Human-Centric EHR system 102 may be connected directly to the EHR network 108 to request and obtain the health records associated with the patient. For instance, the Human-Centric EHR

Date Recue/Date Received 2020-11-05 system 102 may request the health records associated with the patient directly from the EHR
network 108 in a similar fashion to that discussed in regard to step 402; the Human-Centric UR
system 102 may receive the health records associated with the patient directly from the EHR
network 108 in a similar fashion to that discussed in regard to step 404; and the Human-Centric EHR system 102 may store the health records associated with the patient in a similar fashion to that discussed in regard to step 406.
For example, as shown in Figure IC, the Human-Centric EHR system 102 may be part of the EHR network 108 such that it is connected to various EHR systems (e.g., a physician's EHR
system 104A, a laboratory EHR system 104B and a hospital EHR system 104) of the EHR
network 108. In other cases, the Human-Centric EHR system 102 may be connected to and communicates with the central EHR system 503, where the central EHR system 503 is connected to and communicates with various EHR systems (e.g., the physician's EHR system 104A, the laboratory EHR system 104B and the hospital UR system 104).
It is appreciated that Figures IA to IC are examples of possible configurations and interconnections of the Human-Centric EHR system 102 and the EHR network 108 and that other configuration are possible in other embodiments.
The Human-Centric EHR system 102 may also maintain a record of the various physicians' EHR
systems that the patient has medical records associated with.
The technique for populating an EHR system such as the physician's EHR system 104 and/or the Human-Centric EHR system 102 may be implemented in various ways. One technique for populating an EHR system with health records associated with respective patients includes querying the centralized EHR network 108 storing health records about multiple patients. The querying may be performed in the context of a physician dispensing medical services to a first patient of the multiple patients. For example, this may take place when the first patient is at the physician's office seeking a medical consult (e.g., an appointment with the physician). This medical consult may be to seek medical advice/services and/or may be for the purpose of populating the EHR system with health records associated with the first patient. The querying in this example includes accessing the health record of the first patient from the centralized EHR
network 108. It may also include accessing the health record of the first patient from physician's EHR system 104, for example if the physician's EHR system 104 has additional health records Date Recue/Date Received 2020-11-05 about the first patient that are not on the centralized EHR network 108. This technique could then include copying some or all of the information in the health record of the first patient on the centralized EHR network 108 to the EHR system to create a health record for the first patient in the electronic health record system. This copying may include copying some or all of the .. information in the health record of the first patient on the centralized EHR network 108 to the physician's EHR system 104 and/or the Human-Centric EHR system 102. The physician's EHR
system 104 may transmit some or all of the information in the health record of the first patient on the centralized EHR network 108 to the Human-Centric EHR system 102 for storage.
The querying and copying step may then be repeated for a second patient of the multiple patients to access and copy the health record of the second patient from the centralized EHR network 108.
The querying and copying step may then be repeated numerous times such as for a third patient, a fourth patient and so on, of the multiple patients. For example, this may be done each time that the physician is dispensing medical services to a patient of the multiple patients.
It is appreciated that the physician may dispense medical services to only a subset of patients of the multiple patients. In other words, the centralized EHR network 108 stores health records about multiple patients and the physician may only access and copy the health records of the patients that the physician is dispensing medical services thereto. This is the case because the centralized EHR network 108 would typically also store health records associated with patients that are not patients of the physician but of other physicians.
By way of example, each time the physician dispenses medical services to the first patient, the querying of the centralized EHR network 108 may be repeated to access and copy any new health .. records associated with first patient to the EHR system. This may be consider as an update of the first patient's record on the EHR system based on any new records of the first patient on the centralized EHR network 108. In other cases, the querying of the centralized EHR network 108 may be done to access and update the first patient's health records on the EHR
system upon request from the physician and/or the physician's EHR system 104. For example, when the .. physician desires to obtain the new health records associated with the first patient from the centralized EHR network 108 and/or when physician's EHR system 104 has been programmed to access the centralized EHR network 108 such as on a regular interval (e.g., daily, weekly, month basis and/or any other suitable timeframe). In even further cases, the centralized EHR network 108 may be programmed to push the new health records of the first patient to the electronic health Date Recue/Date Received 2020-11-05 record system such as on a regular interval (e.g., daily, weekly, month basis and/or any other suitable timeframe).
It is appreciated that the aforementioned electronic health record system that was populated with health records associated with respective patients could provide an account to the first patient such that the first patient can access the health record associated therewith on the electronic health record system. An account may also be provided to the second patient, and so forth. The account provided may be as discussed elsewhere in this document. This account may be an account to the physician's EHR system 104 and/or the Human-Centric EHR system 102.
In some embodiments, the EHR network 108 may be implemented to include the use of block-chains. A block-chain is a distributed non-centralized database that maintains a continuously-growing list of data records that each refers to previous items on the list, which may be referred to as a ledger. More specifically, the block-chain includes blocks that hold timestamped data records. Each block also includes a hash of the prior block, linking the blocks together. The linked blocks form a chain, each additional block reinforcing those before it, thus giving the database type its name. As such, in this embodiment, instead of the EHR
network 108 having a database management system a block-chain backed ledger system may be used.
In this embodiment, various nodes would include at least a partial copy of the block chain.
It should be appreciated that the EHR network 108 may be a centralized or non-centralized network depending on the implementation of the EHR network 108.
Medical Results Delivery Mechanism Figure 6 illustrates a block diagram of an example of the Human-Centric EHR
system 102 that is able to provide patients with medical results upon authorization in accordance with an embodiment of the invention. As illustrated, the Human-Centric EHR system 102 is connected to the patient computing entity 106 and to the physician's EHR systems 104 which is connected to EHR network 108. Also, a medical EHR system 110 is illustrated as being connected to both the EHR network 108 and to the physician's EHR systems 104. Although in the embodiment shown the medical EHR system is connected to both the EHR network 108 and the physician's EHR
system 104, in other embodiments the medical UR system 110 may only be connected to one of Date Recue/Date Received 2020-11-05 the EHR network 108 and physician's EHR system 104. It is appreciated that other connections are possible in other embodiments.
The various connections between the Human-Centric EHR system 102, the patient's computing entity 106, the physician's EHR system 104, the medical EHR system 110 and/or the EHR
network 108 may be similar to the various connections between systems and devices, as discussed elsewhere in this document. The various connections between the Human-Centric EHR
system 102, the patient's computing entity 106, the physician's EHR system 104, the medical EHR system 110 and/or the EHR network 108 may include one or more connections over one or more data networks. The various connections between the Human-Centric EHR
system 102, the patient's computing entity 106, the physician's EHR system 104, the medical EHR system 110 and/or the EHR network 108 may allow for the communication (e.g., transmission and/or reception) of various information and/or data between the various systems and/or devices. The various information and/or data exchanged may be a "notice", "notices", a "health record" and/or "health records" of the type discussed elsewhere in this document. In other words, the term "medical results" may refer to a notice, notices, a health record and/or health records.
The medical EHR system 110 may be one or more computer systems associated with a laboratory, testing facility, imaging facility or any other suitable facility that provides medical results associated with a test or image of a patient (e.g., an EHR system associated with a laboratory, testing facility and/or imaging facility). The medical result may include test results, such as blood test results, urine test results; imaging results, such as an X-ray image results or CAT (computerized axial tomography) scan results; CT (computerized tomography) scan; ECG
images and/or reports; or any other suitable laboratory, imagining or test result and/or reports.
The medical results may be provided in a health record associated with the patient.
Figure 7A illustrates a flowchart of a process 600, which may be implemented by the physician's EHR system 104 for determining if the Human-Centric EHR system 102 should be notified of receipt of medical results at a physician's office in accordance with a specific non-limiting example of implementation. Prior to process 600, it is appreciated that a patient may have visited the physician and the physician requested that the patient get medical results done (e.g., testing or lab-work done). After the patient visits the facility to get the medical testing or lab-work done, the results are entered into a medical EHR system 110. The Human-Centric EHR
system 104 may receive an indication from the physician's EHR system 104 that medical testing or lab-work has Date Recue/Date Received 2020-11-05 been prescribed and the Human-Centric EHR system 104 may send a notice to the patient's computing entity 106 to get medical results done. The Human-Centric EHR system 104 may use this indication to setup a reminder notice if the patient does not get the medical testing or lab-work done within a certain timeframe. The notices are discussed elsewhere in this document, such as the discussion in association with Figures 17A and 17B.
At step 602, medical results associated with a patient are received at the physician's EHR system 104. At this step, the medical results may be received from the medical EHR
system 110 or may be received from the EHR network 108 (e.g., the central EHR system 503 and/or any other EHR
system). For instance, in some cases, the medical EHR system 110 may send the medical results to the EHR network 108 and the physician's EHR system 104 queries the EHR
network 108 to obtain the medical results or the EHR network 108 transmits the medical results to the physician's EHR system 104 upon receipt from the medical EHR system 110. In other cases, the medical results may be provided in hardcopy and a user enters and/or scans the medical results into the EHR network 108 and/or physician's EHR system 104. Regardless of how the medical results are received, at this step the medical results may be stored in a health record associated with the patient.
At step 604, the patient information associated with the medical results is processed to see if the patient is a subscriber to the Human-Centric EHR system 104 and/or a subscriber to a medical results delivery service. For example, prior to the physician's EHR system 104 receiving the medical results associated with the patient, the patient may have logged into his/her account and subscribed to the medical results delivery service. As such, the Human-Centric EHR system 104 may manage a subscribing list of the patients that subscribe to the medical results delivery service. Figure 16D illustrates a specific and non-limiting example of a profile page of the patient's account, which provides the options to subscribe to the medical results delivery service.
As illustrated, the Human-Centric EHR system 104 may also allow for the patient to select the means for receiving notices (e.g., email, text messages and application). In other cases, the patient may not have the option to select the mode for receiving notices; for example, in the case where the patient's computing entity 106 is running application software associated with the Human-Centric EHR system 104, the notices may be received via the application software.
Turning back to Figure 7A, at step 604, the physician's EHR system 104 may query the Human-Centric EHR system 104 to determine if the patient associated with the medical results is on the Date Recue/Date Received 2020-11-05 subscriber list or not. In this case, the Human-Centric EHR system 102 maintains a subscriber list which lists the subscribers (e.g., various patients) and the physician's EHR
system 104 may provide the Human-Centric EHR system 104 with an identifier associated with the patient (e.g., a medical card number, an account identifier or any other suitable identifier) that can then be used by the Human-Centric EHR system 104 to make a determination of whether the patient associated with the identifier is a subscriber or not. In other cases, the physician's EHR system 104 may query the Human-Centric EHR system 102 for a subscriber list comprising identifiers associated with patients that are a part of the service and then can determine by processing the subscriber list against an identifier associated with the patient. In this case, if a match is found then the patient associated with the medical results is a subscriber and if a match is not found then the patient associated with the medical results is not a subscriber. Yet, in other cases, the physician's EHR
system 104 may include in the medical records associated with the patient that the patient is a subscriber to the medical results delivery service. Regardless of how it is determined that the patient is a subscriber, at this step a determination is made (e.g., at the physician's EHR system 104 and/or the Human-Centric EHR system 102) to determine whether a specific patient is a subscriber or not.
By way of example, the interaction between the physician's EHR system 104 and the Human-Centric EHR system 102 to determine if a specific patient is a subscriber may be implemented as follows. The physician's EHR system 104 queries the Human-Centric EHR system 102 by sending a request to see if the Human-Centric EHR system 102 already has health records associated with a specific patient. The request may include providing a patient's name, gender, date of birth, date of death, social insurance number, a medical card identifier and/or any other suitable identifier. The Human-Centric EHR system processes the request and in the case that a match is found (i.e., the Human-Centric EHR system has health records associated with the requested patient), the Human-Centric EHR system 102 may then communicate to the physician's EHR system 104 that the Human-Centric EHR system 102 has health records associated with the requested patient and that this specific patient may be identified by a specific identifier (e.g., a proxy identifier). This specific identifier may be specific to the requesting physician's EHR
system 104. In other words, each physician's EHR system in a plurality of physician's EHR
system that may communicate with the Human-Centric EHR system 102 would have a specific identifier for a specific patient, where the specific identifier is different for each of the physician's EHR systems. In the case that a match is not found, the Human-Centric EHR
system 102 may still provide the specific identifier for the requested patient and an indication that the Human-Date Recue/Date Received 2020-11-05 Centric EHR system 102 currently does not have any health records associated with the requested patient. It is appreciated that by providing the specific identifier even though the Human-Centric EHR system 102 does not currently have any health records associated with the requested patient that the Human-Centric EHR system 102 may be later able to identify the patient when other .. physician's EHR systems try to request health records associated with the patient. Such a configuration between the Human-Centric EHR system 102 and physician's EHR
system 104 may allow for when the physician's EHR system 104 provides the Human-Centric EHR system 102 with health records associated with the patient, that the physician's EHR
system 104 provides the specific identifier of the patient along with an unique identifier associated with the physician's EHR system 104 (e.g., a doubleton).
If the patient is a subscriber to the service, then at step 608 an indication that the medical results have been received at the physician's office is transmitted from the physician's EHR system 104 to the Human-Centric EHR system 102. At step 606, the physician's EHR system 104 may then notify the physician of the received medial results. If the patient is not a subscriber, then the physician's EHR system 104 may then notify the physician of the received medial results (step 606). In other cases, an optional note may be made in a record associated with the patient that an indication was not sent to the Human-Centric EHR system 102. In other words, a note that the patient was not informed of receipt of the medical results at the physician's office. In other cases, when the patient is a subscriber, an optional note may be made that patient was informed that the medical results were received at the physician's office.
Figure 8A illustrates a flowchart of a process 700 which may be implemented by the Human-Centric EHR system 102 for sending a notice to the patient's computing entity 106 in accordance with a specific non-limiting example of implementation. At step 702, the Human-Centric EHR
system 102 receives from the physician's EHR system 104 an indication that that medical results associated with a patient that subscribes to the notification system of Human-Centric EHR system 102 (i.e., a subscriber) have been received at the physician's office. Step 702 may take places after step 608 of process 600 and in general terms is an indication that medical results are available in the physician's EHR system 104 for review by the physician. At this step the Human-Centric EHR system 102 may store the indication that that medical results associated with the patient have been received at the physician's office in a record associated with the subscribing patient. It is appreciated that there may be a distinction between a patient and a subscriber (or a subscribing patient), as the physician's EHR system 104 would typically have electronic health Date Recue/Date Received 2020-11-05 records associated with different patients, and the physician's EHR system 104 may provide the electronic health records to the Human-Centric EHR system 102 regardless of whether the patient subscribes to the notifications of the Human-Centric EHR system 102.
At step 704, the Human-Centric EHR system 102 then sends a notice to the subscribing patient's computing entity 106 associated with the subscribing patient to notify the subscribing patient that medical information is available. The notice that medical information is available may depend on the type of delivery method that the subscribing patient desires to obtain notices by. For example, the subscribing patient may provide an email address to receive the notice in the form of an .. email; a cell-phone number to receive the notice as a text message. In other cases, where the subscribing patient's computing entity 106 runs an application associated with the Human-Centric EHR system 102 and the application may provide the notice in the form of a pop-up box or window type notice or a red circle in a top corner of an icon associated with the application running on the subscribing patient's computing entity 106. Regardless of the means for providing the notice, the notice may only note that medical information is available for viewing at the Human-Centric EHR system 102 and not provide any specific details regarding the medical information. In other words, patient intervention would typically be required to make the actual medial information visible to the user of the subscribing patient's computing entity 106, as discussed in the steps below.
At step 706 a request for the medical information from the subscribing patient's computing entity 106 is received and the request may include authentication information. In the cases where the notice is provided via email or text-message, the subscribing patient via the subscribing patient's computing entity 106 may login to the Human-Centric EHR system 102 (e.g., through the use of a web browser) to obtain the medical information. For instance, the subscribing patient may provide a user account identifier and a password. In the cases where the notice is provided in the form of a pop-up box or window type notice in the application running on the subscribing patient's computing entity 106, the subscribing patient may provide a user account identifier, a password and/or biometric authentication information (e.g., a finger print via a finger print reader on the patient's computing entity 106) via the application. In other words, at this step the subscribing patient's computing entity 106 requests from the Human-Centric EHR
system 102 access to medical information by providing authentication information.

Date Recue/Date Received 2020-11-05 At step 708, the authentication information included in the request for the medical information is authenticated (e.g., by comparing the authentication information against a record associated with the patient that stores the credential information). Then at step 710 if the authentication information is associated with the subscribing patient, the Human-Centric EHR
system 102 then transmits a notice providing the medical information to the subscribing patient's computing entity 106. In this case, the medical information is a notice that medical results have been received at his/her physician's office but has not yet been reviewed.
In some cases, step 704 may be omitted from the process 700. In these cases, a notice of the availability of medical information is not transmitted to the subscribing patient's computing entity 106 and the Human-Centric EHR system 102 waits for a request from the subscribing patient's computing entity 106.
In other cases, step 708 may be omitted from the process 700 and prior to step 704 the subscribing patient's computing entity 106 provides authentication information and if the authentication information is associated with the subscribing patient, then a notice may be sent at step 704. In other words, notices are not sent unless the subscribing patient has authenticated his/her patient's computing entity 106 to the Human-Centric EHR system 102 in a manner that indicates he/she is currently using the device and would like notices to be received.
Figure 7B illustrates a flowchart of a process 650 which may be implemented by the physician's EHR system 104 for transmitting medical results to the Human-Centric UR system 102 in accordance with a specific non-limiting example of implementation. After step 606 of the process 600, the medical results may be provided to a physician at step 609 of process 650. In other words, after the physician's EHR system receives the medical results associated with the patient, the physician is able to view the medical results and, at step 609, the medical results associated with the patient are provided to the physician. For example, the display/screen of the physician's EHR system 104 may provide the physician with the results and the physician may provide a comment (e.g., an annotation) via an input device such as a keyboard, mouse and/or touch screen.
It is appreciated that the terms "comment" and "annotation" may be used interchangeably in this document, where appropriate, to refer to any annotation, comment, observation and/or explanation associated with a medical result. At step 610, the physician provides a comment regarding the medical results and the physician's EHR system 104 receives the comment and stores the comment in association with the medical results in a health record associated with the Date Recue/Date Received 2020-11-05 patient. At step 612, the physician's EHR system 104 then checks to see if the patient is a subscriber (step 612 of process 650 is similar to step 604 of process 600). If the patient is a subscriber, then at step 618 the medical results associated with the patient and the comment associated with the medical results for the patient are sent to the Human-Centric EHR system 102 .. from the physician's EHR system 104 (step 610 of process 650 is similar to step 608 of process 600; however, instead of providing an indication of the medical results, the medical results themselves are transmitted). It is appreciated that transmission of the medical results may include the actual medical results and/or an explanation of the medical result, which may be transmitted in the form of an electronic health record. It is further appreciated that instead of transmission of .. the medical results that an explanation of the medical results may be transmitted instead. If the patient is not a subscriber, then at step 616, an indication would typically be provided to a staff member (e.g., nurse, receptionist, etc.) to follow-up with the patient (e.g., give them a call or send them an email) to book an appointment to come in and see his/her medical results, if appropriate in the circumstances. Optionally, a note may be made in the health record associated with the .. patient that the medical results was not sent to the Human-Centric EHR
system 102 to indicate that the patient was not notified of the medical results. In other cases, an optional note may be made in the health record associated with the patient that the patient has been informed of the medical results.
.. Figure 8B illustrates a flowchart of a process 800 which may be implemented by the Human-Centric EHR system 102 for sending medical results associated with the subscribing patient to the subscribing patient's computing entity 106 in accordance with a specific non-limiting example of implementation. At step 802 the Human-Centric EHR system 102 receives from the physician's EHR system 104 medical results associated with the subscribing patient. Step 802 may take places after step 618 of process 650 and in general terms the medical results associated with the subscribing patient that are received from the physician's EHR system 104 include a comment from the physician in addition to the medical results or just the comment. The medical results receive may also include one or more action items (discussed elsewhere in this document). At this step the Human-Centric EHR system 102 may store the medical results (including any comments .. and/or action items) associated with the subscribing patient in a record associated with the subscribing patient.
At step 804, the Human-Centric EHR system 102 then sends a notice to the subscribing patient's computing entity 106 associated with the subscribing patient that medical information is Date Recue/Date Received 2020-11-05 available. The notice that medical information is available may depend on the type of delivery method that the subscribing patient desires to obtain notices by. For example, the subscribing patient may provide an email address to receive the notice in the form of an email; a cell-phone number to receive the indication as a text message. In other cases, where the subscribing patient's computing entity 106 runs an application associated with the Human-Centric EHR
system 102, the application may provide the notice in the form of a pop-up box or window type notice or a red circle in a top corner of an icon associated with the application running on the subscribing patient's computing entity 106. Regardless of the means for providing the notice, the notice may only note that medical information is available for viewing at the Human-Centric EHR system .. 102 and not provide any specific details regarding the medical information.
(Step 804 of process 800 is similar to step 704 of process 700).
At step 806 a request for the medical information from the subscribing patient's computing entity 106 is received and the request may include authentication information. In the cases where the notice is provided via email or text-message, the subscribing patient via the subscribing patient's computing entity 106 may login to the Human-Centric EHR system 102 to obtain the medical information. For instance, the subscribing patient may provide a user account identifier and a password. In the cases where the notice is provided in the form of a pop-up box or window type notice in the application running on the subscribing patient's computing entity 106, the .. subscribing patient may provide a user account identifier, a password and/or biometric authentication information. In other words, at this step the subscribing patient's computing entity 106 requests from the Human-Centric EHR system 102 access to medical information by providing authentication information. (Step 806 of process 800 is similar to step 706 of process 700).
At step 808, the authentication information included in the request for the medical information is authenticated for example by comparing the authentication information against a record associated with the subscribing patient. (Step 808 of process 800 is similar to step 706 of process 700). Then, at step 810, if the authentication information is associated with the subscribing patient, the Human-Centric UR system 102 then transmits a notice to the subscribing patient's computing entity 106, the notice includes the medical information. In this case, the medical information is the medical results. If the medical results contain a comment from the physician, the comment from the physician regarding the medical results may also be included in this notice.

Date Recue/Date Received 2020-11-05 Figure 16C illustrates a specific and non-limiting example where the patient via the patient's computing entity 106 may then view these notices. As illustrated, a first notice is provided that indicates that medical results have been received at the physician's office and a second notice is provided that includes the medical results and an annotation.
In some cases, step 804 may be omitted from the process 800. In these cases, a notice of the availability of medical information is not transmitted to the subscribing patient's computing entity 106 and the Human-Centric EHR system 102 waits for a request from the subscribing patient's computing entity 106.
In other cases, step 808 may be omitted from the process 800 and prior to step 804 the subscribing patient's computing entity 106 provides authentication information and if the authentication information is associated with the subscribing patient, then a notice may be sent at step 804. In other words, notices are not sent unless the subscribing patient has authenticated his/her patient's computing entity 106 to the Human-Centric EHR system 102 in a manner that indicates he/she is currently using the device and would like notices to be received.
In some embodiments, the medical results provided in the notice may be transmitted to the patient's computing entity 106 without any comment by the physician. In such case, the physician's EHR system 104 may automatically on creation of a medical record at the physician's EHR system 104 or on receipt of a medical record including medical results (e.g., from the EHR
network 108), transmit the medical record including the medical results to the Human-Centric EHR system 102. The Human-Centric EHR system 102 may then notify the patient's computing entity 106 of the medical results in a similar fashion as discussed elsewhere in this document.
In other embodiments, the medical results transmitted to the patient's computing entity 106 may not contain the medical results received from the medical facility (e.g., lab, imaging facility, etc.) but includes only a comment or annotation from the physician. In other words, the medical results may not actually be transmitted by the physician's EHR system 104 and/or the Human-Centric EHR system 102 and in these cases, annotations of the medical results may be provided instead.
In such case, the process for transmitting the comment on the medical results to the patient's computing entity 106 from the physician's EHR system 104 via the Human-Centric EHR system 102 may be similar to the process discussed elsewhere in this document in relation to transmitting Date Recue/Date Received 2020-11-05 the medical results to the patient's computing entity 106 from the physician's EHR system 104 via the Human-Centric UR system 102.
At step 810, the notice of the medical results associated with the subscribing patient is transmitted to the subscribing patient's computing entity 106 may also include an action item. In other words, the notice may be flagged as requiring patient interaction or not, as well as what type of action is required. For instance, the action item may be a follow-up appointment with the physician, a prescription prescribed by the physician or any other suitable action.
In the case that the action item is an appointment with the physician, the patient may be able to accept or reject an appointment provided via the notice that provided the patient's computing entity 106 with the medical results and the action item. In some cases, the appointment in the notice is a fixed time and date and the patient has the option of accepting or rejecting the time and date. Then the Human-Centric EHR system 102 receives the acceptance or rejection of the appointment from the patient's computing entity 106. The Human-Centric EHR
system 102 may then store the acceptance or rejection in the records associated with the patient at the Human-Centric EHR system 102. The Human-Centric EHR system 102 may also transmit the acceptance or rejection of the appointment to the physician's EHR system 104 and in this case, the physician's EHR system 104 may then store the acceptance or rejection in the medical records .. associated with the patient and/or patient scheduling software. In other cases, the action item in the notice may provide for a means for the patient to schedule an appointment.
For example, the action item may provide a link to the physician's website that allows the patient via the patient's computing entity 106 to book an appointment online. By way of another example, the action item may include an email address or phone number that the patient may then use to schedule an appointment.
In the case that the action item is a prescription, the action item may be provided in various forms. For example, the patient may be able to take the patient's computing entity 106 to a pharmacy and show the prescription to the pharmacy for the fulfillment of the prescription; the action item may indicate a pharmacy where the prescription may be picked-up;
the action item may indicate that the prescription has been registered with the government regulated and/or state-owned or HMO EHR system and that a pharmacy that has access to this system may fulfill the prescription. Upon fulfillment of the prescription, the Human-Centric EHR
system 102, the EHR
network 108 and/or the physician's EHR system 104 may receive acknowledgment of the Date Recue/Date Received 2020-11-05 fulfilled prescription. In other words, the Human-Centric EHR system 102 and/or the physician's EHR system 104 may receive notification that an action item has been completed by the patient.
In some embodiments, Human-Centric EHR system 102 receives a read-receipt from the patient's computing entity 106 after the patient via the patient's computing entity 106 views a notice (e.g., the medical results associated with the patient). The Human-Centric EHR system 102 may then store the notice of the read-receipt in the records associated with the patient at the Human-Centric EHR system 102. The Human-Centric EHR system 102 may also transmit the read-receipt to the physician's EHR system 104 and in this case, the physician's EHR system 104 may then store the read-receipt in the medical records associated with the patient. It is appreciated that such a process may be used to inform the physician if the patient has received medical results, a comment associated with the results and/or any follow up actions.
The notice may be flagged by the Human-Centric EHR system 104 with an expiry date-time stamp. If there is a request for the medical information associated with the notice after the time stamp, the request may be ignored by the Human-Centric EHR system 104. In the case that the patient's computing entity 106 is running application software associated with the Human-Centric EHR system 104, this software may remove notices that have expired. In other cases, the medical results provided in the notice may expire after a set period of time. The notices are discussed elsewhere in this document, such as the discussion in association with Figures 17A and 17B.
It is appreciated that the steps of process 700 and 800 may be considered a "pull" (or "client-pull") based notification system instead of a "push" based notification system. To maintain confidentiality of the patient's medical results it is desirable for the medical results delivery system to be provided in a "pull" based fashion. If the patient's computing entity 106 is in the hands of a third-party, and the notification system is a "push" based notification system the confidentiality of the patient's medical results may be breached if the third-party views the notification. From a human perspective a "pull" can be made to look like a "push" but generally speaking is more desirable in terms of maintain confidentiality of the patient's medical results.
For instance, when the Human-Centric EHR system 102 receives a "pull" request, prior to sending the information requested, the Human-Centric EHR system 102 verifies that the patient's computing entity 106 is verified to pull. Although in some embodiments, the patient via the patient's computing entity 106 initiates communication (e.g., a client-pull) with the Human-Centric UR system 102 to obtain various information (e.g., to get records, annotations, notices, Date Recue/Date Received 2020-11-05 at the like); in alternative embodiments, push notifications (e.g., email, push notification services, server-push systems, and/or any other suitable push notification) may be used.
In other words, the only "push" that may be done in such a configuration is that a push of a communication indicating that there is some information available to be accessed without providing any details on the information available. Afterwards, a "pull" may be used to retrieve the available information once authentication has been done (e.g., verifying identity with a biometric reader).
The processes discussed above (e.g., the processes 700 and 800) provide for an identity management process. This identity management process allows for patients to receive communicates from the Human-Centric EHR system 102 in a confidential way after the patient's identity has been authenticated. By providing a system where the patient is authenticate by the Human-Centric UR system 102 prior to communications possibly containing confidential information allows for a secure manner for communicating patent health related information.
It is also appreciated that after steps 710 or 810, that after the patient view the medical records and/or medical results on the patient's computing entity 106, that the patient's computing entity 106 may be configured to delete the medical records and/or medical results both in volatile and in persistent memory.
Although in the embodiment above, the physician's EHR system 104 provides the notices and medical results to the Human-Centric EHR system 102 and it is the Human-Centric EHR system 102 that provides the patient with the notices and medical results, in other embodiments, the physician's EHR system 104 may notify the patient directly without the use of the Human-Centric EHR system 102. In other words, aspects of the Human-Centric EHR
system 102 may be incorporated into the physician's EHR system 104. As such, in some embodiment, some or all of the functionality of the Human-Centric EHR system 102 discussed in this document may be implemented on the physician's EHR system 104.
In other embodiments, other forms of information exchange capability between the patient and the physician may be possible. In other words, the Human-Centric EHR system 102 may provide for a means for facilitating the exchange of information between the physician via the physician's EHR system 104 and the patient's computing entity 106.
Notices Date Recue/Date Received 2020-11-05 Figure 17A and 17B illustrate examples of a first notice 1700 and second notice 1800 in accordance with a specific and non-limiting example of implementation. As illustrated, the notices 1700 and 1800 include an identifier 1702, notice data 1704, an action 1708 and a timer 1710. The identifier 1702 is used to identify the patient's computing entity 106, such that the notice is communicated from the Human-Centric EHR system 102 to patient's computing entity 106. The identifier 1702 may include an IP address, an email address, an account identifier, a telephone number and/or any other suitable identifier. The notice data 1704 may be used to communicate various information and data, such as: messages, medical results, annotations and/or any other suitable information. As illustrated, the notice data 1704 may include message data 1706, medical results data 1712, and/or an annotation data 1714. The message data 1706 may include a text-based and/or HTML based message used to provide information to the patient's computing entity 106. The medical results data 1712 may include the medical results and/or health records. The annotation data 1714 may be used to provide physician's annotation regarding the medical results. The action data 1708 may be used to convey an action item from the Human-Centric EHR system 102 to the patient's computing entity 106. Such actions may include an allow/deny action, an acknowledge action (e.g., a delivery or read receipt action), an authentication action and/or any other suitable action.
It is appreciated that notices 1700 and 1800 are the general mechanism by which the patient associated with the patient's computing entity 106 becomes aware of any changes of his/her medical record. In fact, the first notice 1700 may also include a token (or a key), where the token may be used by the patient's computing entity 106 in making a pull to Human-Centric EHR
system 102 requesting further information and resulting in the patient's computing entity 106 receiving the second notice 1800 including the further information.
The notice 1700 is now discussed in the context of the example of the Human-Centric EHR
system 102 communicating a notice of authorization to the patient's computing entity 106. This notice of authorization typically is sent first, prior to sending any further notices, to authenticate that the person at the patient's computing entity 106 is in fact the patient.
In this case, the message data 1706 may include a message that indicates to the patient that the Human-Centric EHR system 102 has further information and/or a notice for him/her. The timer 1710 may be an expiry timer, for which the notice is set to expire. In other words, the notice may no longer be accessible by the patient (e.g., the notice if removed from the notices application window on the Date Recue/Date Received 2020-11-05 application software running of the patient's computing entity 106) after a set period of time. In this example, the action 1708 includes an action item for the request for an identifier (e.g., a password, biometric information and/or any other suitable identifier) via the GUI of the patient's computing entity 106. The action item when acknowledged by the patient may send a communication from the patient's computing entity 106 to the Human-Centric EHR
system 102.
In this case, the communication includes the identifier. The Human-Centric EHR
system 102 may process the received identifier to determine if the person at the patient's computing entity 106 is in fact the patient. This may be done by processing the received identifier against a record storing the patient's identifier. If the patient is authenticated, then further notices may be sent from the .. Human-Centric EHR system 102 to the patient's computing entity 106. This may also be done by the Human-Centric EHR system 102 communicating a token (or a key) in the first notice 1700 to the patient's computing entity 106 and then the validating the token in the request from the patient's computing entity 106 such that the Human-Centric EHR system 102 verifies that the token is the token that was previously sent.
The notice 1700 is now discussed in the context of the example of the Human-Centric EHR
system 102 communicating a notice to get medical results done. In this example, the message data 1706 includes a message that indicates to the patient to go to a medical facility to get medical results done. The action 1708 in this example includes an action item for the patient to acknowledge via the GUI of the patient's computing entity 106 that he/she went to the medical facility to get the testing/lab-work done. The timer 1710 may be a reminder to the patient to get the medical testing or lab work done or may be an expiry timer for which the notice is set to expire and the patient can no longer get medical testing/lab-work done. For instance, if the patient does not go to get the testing/lab-work done after a set period of time, the Human-Centric EHR system 102 may issue another notice and/or a reminder. Also, if the patient does not go and get the testing/lab-work done after a set period of time, the notice may no longer be accessible by the patient (e.g., the notice if removed from the notices application window on the application software running of the patient's computing entity 106).
The action item when acknowledged by the patient may send a communication from the patient's computing entity 106 to the Human-Centric EHR system 102. The Human-Centric EHR system 102 may process the receipt of an action item to setup other notices and/or reminders. For example, after the patient acknowledges that he/she got the testing/lab-work done, then the Human-Centric UR system 102 may process this acknowledgement against the type of Date Recue/Date Received 2020-11-05 testing/lab-work done to determine the typical timeframe for the medical results for this testing/lab-work. Then, if the Human-Centric EHR system 102 does not receive acknowledgement from the physician's EHR systems 104 that the medical results have been received at the physician's office, the Human-Centric EHR system 102 may issue a notice to the patient's computing entity 106 and/or physician's EHR systems 104 that the medical results were not received.
For example, if a patient gets a blood count test done, this typically only takes a couple of hours and if the patient via the patient's computing entity 106 has not received a notice that the test results are done within a 24 to 48 hour period, this may be an indication that the test results were lost or the blood work was not done. In other words, the Human-Centric EHR
system 102 may be able to determine if test/lab results are missing or not completed.
Turning now to Figure 17C, a notice 1900, which is similar to the notices 1700 and 1800 is shown; however, the notice 1900 may be a communication that is made from the medical EHR
system 110 to the physician's EHR system 104, either directly or via the EHR
network 108. The notice 1900 may be a communication that is sent from medical EHR system 110, where the notice data 1704 include medical result associated with a patient. The notice 1900 may include an urgency indicator to indicate that the medical results are time sensitive and should be reviewed by .. the physician urgently. The incoming notices at the physician's EHR system 104 may be processed and when a notice includes an urgency indicator, it may be then brought to attention to physician via the physician's EHR system 104 in a more urgent manner than non-urgent notices.
For example, after the patient visits the lab and the lab technician enters in the medical results from the patient's lab tests, the notice 1900 may be communicated from the medical EHR system 110 to the physician's EHR system 104, and in this example the medial results include an outcome/observation that requires urgent review by the attending physician or the primary physician of the patient, as the results of the test indicate an outcome that could have immediate affect on the patient's health condition. The timer 1700 of the notice 1900 may include a "time-out", so that the issuing lab technician associated with the medical EHR
system 110 is notified via the action 1708 which results in the physician's EHR system 104 sending a notice to the medical EHR system 110 that the physician has not seen the medical results within a specific amount of time.

Date Recue/Date Received 2020-11-05 Referring back to Figure 17A, the notice 1700 is now discussed in the context of the example of the Human-Centric EHR system 102 communicating a first notice of the availability of medical information to the patient's computing entity 106. In this case, the message data 1706 includes a message that indicates to the patient that his/her medical results have arrived at the physician's office. The message data 1706 may also include an indication that a notice will be provided later.
The timer 1710 may be used to as reminder so the patient can follow-up with his/her physician if he/she does not receive a notice with the medical results in a set period of time. The timer 1710 may also be an expiry timer for which the notice is set to expire and the patient can no longer view this notice.
The notice 1800 is now discussed in the context of the example of the Human-Centric EHR
system 102 communicating a second notice of the availability of medical information to the patient's computing entity 106. In this case, the medical results data 1712 conveys the medical results and the annotation data 1714 includes a physician's comment or annotation regarding the medical results. The action 1708 may be used for various actions items such as acknowledgment of receipt of the notice, to schedule an appointment and/or to provide a prescription. The timer 1710 may be an expiry timer for which the notice is set to expire and the patient can no longer view this notice.
The physician should report the medical results to the patient in a specific time-frame and the Human-Centric EHR system 102 may be able to record or track the time-frame that it takes each physician to report the medical results. In other words, the Human-Centric EHR
system 102 may monitor and record the time frames of the various timers and actions to produce reports that indicate the average medical facility processing time, the physician's time to review the medical results and/or any other suitable report. This data may be useful in determine which medical facilities process results faster than others and/or to determine which physicians review medical results faster than others.
The message data 1706, medical results data 1712 and the annotation data 1714 may specific that the notice or the information provided in the notice is "for your eyes only"
(or a similar word having the same connotation), as it is appreciated that the patient may be receiving medical results and/or information that is sensitive in nature.
Date Recue/Date Received 2020-11-05 Notice 1700 and/or notice 1800 may also be used in various other embodiments to obtain permission for an action from the patient via the patient's computing entity 106. For example, to receive authorization from the patient to provide health records to a third-party, to receive authorization from the patient to have his/her health records used in a study, and/or to receive authorization from the patient any other suitable action.
In some specific examples of implementation the notices may include a must acknowledge field, an acknowledged by field and an expiry field. The must acknowledge field requires a receipt from the patient's computing entity 106. The acknowledged by field identifies who acknowledged and may include an identifier of the party that acknowledged the receipt of the notice. The expiry field is used to set an expiry timer.
This notification system may be useful when multiple test/lab results are being done, as it may allow for a means to monitor multiple test/lab results.
It is appreciated that timers may be used in various ways in the various embodiments described herein. In general any communication or notice (e.g., the notices 1700, 1800 and 1900) may include a timer 1710. Although the timer 1710 is discussed herein in various examples, more generally a timer may be used to notify patients, physician's, practitioners, and/or any other suitable person of an action that is required by him/her (e.g., view the notice, view the information contained in the notice, follow the action in the notice), any missed actions (e.g., a reminder), may be used for notices to become expired and no long visible by the user.
A delegate, such as a patient's legal guardian and/or any other suitable person, having a delegate's computing entity (similar to the patient's computing entity 106) may be setup for receiving notices with the Human-Centric EHR system 102. The delegate's computing entity may receive notices instead of the patient's computing entity 106 or the patient's computing entity 106 and the delegate's computing entity may both receive notices. This may be useful where the patient is disabled or has limited mobility and needs regular assistance from another person.
Health Related Determination Mechanism Figure 9 illustrates a block diagram of an example of the Human-Centric EHR
system 102, where the Human-Centric EHR system 102 is able to receive and obtain auxiliary medical related Date Recue/Date Received 2020-11-05 information. The Human-Centric EHR system 102 may be connected to the patient computing entity 106, to the physician's EHR systems 104, to the EHR network 108 and/or to one or more systems that provide public health advisories 112. As illustrated, the patient computing entity 106 is connected to one or more sensors 192. In some cases, the patient computing entity 106 is also connected to an external device 194. The various connections between the Human-Centric EHR
system 102, the patient's computing entity 106, the physician's EHR system 104, the medical EHR system 110 (not illustrated in Figure 9), the EHR network 108, the public health advisor systems 112, one or more sensors 192 and/or the external device 194 may include one or more connections over one or more data networks. The various connections between the Human-Centric EHR system 102, the patient's computing entity 106, the physician's EHR system 104, the medical EHR system 110, the EHR network 108, the public health advisor systems 112, one or more sensors 192 and/or the external device 194 may allow for the communication (e.g., transmission and/or reception) of various information and/or data between the various systems and/or devices. The various information and/or data exchanged may be a "notice", "notices", "health record" and/or "health records" of the type discussed elsewhere in this document. In some embodiments the connection between the one or more sensors 192 and/or the external device 194 with the patient's computing entity 106 may be a wired (e.g., USB, USB-C, Ethernet, FirewireTM
or any other suitable connection) or wireless connection (e.g., BluetoothTM, ZigBeeTM, Wi-FiTM, or any other suitable connection).
Figure 10 illustrates a flowchart of a process 1000 which may be implemented at the Human-Centric UR system 102 for making a health related determination at least in part by processing data obtained from one or more sensors 192 in combination with health records associated with a patient. At step 1002, data from one or more sensors 192 is obtained. This may include monitoring data obtained from the one or more sensors 192 where these sensors 192 measure a physical condition of a patient and where the monitoring of the data from the one or more sensors is done over a plurality of time points. These one or more sensors 1002 may be of various types, including: blood pressure monitors, blood glucose monitors, heart rate monitors, accelerometers, GPSs, barometer, altimeter, ambient light level detector, spectrum analyzer, any other sensors located in a portable computing device (e.g., smart-watch, portable phone, tablet, PDA, or any other suitable portable computing device), and/or any other suitable sensor or computing device.
At this step, data from public health advisory systems 112 may also be obtained, which may include various types of information such as smog warnings, heatwaves and/or any other suitable information.

Date Recue/Date Received 2020-11-05 At step 1004 the data from the one or more sensors 192 is stored in association with a health record associated with a patient. It is appreciated that the data from the one or more sensors may be collected over multiple time points to form longitudinal data. This longitudinal data associated with the patient may track a physical condition of a patient over a period of time. This longitudinal data may also include environmental factors such as atmospheric pressure, UV
exposure and/or any other suitable environmental factors. This longitudinal data associated with the patient may be stored in one or more health records on the Human-Centric EHR system 102.
The Human-Centric UR system 102 may also contain a continuum of heath records associated with the patient obtained from various EHR systems and/or the EHR network 108.
In other words, the medical records may have been obtained from a plurality of EHR
systems and/or other sources. This longitudinal data in combination with the continuum of heath records associated with the patient may allow for processing of this information to make a health related determination for the patient, such as may be done at step 1006. In general, at step 1006, health .. records including the data from the sensors 192 are processed. This may include processing the data from the sensors 192 against the medical records associated with the patient or processing the health records associated with the patient where these health records are augmented by the data from the sensors 192. This processing may also include tracking trends in the longitudinal data. Then at step 1008, at least in part by processing the health record including the data from the sensors a health related determination is made. The health related determination may be made when a threshold level is detected. The detection of the threshold level being reached may be determined by computer processing. The detection of the threshold level being reached may also be verified by a third-party agent (e.g., a person). The health related determination may include sending a notice to the patient via the patient's computing entity 106. The health related determination may include a notice being sent to the patient's primary physician, assuming that the patient has named a primary physician. In the case that a third-party agent verifies the threshold level being reached the agent may initiate the communication of the notice to the patient and/or to the physician to indicate the unsafe condition. In the case that the notice from a heath related determination is sent to the physician's EHR system 104, the physician may then be notified via the physician's EHR system 104 to review the notice and then make a determination to notify the patient, which may then be sent from the physician's EHR system 104 to the patient's computing entity 106 via the Human-Centric EHR system 102.
The process 1000 should likely become more readily apparent in view of the following examples:

Date Recue/Date Received 2020-11-05 Blood pressure monitor example: In this example the sensor 192 is a sensor that monitors blood pressure. The sensor 192 is in communication with the patient's computing entity 106 and the patient's computing entity 106 communicates blood pressure data to the Human-Centric EHR system 102, such that the Human-Centric EHR
system 102 may monitor this data. The patient's health records indicate that the patient has high blood pressure and the Human-Centric EHR system 102 based on processing the patient's health records determines that if the blood pressure of the patient rise above a certain threshold that the patient via the patient's computing entity 106 and/or the patient's physician via the physician's EHR system 102 should be notified as this may be an indication of a possible medical issue.
Blood glucose monitor example: In this example the sensor 192 is a sensor that monitors blood glucose levels. Various blood glucose monitors are currently available in the market (e.g., MyGlucoHealth Blood Glucose Meter with Bluetooth Technology).
The sensor 192 is in communication with the patient's computing entity 106 and the patient's computing entity 106 communicates blood glucose data to the Human-Centric EHR
system 102, such that the Human-Centric EHR system 102 may monitor this data.
The patient's health records indicate that the patient has diabetes and the Human-Centric EHR
system 102 based on processing the patient's health records determines that if the blood glucose level of the patient raises above a certain threshold that the patient via the patient's computing entity 106 and/or the patient's physician via the physician's EHR
system 102 should be notified as this may be an indication of a possible medical issue.
Heart rate monitors & exercise equipment example: In this example the sensor 192 is a sensor that monitors heart rate. Various heart rate monitors are currently available (e.g., 0Msignal Biometric Smartwear). The sensor 192 is in communication with the patient's computing entity 106 and the patient's computing entity 106 communicates heart rate data to the Human-Centric EHR system 102, such that the Human-Centric UR
system 102 may monitor this data. In this example, the device 194 generally speaking is a piece of exercise equipment and in particular is a treadmill. Prior to starting to run on the treadmill the patient identifies the sensor 192 and device 194 to the Human-Centric EHR
system 102. The Human-Centric EHR system 102 based on the patient's health records make a determination that the patient should run at a specific pace and may control the Date Recue/Date Received 2020-11-05 speed of the treadmill. As the patient starts to run on the treadmill, his/her heart rate increase and in this example the heart rate is too high and the Human-Centric EHR
system 102 makes the determination by processing the heart rate data in combination with the patient's health records that the speed of the treadmill should be reduced. In other words, in this example, the Human-Centric EHR system 102 may make a recommendation of a treadmill speed based on the patient's health records and may adjust the speed in accordance with changes in heart rate.
Chronic obstructive pulmonary disease, GPS & public health advisory example:
In this example the sensor 192 is a GPS sensor which may be part of the patient's computing entity 106. The sensor 192 is in communication with the patient's computing entity 106 and the patient's computing entity 106 communicates GPS location data to the Human-Centric EHR system 102, such that the Human-Centric EHR system 102 may monitor this data. The patient's health records indicate that the patient has chronic obstructive pulmonary disease (COPD) and the Human-Centric EHR system 102 based on processing the patient's health record determines that the Human-Centric system should obtain public health advisories for the public health advisory system 112.
Then the Human-Centric EHR system 102 monitors the location of the patient and processes the public health advisories to determine if the patient is in a high smog area and if such is the case, notifies the patient via the patient's computing entity 106 and/or the patient's physician via the physician's EHR system 102.
The above examples are intended to be non-limiting and various other examples of using the sensors 192 in combination with the patient's health records obtained for multiple EHR system and/or sources to make health related determinations are possible.
The Human-Centric EHR system may be provided with logic that can process the information received from the various biometric sensors and generate calibration data sent to wearable or stationary devices intended to provide guidance to the patient regarding physical activity. For example, the program logic can interpret the physiological information received such as to set a safe level of activity that the user should not exceed in order to avoid a health risk, such as a heart attack, stroke or other. To be more specific, the program logic will process the physiological information such as the hear rate, blood pressure and blood glucose, among others to derive the safe level for physical activities. This processing can be performed by mapping the physiological Date Recue/Date Received 2020-11-05 data with predetermined degrees of "safe level" exercise intensity, such as exercise duration, speed of running, maximal heart level rate during the exercise, etc. In a possible refinement, the program logic can use other information from the patient record, which is co-related to the physiological information to further refine the "safe level" for the user based on the user's medical history.
The calibration data can be sent to the physiological sensor that generated the physiological data when that sensor is used to provide physical activity guidance to the user, such as the degree of daily physical activity desired. The calibration data will thus determine the amount of activity (calories burned) and the intensity.
In one specific example, the calibration data can be sent to an exercise machine, such as a treadmill, to set the operational parameters of the treadmill for an exercise session for the user, such as the maximal running speed, duration, elevation, etc. A similar approach can be considered for another kind of exercise equipment such a muscle building machine.
In other embodiments instead of the Human-Centric EHR system 102 processing the health record associated with the patient and the auxiliary medical related information (e.g., data from sensors 192, device 194, public health advisory system 112, and/or any other suitable information) the Human-Centric EHR system 102 may transmit the health record associated with the patient and the auxiliary medical related information to a third-party system (e.g., an agent) which may then process the health record and auxiliary medical related information to make the health related determination in a similar fashion as that discussed above. In such case, after the third-party system makes the health related determination, the third-party system may transmit the health related determination to Human-Centric EHR system 102 which may forward the health related determination to the physician's EHR system 104 and/or the patient's computing entity 106.
It is appreciated that the health related determination may be made by a computer based decision support agent that contains logic that can make a health related determination. More specifically, the decision support agent may process the health record associated with the patient and the auxiliary medical related information in relation to rules, fact, fact and rules, models, algorithms, search, procedural code, analytic techniques, inference engine and/or any other suitable technique or logic to make the health related determination that may add value to the patient. In some cases Date Recue/Date Received 2020-11-05 the decision support agent is an artificial intelligence and/or expert system that may emulate the decision making ability of a human expert.
Although in the examples above the health record associated with the patient and the auxiliary medical related information was processed to make a health related determination, in other embodiments the health record associated with the patient may be processed on its own (without the auxiliary medical related information) to make a health related determination in a manner similar to that discussed above.
.. Third-party Medical Record Access Mechanism Figure 11 illustrates a block diagram of an example of the Human-Centric EHR
system 102, where the Human-Centric EHR system 102 is able to provide a health record associated with a patient to a third-party system 111 upon authorization of the patient at the patient computing entity 106 (e.g., a computing entity associated with the patient) in accordance with an embodiment of the invention. The third-party system 111 may be an EHR system similar to the physician's EHR system 104, discussed elsewhere in this document. As illustrates the Human-Centric EHR system 102 is connected to the patient's computing entity 106 and to a third-party systems 111 (e.g., an system associated with a third-party). The various connections between the Human-Centric EHR system 102, the patient's computing entity 106 and/or the third party system 111 may include one or more connections over one or more data networks. The various connections between the Human-Centric EHR system 102, the patient's computing entity 106 and/or the third party system 111 may allow for the communication (e.g., transmission and/or reception) of various information and/or data between the various systems and/or devices. The various information and/or data exchanged may be a "notice", "notices", a "health record" and/or "health records" of the type discussed elsewhere in this document. The third party system 111 may be viewed as an agent. For example, it may be a system that examines records associated with the patient. The agent may be able to examine or process the records and make various determinations and/or annotations to one or more of the records. It is appreciated that the agent may be a person at the third party system 111 that reviews the views the health records and then runs additional tests or processes on the health record to make the various determinations and/or annotations to one or more of the records. In some embodiments, the agent may be a computer based agent comprising the computer based decision support agent (discussed elsewhere in this Date Recue/Date Received 2020-11-05 document) that may process the health records and make various determinations and/or annotations to one or more of the records.
Figure 12A illustrates a flowchart of a first process 1200 for providing one or more health records associated with a patient to the third-party system 111. At step 1202 a request from a third-party system 111 for one or more health records associated with a patient is received at the Human-Centric EHR system 102. The request may be initiated from the third-party system 111. At step 1204, the patient associated with the heath record which was requested is notified of the request for the one or more health records via the patient's computing entity 106. The Human-Centric EHR system may also request that the patient via the patient's computing entity 106 provide authorization to provide the third-party system 111 with the one or more health records. In this example, the patient's computing entity 106 is provided with the notice (similar to the notices discussed elsewhere in this document) and the request for authorization (e.g., an action item). At step 1206, the Human-Centric EHR system 102 receives the authorization from the patient via the patient's computing entity 106. Then, at step 1208, the one or more health records associated with the patient are provided by the Human-Centric EHR system 102 to the third-party via the third-party system 111. If the authorization of the patient at step 1206 fails or the patient declines to authorize the Human-Centric EHR system 102 to provide the records to the third-party system 111, the process 1200 would stop (i.e., no records would be provided at step 1208).
Steps 1204 may be similar to step 704 discussed above, in that a notice is sent to the patient via the patient's computing entity 106. The notice may not provide any indication of the contents of the notice other than indicating that some action/information is available.
The patient may then authenticated himself/herself at step 1206 (e.g., similar to step 706) and the Human-Centric EHR
system 102 would then authenticate the request (e.g., similar to step 708).
Once the patient's computing entity 106 is authenticated to the Human-Centric EHR system 102 a common proxy identifier may be used to communicate data between the patient's computing entity 106 and the Human-Centric EHR system 102. Then the patient's computing entity 106 may send the request to the Human-Centric EHR system 102 to authorize the patient's computing entity 106 to provide one or more records associated with the patient to the third-party system 111.
Figure 12B illustrates a flowchart of a second process 1300 for providing one or more health records associated with a patient to a third-party. The process 1300 is similar to process 1200;
however, the process 1300 may be initiated by the patient while the process 1200 may be initiated Date Recue/Date Received 2020-11-05 by the third-party. At step 1302 a request from a patient via the patient's computing entity 106 is received at the Human-Centric EHR system 102. The request is for the Human-Centric UR
system 102 to provide a health record associated with the patient to a third party. This request from the patient may occur after the patient has authenticated himself/herself to Human-Centric EHR system 102, as discussed above. In this example, the third-party is associated with the third-party system 111. At step 1304, the request is authenticated and then, at step 1306, the one or more health records associated with the patient are provided to the third-party system 111. Step 1304 and 1306 are similar to steps 1206 and 1208 discussed above. If the authorization of the patient at step 1304 fails, the process 1300 would stop (i.e., no records would be provided at step 1306).
Figure 13B illustrates a flowchart of a third process 1350 for providing one or more health records associated with the patient to the third-party system 111. The process 1350 is similar to that of the process 1200; however, the request to provide the one or more health records associated with the patient to the third-party system 111 is initiated by the physician at the physician's UR system 104. For instance, the process 1350 may be implement on the Human-Centric UR system 102 shown in Figure 13A, which illustrates a block diagram of an example of the Human-Centric UR system 102 shown in Figure 11, but where the physician's EHR
system 104 is in communication with the Human-Centric EHR system 102 for initiating the request to provide the one or more health records associated with the patient to the third-party system 111. Turning back to the process 1350, at step 1352 a request from the physician's EHR
system 104 to provide one or more health records associated with a patient to the third-party system 111 is received at the Human-Centric EHR system 102. At step 1354, the patient associated with the heath record which was requested is notified of the request for the one or more health records via the patient's computing entity 106. The Human-Centric EHR system may also request that the patient via patient's computing entity 106 provide authorization to provide the third-party system 111 with the one or more health records. Step 1354 may be implemented in a similar way as step 1204 discussed above. At step 1356, the Human-Centric EHR system 102 receives the authorization from the patient via the patient's computing entity 106. Step 1356 may be implemented in a similar way as step 1206 discussed above. Then, at step 1358, the one or more health records associated with the patient are provided by the Human-Centric EHR system 102 to the third-party system 111. Step 1358 may be implemented in a similar way as step 1208 discussed above. If the authorization of the patient at step 1356 fails or the patient declines to Date Recue/Date Received 2020-11-05 authorize the Human-Centric EHR system 102 to provide the records to the third-party system 111, the process 1350 would stop (i.e., no records would be provided at step 1358).
Also, although not illustrated in Figures 12A, 12B and 13B, the patient may at a later time withdraw authorization to the third-party to have access to the health records associated with the patient. For instance, the patient via the patient's computing entity 106 may authenticate himself/herself to the Human-Centric EHR system 102 (as discussed elsewhere in this document), afterwards the patient via the patient's computing entity 106 may send a request to the Human-Centric EHR system 102 to remove or revoke access to a third-party to one or more of the health records that the third-party previously had access thereto. In other words, the patient with the patient's computing entity 108 may connect to the Human-Centric EHR system 102 to control who has visibility access to his/her entire health record or to specific records.
The processes 1200,1300 and 1350 are illustrated further by way of a specific and non-limiting example. In this example, the Human-Centric EHR system 102 has an agent company providing 'on-call' physicians that can read one or more health records and provide interpretation/information. The patient may first subscribe to the agent and then the patient may request a second opinion on one or more health records (e.g., such as at step 1302). For instance, the patient may subscribe directly to the third-party system 111 or may subscribe to the third-party system 111 via the Human-Centric EHR system 102. The third-party system 111 is notified via the Human-Centric UR system 102, assigns a third-party physician, and issues a notice to authorize (e.g., patient-physician pairing) via the Human-Centric EHR system 102. The patient receives the notice (e.g., such as at step 1204). The notice includes an action which requires confirmation and the patient confirms (e.g., such as step 1206). The third-party physician via the third-party system 111 receives a notice with the one or more health records attached (e.g., such as at step 1208 or 1306). For example, the third-party physician may connect to the third-party system 111 and/or to the Human-Centric EHR system 102 via the third-party system 111 to gain access to the patient's health records. Then the third-party physician may add a determination and/or an annotation to the one or more health records. When a determination and/or annotation is added to the one or more health record associated with the patient on the Human-Centric EHR
system 102, the patient at the patient's computing entity 106 may receive notice from the Human-Centric UR system 102, with the attached third-party physician's determination and/or annotation. The primary physician, of the patient, via the physician's EHR
system 104 may also Date Recue/Date Received 2020-11-05 be notified when a determination and/or an annotation is added to a health record associated with the patient.
Similarly, the example above instead of the health records associated with the patient being provided to a physician for review, the health records may be provided to a third-party system 111 for processing the patient's records to make a health related determination. For example, the determination may be to identify some genetic predisposition that the patient has and/or any other suitable medical condition. In other words, the patient may provide at least some of his/her health records to the third-party system 111 for processing or continuous monitoring, such that the system may make a health related determination and then provide such heath related determination to the patient. For instance, the health related determination may be made by the computer based decision support agent that contains logic that can make a health related determination, discussed elsewhere in this document. The computer based decision support agent may also be used for continuous monitoring of the patient's health record and when a possible .. medical condition is detected, cause a notification to be sent to the patient and/or the patient's physician.
The processes 1200,1300 and 1350 are illustrated further by way of a specific and non-limiting example. In this example, the patient is visiting family in Australia and the patient has a care need. The patient finds a third-party physician and would like to provide this third-party physician with his health records. The patient via the patient's computing entity 106 grants the third-party physician / the third-party physician's clinic access rights to his health records on the Human-Centric EHR system 102. The patient via the patient's computing entity 106 may connect or log into the Human-Centric EHR system 102 and select the third-party that the patient .. desires to share his health records with (e.g., such as at step 1302), as is shown in example illustrated in Figure 16F. The patient may be able to set a start and end date (and time) or an expiry date (and time) for which the third-party physician can have access to the patient's health records. The patient may also be able to select (e.g., flag) which health records that the patient would like to have provided to the third-party physician. After the Human-Centric EHR system 102 receives this request from the patient to grant the third-party physician access rights to the selected health records, the Human-Centric EHR system 102 notifies the third-party physician via the third-party system 111. Although the third-party system 111 in some embodiments is an EHR
system, in other cases this system 111 may not have EHR capabilities but may be any portable or non-portable computing device and/or entity, such as a cell-phone, a tablet, a smart watch, a Date Recue/Date Received 2020-11-05 laptop/notebook computer, a computer or any other suitable computing device.
In this example the third-party system 111 associated with the third-party physician receives a notice from the Human-Centric EHR system 102. This notice may be in the form of a secure email granting the third-party physician access to the Human-Centric EHR system 102 to access the selected health records associated with the patient. In this example, the third-party physician's access to the Human-Centric EHR system 102 would be limited to the health records associated with that patient only and may be limited to health records that the patient chooses to share with the third-party physician. The third-party physician logs-in with his third-party computing device 111 and has access to whatever parts the patient has selected as accessible by the third-party physician. As such, the patient is able to provide access right to all of his health records or to select with health records that the patient would like to grant access to. In this example, before the third-party physician can actually see the health records associated with the patient, the patient's computing entity 106 receives notice with an allow or deny confirmation option (e.g., such as at step 1204).
This option allows for the patient to deny access, for example if the patient is not in the presence of the third-party physician. If the patient allows access (e.g., such as at step 1206), for example, when the patient has the benefit of visually verifying the identity of the third-party physician, the third-party computing device 111 is then provided with the health records associate with the patient that the patient has selected to be accessible by the third-party physician. In this example, the patient may use biometric authentication (or any other suitable means of authentication) on the patient's computing entity 106 in order to confirm that the actual patient, as opposed to the person who has the device in hand, is authorizing the access.
Care Support Group A care support group system will now be described with reference to Figures 18, 19A to 19E, 20A, 20B and 21. In general, the care support group may be considered a subset of the health records associated with a patient that is accessible and updatable by a select group of practitioners. Figure 18 illustrates a block diagram of an example of the Human-Centric EHR
system 102 connected to a primary physician's EHR system 104, a plurality of EHR systems 1041 1042 1043 associated with other practitioners and to the patient's computing entity 106 in accordance with an embodiment of the invention. In this embodiment, the primary physician via the physician's EHR system 104 is able to create a care support group around a patient and a situation associated with the patient via the Human-Centric EHR system 102.
Figures 19A to 19E illustrate specific and non-limiting examples of information that may be displayed on a Date Recue/Date Received 2020-11-05 graphical user interface (GUI) of a physician's computing entity in the process of creating the care support group in accordance with specific and non-limiting examples of implementation.
Figures 20A and 20B illustrate flowcharts of processes 2000A and 2000B for creating the care support group in accordance with a specific non-limiting example of implementation. Figure 21 illustrates an example of a computer readable data structure 2100 for the care support group that may be stored on the Human-Centric EHR system 102 in accordance with a specific non-limiting example of implementation.
It is appreciated that the primary physician associated with the patient may want to share various health records and information associated with a patient in order to provide care to the patient.
For instance, the primary physician may want to create a therapeutic team for the collaboration in the treatment of a specific condition (e.g., condition, disorder, infection, disability, injury, situation and/or any other suitable condition or situation) associated with the patient. For instance, the medical condition may have specific symptoms and signs that the physician has identified which may be determined based on testing results (e.g., blood tests, urine tests, x-ray images, and/or any other suitable test). As such, the physician may want to further investigate and/or treat the medical condition. Regardless of the specific condition or situation for creating the care support group around, the physician may interact with the Human-Centric EHR
system 102 to create the care support group further described below.
A specific and non-limiting example of the care support group (or circle of care) will now be described. In this example, the patient John Doe was diagnosed as having cancer by his primary physician Dr. Smith. As John Doe chooses to undergo various treatments based on the advice of his primary physician, Dr. Smith chooses to interact with the Human-Centric UR
system 102 via his physician's EHR system 104 to create a care support group during the treatment of John Doe's cancer. As such, the primary physician Dr. Smith connects to the Human-Centric UR
system 102 which may include him logging in with the physician's EHR system 104 to the Human-Centric UR system 102 by providing his account identifier and credential. After logging in to the Human-Centric EHR system 102, the GUI of the display device associated with the primary physician's EHR system 104 may be conditioned to display the information shown in Figure 19A. As shown, Figure 19A provides Dr. Smith with various interface controls to allow him to select and view health records associated with a patient, add a patient to the Human-Centric UR system 102, create a care support group, view a care support group and edit a care support group. Other interface controls may be available in other embodiments.

Date Recue/Date Received 2020-11-05 The primary physician Dr. Smith may select the interface control to create a new care support group and then may be provided with the information shown in Figure 19B, which includes interface controls for adding a patient, adding practitioners. Other interface controls may be included in other embodiments. Afterwards, the primary physician Dr. Smith may create the care support group according to the process 2000A in Figure 20A. For instance, the primary physician Dr. Smith may create the care support group by adding a patient to the care support group (step 2002), adding one or more practitioners to the care support group associated with the patient (step 2004) and adding one or more health records to the care support group associated with the patient (step 2006). The order of steps 2002, 2004, 2006 may vary in various embodiments. The Human-Centric EHR system 102 receives the requests from the physician's EHR
system 104 to create and add aforementioned aspects to the care support group, processes the request and creates the care support group accordingly which may include creating the data structure 2100.
The data structure 2100 is for illustration purposes only and may vary in various implementations of the care support group.
To further illustrate step 2002, the primary physician Dr. Smith may select the interface control to add a patient to the care support group and then may be provided with the information shown in Figure 19C. Figure 19C illustrates an example of information shown on the GUI
of the primary physician's EHR system 104 for adding a patient to the care support group. As shown, the primary physician Dr. Smith may search for a patient by his/her name, date of birth, health card number and/or any other suitable identifier (e.g., address, phone number, to name a few). Then the primary physician Dr. Smith may add the patient, which in this example is John Doe, to the care support group. The Human-Centric EHR system 102 may provide the primary physician's EHR system 104 with a listing of patients. Adding the patient to the care support group may include selecting John Doe's name (or other suitable identifier) from the listing shown on the GUI of potential patients selectable by the physician.
To further illustrate step 2004, the primary physician Dr. Smith may select the interface control to add practitioners to the care support group and then may be provided with the information shown in Figure 19D. Figure 19D illustrates an example of information shown on the GUI of the primary physician's EHR system 104 for adding one or more practitioners to the care support group. As shown, the primary physician Dr. Smith may search for a practitioner by his/her name, specialty, location and/or any other suitable identifier (e.g., clinic name, hospital name, to name a Date Recue/Date Received 2020-11-05 few). The Human-Centric EHR system 102 may provide the primary physician's EHR
system 104 with a listing of practitioners. Then the primary physician Dr. Smith may add a desired practitioner to the care support group. Adding the practitioner to the care support group may include selecting the practitioner's name (or other suitable identifier) from the listing shown on the GUI of potential practitioners selectable by the physician. The primary physician Dr. Smith may add more than one practitioner to the care support group at this step. In this example, the primary physician Dr. Smith adds an oncologist Dr. Johnson, a radiologist Dr.
Williams and a nurse practitioner Ms. Jones.
To further illustrate step 2006, the primary physician Dr. Smith may select the interface control to add one or more health records to the care support group and then may be provided with the information shown in Figure 19E. Figure 19E illustrates an example of information shown on the GUI of the primary physician's EHR system 104 for adding one or more health records associated with the patient to the care support group. The primary physician Dr. Smith may be provided with a listing of all or a select number of the patient John Smith's health records that are stored on the Human-Centric EHR system 102 and then is provided the opportunity to select the health records that the primary physician Dr. Smith believes to be relevant for being added to the care support group for access by the other practitioners associated with the care support group.
The selection of the health records for being accessible to the care support group may include the use of a search and/or selection field for selecting specific health records meeting a specific criterion. For example, the primary physician Dr. Smith may be able to select records according to: a date range (e.g., health records before a certain date, after a certain date, between two dates);
a location (e.g., a specific clinic, hospital, laboratory, imaging facility, city, province/state, country); a practitioner (e.g., a doctor's or practitioner's name) a condition associated with the record (e.g., disorder, infection, disability, injury, situation and/or any other suitable condition or situation); testing results (e.g., blood tests, urine tests, x-ray images, and/or any other suitable test or image type); and/or any other suitable field for selecting health records.
Once the primary physician Dr. Smith creates the care support group, prior to the other practitioners (which in this example are Dr. Johnson, Dr. Williams and Ms.
Jones) are granted access to the care support group the patient may have to grant authorization.
At step 2008, the primary physician Dr. Smith requests authorization from the patient to create the care support group. The authorization may be done through the Human-Centric EHR system 102 in which case upon creation of the care support group the patient is notified via the Human-Centric EHR
Date Recue/Date Received 2020-11-05 system 102 of the care support group and is asked to grant access, which may be done according to the process 2000B. In other cases, the authorization may be a verbal authorization by the patient to the physician during the consultation, in which case the primary physician may indicate to the Human-Centric EHR system 102 that the patient has provided consent and the other practitioners may now have access to the care support group.
Turning to Figure 21, the example care support group data structure 2100 stored on the Human-Centric EHR system 102 is shown. As shown, the data structure 2100 includes a primary physician identifier 22001 which is used as a pointer to point to a data record 2201 associated with the primary physician Dr. Smith. When the primary physician Dr. Smith creates the care support group (as discussed above) the Human-Centric EHR system 102 may create the care support group data structure 2100 and add the primary physician's identifier 22001 upon creation (e.g., creates the pointer). The data record 2201 may include information associated with the primary physician Dr. Smith such that when the primary physician Dr. Smith connects and logs in to the Human-Centric EHR system 102 via his EHR system 104, he has access to the care support group associated with the data structure 2100.
The data structure 2100 also includes a patient identifier 11001 which is used as a pointer to point to a data record 2110 associated with the patient John Doe. When the primary physician Dr.
Smith created the care support group (as discussed above) and associates the patient to the care support group, the Human-Centric EHR system 102 may add the patient identifier 11001 to the data structure 2100 (e.g., creates the pointer). It is appreciated that the Human-Centric EHR
system 102 may maintain a list of the patients that are registered with the Human-Centric EHR
system 102 and/or that have health records stored therein. As such, the Human-Centric EHR
system 102 may have a list of patients where each of the patients is associated with a unique identifier, which may be used in the storage of data and health records associated with each patient. The data record 2110 may include information associated with the patient John Smith such that when the patient John Smith connects and logs in to the Human-Centric EHR system 102 via his computing entity 106, he has access to the care support group associated with the data structure 2100. The data record 2110 may include information pertaining to the patient John Smith's health records such as storage of the health records themselves and/or pointers to where the health records associated with the patient may be accessed.

Date Recue/Date Received 2020-11-05 The data structure 2100 also includes other practitioners' identifiers 22012, 22014, 22016 which are used as pointers to point to respective data records 2202 2204 2206 associated with Dr.
Johnson, Dr. Williams and Ms. Jones, respectively. When the primary physician Dr. Smith created the care support group (as discussed above) and associates the other practitioners to the care support group, the Human-Centric EHR system 102 may add the other practitioners' identifiers 22012, 22014 and 22016 to the data structure 2100 (e.g., creates the pointers). It is appreciated that the Human-Centric EHR system 102 may maintain a list of the practitioners that are registered with the Human-Centric EHR system 102. As such, the Human-Centric EHR
system 102 may have a list of all of the practitioners where each of the practitioners is associated .. with a unique identifier, where the unique identifiers may be used for allowing respective practitioners access to various health records associated with various patients. More specifically, the practitioners' identifiers may be used such that respective practitioners have access to the care support group. The data records 2202, 2204 and 2206 may include information associated with the respective practitioners such that when one of the practitioners connects and logs in (e.g., by .. providing his/her account identifier and credential) to the Human-Centric EHR system 102 via his/her EHR system 1041, 1042 or 1043, he/she has access to the care support group associated with the data structure 2100.
The data structure 2100 also includes health record identifiers 11001-00010, 11001-00011, 11001-00012, 11001-00013, 11001-00014 and 11001-00015, which are used as pointers that point to respective health records 3021, 3022, 3023, 3024 and 3025, respectively. When the primary physician Dr. Smith created the care support group (as discussed above) and associates patient's health records to the care support group, the Human-Centric EHR system 102 may add the health record identifiers 11001-00010, 11001-00011, 11001-00012,11001-00013, 11001-00014 and .. 11001-00015 to the data structure 2100. These health records 3021, 3022, 3023, 3024 and 3025 may be of the type discussed elsewhere in this document.
Turning now to Figure 20B, the patient may grant access to the selected practitioners to the care support group according to the process 2000B. At step 2052, the Human-Centric EHR system 102 receives the request from the physician's EHR system 104 to create the care support group associated with the patient (e.g., step 2008 of process 2000A). At step 2054, the Human-Centric EHR system 102 then notifies the patient John Doe via his computing entity 106 of the request to create the care support group and request authorization from the patient. This step of notification and authorization may be done according to the various methods and process discussed elsewhere Date Recue/Date Received 2020-11-05 in the document, which may include sending a notice which does not provide any confidential information prior to sending the request for authorization. At step 2056, the Human-Centric EHR
system 102 receives the authorization from the patient, and the Human-Centric EHR system 102 authorizes the practitioners associated with the care support group access to patient's health records associated with the care support group. Then at step 2058, in response to the patient's authorization for the creation of the care support group, then each of the practitioners associated with the care support group may have access to the care support group and the associated health records of the patient made available through the care support group.
.. It is appreciated that the patient may deny access to the creation of the care support group and in such case access would not be granted to the practitioners. In other cases, the patient have the ability in granting the authorization to select which practitioners may be added to the care support group and/or which health records may be added to the care support group. For example, the patient may be provided on the GUI of his computing entity 106 with a list of the other .. practitioner that the primary physician has added to the care support group and/or a list of the health records that the primary physician has added to the care support group.
Then, the patient may be able to select the various practitioners and/or health records that are made available to the care support group.
After the care support group has been created, the patient (e.g., John Doe) may be able to log into the Human-Centric EHR system 102 and add additional practitioners and/or health records to the care support group. For example, if the patient John Doe sees another doctor Dr. Anderson, then John Doe may then add Dr. Anderson to his care support group such that Dr.
Anderson may be able to log in to the Human-Centric EHR system 102 and have access to the care support group.
By way of another example, if the Human-Centric EHR system 102 receives additional health records associated with the patient, the patient may be notified of the additional health records, which the patient may add to the care support group. In general, the patient may be able to add health records to the care support group by selecting any of the health records stored on the Human-Centric EHR system 102 such that the practitioners associated with the care support group have access to the added health records.
In some embodiments, the patient may have the ability to specify which health records to be accessible to which of the practitioners associated with the care support group and may have the ability to place restrictions on the practitioners that have access to the care support group. The Date Recue/Date Received 2020-11-05 practitioners added to the care support group may be added with specific time limitations (e.g., corresponding to a treatment and/or recovery period) and the patient may be able to specify the time periods that one or more of the practitioners has access to the care support group. The patient may also have the ability to be able to log in to the Human-Centric EHR system 102 and remove practitioners and/or health records from the care support group.
After step 2058 each of the practitioners may be sent a notice from the Human-Centric EHR
system 102 that the care support group has been created, that the patient has granted authorization and/or that they now have access to the care support group. In this example, the practitioners Dr.
Smith, Dr. Johnson, Dr. Williams and Ms. Jones may then be able to connect to the Human-Centric EHR system 102 to have access to the care support group. The practitioners Dr. Smith, Dr. Johnson, Dr. Williams and Ms. Jones may connect via the respective EHR
systems 104, 1041, 1042 and 1043. It is appreciated that the practitioners Dr. Smith, Dr.
Johnson, Dr. Williams and Ms. Jones may not be tied to a specific system or device and may connect via various EHR
systems or devices to the Human-Centric EHR system 102 using their account identifiers and credentials.
Each of the practitioners may be able to view the health records associated with the patient that is associated with the care support group. For example, prior to the patient John Doe having a consult with Dr. Johnson, Dr. Johnson may connect to the Human-Centric EHR
system 102 and view the various records of the care support group associated with the patient John Doe.
Each of the practitioners may be able to add annotations to a specific health record in the group of the health records associated with the care support group. Each of the practitioners may be able to add additional health records to the group of health records associated with the patient that is associated with the care support group. For example, after the patient John Doe has a consult with Dr. Johnson, Dr. Johnson may then add an annotation and/or a new health record to the care support group associated with the patient John Doe, which may detail the Dr.
Johnson assessment the patient and/or the patient's current health records.
Continuing with this example, Dr. Johnson may add a treatment regime for the patient John Doe and may add this to a new health record associated the care support group associated with the patient John Doe. Then in administering the treatment regime, the nurse practitioner Ms. Jones may access the care support group associated with the patient John Doe to view the treatment Date Recue/Date Received 2020-11-05 regime which may include a treatment dosage and schedule for the treatment of John Doe's cancer. Ms. Jones may add an annotation and/or new health record to the care support group associated with the patient John Doe after administering the cancer treatment.
After adding the annotation and/or new health record related to the patient being administered the treatment, a notice may be sent to Dr. Johnson via the Human-Centric EHR system 102 such that Dr. Johnson is notified that the patient is undergoing the prescribed treatment.
It is appreciated that the annotation and/or new health record added to the care support group associated with the patient John Doe may also include the addition of notices and/or action items (which are also discussed elsewhere in this document). For example, Dr.
Johnson in adding the treatment regime may add an action item to notify the nurse practitioner that John Doe is going to undergo treatment and that an appointment should be schedule. By way of another example, Dr.
Johnson in adding the treatment regime may add an action item such that he will be notified of the patient's treatment. In other words, action items and/or notices may be used by the practitioners to schedule treatments, prescribe prescriptions/treatments, to schedule appointments, setup reminders, inter-practitioner communication, to share laboratory testing and/or imaging results, and/or any other suitable means.
It is also appreciated that the same patient may be part of more than one care support group, as the care support group may be created regarding a specific condition. For example, the patient may have a care support group for the treatment of cancer and another care support group for the treatment of diabetes, where the practitioners in each care support group are different and have different access to the patient's health records. In some cases, the primary physician may be the same in multiple care support groups and some practitioners may be associated with multiple cares support groups associated with the same patient.
Although in this example the plurality of EHR systems 1041 1042 1043 associated with other practitioners have EHR functionality, in other embodiments, the systems 1041 associated with other practitioners do not have EHR capability are may be any suitable computing system such as a computer, laptop, tablet, mobile phone and/or any other suitable device. In such case, the systems 1041 1042 1043 associated with other practitioners may connect to the Human-Centric EHR system 102 via a web browser, application software running on the systems 1041 1042 1043 and/or any other suitable means.
Date Recue/Date Received 2020-11-05 Although in this example, the primary physician Dr. Smith creates the care support group, in other embodiments, the patient or other practitioners may create the care support group in a similar fashion to that described herein.
Although in the this example, the primary physician Dr. Smith added specific practitioners, in other examples the primary physician Dr. Smith may have added a facility to the care support group. For example the facility added to the care support group may be a laboratory or testing facility, which can then view the test prescribed by any of the practitioners in the care support group and then add the test results to the care support group. In other words, access to the care support group may be assigned to specific entities such as hospitals, clinics, laboratories and/or any other suitable entity.
In other examples, the primary physician Dr. Smith may also add the computer based decision support agent (discussed elsewhere in this document) to assess the patient's health record such that the practitioners associated with the care support group may view the results from the decision support agent, which may then be used for the treatment of the patient and/or discussed among the practitioners.
It is further appreciated that the care support group may also be used for clinical research.
Anonymized Health Record Access Mechanism Figure 14 illustrates a block diagram of an example of the Human-Centric EHR
system 102 connected to an agent or third-party computing entity 114, such that the Human-Centric EHR
system 102 may provide patient anonymized health records to a third-party computing entity 114.
In other cases, the health records provided to the third-party computing entity 114 are not anonymized and may be similar to the various other embodiments discussed in this document.
The connection between the Human-Centric EHR system 102 and the third party computing entity 114 may include one or more connections over one or more data networks.
The connection between the Human-Centric EHR system 102 and the third party computing entity 114 may allow for the communication (e.g., transmission and/or reception) of various information and/or data between the various systems and/or devices. The various information and/or data exchanged may be a "notice", "notices" a "health record" and/or "health records" of the type discussed elsewhere in this document.

Date Recue/Date Received 2020-11-05 Figure 15 illustrates a flowchart of a process 1500 for providing patient anonymized health records to the third-party computing entity 114. At step 1502, the Human-Centric EHR system 102 receives a request from a third-party for health records relating to a criterion or criteria. In this example, the third party is the third-party computing entity 114. Then, at step 1504, the Human-Centric EHR system 102 obtains health records meeting the criterion or criteria, by processes the criterion or criteria against the database 206 of health records to obtain health records meeting the criterion or criteria and where each obtained record has permission from the respective patient associated with the record for the record to be provided to third-parties. For instance, when patients register with the Human-Centric EHR system 102 they may be asked if they are willing to provide anonymized data from their health record to third-parties. In other words, a patient may be able to deny access to third-parties to his/her health record. For example, as is shown in Figure 16E, there may be a settings page associated with the patient's account with the Human-Centric EHR system 102, such that the patient can view this page once he/she is logged into the Human-Centric EHR system 102. Then at step 1506, the patient identification information is removed from the health records to form a cohort of anonymized health records. At step 1508, the cohort of anonymized health records is provided to the third-party computing entity 114.
In some embodiments, the third-party computing entity 114 is associated with an agent that is associated with the Human-Centric EHR system 106. For example, the operator or the Human-Centric EHR system 106 could have agreements with agents to provide agents with access to various aspects of the data stored in the Human-Centric EHR system 106. For example, in one case, an agent could be registered to obtain a cohort of patient health records meeting a certain criteria. The Human-Centric EHR system 106 upon a query could provide anonymized data to the third-party computing entity 114, such that the agent could conduct research with the cohort of patient health records. The patient can allow/deny being discovered as part of a query for cohorts.
In order for the Human-Centric EHR system 106 to allow for the privacy of patient health information, the patient may be able to configure via the patient's computing entity 106 whether he/she is allowed to be discovered by queries from third-parties. If the patient desires for his/her medical information to not be provided to third-parties, even if the patient matches the criteria of the query, his/her anonymized data is not returned to the third-party agent.

Date Recue/Date Received 2020-11-05 In some embodiments, if patient agrees to provide anonymized data to third-parties, each time his/her name is picked in a query (e.g., on a per a study basis), he/she may have the option to opt-out of the cohort. For example, each time his/her name is picked in a query, he/she may receive a notice (such as the type discussed elsewhere in this document) and accept or deny his/her health records to be included in the cohort.
In some embodiments, the agent is able to select a specific anonymized patient from the cohort of patient health records to conduct further health analysis (diagnostics) or establish patient membership in a specific research topic. For example, if a specific anonymized patient, he/she may receive a notice (such as the type discussed elsewhere in this document) and accept or deny his/her health record to be included in the further health analysis (diagnostics) or establish patient membership in a specific research topic In some embodiments, the agent could be a 'blood pressure' monitor software-as-a-service component, that could alert the patient (and physician) of an abnormal situation over time. The patient again may subscribe, permit notifications, and the physician can do the same for certain 'thresholds' defined by the agent. The 'blood pressure monitor' may not need to be co-resident with the Human-Centric EHR system, but may makes use of notifications and notification-lists to habilitate and regulate the flow of information device-agent-medical record-physician.
In some embodiments, the Human-Centric EHR system 102 could have agreement with agents for 'travel related risks'. In this case, the patient subscribes for notifications from the agent and authorizes the agent to use his/her information to monitor potential health hazards as he moves around the globe. In this case, the data is not anonymized, since it is used directly for a specific patient.
The Human-Centric EHR system 102 may include in the account of the patient a record of the various studies and/or third-parties that he/she participated in, which may be used for compensating the patient for participating. The patient may be compensated monetarily or may be compensated by receiving various information and/or data from the study that may be useful to the patient. For instance, the Human-Centric EHR system 102 may notify the patient via the patient's computing entity 106 with a notice that a third-party is requesting to use his/her data and provide him/her with the available compensation, if the patient accepts to provide his/her health Date Recue/Date Received 2020-11-05 record. If the patient acknowledges by selecting the allow option in the notice, then the patient's account may be compensated.
The term "agent" may be used to refer to a third-party system that may be able to receive one or more health records associated with a patient, where the health records may or may not be anonymized. As such, the patient may provide one or more health records to an agent where the agent could provide monitoring, processing or computational service of heath records. It is appreciated that the agent may include the computer based decision support agent discussed elsewhere in this document.
In another embodiment, the Human-Centric EHR system 102 may be used to provide a decision aid for physicians. For example, the physician at the physician's EHR system 104 may be able to configure various parameters of a health record associated with a patient on the Human-Centric EHR system 102. Such parameters including which record and which information may be made available to third-parties. As such the physician may then provide a health record associated with a patient or various parts of the patient's health record that the physician would like to provide to a third-party such as an agent (e.g., the agent at the third-party system 111 or third-party computing entity 114). More specifically, the physician may provide one or more workflows to be done by the agent on the physician's behalf. Furthermore, the physician may be able to configure the "anomaly" detection thresholds of various observations to suit his/her practice.
Also, an agent may be able to examine a patient's entire records collection, and evaluate observations against each other and against the patient's health condition, to try to determine whether some adverse condition is possible given the patient's observation results and other information available therein. In some cases, the agent is another physician that the primary physician would like to have his/her patient's health record reviewed by.
Although the term electronic health record (EHR) system is used in this document, this term may also be referred to as an electronic health or medical record system or any other suitable termed system, computing entity or computing platform.
Any feature of any embodiment discussed herein may be combined with any feature of any other embodiment discussed herein in some examples of implementation.

Date Recue/Date Received 2020-11-05 Any of the steps of the processes discussed herein in may be done in different orders, the steps of process discussed herein may be combined and some steps of the processes discussed herein may be omitted in some examples of implementation.
The use of the term "patient" is used herein to refer to a person or an individual and is not intended to be limiting. For example, term "patient" could be used to include a legal guardian acting on behalf of the patient.
In the embodiments discussed herein the term "physician" is used, in other examples of implementation other types of medical professions, such as dentists, optometrists, pharmacists, nurses, nurse practitioners, physician assistants and/or any other suitable medical professional may be used synonymously with the term "physician". The term "physician" may include any medical or health related "practitioner", where the practitioner include may include any person that has access to read and/or write records to a patient's record.
Although reference is made in the examples above where interaction takes place with a government-managed EHR system and/or network, in other examples, other EHR
systems and/or networks associated with other organizations (e.g., commercial organizations, government health care systems, HMOs, etc.) may synonymously be used.
It is also appreciated that the term database when referenced in this document could be a single structured table that includes information or it could reference to a collection of databases that could have multiple records or tables that can work jointly or independently of each other. In other words, the reference to database in this document may be to indicate the function of storage or reception of information such as patient records, summary medical records, prescription information, drug information, patient information, insurance information, data records, health records, medical records, etc. in one or more database, one or more tables and/or one or more records, where the databases, tables, and/or records are stored in one or more computer readable memories.
It is further appreciated that the term "EHR system" may be interpreted to include any computer based system that runs or accesses application software that provides the functionality of electronic record systems described herein. For instance, the application software may be running Date Recue/Date Received 2020-11-05 on the EHR system itself or may be running on a separate computer system or server arrangement that the EHR system accesses (e.g., over a data network).
Certain additional elements that may be needed for operation of some embodiments have not been described or illustrated as they are assumed to be within the purview of those of ordinary skill in the art. Moreover, certain embodiments may be free of, may lack and/or may function without any element that is not specifically disclosed herein.
Although various embodiments and examples have been presented, this was for the purpose of describing, but not limiting, the invention. Various modifications and enhancements will become apparent to those of ordinary skill in the art and are within the scope of the invention, which is defined by the appended claims.
User authentication The accessibility and portability of the EHR networks 108 raise issues regarding confidentiality of the health records, as accurately identifying a patient remotely accessing health records is challenging. In some embodiments, the authentication system 2210 is part of an EHR network 108.
Figure 22 shows an authentication system 2210 allowing a user 40 to connect to a database 32 managed by an administrator system 30, using a client system 20. In this embodiment, the authentication system 2210 ensures that client system 20 is owned and manipulated by the rightful user 40, therefore preventing unauthorized users to access the database 32 of the administrator system 30. The authentication system 2210 may comprise the administrator system communicating with the client system 20 to exchange data.
In a specific embodiment, the user 40 is a patient who is authenticated via the administrator system that could be partially or entirely located in a medical clinic in order to access electronic 30 records 42 that could be electronic health records. if the EHR network 108 is entirely managed by a single medical clinic, the administrator system 30, including the servers 36, may be located at the clinic. If the EHR network 108 is managed by a plurality of medical clinics, the administrator system 30 may be spread between the clinics and the servers 36 may be located at one of the clinics or elsewhere. The servers 36 may be, for example, cloud-based.

Date Recue/Date Received 2020-11-05 In the embodiments discussed herein the term "medical clinic" is used. In other examples of implementation, "medical clinic" may include paramedical services such as dental clinics, optometry clinics, pharmacies and/or any other suitable medical/paramedical service provided and may be used synonymously with the term "medical clinic".
In a specific example of implementation, the Human-Centric EHR system 102 shown in Figure IA may implement, the administrator system 30 in Figure 22, while the client system 20 in Figure 22 may be implemented by the functionality of the Patient's computing entity 106 shown in Figure 1A.
More specifically, in this example, the administrator system 30 comprises a processing unit, input/output ports, and computer readable memory comprising the database 32 and an administrator authentication program. For instance, the administrator system 30 may comprise a server 36 and optionally one or more computers connected to the server 36. The administrator system 30 may have a distributed architecture where the various elements of the administrator system 30 communicate with each other via data links. The database 32 stores one or more electronic records 42 associated with a user 40 and at least one authorized user device 44 having identifiers 46. The administrator authentication program comprises program code which when executed by the processing unit causes the administrator system to perform various operations.
The administrator system 30 connects to the client system 20 via one or more data networks.
The client system 20 typically comprises a processing unit, input/output ports, and computer-readable memory, a client authentication program, and identifiers 46, such as authentication information uniquely identifying the user. The processing unit, input/output ports and computer readable memory of the client system 20 may be connected to each other by various data buses and in the case of a distributed computing environment may be interconnected by one or more data networks. The client authentication program comprises program code which when executed by the processing unit causes the client system to perform various operations, such as managing a user authentication operation involving the identifiers 46.
The client system 20 can communicate with the administrator system 30 to access information in the database 32. In particular, the client system may access a given one of the electronic records 42 of the database 32. The communication between the client system 20 and the Date Recue/Date Received 2020-11-05 administrator system 30 may be initiated by any one of the systems 20, 30. The administrator system 30 may transmit the given one of the electronic records 42 of the database 32 to the client system 20 if the identifiers 46 of the client system 20 are recognized by the administrator authentication program as being authorized to give access to a particular one of the electronic records 42. In particular, the client system 20 transmits the identifiers to the administrator system 30 and the administrator system 30 compares the identifiers of the client system 20 to the identifiers of the authorized user device associated with the given one of the electronic records. If there is a match, the administrator system 30 recognizes the client system 20 as belonging to the user 40 and the given one of the records is transmitted to the client system 20. If there is no match, the client system 20 is not recognized as being an authorized user device and no access to the information in the database 32 is allowed.
As shown in Figure 23, in one embodiment, the authentication system 2210 performs a process including an activation phase 2310, wherein the user 40 of the client system 20, which typically is a mobile, is authenticated, the mobile of the user 40 communicates with the administrator system 30 and transmits authentication information to the administrator system 30, the administrator system 30 associates the authentication information 46 of the device 44 of the authorized user 40, and the administrator system 30 stores the authentication information of the device 44 into the computer readable memory of the administrator system. In some embodiments, activation phase 2310 is followed by a recognition phase 2320. In this phase, the user 40 may authenticate himself/herself to remotely access his/her personal data, acknowledge correspondence from a physicist, request an appointment, etc., and optionally enter into the subsequent activation phase 2330, using the device 44, to activate a new device 144.
The activation phase 110 is a phase wherein authentication information about the device 44 is saved into servers 36 of the administrator system 30 and identified as being allowed to access a particular one(s) of the electronic records 42 of the database 32. As shown in Figure 24A, in some embodiments, the activation phase 2310 may comprise step 2409, which is preliminary identification, and step 2410, which is a transaction 50. Activation phase may also comprise a confirmation step 2411 wherein the ownership of the user device 44 by the user 40 is confirmed.
At step 2409, the user 40 is identified and information provided by the user is transmitted to the administrator system 30. In this embodiment, the identification of the user 40 is accomplished by an identity verification agent (IVA). An example of steps of the preliminary identification is Date Recue/Date Received 2020-11-05 depicted in Figure 25A. The IVA, who can be a receptionist at a medical clinic first identifies the user 40 at step 2501, for example by using identification document (ID) and by comparing features depicted on the ID to features of the face of the user 40 to verify that the ID is legitimately owned by the user 40 and/or by verifying information (e.g., name, birth date, social security number) printed on the ID to ensure that the user 40 is who he says he is. Secondly, the identity of the user 40 is recorded into the administrator system 30 at step 2502 (Fig 25A-B). In some cases, the user 40 may enter its own identity into the administrator system 30, while in other cases, the IVA may enter the user 40 identity information into the administrator system 30. For example, in a preferred embodiment, the IVA enters an email address and cell phone number of the user 40 into the database 32 of the administrator system 30. Optionally, the IVA may indicate by checking a radio box that the user wants to access his data remotely at step 2503.
Subsequently, at step 2504, the administrator system 30 sends an email to the user 40 using information provided by the user 40 as means to start the activation phase 2310. While steps 2501, 2502, 2503, 2504 are completed, the user 40 may install an application or software 48 on .. the device 44.
Alternatively, the preliminary identification of the user 40 at step 2409 may be made automatically by a machine belonging to the administrator system 30, using an ID scan, face recognition, digital prints, or the like. At step 2502, the user 40 may enter identity information into the machine. Step 2504 happens subsequently.
At step 2410, the transaction 50 takes place, ensures that the device 44 is indeed owned by the user 40 and allows the device 44 to transmit identifiers 46 to the servers 36 of the administrator system 30, which records the identifiers 46 and associates them to the electronic records 42. As such, the transaction 50 involves multiple parties comprising an activating party 52, an offering party 54 and the servers 36 of the administrator system 30.
Figures 26A-D show non-limiting examples of activating party 52, offering party 54 and server 36 that are involved within a transaction 50. In this case, the device 44 may be considered as the activating party 52. The offering party 54 may be, in some cases, a device owned by the user 40;
in some cases, a device manipulated by the IVA; in some cases, the machine belonging to the administrator system 30; and in some cases, a device that is also part of the administrator system 30.
A way to ensure that the device 44 is owned by the entitled user 40 is to control the offering party 54 and requires a physical proximity between the offering party 52 and the activating party 54 for Date Recue/Date Received 2020-11-05 the transaction 50 to succeed. As such, in cases where the activating party 54 is a device manipulated by the WA, this may allow the IVA to ensure that the device 44 is indeed owned by the user 40, who was previously identified at step 2409. Similarly, in cases where the activating party 54 is the machine belonging to the administrator system 30, this may allow the administrator system 30 to ensure that the device 44 is indeed owned by the user 40, who was previously identified at step 2409.
Figure 28 shows an example of the transaction 50 according to this embodiment.
The offering party 54 first communicates with the server 36 of the administrator system 30 to initiate the transaction 50 at step 2801. At step 2802, the server 36 produces a unique temporary token 58, which is then delivered to the offering party 54 at step 2803. The temporary token 58 may be, for example, a QR code, an alphanumeric digital key, etc. Then, at step 2804, the offering party 54 renders the temporary token 58 available for scanning by the device 44 of the activating party 52.
For example, in cases where the temporary token 58 is a QR code and the offering party 54 is a smartphone, a tablet or a computer, the temporary token 58 may be made available for scanning by being displayed on a display of the offering party 54. As another example, in cases where the temporary token 58 is an alphanumeric digital key and the offering party 54 comprises a NFC
emitter, the temporary token 58 may be made available for scanning by enabling the NFC emitter of the offering party 54 and pushing the temporary token 58 to other devices connected through the NFC connection. Subsequently, at step 2805, the activating party 52 scans the temporary token 58 through the application 48 of the device 44. The activating party 52 may then process the scanned temporary token 58 at step 2806 to produce an output 59. The output depends on the temporary token 58. In some cases, the output 59 is identical to the temporary token 58, while in the other case the output 59 differs: for example, for a temporary token 58 being a QR code, the output 59 may be an alphanumerical key. The output 59 may also comprise a signature of the activating party 52, e.g., the identifiers 46 of the device 44. At step 2807, the activating party 52 transmits the output 59 to the server 36, using the application 38. While in the present case, the activating party 52 transmits the output 59 directly to the server 36, in some embodiments, the activating party 52 transmits the output 59 indirectly to the server 36, e.g., by delivering the output 59 to the offering party 54, which may then deliver the output 59 to the server 36. At step 2808, the server 36 processes the output 59 and determines if a pre-determined set of rules of the transaction 50 is verified. If the pre-determined set of rules is verified, the identifiers 46 of the client device 44 may be registered into the server 36 and the transaction 50 is completed. If the Date Recue/Date Received 2020-11-05 pre-determined set of rules is not verified, the identifiers 46 of the client device 44 are not registered and the transaction 50 is aborted.
As previously mentioned, the temporary token 58 may be of any suitable form.
For example, in some cases, the temporary token 58 may be an image such as a QR code, or any other image. In some cases, the temporary token may be a numerical key or an alphanumerical link. In some cases, the temporary token may be a hyperlink.
In some examples, if the step 2801 of the transaction 50 is repeated, the temporary token 58 may be deactivated and a new temporary token may be activated. Every remaining step of the transaction 50 may also be repeated to complete the transaction 50. Also, the pre-determined set of rules of the transaction 50 may comprise a rule stating that the temporary token 58 must be activated, to ensure that no more than one valid temporary token 58 is available and to reduce the risk that unauthorized users take part in the transaction and corrupt the authentication system 2210.
In this case, also, the temporary token 58 may have a limited and pre-determined lifetime. Once the lifetime becomes expired, the temporary token 58 may be deactivated by the server 36. Also, the pre-determined set of rules of the transaction 50 may comprise a rule stating that the temporary token 58 must be activated and its lifetime must not be expired. To complete the transaction 50, a new temporary token 58 must be delivered by the server.
In some embodiments, the transaction 50 determines an outcome of the activation phase 2310. If the transaction 50 is completed, the server 36 activates the identifiers 46 of the device 44, i.e., the server 36 registers the identifiers 46 as being authorized to access the given one of the electronic records 42 of the database 32. In this case, the activation phase 2310 is a success. Otherwise, the activation phase 2310 is a failure.
In other embodiments, the transaction 50 alone does not determine the outcome of the activation phase 2310. If the transaction 50 is completed, other steps still have to be completed to determine the outcome of the activation phase 2310. For example, in some embodiments, as shown by Figure 29 the activation phase 2310 further comprises step 2411, which is a confirmation 60. At step 2411, the confirmation 60 further ensures that the device 44 is indeed owned by the user 40 previously identified at step 2409. The confirmation 60 may take various forms. For example, in Date Recue/Date Received 2020-11-05 some embodiments, the server 36 of the administrator system 30 transmits a confirmation key 62 to the device 44 using a communication means different than a communication means used during the transaction 50.
As shown in Figure 30, the confirmation 60 may comprise the step 3001, at which the server 36 produces the confirmation key 62. In the present case, the confirmation key 62 is alphanumerical.
In other embodiments, the confirmation key 62 may be a hyperlink. At step 3002, the server 36 transmits the confirmation key 62 to the device 44. In some cases, the server 36 of the administrator system 30 may transmit the confirmation key 62 to the device 44 by short messaging service (SMS), while in some cases, the server 36 may transmit the confirmation key 62 to the device 44 by email, in every case using the cell phone number or the email address provided by the user 40. In some cases, also, the confirmation key 62 is provided directly to the device 44, while in other cases the confirmation key 62 is provided to the user 40, and the user 40 needs to scan or enter the confirmation key 62 into the application 48 installed on the device 44.
Then, at step 3003, the application 48 of the device 44 processes the confirmation key 62 and produces an output 67. Similar to step 2806 of the transaction 50, the output 67 depends on the confirmation key 62. In some cases, the output 67 is identical to the confirmation key 62, while in other cases the output 67 differs. The output 67 may also comprise the identifiers 46 of the device 44. At step 3004, the device 44 delivers the output 67 to the server 36. At step 3005, the server 36 processes the output 67 and determines if a pre-determined set of rules of the confirmation 60 is verified. If the pre-determined set of rules is verified, the identifiers 46 of the client device 44 may be confirmed and registered into the server 36 as associated to the user 40.
If the pre-determined set of rules is not verified, the identifiers 46 of the client device 44 are not confirmed and the confirmation 60 fails.
The confirmation key 62 may be a temporary token delivered by the server 36 of the administrator system 30, i.e., may have a limited and pre-determined lifetime.
After the lifetime has expired, the temporary token may be deactivated. Also, the pre-determined set of rules of the server may comprise a rule stating that the temporary token must be activated in a timely manner.
To complete the confirmation 60, a new temporary token must be delivered by the server 36.
In other embodiments, the confirmation key 62 may be a permanent token delivered by the server 36 of the administrator system 30, i.e., may have unlimited lifetime.

Date Recue/Date Received 2020-11-05 The pre-determined set of rules of the confirmation 60 may comprise a rule stating that, in order to complete the confirmation 60, the identifiers 46 provided during the transaction 50 and the confirmation 60 must be compared, and must be identical. Another rule of the predetermined set of rules of the confirmation may be that, in order to complete the confirmation 60, the output 67 transmitted by the application 48 to the server 36 at step 3004 must correspond to the confirmation key 62 delivered by the server 36 at step 3002.
In some embodiments, if the identifiers 46 transmitted during steps 2410 and 2411are not consistent, the given one of the electronic records 42 may be blocked such that they remain inaccessible and/or a notification may be sent to the user 40.
Once the activation phase 23 10 of the device 44 is completed, the user 40 may access data belonging to the given one of the electronic records 42, transmit such data, modify such data, process transactions, request services, etc., using the application 48 installed on the device 44.
While the activation phase 2310 may ensure that the device 44 belongs to the entitled user 40, it may not ensure that the device 44 is being manipulated by the rightful user 40 at the moment when access to the electronic records 42 is requested by the application 48 of the device 44.
Figure 31 shows that, in some embodiments, the application 48 requires authentication of the user 44 prior to accessing the given one of the electronic records 42. In some embodiments, after the application 48 is put into sleep or into background process, for example while another application 48 is being used, or after a time delay has expired, the user 44 may be required to authenticate prior to re-accessing the application 48 or the given one of the electronic records 42. If the authentication is not accomplished or fails, the application 48 may then be blocked, thus preventing the user 40 to use the application 48 and access the given one of the electronic records 42. For example, in some embodiments, the application 48 may request that the user 40 authenticate using face recognition, iris scan, fingerprint, pattern, password and/or pin. In some embodiments, the application 48 may request that the user 40 authenticate using the safest technology available on the device 44: for example, if face recognition and/or iris scan are available, authentication is accomplished using one of these technologies;
otherwise, if fingerprint is available, authentication is accomplished using fingerprint;
otherwise, if pattern is available, authentication is accomplished using pattern; otherwise, if password is available, authentication is accomplished using password; otherwise, if pin is available, authentication is Date Recue/Date Received 2020-11-05 accomplished using pin; otherwise, the application 48 cannot be unlocked and remains inaccessible. Any other authentication technology may also be used.
In some embodiments, the device 44 is a first device and the user 40 may initiate a subsequent activation phase 2330to allow access to personal data of the user 40 from a second device 144 having identifiers 146.
The subsequent activation phase 2330 is somewhat similar to the activation phase 2310. It is a phase wherein identifiers of the second device 144 are saved into servers 36 of the administrator system 30 and identified as being allowed to access the given one of the electronic records 42 of the database 32, in a manner which ensures that the user 40 is entitled to access the given one of the electronic records 42 of the database, and that the second device 144 is indeed owned by the user 40 and not by someone else. First, the user 40 must install the application 48 onto the second device 144. Then, as shown in Figure 24B, the subsequent activation phase 2330 may comprise step 2419, which is preliminary identification, and step 2420, which is a transaction 150.
At step 2419, the user 40 is identified and information provided by the user is transmitted to the administrator system 20. As previously discussed, the application 48 may require that the user 40 authenticate prior to accessing the application 48. As such, in this embodiment, preliminary identification is simply accomplished by authenticating and accessing the application 48. In some embodiments, also, the application 48 may ask yet another similar authentication when the user 40 selects an option to activate a new device in the application of the first device 44.
At step 2420, the transaction 150 takes place, ensures that the device 44 is indeed owned by the user 40 and allows the second device 144 to send identifiers 146 to the servers 36 of the administrator system 30, which records the identifiers 146 and associates them to the electronic records 42. The transaction 150 is somewhat similar to the transaction 50 and involves an activating party 152, an offering party 154 and the servers 36 of the administrator system 30.
In some cases, the activating party 152 may be the new device 144, the offering party may be a device owned by the user 40, a device manipulated by the IVA, or a device that is also part of the administrator system 30, and the transaction 150 takes place in the same way as the transaction 50.

Date Recue/Date Received 2020-11-05 In this case, the activating party 152 is the new device 144 and the offering party 154 is the device 44. As shown in Figure 32, the user 40 first initiates the transaction 150 by selecting the option to activate a new device 144 in the application of the first device 44, at step 3201. The offering party 154 then communicates with the server 36 of the administrator system 30 to initiate the transaction 150. The following steps of the transaction 150 are identical to steps of the transaction 50.
The transaction 150 may determine an outcome of the subsequent activation phase 2330. If the transaction 150 is completed, the server 36 activates the identifiers 146 of the new device 144, i.e., the server 36 registers the identifiers 146 as being authorized to access the given one of the electronic records 42 of the database 32. In this case, the activation phase 120 is a success.
Otherwise, the subsequent activation phase 2330 is a failure.
In other cases, the transaction 150 alone does not determine the outcome of the activation phase 120. If the transaction 150 is completed, other steps still have to be completed to determine the outcome of the subsequent activation phase 2330. For instance, the activation phase 120 may further comprise step 321, which is a confirmation somewhat identical to the confirmation 60 but regarding the new device 144 instead of the device 44.
Managing medical data access over interconnected networks.
In previous examples of implementation, the Human-Centric EHR system stores the medical information of patients, such as lab results, imaging results etc. In other words, medical data, such as a lab result received from a testing lab is copied at the server of the Human-Centric EHR and retained there. If the patient accesses the Human-Centric EHR system to view the data, the patient is actually viewing the copy of the data stored locally in the server and not the data at the original source.
A possible disadvantage of that approach is the need to carefully preserve the confidentiality of the medical data that is being collected over time at the server of the Human-Centric EHR
system. Medical data is very sensitive and to preserve it requires robust safeguards against hacking. That is costly and there is always some risk of a data breach.
Date Recue/Date Received 2020-11-05 Another challenge is accessing medical information stored in different networks is that those networks often are not designed to interoperate. Each network has its own protocols, data structures and ways of classifying the information. Trying to make those networks work in a seamless fashion to provide a satisfactory user experience, where the patient can quickly and conveniently access the medical information of interest is difficult.
This example of implementation the invention illustrates a different approach where the data remains at the original source location and the Human-Centric EHR system is configured to respond to patient's requests to view document by managing access to the data at the original source location. In this fashion no sensitive data is stored at the server of the Human-Centric EHR, thus reducing significantly the risk of exposure of confidential user data to a minimum. In addition, by limiting the interaction between networks at the level of access management of the data, the networks can be made to work together in order to provide one the one hand satisfactory patent access and on the other hand there is no need provide a deep level of integration. Each network can work as originally designed, and only a thin layer of interoperability is necessary for the information flow to occur in the intended fashion.
The architecture of the system is shown at Figure 34. It includes the Human-Centric EHR system 5004 which is arranged largely in the same fashion as discussed in the earlier examples, with the exception of the new functionalities discussed below. The Human-Centric EHR
system 5004 communicates with Patient's system 5002 which in most forms of implementation is mobile. The Human-Centric EHR system 5004 also communicates with the physician's EHR
system 5000 to provide the functionalities generally described earlier.
The Human-Centric EHR system 5004 communicates with a range of medical data sources 5008, 5010 and 5012 which reside at respective nodes, via a Feed Node 5006. The medical data sources 5008, 5010 and 5012 are not part, strictly speaking of the Human-Centric EHR
system 5004.
Those medical data sources are independent networks in themselves or part of independent networks. So, while they can communicate with the Human-Centric EHR system 5004, they can also communicate and perform data transactions with a range of other entities that are unrelated to the Human-Centric EHR system 5004. Accordingly, the medical data sources 5008, 5010 and 5012 implement their own data protection and user authentication schemes. What this means is that if a patient wants to access medical data on medical data source 1 at 5008, the patient would access the server associated with the medical data source 1, for example via a web browser, Date Recue/Date Received 2020-11-05 authenticate himself through password or biometric features to gain access to the data. The same process would then need to be repeated at medical data source 2 5010 and medical data source 3 5012 that hold other medical data for the patient. This is very inconvenient for the patient as he needs to remember different passwords and the person needs to perform the access process multiple times to get access to multiple documents, not to mention the possible confusion in terms of where different documents reside.
In a typical implementation, medical source 1 5008, medical source 2 5010 and medical source 3 5012 are associated with entities that generate medical information or more generally process medical information, such as a testing lab, a radiology or other imaging service lab, a hospital and a drug dispensing entity, such as a pharmacy, among others. Accordingly, a patient that is prescribed a blood test by the physician would go to the testing facility of the lab where a blood sample is taken, the blood sample processed, and results generated and entered into the database of the lab.
The results are communicated to the Human-Centric EHR system 5004 by the given medical data source, say source 1 5008 through the Feed Node 5006 that has a functionality to enable the patient to look at a future time, at the medical data without the need to directly access and authenticate himself with a password or biometric feature a the medical data source 1 5008. In practice, the Feed Node 5006 can be configured as a server that is remote of the nodes implementing the medical data source 1 5008, the medical data source 2 5010 and the medical data source 3 5012. In this instance, each of the nodes implementing the medical data source 1 5008, the medical data source 2 5010 and the medical data source 3 5012 communicate with the Feed Node 5006 over communication links and via standard communication protocols. In this form of implementation, the services at the Feed Node 5006 exist as a number of different instances, each instance being associated with a given medical data source.
Alternatively, the Feed Node 5006 can be implemented as software that executes on the server of each medical data source. This approach is preferred from the perspective of cost as there is no need to install a separate server but may be more complex to implement as it requires to install software on a range of different medical data source nodes.
In yet another form of implementation, the Feed Node 5006 can be part of the Human-Centric EHR system 5004, in other words the software providing the functionality of the Feed Node 5006 Date Recue/Date Received 2020-11-05 is part of the overall software package at the server implementing the Human-Centric EHR
system 5004. In such example, the medical data source nodes communicate directly with the server implementing the Human-Centric EHR system 5004.
The role of the Feed Node 5006, in each form of implementation is to maintain a trusted relation with the respective medical data source node, such that requests to access medical information channeled through the Feed Node 5006 are deemed legitimate and no interaction with the patient is required to authenticate the request for the medical data. In this fashion the patient, only need to authenticate himself to the Human-Centric EHR system 5004.
Figure 35 is a flowchart illustrating the operation of the Feed Node 5006 when new medical data is generated at the medical data source 1 node, with the understanding that the same process is performed in connection with the other nodes.
The process starts at step 5100. At step 5102 the Feed Node 5006 receives metadata indicating that new medical information is produced at the data source node. The metadata would typically include an identifier of the patient to whom the medical data pertains. The identifier can be a name of the patient and/or other identification information such as to uniquely identify the individual. More generally, the metadata can include a range of information categories. The following are examples:
1. An identifier of the message. The identifier can be any suitable alphanumerical string that uniquely identifies the message among other messages.
2. The identifier of the patient, such as the patient name or any identifier that can be mapped to the patient;
3. The dispatch profile of the message. The dispatch profile indicates how the message should be sent to the patient and/or whether the message is urgent or not urgent or any other urgency related categorization. For example, if the message relates to medical information that denotes an urgent condition, such as abnormal results, then the dispatch profile will contain this information;
4. The identifier of the practitioner. The practitioner can be the treating physician of the patient or the physician that has requested the particular test or procedure that is associated with the metadata.

Date Recue/Date Received 2020-11-05 5. A mechanism to trigger an answer from the patient, such as agreement or consent to enroll the patient in a clinical research trial or some follow-up procedure that stems from medical information being communicated to the patient. For example, the patient may indicate that he or she wishes to receive medical news about the condition associated with the medical information or advertisement on products or services associated with the medical information. The answer from the patient is retained at the Human-Centric EHR
system 5004 once the patient responds to the inquiry Advantageously, the metadata holds no personal private medical information.
For example, in the case of a blood test, no test values are conveyed by the metadata. This approach protects the confidentiality of the patient information which is accessible only at the location pointed to by the metadata.
At step 5104 the Feed Node 5006 will query the Human-Centric EHR 5004 to determine if the patent is registered by, for example, searching in the list or registered users the patient name. if no match is found, in other words, the patient for whom medical results are available is not a subscriber of the Human-Centric EHR system 5004, the process terminates at 5106.
However, if a match is identified in the list of registered users the Feed Node 5006 will generate the metadata associated with the medical information to enable the patient to access it via the patient's system 5002 and the Human-Centric EHR system 5004.
Typically, the identifier of the message that is conveyed by the metadata maps to a location which can be a physical one or a logical one, where the medical data resides such that it can be retrieved at a future time. Typically, the location of the medical data would be supplied by the medical data source node when the later communicates with the Feed Node 5006 to submit the medial data.
The metadata can be supplied by the medical data source node when it communicates with the Feed Node 5006. Alternatively, the Feed Node 5006 can generate some elements of the metadata.
One possibility is to provide the Feed Node with logic to parse the medical data and identify its nature. In a specific example, the medical data can be supplied as a pdf document on which Optical Character Recognition (OCR) can be performed by the Feed Node 5006 logic to identify key terms allowing the logic to classify the medical data in a category, among a range of Date Recue/Date Received 2020-11-05 categories, such as blood tests, imaging results, etc. The Feed Node 5006 can be further configured to perform a more sophisticated text analysis of the medical data to determine if it conveys results that are outside normal ranges and include an indication that abnormal results are present in the summary information. Alternatively, the metadata may include components organized according to the HL7 standard to facilitate the interpretation on the Feed Node 5006 side.
The metadata thus generated is stored at the Feed Node 5006 location.
Alternatively, it can be transmitted to the medical data source node. In addition, the metadata is sent to the Human-Centric EHR system 5004, where it can be used to update the patient record such that the patient can access the medical data. In addition to the metadata, the transmission would include an identifier of the patient to enable the Human-Centric EHR system 5004 to match the metadata to a subscribing patient.
The process at the Human-Centric EHR is illustrated by the flowchart at Figure 38. The process starts at 5400. At step 5402, the Human-Centric EHR receives the metadata in connection with a medical data from the Feed Node 5006. At step 5404, the Human-Centric EHR will identify on the basis of the patient identifier the record of the subscribing patient to which it belongs and record it there. The recording operation preferably includes writing the metadata or elements thereof in an index such as to constitute over time a summary medical record identifying the health care service events dispensed to the patient for which a document exists and can be consulted. The index can be developed by logic at the Human-Centric EHR system 5004 to identify from the metadata the nature of the service event or the medical information and put that item in an index, thus allowing the patient or a service provider to quickly access the information of interest. For instance, the index may be constructed by grouping the medical information in classes or categories such as "blood tests", "imaging results", etc., the individual entries being classified by date, whether the results are normal or any other suitable factor. For convenience, individual entries can appear to the user over a GUI as hyperlinks. When the user clicks on a hyperlink the process for displaying the medical data identified by the metadata is triggered, as discussed below.
Figure 47 illustrates a data structure mapping the identifiers of the medical information across the different networks such that the medical information can be accessed. The index or summary of the medical data that the patient sees is depicted at 4700. In the drawing, it is presented as a Date Recue/Date Received 2020-11-05 simple list of medical data items, such as blood tests, imaging results and others, but the organization of the information may be more complex, including a categorization of the information in different classes, as discussed above. What the patient would see on the screen of the mobile is then a list of medical data items, each item corresponding to medical data that is stored at either one of the medical data sources 1, 2 or 3. As indicated previously, the medical data item can be in the form of a hyperlink, and when the patient clicks on the hyperlink the process of retrieving the information is performed. The data structure maps each medical data item to a corresponding identifier that indicates where the medical data resides on an external node. For example, the medical data item 1 points to a medical data source 2 identifier. The identifier is extracted from the metadata that was originally sent from the data source node 2, when that data source node 2 dispatched the metadata to the Feed Node 5006 and eventually to the Patient Centric EHR system 5004. So the identifier stored at the Human-Centric EHR system 5004 allows to reconstruct the location of the source of the data such that it can be retrieved and displayed to the patient.
The table of the identifiers 4702 is dynamically updated as messages are received from the respective data source nodes to notify the Human-Centric EHR system 5006 that new medical information for the patient exists. As a new message is received and it is processed as discussed to extract the identifier of the data location from the metadata, an entry in the index 4700 is created and at the same time an entry in the identifier table 4702 is also created.
In this example, it should be pointed out that no medical data is stored on the Human-Centric EHR system 5004. Only metadata is stored, which in itself conveys no meaningful medical information and in the event of a breach even if the metadata is leaked outside the Patent-Centric EHR system 5004, it does not expose any sensitive information about a patient.
Specifically, neither the index 4700 nor the identifier table 4702 contains personal medical information. The personal medical information resides at the respective medical data source nodes 1, 2 and 3.
Figure 36 illustrates the process for a patient or a physician to access medical data. The process starts at 5200. At 5204 the Process-Centric EHR system 5004 receives from the system 5002 a request to initiate a session. Typically, if the patient's system 5002 is implemented on a mobile, such as an App, for example, by activating the App on the mobile, a communication is triggered with the server implementing the Human-Centric EHR system 5004, to which the server will respond by an authentication request.

Date Recue/Date Received 2020-11-05 The user authentication is performed at step 5204. This is accomplished by the user entering a username and a password combination or a biometric feature such as a fingerprint or face recognition. If the user credentials are recognized by the Human-Centric EHR
system, the user profile is loaded, and the GUI would show the metadata-based index of documents that are available for the user to view. This is performed at step 5206.
Assume for the purpose of this example that the user selects a document in the list, at step 5208.
The source of the medical data associated with that selection is retrieved from the user profile at step 5210 and the node at which the document is located is determined. As discussed previously, the metadata initially received from the source node defines not only the location of the document at the particular medical data source node, but the location of the document within the entire network, including the location of the node itself. More specifically, the process will extract from the data structure at Figure 47 the identifier mapped to the user selection and build a medical data read request from a source specified in the data structure.
At step 5214, the Human-Centric EHR system 5004 then communicates with the medical data source node by supplying back the data identifier to identify the document requested, though the Feed Node 5006. Since the medical data source node can establish the identity of the requester (Feeder Node 5006 or Human-Centric EHR system 5004, that are known to be genuine requesters, the medical data source node will then retrieve the document, render an image of it and the rendered image is then transmitted back through the Feed Node 5006, the Patent-Centric EHR system 5004 and ultimately the patient's mobile 5002, where it appears on the screen.
Accordingly, the patient can consult the document but there is no actual storage or retention of the medical data at either one of the Feed Node 5006, the Human-Centric EHR
system 5004 or the Patient's system 5002. So, when the session is completed, such when the user logs out of the Human-Centric EHR server 5004, no data is retained.
Patient data access management From the perspective of the patient, it is important to have control over the privacy of the medical data that is either stored (and retained) in the Human-Centric EHR system or the data that is stored at remote nodes and that is accessed through the Human-Centric EHR
system. Typically, the medical information in the Human-Centric EHR system is intended to be consulted by health Date Recue/Date Received 2020-11-05 care professionals to enable them to dispense health care services. It is the practice today to have the entirety of the EHR patient file made available to the health care professional. This is for example, the case of the Dossier Sante Quebec (DSQ). While such an approach has some merit in certain circumstances, such as when the patient is admitted for urgent care at a facility that has no previous record of his or EHR condition, where it would be useful for the threating physician to get access to all information in order to be able to make a diagnosis, those instances are rare.
In most cases, a threating physician or any other health care service provider needs less than the entirety of the medical information to dispense high quality services.
Further, the medical information stored or available through the Human-Centric EHR system is very sensitive. The patient may not want one or more health care service professionals to know certain details that are not need for those health care service professionals to do their work. For example, the patient may have been diagnosed with a Sexually Transmitted Disease (STD) and that diagnosis may be embarrassing and something which the patient would like to keep confidential and share only on a need to know basis. Accordingly, a mechanism allowing the patient to control with fine granularity who has access to the sensitive medical data, which the present example provides, would be highly useful.
The example of implementation of the invention shown at Figure 43 is designed to provide this functionality. That figure is a block diagram illustrating some functional blocks of the Human-Centric EHR system. Each patient that subscribes to the in the Human-Centric EHR system has a user profile that stores functions and configuration information specific to that patient. The functions and configurations determine how the patient data is accessed or pushed to third parties.
The user profile 4300 has two functions, among others, namely a user access manager 4302 and a data privacy configurator 4304. The user access manager 4302 holds a list of the individuals that can access medical information about the patient. The data privacy configurator 4304 determines, who among the registered users in the user access manager 4302 has access to what.
The combination of the user access manager 4302 and data privacy configurator 4304 form a gateway to the patient data, such that only the information that the patient has agreed to share is actually being shared.
The patient interfaces and controls the data privacy configurator 4304 through a Graphical User Interface which has controls allowing the patient to determine how his medical information is Date Recue/Date Received 2020-11-05 accessed. An example of a GUI and the attendant controls is depicted in Figure 38. The GUI
3800 has a list of health care service events 3802, that reflect the different interactions the patient had with health care service providers. For example, an item in this list could be a blood test result, an imaging procedure, a drug prescription and a surgery procedure among many others.
Beside the list appear two rows of controls, such as check boxes, organized in two groups, namely a confidential group 3804 and a non-confidential group 3806. This allows the patient to designate each health care service event as either a confidential one or a non-confidential one.
Accordingly, another user, such as a physician that accesses the medical information will only be allowed to see health care service events that are designated non-confidential.
Objectively, this form of data privacy management requires significant involvement from the patient as the latter needs to update the data privacy configurator 4304 every time a new health care service event is generated. At the same time, it provides a lot of granularity as each health care service event can be individually managed from a confidentiality perspective.
It should also be understood that the above applies to individuals accessing the medical information other than the patient. The patient has full access rights all the time.
One way to simplify the data privacy management is to invoke the GUI at Figure 38 every time a new health care service event is recorded in and the patient is notified of that new health care service event. The flowchart of this operation is shown at figure 42. The process begins at 4200.
At step 4202, the patient is notified of new medical data, as it was previously described, for example by generating a notification on the patient mobile, which requires the patient to open the app and consult the medical data. As the patient interacts with the app, the GUI at Figure 38 is invoked (step 4204) and the health care service event highlighted required user input to designate it as confidential or non-confidential, at step 4206.
At step 4208 the new data privacy settings regarding this health care service event are recorded into the data privacy configurator 4304.
An alternative to the approach described earlier is to group the individual health care service events into classes and designate each class as confidential or a non-confidential one. This option is shown at Figure 39. Instead of listing individual health care service events, the GUI shows Date Recue/Date Received 2020-11-05 health care service classes that define groupings in which the individual health care service events are classified. The classification can be built around the HL7 standard. In this example, the patient can designate via check boxes whether a particular class is confidential or non-confidential, in which case a user that accesses the medical data will see all the health care service events that are grouped in the particular class.
Once the patient sets his or EHR preferences in the checkboxes of the GUI at Figure 39, those settings are stored in the data privacy configurator 4304.
A further refinement of the above approach to data privacy management is shown at Figure 40. In this example, additional granularity is provided to tailor individual user access rights. In other words, some users may have expanded rights than others.
The GUI 4000 displays a list of the individual health care service events at 4002 and a list of controls 4004 associated with respective users, which in this example are treating physicians.
The controls 4004, such as check boxes allow the patient to select whether to enable or not enable a particular user to access a particular health care service event. So, if there are certain health care service events that the patient does not want a particular treating physician to see, the patient can configure that through the controls 4004.
It is to be understood that the authorized access users list is dynamically updated when the list of uses in the user access manager 4302 changes. When a new user is added in the user access manager 4302, that change would reflect itself at the GUI 4000.
Since this example manages the data privacy on the basis of individual health care service events, the process described by the flowchart at Figure 42 can also be followed every time a new health care service event is generated. As the patient interacts with the app on his or EHR profile to see the information associated with the health care service event, the GUI at Figure 40 is invoked allowing the patient to specify which authorized access user is enabled to see the medical data associated with the health care service event.
Figure 41 is another variant where permissions for individual users are granted on a health care service class basis. The GUI at figure 41 shows the existing classes of health care service events, allowing through the control group 4102 to indicate which user gets access to which class, with Date Recue/Date Received 2020-11-05 the understanding that once access to a given class is allowed, the user can access each health care service event stored in that particular class.
Figure 45 is a flowchart of the process allowing a user to access the medical information of the patient. This process applies to example of implementation shown in Figure 38.
The process starts at step 4500. At step 4502 the user logs into the Human-Centric UR
system which requires user verification. While not shown in the flowchart, there could an additional step where the user would designate which file or record the user wants to access.
typically, that would be the case for a treating physician that treats a number of individual patents having medical .. information available via the Human-Centric UR system. So, at that step, the authorized user would identify the patent whose medical data the user wants to access.
At step 4504 the Human-Centric EHR system determines if the user is an authorized user for the particular patient. This is performed by the user access manager 4302 by comparing the identify and credentials of the user against the list of the authorized users stored in the patient profile. If there is a match, the user is deemed authorized and access is given according to the data privacy configuration.
At step 4206, the medical data for the patient is modulated according to the data privacy settings and only the information that the patient has authorized is exposed to the user. The information that the patient does not want to expose is not made available to the user. In particular, in the case of the GUIs at Figures 38 and 39 the user would be able to see any information that is identified as being non-confidential. In that embodiment, all users that are authorized have the same privileges and see all the information that is designated as being non-confidential. In the embodiments of Figures 40 and 41, the filtering operation at step 4206 is performed differently in that it is based on the identify the authorized user and that user is enabled to see only the information the patent has authorized as far as that user is concerned.
For further control over the access of the information, the user profile can include a log function that records which authorized user has accessed what element of information, along with the date and time. This function provides an additional assurance to the patient and shows what in actuality is happening in terms of data access, in addition to confirming that the data privacy settings work as intended. So, if the patient data contains something that the patient definitely Date Recue/Date Received 2020-11-05 does not want one or more authorized users to know about, the patient can at any time by looking at the log confirm that those users have not accessed that information.
Instead of users taking positive action to access the medical information in the file or record, a push procedure can be implemented when new medical information is available that would send a notification or the medical information itself to all the authorized users that should be informed of the event. Such push procedure is more practical, and it is a proactive way to ensure that treating physicians are kept up to date about patient condition.
The push procedure can send a notification that new medical data is available, where the medical data itself is obfuscated and requires the user to log into the Human-Centric EHR system in order to be able to access the data. Alternatively, the push procedure can be a mechanism to notify the authorized user about the new medical information and provide an access to the information in a facilitated fashion by comparison to the normal access route. An example of facilitation would be to provide a direct link in the notification that the user can invoke and that would bring him or EHR to the medical information.
The flowchart at Figure 46 illustrates the push process in greater detail. The process starts at 4600. At step 4602, the Human-Centric EHR system notifies the patient over the mobile that new medical data is available. As discussed previously, a notification can be sent to the mobile which displays a banner on the display screen indicating that the app requires the attention of the patient.
When the patient opens the app and authenticates himself/herself, the patient can then view the new medical information by interacting with the Human-Centric EHR system.
At step 4604, the user profile 4300 extracts from the user access manager 4302 and the data privacy configurator a list of recipients for the notification about the new medical data. The list is built on the basis of the access authorizations that have been previously specified by the patient.
At step 4606, the list of recipients is sent to the patient mobile and displayed on the GUI. This step is optional but preferred because it informs the patient who is about to get the new medical information.
At step 4608 the patient provides input via the GUI. That input can be a simple confirmation or can be a request to change the list of recipients or to cancel the dispatch.
If at decision step 4610 Date Recue/Date Received 2020-11-05 the patient input is to authorize the dispatch, then at step 4612 the Human-Centric EHR system performs it. However, if the patient wants to make changes to the recipient list or cancel the dispatch, that action is carried out at step 4614.
An alternative approach to data privacy management is to use logic that masks or unmasks parts of the medical file on the basis of certain themes, such as for example, nature of the medical information, a time window and locations of healthcare dispensing events, among others. This is achieved by using a filter that provides a certain options to the patient in terms of masking themes and based on the patient selection, the medical data of the patient is processed and placed into a visible category or a non-visible category.
Figure 48 illustrates the user interface, similar to the user interfaces shown at Figures 38 to 41, where the patient can selectively mask information on the basis of certain themes. In this example, the patient selects a particular theme and indicates if the information is confidential or non-confidential. A possible refinement is to provide a more granular specification for whom the mask is effective, such as in Figures 40 and 41. For instance if the patient wants to mask information based on theme #1, the patient can specify if the specific authorized user for whom the mask is effective, such as Dr. A, Dr. B, Dr. C or Dr.D.
Each theme is defined by parameters. Those parameters identify the medical information to be masked. The identification of what is to be masked and what is not to be masked is performed by processing the medical information through the theme filter.
Examples of themes include:
1) Particular diseases or conditions that the patient wants to mask. For instance, those can be sexually transmitted diseases or screening thereof, phycological diagnoses or treatments and drug use, among others.
2) Time window or time limit during which health care services have been dispensed to the patient;
3) Particular physicians or other health care service providers that have dispensed health care services to the patient 4) Particular institutions, such as hospitals or clinics, that have dispensed health care services to the patient Date Recue/Date Received 2020-11-05 5) Countries or more generally geographic locations where health care services have been dispensed to the patient 6) Prescribed drugs to treat certain diseases 7) Clinical research protocols in which the patient was involved As indicated earlier, each theme is defined by a set of parameters, which is programable. The parameters map data items in the medical information of the patient to the theme. The medical data items are indicators or signs that the particular theme exists in the patient medical history.
For example, when the patent wishes to mask sexually transmitted diseases, the set of parameters are designed to catch any indicator in the medical history about a sexually transmitted disease.
For example, the set of parameters would track diagnoses for STDs, tests for STDs such as test requests and/or tests results and prescribed medication that is used to treat STDs, among others.
When a trace of an STD related information is identified, the document containing that trace is masked.
For STDs the tracking can be performed by using a key word search to scan the medical history for terms that are STD related. Prescribed medication is also scanned for drugs that are usually prescribed to threat STDs. Note that since the medical information does not reside on the server of the Human-Centric EHR system 5004, the filter cannot scan the full medical data.
Advantageously, the filter is invoked every time the patient or an authorized user will view medical data stored at a remote location. At that time, the data is available and the filter, according to the settings in the patient profile is run. if a certain document is found to contain STD related information that document is marked as confidential or to be masked in the patient profile. Each disease or condition to be masked will have its own set of parameters. When the filter in connection with a particular disease or condition is activated by the patient, the medical information being read or viewed by the patient is screened by each filter to determine if the information is to be masked or not.
A theme such as a time window or time limit are simpler to implement as they operate on the basis of dates. In this case, the patient will indicate the time window or the date limit and every medical information document that is within those date specifications will be masked.

Date Recue/Date Received 2020-11-05 Particular physicians and institutions theme would involve a key word search in the medical information to identify the documents that may be relevant and mark those as being masked. The country theme can be handled in the same fashion, in other words through a keyword search.
The prescribed drugs theme be done through a keyword search to identify specific drugs that have been prescribed and that are to be masked. The clinical research protocol theme is handled in the same manner.
The process for the operation of the filter to identify which document will be masked or is illustrated by the flowchart of Figure 44. The process starts at 4400. At step 4402 the patient receives a notification that new medical information is available at a remote node and views the information as per the process described earlier. At step 4404, the masking filter is invoked. This implies processing the medical information that has been sent from the remote node through the parameters of the themes that the patient has activated or enabled via the user interface, as performed at step 4406. The output at step 4406 is list of documents, or items of information in individual documents that constitute traces of certain themes that the patient would like to mask.
At step 4408, the list of the documents to be masked or items of information to be masked are shown or highlighted to the patient via the GUI, such that the patient can approve the selections.
If the output of decision step 4410 is "yes" the patient profile is modified to indicate that the documents or items of documents are to be masked (step 4412), otherwise the document remains unmasked (step 4414).
Consent management To allow entities that are not involved into providing direct health care services to the patient to access the medical information of the patient, a consent from the patient may be required. In a first example, medical data can be useful for research purposes and research institutions would want to collect medical information from many individuals in order to do analytics to find trends, etc. In this case, the medical data collected from patients would be stripped of nominative information and other non-biological or non-medical information about the individual leaving only medical information and/or general Date Recue/Date Received 2020-11-05 socio-economic information that cannot be traced back to a particular individual. Such de-identified data is then pooled, and analytics can be run on it.
In a second example, it may be desirable to perform analytics on the medical data for a particular individual to provide value added advices to that individual, such as a tailored diet or tailored supplements, exercise regimen etc. In this case, the analytics are performed over the medical information of a single individual to produce focused recommendations such as by using Artificial Intelligence (AI). Typically, the analytics are performed by a service that is external to the entity holding the medical data of the .. patient. Accordingly, for the analytics to be run, the medical data must be exported to the entity, which requires the consent of the patient.
In those two scenarios, among others, patient consent is not a trivial process and requires some degree of management. For example, the consent may be time limited and account for the fact that a patient may change his mind about granting access to an external entity to his or her medical information. In other words, it would be desirable to allow the patient to revoke the consent. Also, the consent should be able to define boundaries about the medical information the patient is granting access over. For instance, the patient may not be willing to share certain medical conditions or events, even in instances where the data being shared is de-identfied.
The Human-Centric EHR system that implements the consent management functionality is arranged largely in the same fashion as discussed in the earlier examples, with the exception of the functions shown in Figures 49 to 63. With specific reference to Figure 49 which is a block diagram of the user profile 4300 residing on the server of the EHR
system, shows that the user profile 4300 communicates with a patient data repository that is the source of the medical information of the user/patient. The user profile shown in Figure 49 has two functional modules, among others (not shown) namely a user access manager 4302 and a consent manager 4900. The consent manager provides a series of services focused on consent management to the user access manager. An instance where the consent manager 4900 is invoked is one where an external entity 4902 communicates Date Recue/Date Received 2020-11-05 with the user access manager 4302 to gain access to patient medical data. In that instance, the consent manager 4900 is invoked to perform a consent management operation and authorize access to the patient data consistent with the consent provided by the user/patient.
The general process flow is shown in Figure 50. At step 6000, the Human-Centric EHR
receives from the external entity request for data access. Examples of such external entity 4902 include research organizations, whether private or public, or analytics services that are desirous of performing an analytics process on the medical data to extract information that is highly specific to the patient in order to provide an advice, for example an advice to improve a condition of the user/patient.
Examples of advice that are related to the well-being of the patient, include:
1. Dietary advice ¨ develop a diet that is specific to the patient and tailored to his or her medical condition as characterized by the medical data.
2. Physical exercise regimen ¨ develop a specific physical activity program tailored to the individual 3. Cosmetics blends ¨ develop a specific blend of beauty products that are used to care for the face, body and hair to improve the person's appearance 4. Tailor pharmaceutical regimen or preparations compounding ¨ adjust or substitute ingredients, such as non-active ingredients to better fit the individual 5. Genetic therapy Examples of advice or generally information that is not directedly related to well-being, including:
1. Insurance, such as life insurance ¨ an assessment of life insurance acceptability and tailoring life insurance offering to a user/patient. More Date Recue/Date Received 2020-11-05 generally, this can be characterized as a risk assessment for the purpose of a financial or insurance product, where a financial or insurance service provider can view de-identified and highly granular medical data to make a risk assessment that is specific to the user/patient.
2. Granting a visa in locations that prohibit individuals with certain medical conditions 3. Prior drug or substance use disorder 4. Work related health suitability At step 6002, the user access manager 4302 that can be assumed to run constantly in the background invokes the consent manager 4900 when the request for medical data is received from the external entity 4902. The consent manager 4900 describes collectively the functions that are provided by the Human-Centric EHR to manage consents, such as setting up a consent in relation to a particular external entity, modifying an existing consent or terminating a consent. Specific examples will be provided below to illustrate a range of scenarios. At step 6004, the consent manager 4900 tries to match the request for access to medical data to an existing consent. If an existing consent is found in the user profile 4300, in other words the user has previously authorized that particular external entity to access a portion of the medical data, fully or in part, the medical data is filtered at 6004 according to a filter or mask associated with the particular consent and the filtered data is then sent at 6006 to the external entity.
The external entity receives the filtered data and processes it at 6008. The processing can include running the filtered data through a convolutional neural network trained to perform analytics. After the analysis process 6008 is completed, the results are sent to the user at 6010, via the Human-Centric EHR system or via another channel.
Figure 51 is a more detailed process flow of steps 6002 and the subsequent decision step, illustrating in more detail the operations performed by the consent manager 4900. After reception of the request to access medical data 6000, the consent manager 4900 tries to determine if there is a consent in place from the user, associated with that particular Date Recue/Date Received 2020-11-05 external entity 4902. This is done at step 7000 and involves carrying out two operations:
(1) to identify a consent corresponding to the request and (2) authenticate the request.
Requests can fall generally in two categories, one being one-time request, and the other repeated requests. For one-time requests there is likely not going to be consent on record in the user profile 4300, which will require invoking a mechanism to query the user about setting up a consent, including defining the scope of the medical information that can be exposed. That will be described in detail later. For repeated requests, a consent could be on record and the consent manager 4900 is trying to identify it and authenticate it.
Assuming the consent is found, the consent manager will derive from the user profile 4900 at 7002 a filter or pattern that will expose only the portion of the data consistent with the consent.
Figure 52 illustrates the data structure in the memory 8000 of the server implementing the user profile 4300, showing the relevant data elements that make up a consent data element. The memory 8000 holds a plurality of consent data elements 8002, 8004, 8006, 8008. Each consent data element includes an identifier, authentication data, and a medical data filter. The identifier is a unique identification element that distinguishes one consent data element from another. For example, it can be a unique alphanumerical string. The authentication data is used to confirm the identity of the external entity, namely confirms that it is the same entity for which the consent was set up and not somebody else. The medical data filter identifies a subset of the medical data of the user that can be exposed in connection with this request.
The authentication data can be any type of data or mechanism allowing the consent manager 4900 to confirm the identity of the external entity 4902. The request from the external entity would contain two elements of information to identify and authenticate the consent, namely an identifier, and authentication data. If these two elements are present the consent manager 4900 locates the consent data element corresponding to the identifier and runs the authentication process to determine if it passes or fails. For example, the consent manager 4900 compares the authentication data stored in the consent data Date Recue/Date Received 2020-11-05 element to the authentication data conveyed by the request from the external entity. If both match, the authentication passes, otherwise it fails. The reader skilled in the art will appreciate that the authentication process can be performed differently without necessarily the need to compare locally authentication data.
The medical data filter extracts a portion of the entire medical data set of the user and creates a subset that is then sent to the external entity. The data filter is associated with the particular consent and defines the information that the user is willing to expose in connection with that consent. Note that in some instances, nothing may be sent out as the filter may be designed to block any dispatch of data.
Referring back to the flowchart of Figure 50, the process path when the decision box is answered NO is to invoke at step 6012 the GUI screen to allow the user to set up a consent. An example of the GUI screen and various controls is shown at Figure 53. The initial page of the GUI is a welcome screen with two button-like controls 9002 and 9004, the control 9002 being pressed when the user wants to create a new consent, while the button 9004 is pressed to manage existing consents. As it will be described later, the management function allows the user to terminate a consent or to modify it. An example of modification is to change the data filter to change the scope of the medical information being exposed.
Assume the user clicks on the button 9002 to create a new consent. The user is then brought to another page that provides a range of controls to create and define consents, as shown in Figure 54. The screen 10000 includes three control sub-sets, namely the controls 10002 to define the medical data filter, the information display box 10004 to display the name of the party associated with the consent and the set of controls 10006 to define a period of validity for the consent.
The medical data filter set of controls 10002 provides the user with a set of simple choices in terms of the end use of the filtered data in order to set the appropriate filter.
The user sees themes that are simple to understand and would not require the user to Date Recue/Date Received 2020-11-05 parse the entire medical data record to select individual items of information to include or exclude. The range of themes is vast. Examples shown in the drawings include a theme for dietary purposes where the information extracted from the medical data is sufficient to enable the creation of a highly customized diet, and no more. Similarly, the exercise theme is designed to expose only the information that is needed to create an exercise regimen for the user. The insurance theme is designed to extract only the information that an insurance company may need to provide an initial quotation for life insurance for the individual and would typically include information about key medical conditions of the user that would predict a life span.
In a specific example of implementation, the themes are respective sets of medical information categories, such as particular conditions affecting the individual, heart disease, diabetes, high blood pressure, etc. Each theme includes logic that parses the individual entries in the medical record of the user and then populates the categories accordingly. Populating a category may include placing there the entries of the medical data or a simplified version, such as a qualitative assessment of the condition (the patient suffers from hypertension at stage 2 of 4 stages).
The medical data filter definition control also includes a theme of information that is to be excluded (information to hide button). By clicking on it the user is presented with categories of information that are to remain hidden. The selection of the information to hide overrides the other themes. In other words, if a theme is designed to include information about STIs and the information to hide theme specifically indicates excludes STIs, then the particular category of information in the data filter theme will remain empty. While not shown in the drawings, once the user clicks on the button "information to hide" the user is shown yet another screen that lists information elements that can be selectively chosen and that will remain masked. Examples of categories include STIs, phycological conditions, substance use, sex reassignment therapies or psychological procedures, and anything else that the user wants to keep confidential. As per the other themes, the user picks a theme and underlying logic will parse the medical entries to identify those that can be associated with the theme and will mask those.

Date Recue/Date Received 2020-11-05 The user also has a "custom" button that allows to build a custom filter if an otherwise suitable category does not exist in the list. The custom button would bring a list of the entire medical record and the user can individually select the ones to include or exclude.
It will be noted that by default, the information to hide button is set to remove nominative information and any other information of the user. In this fashion, the medical information received by the external entity cannot identify the person associated with the medical information that is being to the external entity 4902. Optionally, a control may be provided, such as a toggle control, to de-identify the data sent out or to include the nominative information. This would make the GUI more user-friendly as it would communicate clearly to the user the key condition of the data being sent ¨ de-identified or raw data including nominative information.
The display box 10004 shows the identity of the entity making the request.
That information is derived from the request itself received by the server of the Human-Centric EHR system.
The set of controls 10006 set the period of validity of the consent. Possible options include one time, one month, 6 months, and one year, among others.
At the conclusion of the process during which the user supplies the necessary information and makes the relevant selections, the consent manager 4900 creates a consent data item in the memory of the server of the Human-Centric EHR system. The consent data item or consent record includes, as indicated earlier a unique identifier in order to distinguish one consent record from other consent records. The consent identifier may also include the identification of the entity that made the request, such as the name of the entity and other identification characteristics. The consent record further stores authentication data that is generated as a result of a registration process with the external entity 4902, allowing the Human-Centric EHR system to be able to uniquely and securely recognize the external entity 4902, when the later makes future requests for access to medical Date Recue/Date Received 2020-11-05 information. Finally, the consent record stores the medical data filter based on the input by the user.
Referring back to Figure 50, the act of storing the consent is shown at 6014.
At that point the processing goes to step 6004 that will filter the medical data based on the medical data filter in the consent as described earlier. To summarize, the individual medical data entries are parsed to determine which ones belong to a category of information that is to be included in the data sent out, by taking into account the categories of information that are to be specifically excluded. In addition to this categorization process, the data may be further processed to extract features or perform characterization of individual categories, instead of sending out medical data entries. An example of feature extraction in a category that is associated with a certain condition, say diabetes, the feature extraction may specify if the user/patent is positive or negative and in the event the user is positive a characterization of the gravity of the situation.
Referring back to the illustration of the GUI 9000, the user has the option to access to a manager of existing consents. To access the manager function, the user uses the control 9004 to access the GUI screen shown in Figure 55. By way of context, the manager of consents is used to control repeated access to the medical data, in particular allowing a third party to periodically access the medical information and get access to updates of that medical information. As it will be described later, the manager also can be used to control access to medical information by third parties that are unspecified and not known to the user. For instance, the user can authorize via a consent access to his/her medical information to third parties for research purposes. Specific examples of those scenarios will be discussed in detail later.
With specific reference to Figure 55, the GUI presents the user with a depiction of the various consents 11000 that appear as a list in the example. The user can scroll through the list to view all the consents on record. For example, the consents can be identified by the name of the party that has the authorization to access the medical information. For example, the user may see as consent identifier party "ABC", etc.
Alternatively, the Date Recue/Date Received 2020-11-05 consents can be grouped into categories or profiles make the identification and management of individual consents easier. For instance, the user may be provided with a profile based on the use of the medical information that is provided to a third party.
Categories or profiles like research purposes, well-being services, are possibilities. In those instances, the consent manager can be provided with logic to classify the active consents into categories. The categories or profiles can be predetermined categories and the logic can make a decision on the basis of information, such as the name of the external entity to which the medical information is provided. The logic can be trained or otherwise programmed to distinguish between different external entities and place them in the corresponding categories.
Alternatively, a list of consent profiles can be presented to the user that the user can activate or deactivate and that would automatically apply to future requests, thus automating the dispatch of medial data to a third party. For instance, the list may include a profile adapted to medial data use by a research institution. The GUI allows the user to activate or deactivate profiles. When a profile is activated, logic will process incoming requests and determine on the basis of a keyword search for example, the consent profile to associate with the request. Once the association is created, the request is processed as discussed earlier and the consent profile, associated with the request along with the .. medical data is sent to the third party.
The GUI mechanism provided to display the existing consents is designed to allow the user to view all the existing consents and to identify one or more among them for which a change in parameters is to be made. For instance, assume the consents are presented as a list, the user can highlight the desired one and then click on the control 11002 to edit it.
Actuation of this control can bring the user to the GUI shown at Figure 54 where the user can re-define the medical data filter 10002 or re-set the period of validity.
Further to what is shown on the GUI screen of Figure 54, there may provided a further option to cancel the consent and make further access by the external entity no longer possible.

Date Recue/Date Received 2020-11-05 The function of periodically reviewing consents in order to cancel them or renew them may be built into the consent manager functionality. The flowchart at Figure 56 illustrates this. The process starts at 12000. At step 12002 the consent manager logic identifies among the existing consents those that have a validity period expiring shortly, at step 12002. At step 12004 those consents are brought forward to the attention of the user.
That can happen by invoking the GUI shown at Figure 55 where the consents identified at the previous step are shown and where the user can make a decision, either renew them or cancel them. If the user is unable or unwilling to take action on the consent management, the consent manager logic may be designed to suspend the consents avoid that they go beyond their validity. In this fashion no medical information is sent out to a party that is outside the period of validity specifically indicated by the user originally.
The consent manager can also be designed with functionality to provide statistics about the consents and the export of medical information to third parties. The statistics may be made available to the user through a specific GUI screen and include the following elements of information such as how many times a particular entity has accessed medical information and ranking the entities in terms of frequency of access, among others.
As indicated above, some users may desire to allow controlled access to their medical information to a third party, without necessarily having to authorize the initial access individually. An example is research organizations that use the medical data for medical studies. Users may be willing to freely share their medical data (in a controlled fashion) with one or more entities that will use the data for a specific and well-defined purpose.
The difference here with the previous examples is that the recipient of the data is not initially identified and known. The recipient can be anyone that fits admissibility criteria.
To manage this type of access to the medical data the GUI of the consent manager is modified to include admissibility criteria. Those criteria can be structured in manner that is simple and intuitive for the user to understand. For example, the admissibility criteria can be based on the purpose of use of the data and may offer the user the following specific choices:

Date Recue/Date Received 2020-11-05 1. Broad research purposes, where the data is used to advance the human knowledge in medicine 2. Research purposes have specific goals, in terms of class of treatment:
a. Pharmaceutical research b. Medical treatment other than pharmaceutical research 3. Research purposes in relation to specific diseases or conditions, for example research in connection with:
a. Heart disease;
b. Alzheimer's disease c. Diabetes d. Cancer An example of a GUI that would allow the user to make choices and set the admissibility criteria is shown in Figure 57. Initially, the user sees a first their options 13000, some of which lead to second their options 13002 and possibly to third, fourth or more tiers options. If the user activates the control 13004 the selection terminates, and the consent manager stores the selection in the medical data filter which will be processed as it will be discussed later.
Assuming the user makes the choice at the control 13006, the GUI switches to the second-tier options 13002 where the user can select between the two options shown there. Alternatively, if the user selects the option 13008, the user is presented with the second-tier options 13002 comprising a list of disease or conditions selections.
In all instances, after the selection operation is completed, the admissibility criteria selection is recorded in the medical data filter. In addition to setting the admissibility criteria it is to be understood that the GUI operates to prompt the user to specify information that the user does not want to share, along with a period of validity, as per the previous examples.

Date Recue/Date Received 2020-11-05 There may be some instances where medical studies may require the research team to communicate with the patient in order to perform specific lab tests interviews, etc. In such instances, the initial request may contain instructions to display a message to the user requesting that the user contact information be sent to the research team such that the research team can in turn reach out to the patent.
The instructions can be designed in such a way as to provide on the GUI an option for the user to deny the request, in which case the process aborts.
The management of requests of previously unidentified external entities is described in relation to the flowchart of Figure 58. The process starts at 14000.
At step 14002 the access manager receives from an external entity a request to access medical data from the patient. At step 14004 the consent manager is invoked. At step 14006 the request is processed. That step includes determining if a consent is on record with the particular entity generating the request as, for example, the process shown in the flowchart of Figure 50. Assuming no consent on file exists the consent manager triggers an agent to determine if the request falls in the admissible categories as specified by the medical data filter.
1. In a first option, the agent, which is a logic module, tries to match the request to anyone of the admissible categories specified by the user. Here the request conveys information to define the purpose of the use of the medical data along with the identity of the entity. The request may include keywords and the agent may look at the keywords and on the basis of them determine if the request falls in any admissible category.
Alternatively, the request may use HL7 language to define the purpose of the data allowing the agent to figure out if the request falls in any one of the admissible categories previously specified by the user.
2. In a second option, the request may include a link to an external file that can be imported by the agent and that contains the specification of the data Date Recue/Date Received 2020-11-05 use. The agent imports the external file and processes it against the admissibility criteria to determine if there is a match.
If a match between the request and the admissibility criteria is established, as shown by the "YES" answer to the decision box 14008, the medical data is filtered as per the medical data filter settings at step 14010, for instance to strip out the name and other identifying information for the user along with any medical information the user does not want to expose and the medical information is sent out at step 14012. A
transaction record is then generated and stored in the user profile at step 14014. The transaction record has a unique identifier and serves to distinguish that transaction from every other transaction record. In addition to the unique identifier the transaction record includes any other data that is necessary to characterize the transaction, such as time, date, the identification of the external entity and the medical data that was sent. The unique identifier is shared with the external entity by sending it along with the medical data.
Assuming the request for access fits no admissibility criteria and the decision step 14008 is answered in the negative, the processing stops and no medical data is sent to the external entity.
The unique transaction record is useful in instances where the external entity, such as a research institution while performing the research work finds that the medical data conveys a serious condition and for ethical reasons needs to alert the user.
Since no identification of the patient is sent out with medical data, the external entity has no way of alerting the user directly. Accordingly, if such anomalous data is identified, the external entity will send an alert notice such that the Human-Centric EHR
system can identify the subscriber associated with the particular transaction, notify the subscriber (user) and optionally notify the physician that provides health care services to the user.
The process for sending such an alert notice is shown at Figure 59.
At step 15000 the external entity identifies an anomalous condition in the medical data of the user, but since the data is de-identified there is no way to know the identify the person Date Recue/Date Received 2020-11-05 and reach that person directly. However, the external entity maintains its own transaction record which contains the unique identifier generated by the Human-Centric EHR
system when the medical data was originally sent to the external entity. The alert notice would include the unique identifier along, at minimum, with an indication that anomalous information was found for that user. Optionally, details of the abnormality can be provided, for example by pointing to certain medical parameter that is abnormal. At step 15002 the alert notice containing the above information elements is generated and sent out to the Human-Centric EHR system at step 15004.
At step 15006 the alert notice is received at the Human-Centric EHR system and the server will search the unique identifiers for all the subscribers to find which subscriber is associated to the one in the alert notice. Once the subscriber has been identified the Human-Centric EHR system will notify the subscriber and optionally send a notification to physician identified in the care support group in the user profile of the subscriber.
In another possible variant to allow the user to share its medical data is to present the user with a list of available projects, such as research projects that could use the medial information. The user can visit websites associated with such projects and proactively send tout the information instead for the external entity asking for it.
Assume the user is presented on a GUI with the list of the research projects, the user can select the ones of interest and export the data after the data has been filtered as per the settings in the medical data filter. Note that the external entities can provide their own research project consent document for the user to review and consent to. For example, in instances where the research institution sends out requests to users to gain access to their medical information and eventually to enroll them in research projects, the initial request may contain the consent information allowing the user to view it and accept it on the GUI.
In another variant, a possible option to assist the user in properly setting the admissibility criteria, as explained previously in relation to Figure 57, is to provide the consent manager with an agent that can guide the user in making choices that are consistent with its medical condition. In other words, while the user may want to offer its medical Date Recue/Date Received 2020-11-05 information for research in relation to particular diseases and conditions, the user data would be of practical usefulness to the research if the user actually has those diseases and conditions. For instance, medical data from someone that has a healthy heart may not be useful to a research project on heart disease. In order to assist the user in making the choices that are consistent with his or her medical condition, the consent manger is provided with an agent that can make a correlation between the medical data of the user and the options offered by the GUI in Figure 57 to highlight those that are the most consistent with the medical information.
The process is depicted in the flowchart of Figure 60. The process starts at step 16000. At step 16002 the admissibility criteria selection agent is invoked. The admissibility criterial selection agent is logic that processes the medical information in the user record to identify diseases or conditions that afflict the user and then match those to admissibility conditions. This occurs at step 16004. In one possible example, the agent will parse the medial information for keywords corresponding to treatment, prescribed drugs or diagnosis associated with a disease or condition in a pre-set number of diseases or conditions the agent is designed to identify. In this example, the output of step 16004 is a list of diseases or conditions the agent has identified in the medical information of the user. At step 16006, the agent tries to match the identified diseases or conditions so identified with choices for the admissibility criteria available to the user.
For instance, if there are choices based on diseases or conditions, then those choices that match the diseases or conditions identified in the medical information of the user are highlighted to indicate to the user that his medical data is likely to be most useful for research in those areas. This guides the user in making more relevant selections.
In yet another example of implementation, the Human-Centric EHR system is configured with functionality to allow better matching between research institutions, either private or public that need medical data and human participants to perform fundamental research, either drug or medical device and procedures development. In many instances it is difficult for such research institutions to get access to medical data for statistical research, and even more difficult to get participants involved in clinical trials, especially when the Date Recue/Date Received 2020-11-05 trials require candidates that have a certain rare disease or condition. In other words, it is difficult for research institutions to reach out to candidates who might be interested to participate in such research work. The typical process for a research institution is to advise hospitals or other care health care centers that treat a large number of patients about research projects and rely on physicians treating patients to determine which ones might fit the admissibility criteria of a certain research project and propose to the patients to participate. The process is long, tedious and in the end misses a number of potential candidates.
The Human-Centric EHR system may be configured to act as an intermediary between on the one hand research institutions and on the other hand a large pool of users in order to automatically perform a screening process and identify individuals who may fit the admissibility criteria of certain research projects, without exposing medical data of the individuals, and notify suitable candidates about the possibility of participation. The process is secure in the sense that no medical information is being exposed, the notification to the users about the possibility of participation in a research project is made in a private and confidential fashion leaving the ultimate decision to each individual as to participate or not. In addition, the process allows to set a financial compensation or other form of compensation in place for the use medical information.
With specific reference to the block diagram of figure 61, the Human-Centric EHR
system 17000 is provided with a portal where a research institution can send information about research projects. Such research projects may be of several kind, where only the medical information of the user is needed, or where the medical information and additional participation of the user is required. For example, in a clinical trial designed to determine the efficacy and safety of a drug, the admissible participants are required to interact with the research organisation that would administer the active compound or a placebo and monitor the response of the human body. Typically, this process requires that the patient visits a clinic and subjects himself to periodic medical examinations over the course a certain time period, typically a number of months.

Date Recue/Date Received 2020-11-05 The research institutions 17002 send to the online portal 17004 information about research projects. The information defines the parameters of the research project, in particular:
1. Medical/physical admissibility criteria ¨ a definition of the medical or physical condition required for admission. The medical admissibility criteria may include, age, race, sex, presence of certain medical conditions which can be further characterized by degree of severity or presence of further physical conditions that can be characterized with any particular granularity. Demographics, including socio-economic status, or geographic localization are other examples of admissibility criteria 2. Access to medical data only is required or if further engagement with the individual is required and in the alter case the characterization of this further engagement, such as participation in a clinical trial, interview with the research organization or others 3. Compensation parameters. In other words, is there a possibility for financial compensation or other, the scope and conditions associated with it.
The Human-Centric EHR system 17000 is provided with an agent that receives the information defining the parameters of each research project, tries to match the research project to individual subscribers and when a match is found notifies the individual to determine if the person is interested to participate.
Figure 62 is a block diagram illustrating this functionality. The agent 18000 is a software implemented function that receives as an input the information defining the parameters of the research project and tries to match those parameters with the medical information of individual subscribers. The information about a particular research project, in particular the admissibility criteria can be structured in any suitable way to enable in turn the agent 18000 to match the information to the medical data of different subscribers.
In one example, the admissibility criteria can be structured in terms of categories.
The agent is Date Recue/Date Received 2020-11-05 configured to process the medical data of the subscribers and categorize it accordingly and then determine if there is a match into individual categories. In a specific example, the admissibility data may include the following categories:
1. Age ¨ in the range of 20 ¨ 80 2. Race¨any race 3. Sex¨any 4. HDL cholesterol levels in excess of 3.1 mmol/L
The agent parses the medical information associated with each subscriber to identify those that match the categories above. Matches are identified and a notification is sent to each user. The notifications can be made through a GUI, as the one shown in Figure 63.
The GUI shows at 19000 the clinical trial or the medical project to which the subscriber is admissible. The display field 19000 would show a range of information including the name of the external entity that is responsible for the project, details about the project and any other suitable information. The user is provided with a series of controls to manage the acceptance or refusal to participate in the project.
Control 19002 triggers the display of additional information that the user may need to make a decision about his or her participation. For instance, the information may indicate the kind of participation required, such as whether only access to the medical information of the user is required or further involvement is also necessary such as enrolment in a clinical trial. The "details" screen can also indicate if compensation to user is available and details of that compensation such as the mechanism for payment.
The consent 19004 displays a consent management page the user can consent to have its medical data, either fully or partially released to the external entity. Note that the consent management page may include a functionality to prevent exposing information the user wants to keep private, similar to the control 10002 at Figure 54.

Date Recue/Date Received 2020-11-05 Finally, the acceptance control 19006, once triggered signifies acceptance to participation by the user. That may include sending the information to which the user has consented or providing the external entity with the contact information of the user such that the user can receive further details about his or her participation.
It should be noted that under any of the above scenarios, the consent information provided by the user is stored in a log that is retained in order to be able to establish for the Human-Centric EHR system legal compliance, if any, for consent management.

Date Recue/Date Received 2020-11-05

Claims

CLAIMS:

1. A method for populating an electronic health record system with health records associated with respective patients, the method comprising:
a. querying a centralized health record network storing health records about multiple patients, the quelying being performed in the context of a physician dispensing medical services to a first patient of the multiple patients, the querying including accessing the health record of the first patient;
b. copying some or all of the information in the health record of the first patient to the electronic health record system to create health record for the first patient in the electronic health record system;
c. repeating steps (a) and (b) for a second patient of the multiple patients;
d. wherein the physician dispenses medical services to only a subset of patients of the multiple patients.

2. The method of claim 1, including providing an account to the first patient such that the first patient can access the health record associated therewith on the electronic health record system.

3. A method for providing health records associated with a patient to an electronic health record system, the method comprising:
a. receiving an indication for a request to obtain the health records associated with the patient;
b. requesting the health records associated with the patient from an electronic health record network comprising a plurality of nodes, the health records associated with the patient being distributed amongst the plurality of nodes of the health record network;
c. obtaining the health records associated with the patient, in response to requesting the health records associated with the patient from the electronic health record network; and d. transmitting the health records associated with the patient to an electronic health record system for centralized storage of the health record.

4. The method of claim 3, wherein the indication for the request to obtain the health records associated with the patient from the electronic health record network is received from a Human-Centric electronic health record system or is received by the Human-Centric electronic health record system.

5. The method of claim 3, wherein the electronic health record system for centralized storage of the health records is a Human-Centric electronic health record system.

6. The method of claim 3, wherein the plurality of nodes of the electronic health record network is a plurality of electronic health record systems.

7. The method of claim 6, wherein said requesting the health records associated with the patient from the electronic health record network comprises requesting from a server associated with the plurality of electronic health record systems to obtain the health records associated with the patient from the plurality of electronic health record systems.

8. The method of claim 5, wherein said requesting the health records associated with the patient from the electronic health record network comprises requesting from each of the plurality of electronic health record systems to obtain the health records associated with the patient from the plurality of electronic health record systems.

9. A method for providing at least one computing device associated with a patient a notice that medical results associated with the patient have been received at an office associated with a physician, the method comprising:
a. receiving from an electronic record system associated with the physician an indication that medical results associated with the patient have been received at the office associated with the physician;
b. transmitting to a computing entity associated with the patient an first notice that medical information is available;
c. receiving a request for the medical information from the computing entity associated with the patient, the request including authentication information;
and d. if the authentication information is associated with the patient, transmitting to the computing entity associated with the patient a second notice, the second notice indicating that medical results associated with the patient have been received at the office associated with the physician.

10. A method for providing medical results associated with a patient to a computing device associated with the patient, the method comprising:
a. receiving medical results associated with the patient from an electronic record system associated with a physician;
b. transmitting to a computing entity associated with the patient an first notice that medical information is available;
c. receiving a request for the medical information from the computing entity associated with the patient, the request including authentication information;
and d. if the authentication information is associated with the patient, transmitting to the computing entity associated with the patient a second notice, the second notice comprising the medical results associated with the patient.

11. The method of claim 10 wherein the medical results comprise medical results from a third-party medical facility.

12. The method of claim 10 wherein the medical results comprise an annotation from the physician.

13. The method of claim 10 wherein the medical results comprise an action item.

14. The method of claim 13, wherein the action item is to schedule an appointment with the physician.

15. The method of claim 13, wherein the action item is a prescription.

16. A method for making a health related determination, the method comprising:

a. monitoring data obtained from one or more sensors measuring a physical condition of a patient, the monitoring of the data from the one or more sensors being done over a plurality of time points;
b. storing the data from the one or more sensors in association with medical records associated with the patient c. processing the data from the one or more sensors against the medical records associated with the patient to make a health related determination, the medical records being obtained from a plurality of electronic health record systems.

17. The method of claim 16, wherein the one or more sensors measure blood glucose and the health related determination is that the blood glucose level of the patient is high.

18. The method of claim 16, wherein the one or more sensors measure heart rate and the health related determination is that the heart rate of the patient is high.

19. The method of claim 16, wherein the one or more sensors measure blood pressure and the health related determination is that the blood pressure of the patient is high.

20. The method of claim 16 further comprising transmitting a notification of the health related determination to a computing entity associated with the patient.

21. The method of claim 16 further comprising transmitting a notification of the health related determination to an electronic health record system associated with a physician.

22. A method for providing a third-party with health records associated with a patient, the method comprising:
a. receiving a request to provide the third-party with the health records associated with the patient;
b. authenticating the request with a computing device associated with the patient;
c. providing a third-party computing device with access to the health records associated with the patient.

23. The method of claim 22 wherein the request is received from the computing device associated with the patient.

24. The method of claim 22 wherein the request is received from the computing device associated with the third-party.

25. The method of claim 22 wherein the access to health records is provided for a limited time period.

26. The method of claim 21, wherein the method further comprises receiving from the computing device associated with the third-party an annotation associated with one or more of the health records associated with the patient.

27. A method of providing health records to an agent, the method comprising:
a. receiving a request for a plurality of health records meeting a specific criteria from a third-party computing entity associated with the agent;
b. obtaining a plurality of health records meeting the specific criteria;
and c. providing to the third-party computing entity the plurality of health records.

28. The method of claim 27 further includes removing patient identifying characterizes from the plurality of health records meeting the specific criteria to form a plurality of anonymized health records prior to providing the third-party computing entity the plurality of health records, wherein the plurality of health records provided to the third-party are anonymized.