WO2019209831A1

WO2019209831A1 - Clinician/patient data input and monitoring systems and methods

Info

Publication number: WO2019209831A1
Application number: PCT/US2019/028729
Authority: WO
Inventors: Raghav MURALI-GANESH; Nikhil POOVIAH
Original assignee: Canceraid, Inc.
Priority date: 2018-04-23
Filing date: 2019-04-23
Publication date: 2019-10-31

Abstract

Patient self-reporting data (health, symptom, activity data) systems and methods, particularly systems suitable for facilitating secure communication between an authorized recipient (identified clinician(s)/facility and/or facilities) and a patient, are disclosed herein. Systems and methods that provide an authorized recipient (e.g., clinician) with access to patient recorded data are described. Secure and encrypted electronic systems and methods for system verified authorized recipients (clinicians, facilities, medical treatment facilities) to access specific system verified patient transmitted data through a secure portal, and as an electronic "App" system, are also presented.

Description

CLINICIAN/PATIENT DATA INPUT AND MONITORING SYSTEMS AND METHODS

CROSS-REFERENCE TO RELATED APPLICATIONS

This Application claims priority to ET.S. Provisional Patent Application Serial No. 62/661,579, filed on April 23, 2018, to Raghav Murali-Ganesh et al., entitled“Clinician/Patient Data Input and Monitoring Systems and Methods,” currently pending, the entire disclosure of which is incorporated herein by reference.

FIELD OF THE INVENTION

The disclosure as detailed herein generally relates to the technical field of systems for data input, particularly personal health and symptom data input and transmission.

DESCRIPTION OF THE RELATED ART

Patient care generally requires a patient communicating with an attending physician. Conventionally, a patient will verbally convey symptoms, if any, of a malady to an attending health care professional (e.g., nurse, clinician, psychologist, social worker, dietician, physiotherapist, occupational therapist, integrative medicine, behavioral health or mental health professional, etc.) during a routine scheduled visit. ETpon learning the symptoms from the patient, the health care professional and/or staff will write down the information and/or input the symptoms into a computer. The information will then become part of the electronic copy of the patient’s medical record, or electronic medical record (EMR). The physician may simultaneously review the information and render a diagnosis and a proposed treatment plan.

Retrospective patient symptoms are also recorded during scheduled visits even when the patient is no longer suffering from the symptoms. Additionally, because scheduled physician visits are relatively infrequent, some symptoms reported during a physician visit may have worsened past a point where a beneficial treatment plan could or should have been implemented. Patients in critical care situations, such as oncology patients, are at risk for rapid deterioration or death when certain symptoms are not communicated to a health care provider. In view of these considerations, the medical arts need improved healthcare tools that allow patients to report symptoms more frequently to a doctor, and furthermore, there exists a need for doctors and other medical professionals to continually monitor patient symptoms to detect worsening health conditions.

SUMMARY OF THE INVENTION

Patient health, symptom and activity data reporting systems and methods are disclosed herein. Secure and encrypted electronic systems and methods for receiving, recording and transmitting data, such as data from a patient (including protected medical information (PMI)), to another are described. In particular, instantaneous transmission of contemporaneously generated patient self-entered health, symptom and activity data, between a patient and a health care professional (e.g., clinician, care facility), are provided. Systems and methods for improving the delivery of health care to patients, particularly to oncology patients, through a secure electronic self-reporting data (e.g., health, symptom and activity data) system, are disclosed.

As part of the systems and methods, the security of a patient’s data is protected through a defined enrollment process, among other safe guards. Once enrolled, the patient will be able to enter data related to his/her health, symptom and activity, which will include an option to enter his/her responses to at least a defined menu of 17 specific symptoms, with one optional data point of the patient’s choice, to be specified and identified by the patient themselves. The patient will provide a score to the relative intensity level of the specific symptom on a defined scale. Several scales are available for a patient or other user to score relative intensity level of a specific health parameter or symptom. By way of example, some scoring systems use a scale of 1 (almost no symptom) to 10 (most severe) symptom. Another scoring system employs a scale of 0 (no symptom) to 4 (most intense).

In one aspect, a method is disclosed comprising receiving patient data (health, symptom and/or activity) data into a first device, receiving a decoding token from a second device, wherein the decoding token comprises a linking code; and transmitting the patient data to the second device in response to the linking code. In some embodiments, the linking code identifies a patient. In some embodiments, the second device is a device of a clinician or other health care provider/health care facility, the second device being capable of receiving the patient data from the first device.

In a particular aspect, a method is disclosed comprising transmitting a link from a first device to a second device of an identified patient, receiving the link by the second device and transmitting acceptance of terms of use by the second device, receiving a decoding token from the first device, wherein the decoding token comprises an identifier identifying the patient’s clinician and/or facility and an identifier identifying an electronic medical record reference of the patient (such as a Medical Record Number (MRN)), that is associated with a specific patient, generating a linking code associated with the patient, transmitting the linking code to the first device, receiving a notification that a second device identified with the specific patient has entered the linking code, receiving patient data into the second device, and transmitting patient data to the first device. In some embodiments, the first device is a device of the patient’s clinician, health care provider, or health care facility.

According to yet another aspect, a method for transmitting and receiving patient health and symptom data is provided according to any method described herein. A system for transmitting and receiving patient data (health, symptom, activity) according to any system described herein is also disclosed.

The several systems and methods as described herein may be employed in recording, transmitting and/or receiving patient data by a clinician and/or facility from a patient. For example, the systems and methods may be used by patients with any type of chronic disease including a cancer diagnosis (breast, pancreatic, stomach, ovarian, bladder, prostate, lung, etc.), arthritis, Alzheimer’s disease, Parkinson’s disease, or any other type of autoimmune disease or non-autoimmune disease in which an ability to input symptom data would be advantageous. It is also expected that the present systems and methods are useful with geriatric patients and patients with a reduced or compromised ability to care for themselves independently, particularly patients that live alone and/or that live in remote/rural areas.

The present methods and systems present many advantages and improvements over existing systems. By way of example, these include improved security and integrity in collecting and storing patient data. The methods and systems are configured to be performed in a manner that ensures the generation of a “linking” tool, the “linking” tool assuring that the clinician/facility is authorized by a specifically identified patient to be associated with the specific patient. The methods and systems also minimize risk associated with connecting an incorrect medical record with a particular patient. The methods and systems also assure the secure association and access of more than one authorized clinician and/or authorized medical facility with a specifically identified patient (user), at once (simultaneously), while minimizing collision and/or confusion of individual patient data being transmitted to an unintended clinician/facility, and/or between an unintended clinician/facility and a specific user patient. In addition, the systems and methods provide for an enhanced token verification system of steps, wherein the verification token system assures that a token provided as part of a URL launched within a web browser has been validly constructed by a clinician/medical facility user that has been verified as part of the user connection process. Appropriate controls are implemented that assure the system is robust against replay attacks, among other advantages. As used in the descriptions here, a replay attack (also known as playback attack) is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. This is carried out either by the originator or by an adversary who intercepts the data and re-transmits it, possibly as part of a masquerade attack by IP packet substitution. This is one of the lower tier versions of a "Man in the middle attack." Another way of describing such an attack is: "an attack on a security protocol using replay of messages from a different context into the intended (or original and expected) context, thereby erroneously informing/alerting an intended participant(s) into thinking they have successfully completed the appropriate protocol run.

While aspects of the present disclosure can be described and claimed in a particular statutory class, such as the system statutory class, this is for convenience only, and one of skill in the art will understand that each embodiment of the present disclosure can be implemented and claimed in any statutory class. Unless otherwise expressly stated, it is in no way intended that any method or aspect set forth herein be construed as requiring that its steps be performed in a specific order. Accordingly, where a method claim does not specifically state in the claims or descriptions that the steps are to be limited to a specific order, it is no way intended that an order be inferred, in any respect. This holds for any possible non-express basis for interpretation, including matters of logic with respect to arrangement of steps or operational flow, plain meaning derived from grammatical organization or punctuation, or the number or type of aspects described in the specification.

DESCRIPTION OF FIGURES

Figure 1 illustrates a system according to an exemplary embodiment.

Figure 2 illustrates a method according to an exemplary embodiment.

Figure 3 illustrates a flow diagram of the system according to an exemplary embodiment. Figure 4 illustrates a flow diagram of the system according to an exemplary embodiment.

Figure 5 illustrates a flow diagram of the system according to an exemplary embodiment.

Figure 6 illustrates a method according to an exemplary embodiment

Figures 7A - 7C illustrate graphical user interface screenshots according to an exemplary embodiment.

Figures 8A- 8G illustrate graphical user interface screenshots according to an exemplary embodiment.

Additional advantages of the disclosure will be set forth in pan in the description that follows and, in part will be obvious from the description or can be learned by practice of the disclosure. The advantages of the disclosure will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure, as claimed.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present disclosure can be understood more readily by reference to the following detailed description of the disclosure.

As used in the specification and the appended claims, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to "a health record", "an algorithm", or "a QR code," "RFID," or "PIN" includes mixtures of two or more such functional health records; algorithms; QR codes, RFIDs, or PINs; and the like.

Ranges can be expressed herein as from "about" one particular value and/or to "about" another particular value. When such a range is expressed, a further aspect includes from the one particular value and/or to the other particular value. Similarly, when values are expressed as approximations by use of the antecedent "about," it will be understood that the particular value forms a further aspect. It will be further understood that the endpoints of each of the ranges are significant both in relation to the other endpoint, and independently of the other endpoint. It is also understood that there are a number of values disclosed herein, and that each value is also herein disclosed as "about" that particular value in addition to the value itself. For example, if the value "10" is disclosed, then "about 10" is also disclosed. It is also understood that each unit between two particular units are also disclosed. For example, if 10 and 15 are disclosed, then 11, 12, 13, and 14 are also disclosed.

As used herein, the terms "optional" or "optionally" mean that the subsequently described event or circumstance can or cannot occur, and that the description includes instances where the event or circumstance occurs and instances where it does not.

As used herein, the term "mobile device" may comprise a wide variety of computing devices. In some embodiments, the mobile device may refer to a smart phone, a laptop, a tablet, a wearable device, or the like.

As used herein, an "installed application" refers to a software application that has been downloaded onto an electronic device and is ready to be launched (e.g., become opened) on the device. In some embodiments, a downloaded application becomes an installed application by way of an installation program that extracts program portions from a downloaded package and integrates the extracted portions with the operating system of the computer system.

The term“automatically” refers to an action or operation performed by a computer system (e.g., software executed by the computer system) or device (e.g., circuitry, programmable hardware elements, ASICs, etc.), without user input directly specifying or performing the action or operation. Thus the term "automatically" is in contrast to an operation being manually performed or specified by the user, where the user provides input to directly perform the operation. An automatic procedure may be initiated by input provided by the user, but the subsequent actions that are performed "automatically" are not specified by the user, i.e., are not performed "manually", where the user specifies each action to perform. For example, a user filling out an electronic form by selecting each field and providing input specifying information (e.g., by typing information, selecting check boxes, radio selections, etc.) is filling out the form manually, even though the computer system must update the form in response to the user actions. The form may be automatically filled out by the computer system where the computer system (e.g., software executing on the computer system) analyzes the fields of the form and fills in the form without user input specifying the answer or answers to one or more of the fields. As indicated above, the user may invoke the automatic filling of the form, but is not involved in the actual filling of all of the fields of the form (e.g., the user is not manually specifying answers to all fields, but rather some or all of the fields are being automatically completed). Aspects of the present invention are described in the instant specification with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s).

It should also be noted, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Although some examples are described as being performed via Wi-Fi communication, any number of other communication technologies may be used in addition or as alternatives to Wi-Fi. For example, any of near field communication (NFC), Bluetooth, various local and/or wide area networking technologies, and/or any other non-cellular communication technology may be used individually or in combination to provide a communication link between a user device and a device to which the user device is communicating.

Embodiments of the present disclosure may be realized in any of various forms. For example some embodiments may be realized as a computer-implemented method, a computer- readable memory medium, or a computer system. Other embodiments may be realized using one or more custom-designed hardware devices such as ASICs. Still other embodiments may be realized using one or more programmable hardware elements such as FPGAs.

In some embodiments, a non-transitory computer-readable memory medium may be configured so that it stores program instructions and/or data, where the program instructions, if executed by a computer system, cause the computer system to perform a method, e.g., any of the method embodiments described herein, or, any combination of the method embodiments described herein, or, any subset of any of the method embodiments described herein, or, any system or method combination of such subsets.

In some embodiments, a device may be configured to include a processor (or a set of processors) and a memory medium, where the memory medium stores program instructions, where the processor is configured to read and execute the program instructions from the memory medium, where the program instructions are executable to implement any of the various method embodiments described herein (or, any combination of the method embodiments described herein, or, any subset of any of the method embodiments described herein, or, any combination of such subsets). The device may be realized in any of various forms.

Unless otherwise expressly stated, it is in no way intended that any method set forth herein be construed as requiring that its steps be performed in a specific order.

Accordingly, where a method claim does not actually recite an order to be followed by its steps or it is not otherwise specifically stated in the claims or descriptions that the steps are to be limited to a specific order, it is no way intended that an order be inferred, in any, respect. This holds for any possible non-express basis for interpretation, including the following: matters of logic with respect to arrangement of steps or operational flow, plain meaning derived from grammatical organization or punctuation, and the number or type of aspects described, in the specification.

While this invention is susceptible of an embodiment in many different forms, there are shown in the drawings and will be described herein in detail specific embodiments thereof with the understanding that the present disclosure is to be considered as an exemplification of the principles of the invention. It is not intended to limit the invention to the specific illustrated embodiments.

Physical and psychological symptoms are common during medical treatments, such as cancer treatments (e.g., radiotherapy) and chemotherapy, and real-time monitoring of these symptoms can improve patient outcomes. For example, when symptoms are frequently reported by patients and those reported symptoms are frequently reviewed by physicians or other attending medical professionals, medical professionals can diagnose worsening conditions, prevent life-threatening adverse effects, and prescribe remedial drugs or treatment plans to combat worsening conditions. Due to these improvements in medical care, health care costs can be substantially reduced, patient satisfaction and quality of life can be improved, and patient survival and life span can be increased (e.g. by five to eight months or more). Furthermore, patients can receive medical attention remotely between clinic visits without having to travel to a physician’s clinic or office to report new or worsening conditions.

FIG. 1 illustrates a system for patient monitoring according to an exemplary embodiment. As shown, the system includes a health service system, a company system, and a mobile device.

In some embodiments, the health service system can be a client computer or terminal used by a clinician at a medical facility, such as a clinic, skilled nursing facility, hospital, or doctor’s office. Using the health service system, a clinician or other medical professional can access an electronic medical record (“EMR”). An EMR can include medical information about a patient. For example, the EMR can include treatment information, diagnosis information, prescription information, demographic and personal information about the patient, and appointments. Generally, an EMR can be a medical record that is specific or unique to a specific medical organization, such as a single medical office or a single hospital. While an EMR is described herein for illustration purposes, the systems and methods described herein can also access and utilize electronic health records (EHR). EHR generally include health data from multiple medical organizations and practices. It is envisioned that the methods and systems herein may be used in both EMR and EHR systems, and the terms may be understood to be used interchangeably herein.

In some embodiments, the health service system can generate a decoding token that encrypts EMR data with a pre-shared key (also known as a linking code). According to an exemplary embodiment, the pre-shared key can be used by the company system to ensure that a patient’s data is only shared with an approved clinician. That is, only approved clinicians can access a particular patient’s data. The system will maintain patient data security and will comply with the Health Insurance Portability and Accountability Act (HIPAA) and the General Data Protection Regulation (GDPR). The process of generating, sharing, and obtaining the pre-shared key is described below. According to an exemplary embodiment, the company system can provide patient data in response to a valid decoding token and a valid pre-shared key, and the company system can deny requests for data that lack a valid decoding token and a valid pre- shared key.

According to an exemplary embodiment, the health service system can transmit the decoding token to the company system through a web-browser on the health service system. In some embodiments, the decoding token can be transmitted to the company system through a wide area network, such as the Internet, and the decoding token can be encrypted using TLS encrypted communications.

According to an exemplary embodiment, the company system can store patient data received from the mobile device. Furthermore, according to an exemplary embodiment, the company system can provide some of the patient data to the health service system in response to detecting the valid decoding token.

According to an exemplary embodiment, the mobile device can execute a software application, sometimes called an“App”, to request and receive medical information from a patient. In some embodiments, the App can present a questionnaire on a graphical user interface (GUI) of the mobile device, and the patient can provide answers to the questionnaire through the GUI. For example, the questionnaire can include up to seventeen or eighteen questions about various health (e.g., vital signs, including weight, heart rate, blood pressure, temperature), activity (work and/or exercise (steps, distance, length of time)), and/or symptoms of a medical condition or medical treatment plan that the patient is experiencing. By way of example, symptoms may include such things as pain, tiredness (fatigue), fever, nausea, vomiting, depression, anxiousness, appetite loss, shortness of breath, constipation, diarrhea, coughing, a feeling of pins and needles, painful urination, hot flashes, acid reflux, drowsiness, and any other at least one additional symptom identified by the patient. In some embodiments, one of the questions of the questionnaire can include a question asking the patient which symptom is most bothersome to the patient. The answers to the questions of the questionnaire can be entered by a user selecting a number on a scale (e.g. responding to the question:“on a scale of 1 (no symptoms) to 10 (unbearable), how bad is your nausea?”). In another embodiment, the patient can enter textual answers into the user interface using a keyboard. After the user answers the questions of the questionnaire, the App can transmit the answers to the company system, and the company system can store the answers in a medical record specific to the patient. The linking code for the patient may also be transmitted with the answers to save the medical data in the proper medical record. In some embodiments, the company system may create a new medical record for the patient based on the answers, and in some embodiments, the company system may update or append the patient’s medical record with the answers. In some embodiments, the App can save the linking code and provide the linking code to the company server automatically upon transmission of the questionnaire answers.

According to an exemplary embodiment, the patient can take the questionnaire whenever and as often as the patient desires, feels a new symptom, or feels a change in a symptom. Alternatively, the App may prevent a user from taking the questionnaire more than once a day. In yet another embodiment, the App may generate a notification through an operating system of the mobile device reminding the patient to take the questionnaire, such as at least once a day or more.

While FIG. 1 illustrates a single mobile device and a single health service system with the company system, it is assumed that the company system may communication with numerous mobile devices and numerous health service systems.

As noted above, a patient can use the App described above to enter data (health, activity, symptom), that are then remotely saved at the company system. Figure 2 illustrates the method whereby a patient enters data (health, activity, symptom), using the App and the mobile device. According to the method illustrated by Figure 2, a patient can download the App from a specific URL or application provider (e.g. the App Store or Play Store), and the patient can enter a pairing code provided by the clinician/health care provider and/or health care facility (described below). After entering the pairing code, the App can command the mobile device to display a user agreement. By way of example, such a user agreement may present a patient’s rights regarding medical data privacy. The presented user agreement will provide a means whereby the patient can respond, such as by providing a patient’s“informed consent” to the sharing of any data, such as any private medical data, with the clinician and/or medical facility that provided the linking code (or the user can opt-out). After responding to the“user agreement” in a manner that indicates the patient agrees to the terms of service, the patient can enter data into the system, such as through the use of the App to enter data (health, activity and/or symptoms).

The system and/or the App may then transmit the data through a secure network using the company system. The company system may then transmit the patient data to an intended recipient, such as a clinician, medical facility or other service (such as to an insurance provider (payor), medical care coordinator, pharmaceutical company).

According to the guidelines of HIPAA and/or GDPR (General Data Protection Regulation) requirements, a patient has certain rights governing the security of their identifying health data. As such, to be compliant with the regulatory framework of these requirements, the systems and methods include a secure method and mechanism by which the patient is able to input data, as well as by which the data is maintained and transferred/transmitted to another, in a secure manner. The system will grant only a designated party (clinician, healthcare provider, medical facility, insurance provider, payor), access to the patient data (symptoms) entered through the App. The systems and methods described herein provide at least two technical methods for securing the privacy of data, and particularly protected medical information (PMI) , of a patient and ensuring that the data (PMI), and any other private medical data is not shared with anyone not specifically designated by the patient. In this manner, compliance with any regulatory and/or privacy requirement, may be coordinated (thereby complying with HIPAA and/or GDPR for example).

FIG. 3 illustrates a method of enrolling and linking patients and clinicians so that patient data (e.g., medical symptom, health or activity data, including PMI) is not shared with any party not specifically designated by the patient. To begin, a patient may select a clinician or medical professional who has an account with the company service or other Service connected with the company service. The patient visits the clinician and/or medical facility. The clinician and/or medical facility, presents the patient with an option to use the company service (the App), to self- enter and record their data (activity, health and symptoms) on a regular basis (e.g. every day). Alternatively, the patient may request to use the service (App) to record data (e.g., symptoms) during a visit to his/her clinician and/or medical facility. During or after the routine medical visit, the authorized clinician and/or medical facility will be able to access the patient’s EMR (or EHR) by connection to the Service and to an electronic record of the patient’s data, such as to an EMR compilation provided by any one of a number of potential software systems created for this purpose (e.g. EPIC™, Cerner, Allscripts™, Mosaiq™, Aria™, Meditech™, IKnowMed™, GE Centricity™, or AthenaHealth™ , OncoEMR™, EHR). ETpon the patient signing up for the Service, the Service can provide a software plugin (script, macro, or add-on) to the patient that is specific for the EMR, such as to the specific EMR vendor software being used by the clinician and/or medical facility. The plugin can integrate with the EMR vendor software, and generate an icon in a toolbar or menu of the EMR vendor software, and selection of the icon can activate the plugin. The clinician and/or medical facility can use the plugin to access patient data submitted by the patient, such as through the App and stored on the company system or Service.

ETpon activating or invoking the plugin, the plugin can generate a first encrypted token. According to an exemplary embodiment, the first encrypted token can include a“patient identifier” included in the patient’ s EMR (such as the patient’s Medical Record Number (MRN)), and an identifier of the clinician and/or medical facility (based on a logged-in profile of the clinician and/or medical facility created through the EMR vendor software (“clinician ID”)). According to an exemplary embodiment, the plugin can transmit a first encrypted token through a web browser on the health service system, to a URL stored in the plugin, where the URL is associated with the company system.

In response to receiving the first encrypted token, the Service can detect that the first encrypted token lacks a linking code. In some embodiments, the Service may also detect that no medical records are associated with the patient ID (the MRN), because the patient associated with the patient ID may not have uploaded any data (symptoms) yet. Detection by the Service of either of these two conditions can generate the linking code, the company system (“Service) can transmit the linking code to the health service system (e.g., the clinician provider, hospital, health care facility), and the clinician can receive the linking code through the web browser. The data received with the linking code through the web browser can include a web link for emailing the linking code or otherwise transmitting (SMS text, send directly to App) the linking code to the patient. According to an exemplary embodiment, the clinician can activate the link and transmit the linking code to the patient, and the patient can enter the linking code into the App, which results in presenting the terms of service and user agreement described above.

After the patient provides consent to allow the clinician (or health care facility, hospital) that sent the linking code, to see the patient’s data (such as data entered through the App), the patient and the clinician (and/or health care facility, hospital) can be linked. As shown the linking code can be included in every transmission from the App to the Service and from the health service system to the Service. According to an exemplary embodiment, the Service can reference the linking code to find the MRN (or other positive patient identifier) associated with the patient when the patient uploads data (new symptoms, activity or health data), and the Service can automatically update the Medical Record with the new data/symptoms. Furthermore, any time the clinician requests updated symptom/data information from the Service, the plugin can transmit the linking code to the Service. In some embodiments, the plugin can associate the patient ID with the linking code in a look-up table (LUT) so that anytime the clinician requests information about a patient by downloading an EMR, the plugin can reference the linking code in the LUT by referencing the patient identifier (ID) in the EMR.

Figure 3 illustrated an embodiment where a patient (5) enrolls in the Service (11). Figure 4 illustrates the embodiment where the patient (5) is already enrolled and continuously uploads new symptom/health data information (12).

According to the embodiment illustrated in Figure 4, the patient (5) can continuously upload symptom data (12) through the App to the Service. In some embodiments, the App can also communicate with a mobile device health repository (20), such as a wearable device, and the mobile device health repository can upload activity information about the patient and vital measurements (25), such as step count, distance run/walked, weight and heart rate. The App can upload the symptom information, activity information, and vital measurements to the Service (11) (with the linking code), and the Service can save the uploaded information in the patient’s EMR (30) based on the linking code. Like Figure 3, the flow can further include a clinician accessing a patient’s EMR through the EMR vendor software. In some embodiments, the EMR vendor software is not necessary, and the clinician can access the Service by navigating to a LIRE associated with the Service. In either embodiment, the browser can transmit a second encrypted token to the Service. The second encrypted token is similar to the first encrypted token except that the second encrypted token also includes the linking code because, in the flow illustrated in Figure 4, the clinician and the patient are already linked. In some embodiments, the linking code can be a number or identifier associated with a specific patient’s identifying number, such as the patient’s MRN.

In response to receiving the second encrypted token, the Service can respond with the patient’s medical information it received through the App, which can be in the form of symptom history graphs or textual information (see Figure 8A). According to an exemplary embodiment, the Service can transmit all data received including the most recent data received from the App, thereby ensuring that the doctor is looking at the patient’s real-time symptoms. If the clinician notices worsening conditions or concerning changes or fluctuations, the clinician can immediately prescribe remedial regiments or request that the patient visit the clinic immediately. The clinician and/or health care facility may also incorporate processes and alert systems to appropriately manage any adverse changes detected by a clinician from interpreting the patient data (e.g., informing a nurse navigator to call/contact a patient.). In some embodiments, the clinician can transmit a scheduled visit request through the browser, and the scheduled visit request can be transmitted to the App. In some embodiments, the App can generate a notification notifying the patient that the clinician has requested to see the patient as soon as possible. In some embodiments, the patient can schedule the visit through the App.

Figure 5 illustrates a flow similar to Figure 4, but with additional features. For example, Figure 5 illustrates that a clinician (1) can access the Service either through EMR vendor software or a web interface (35). Figure 5 also illustrates that the Service can store diagnosis information, treatment information, and appointments stored in the EMR. Furthermore, Figure 5 illustrates that the App can receive symptom entry reminders from the Service and display diagnosis and treatment timelines.

Figure 6 generally illustrates the flow of Figures 2-5 as a method. For example, a clinician can launch the plugin through EMR vendor software while viewing the patient’s EMR. In response, the plugin can generate the decoding token and the LIRE in the form of an authentication link, and the plugin transmits the authentication link through a web browser. Upon receiving the authentication link, the Service can determine whether or not the clinician has a linking code for the patient. If the clinician does not have a linking code, the Service can generate and display an enrollment screen (See Figures 7A-7C) through the web browser and can generate a linking code, which can be transmitted to the patient through a communication medium (e.g. email). Upon receiving the linking code from the clinician, the patient can enter the linking code into the App (see Figure 8B), and the App can generate and display informed disclosure terms (see Figure 8C), which can explain how the data submitted will be used and protected. Upon receiving consent from the patient (see Figure 8D), the clinician and the patient can be linked, the patient can enter symptoms into the App (see Figure 8E), and the clinician can view the patient’s symptom data (see Figure 8 A).

If the patient ever wishes to revoke the clinician’s access to the patient’s medical data (for example, if the patient changes doctors), the patient can revoke the clinician’s access using the App (see Figure 8F-8G).

In some embodiments, for additional security, the Service may request a second layer of authentication from the clinician to view the patient’s data. For example, after receiving the decoding token, the Service may request, through the web browser, an additional piece of information about the patient to ensure that the clinician should have access to the patient’s data. (Figure 1). For example, the second piece of data can be the patient’s date of birth, social security number, or diagnosed medical condition.

In some embodiments, the Service can generate alerts or notifications to the clinician upon detecting a serious change in medical condition. For example, if a symptom changes from a 1 (mild discomfort) to a 10 (unbearable discomfort) in a relatively short period of time (e.g. 24- 48 hours), the Service can alert the clinician of the major change. The alert may be an email, an alert generated through the EMR vendor software, or a message sent to a mobile device associated with the clinician.

The present application presents a substantial advancement over the prior art because the present application results in reduced health care costs, increased patient satisfaction and quality of life, and increased patient survival and life span. Furthermore, there is a greatly improved percentage of patient compliance with treatment regimens, as well as with completion of treatment regimens (reduced patient“leakage”, less than 10%). The feed-back loop between clinician and patient also reduces the incidence and development of life-threatening adverse effects to the patient. Quality of care is improved for patients between clinic visits without having to travel to a physician’s clinic or office. And finally, the present system/method/application provides the technical implementation required to securely protect the protected health information and other private medical information of the patient through a linking process having a linking code and a decoding process of a decoding token.

Although a few embodiments have been described in detail above, other modifications are possible. For example, the logic flows described above do not require the particular order described or sequential order to achieve desirable results. Other steps may be provided, steps may be eliminated from the described flows, and other components may be added to or removed from the described systems. Other embodiments may be within the scope of the invention.

The following examples are provided in order to demonstrate and further illustrate certain embodiments and aspects of the present invention and are not to be construed as limiting the scope of the system or methods, or any other aspect of the invention.

Example 1 - Patient User Journey

The present example presents an example of the present system as used by a patient, such as a patient that is under the ongoing supervision of a clinician or other type of patient that would benefit from an ability to record their own symptoms contemporaneously without the need to visit a clinician’s office or make a hospital visit.

The first step for such a patient would be for the patient to download the electronic application of the present system (the“App”), onto their electronic device (e.g., smart phone, iPhone, tablet, iPad). Next, a clinician or medical health facility /hospital/skilled care facility that has been authenticated by the system as described herein would send electronically to the patient a“pairing code”. The patient, upon receiving the pairing code, would input the code into their mobile device ant the proper screen prompt. The patient would then be presented with an “Informed Consent” screen to approve or to not approve. Upon entry of an“approve” response by the patient, the patient may begin to record their symptoms as described herein into the appropriate screen(s), and this information will be simultaneously included in the patient’s electronic medical record (EMR) and/or electronic health record (EHR). Example 2 - Clinician User Journey (ClinicianLink™)

The present example presents an example of the present system as used by a clinician, or other health care provider, such as a nurse, physician’s assistant, physical therapist, nursing home attendant, or other skilled or semi-skilled heath care provider whose care a patient would benefit from with knowledge of the transmitted and recorded symptom and health data / information of the patient.

Clinicians can view conventionally recorded symptom information of a patient, such as that recorded at an in office visit, on an electronic device. However, clinicians are not able to access simultaneously electronically recorded symptom information being recorded by an individual patient on the clinician’s electronic device. The example presents a Clinician View application of the present systems and methods that provides for this access.

The Clinician View is used by clinicians and other health care providers having the appropriate access credentialing and verification (encrypted tokens) through the system, to gain valuable insights into their patients, and to detect worsening symptoms early in development. This real-time detection and assessment of symptoms and side-effects provides an opportunity for clinicians to intervene earlier between clinic visits, as well as to prevent unnecessary clinician or hospital visits. The patient’s quality of life is also significantly improved, as early detection prevents escalation to catastrophic, fatal results in the patient, and reduces the inconvenience and cost of frequent clinician/hospital visits.

The Steps for the implementation of the Clinician User method and system includes the following:

1. Integration into an electronic medical records system workflow. An example of an electronic medical records software system is EPIC™. As an example, the Clinician View system will therefore be integrated into an electronic medical records workflow for clinicians to view the patient’s symptom tracking profiles. To achieve this, a decoding token will be sent by the electronic medical records software system (or other system) as part of the URL which is used to launch the Service (e.g., CancerAid™ ) interface.

2. Authentication of clinician and patient. Each patient’s electronic medical record (EMR), that is a patient from a particular medical facility or clinician’s practice, will launch the Service (CancerAid™) Clinician View in a“Hyperspace View”. This will appear in a browser window with a token provided from the electronic medical record software. The token will be used to determine the currently logged-in clinician use and the appropriate patient’s medical record.

3. Service“Button”

The Service (CancerAid™ service) will provide the clinician’s practice, medical facility, or medical facility team with the specific requirements for a“button” that will be needed to launch Service (CancerAid™) to the electronic medical records software system.

4. Patient enrollment and onboarding. Each clinician’s and/or medical facilities patient will need to be linked in as a specific identifiable System user (i.e., a CancerAid™ user, patient), by a positive identifier for that user, such as a patient’s medical record number (MRN).

Each time a new patient from the medical facility of clinician’s practice is on boarded, the clinician user will be provided with instructions for enrollment of the new patient. The clinician user will also be provided with a linking code, this linking code to be sent to the patient for the patient to enter into the patient’s user device in the System (CancerAid™) App. This will be used to facilitate the linking of the patient user and the patient’s appropriate MRN.

5. Allow Clinician View enrollment in App. An interface will be developed within the System (CancerAid™) App to allow clinician users and/or medical facility, payor, or other authorized user, to input a linking code. Along with the linking code, a prompt may also optionally be included for the clinician and/or other authorized user to enter a second data input (e.g., DOB (date of birth)), to assist with linking the appropriate accounts together.

6. Display terms and conditions for informed consent. To facilitate informed consent for a particular group of physician’s patients or medical facilities patients, a specific Terms and Conditions screen may be prepared and presented to that identified patient and the patients that make up a specific patient group. The Terms and Conditions will be fashioned according to the needs and requirements of the clinician and/or facility.

7. Add Clinician View (ClinicianLink™) onboarding to In-App onboarding. A revised onboarding experience may be provided to patients that may also include a process to link with the System (CancerAid™) Clinician View. This may be provided in the form of a revised sign up process for existing patient users. 8. Clinician View Interface. An interface within the medical records software on which a clinician is able to view symptom data is also provided as part of the present system and methods. In one embodiment, the Clinician View interface is referred to as ClinicianLink™.

From the foregoing, it will be observed that numerous variations and modifications may be effected without departing from the spirit and scope of the invention. It is to be understood that no limitation with respect to the specific system or method described herein is intended or should be inferred. It is, of course, intended to cover all such modifications as fall within the spirit and scope of the invention.

Claims

CLAIMS We Claim:

1. A method comprising:

receiving patient data into a first device;

receiving a decoding token from a second device, wherein the decoding token comprises a linking code; and

transmitting the patient data to the second device in response to the linking code, wherein the linking code identifies a patient associated with the patient data received.

2. The method of claim 1 wherein the second device is the device of an authorized recipient associated with the identified patient.

3. A method comprising:

receiving a decoding token from a first device, wherein the decoding token comprises an identifier for an authorized recipient of data from a specific patient;

generating a linking code associated with the specific patient; transmitting the linking code to the first device;

receiving a notification that a second device identified with the specific patient has entered the linking code;

receiving data from the specific patient into the second device; and transmitting the patient data to the first device.

4. The method of claim 3 wherein the first device is a device of an identified clinician or facility.

5. A method for transmitting and receiving patient data according to any method described herein.

6. A system for transmitting and receiving patient data according to any system described herein.