HEALTHCARE-ACTIVITY TRIGGERED DATA MANAGEMENT

CROSS-REFERENCE TO RELATED APPLICATION

Priority is claimed to European Patent Application No. EP 22183873.3, filed on Jul. 8, 2022, the entire disclosure of which is hereby incorporated by reference herein.

TECHNICAL FIELD

The present application relates to a computer-implemented method and a healthcare-data-management system for healthcare-activity triggered data management.

BACKGROUND

With the advent of distributed ledgers (DL) and the blockchain (BC) technology, a trusted, because transparent, data-storage system was developed, allowing to exchange a variety of digital assets without any central counterparty. Digital assets such as cryptocurrencies or non-fungible tokens (NFTs) have a huge variety of use cases and are expected to have serious impact on current-day finance, payment infrastructures, gaming, or art. One of the most intriguing applications of BC technology is the unique opportunity to create immutable data objects allowing to transparently verify track records, identify ownership, and verify authenticity of digital assets and real-world assets linked thereto. Inherently, BC technology allows to keep track of any minted data objects so that ownership or user rights can clearly be determined and assigned.

New technological developments within the BC infrastructure allowed to fully integrate executable code embedded on BCs, which marked a major step forward toward fully decentralized financial infrastructures. For example, the Ethereum BC was one of the first frameworks providing the integration of on-chain executable code. Such smart contracts provide the unique feature to perform autonomous transaction of digital assets or minted data objects forgery-proof secured by BC technology. With smart contracts all counterparties have the guarantee that essential data transactions are indeed performed if the underlying conditions are met.

In the healthcare sector, on the other hand, trusted and secure data transactions as well as tamper-proof documentations are key to comply with regulatory standards and perform both safe and effective medical treatments. However, tamper-proof documentation of classical data systems is usually not guaranteed. Moreover, since patients that receive medical therapy often interrupt, change, or terminate their prescribed treatments or drug dosage due to the additional burdens accompanied with such medical interventions, tamper-proof documentations of treatments and drug intakes is advantageous to guarantee successful therapies. The worsening of the patient's health condition as well as a loss in the quality of life are only two severe consequences for patients due to non-adherence to medical therapies. Incentives such as monetary compensations for adherence can support patients to better adhere to their life-saving treatment and medications.

For any compensation system, however, safe, secure, and reliable data-transfer technology is advantageous. Moreover, strict local data-protection standards usually require the handling of medical data such as patient data with utmost care. For example, any usage or exploitation of patient data usually requires the patient's consent.

SUMMARY

In an exemplary embodiment, the present application provides a computer-implemented method for verifiably controlling data transfers. The method includes: retrieving, by a healthcare-data-management system, interaction data associated with a user from a first reinforced-protection database, wherein the interaction data includes data of an interaction between the user and a healthcare system; generating, by the healthcare-data-management system, an activity gauge associated with the user at least partly based on the interaction data; retrieving, by the healthcare-data-management system, requirement data from the first reinforced-protection database and/or a second reinforced-protection database, wherein the requirement data includes information related to performance of a user procedure associated with a data transfer based on the activity gauge; and performing and/or triggering performance of the user procedure based on the activity gauge.

In a further exemplary embodiment, the first reinforced-protection database and/or the second reinforced-protection database comprise a distributed ledger.

In a further exemplary embodiment, the distributed ledger comprises a blockchain-type data system and/or a directed-acyclic-graph-type data system.

In a further exemplary embodiment, performing and/or triggering performance of the user procedure generates triggering data, wherein the triggering data and/or log data thereof are stored on the first reinforced-protection database and/or second reinforced-protection database.

In a further exemplary embodiment, performing and/or triggering performance of the user procedure is implemented as a smart contract on the first reinforced-protection database.

In a further exemplary embodiment, the interaction data are derived by sensing and/or acquiring logging data, health data, omics data, healthcare-system data, adherence data, and/or treatment data.

In a further exemplary embodiment, the activity gauge includes a discount factor.

In a further exemplary embodiment, the generated activity gauge comprises a multi-dimensional activity gauge.

In a further exemplary embodiment, the generated activity gauge comprises a quantity gauge.

In a further exemplary embodiment, performing and/or triggering performance of the user procedure is conditional on characteristics of the quantity gauge.

In a further exemplary embodiment, the generated activity gauge comprises a separate quantity gauge for each data category of the interaction data.

In a further exemplary embodiment, performing and/or triggering performance of the user procedure is conditional on characteristics of the separate quantity gauge(s).

In a further exemplary embodiment, the first reinforced-protection database is configured to: read the interaction data; or receive the interaction data from an external device and store the interaction data.

In another exemplary embodiment, the present application provides a non-transitory computer-readable medium having processor-executable instructions stored thereon for verifiably controlling data transfers. The processor-executable instructions, when executed, facilitate performance of the following: retrieving, by a healthcare-data-management system, interaction data associated with a user from a first reinforced-protection database, wherein the interaction data includes data of an interaction between the user and a healthcare system; generating, by the healthcare-data-management system, an activity gauge associated with the user at least partly based on the interaction data; retrieving, by the healthcare-data-management system, requirement data from the first reinforced-protection database and/or a second reinforced-protection database, wherein the requirement data includes information related to performance of a user procedure associated with a data transfer based on the activity gauge; and performing and/or triggering performance of the user procedure based on the activity gauge.

In a further exemplary embodiment, the first reinforced-protection database and/or the second reinforced-protection database comprise a distributed ledger.

In a further exemplary embodiment, performing and/or triggering performance of the user procedure is implemented as a smart contract on the first reinforced-protection database.

In a further exemplary embodiment, the interaction data are derived by sensing and/or acquiring logging data, health data, omics data, healthcare-system data, adherence data, and/or treatment data.

In yet another exemplary embodiment, the present application provides a system. The system includes: a first reinforced-protection database configured to store interaction data associated with a user, wherein the interaction data includes data of an interaction between the user and a healthcare system; and a healthcare-data-management system configured to: retrieve the interaction data from the first reinforced-protection database; generate an activity gauge associated with the user at least partly based on the interaction data; retrieve requirement data from the first reinforced-protection database and/or a second reinforced-protection database, wherein the requirement data includes information related to performance of a user procedure associated with a data transfer based on the activity gauge; and perform and/or triggering performance of the user procedure based on the activity gauge.

In a further exemplary embodiment, the first reinforced-protection database and/or the second reinforced-protection database comprise a distributed ledger.

BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary embodiments of the present application will be described in even greater detail below based on the exemplary figures. The application is not limited to the exemplary embodiments. All features described and/or illustrated herein can be used alone or combined in different combinations in embodiments of the application. Features and advantages of various embodiments of the present application will become apparent by reading the following detailed description with reference to the attached drawings which illustrate the following:

FIG. 1A depicts a block diagram of a system configured to execute a method according to an embodiment of the present application.

FIG. 1B depicts a method according to an embodiment of the present application.

FIG. 2 depicts a user procedure according to an embodiment of the present application.

FIG. 3A depicts an example of an activity gauge according to an embodiment of the present application.

FIG. 3B shows another example of an activity gauge according to an embodiment of the present application.

FIG. 3C shows another example of an activity gauge according to an embodiment of the present application.

FIG. 3D shows another example of an activity gauge according to an embodiment of the present application.

FIG. 3E shows an example of a multi-dimensional activity gauge according to an embodiment of the present application.

FIG. 4 shows an example of a quantity gauge according to an embodiment of the present application.

DETAILED DESCRIPTION

Exemplary embodiments of the present application provide data systems which are secure-by-design and forgery-proof, and which allow patients or other users to take full control of their data, for example in situations where patients become unable to express their will anymore (e.g., after leaving a healthcare program or even after death.

Exemplary embodiments of the present application include a computer-implemented method for verifiably controlling data transfers, a computer program, a computer-readable medium, and a healthcare-data-management system for verifiably controlling data transfers.

In an exemplary embodiment, the present application provides a computer-implemented method comprising the step of retrieving interaction data associated with a user from a first reinforced-protection database. Hereby, the interaction data include data of an interaction between a user and a healthcare system. The method further comprises the steps of generating an activity gauge associated with the user at least partly based on the interaction data, retrieving requirement data from the first and/or a second reinforced-protection database, wherein requirement data include information related to the performing of a user procedure associated with a data transfer depending on the activity gauge, and performing and/or triggering the performing of the user procedure depending on the activity gauge.

In another exemplary embodiment, the present application provides a computer program comprising instructions which, when the program is executed by a computing device, cause the computing device to carry out a method according the present application.

In yet another exemplary embodiment, the present application provides a computer-readable medium having stored thereon a computer program.

In yet another exemplary embodiment, the present application provides a healthcare-data-management system for verifiably controlling data transfers, comprising a data acquisition unit configured to acquire interaction data including data of an interaction between a user and a healthcare system. The healthcare-data-management system further comprises a communication interface configured to exchange the interaction data with a first reinforced-protection database and/or with a second reinforced-protection database, wherein the healthcare-data-management system is configured to generate an activity gauge at least partly based on the interaction data, retrieve requirement data from the first and/or second reinforced-protection database, wherein the requirement data include information related to the performing of a user procedure associated with a data transfer depending on the activity gauge, and perform and/or trigger the performing of the user procedure depending on the activity gauge.

It will be appreciated that the execution of the various machine-implemented processes and steps described herein may occur via the execution, by one or more respective processors, of processor-executable instructions stored on one or more tangible, non-transitory computer-readable mediums (such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), and/or another electronic memory mechanism). Thus, for example, operations performed by respective units or components discussed herein may be carried out according to instructions stored on one or more non-transitory computer-readable mediums and/or applications installed on one or more respective computing devices.

FIG. 1A depicts a reinforced-protection database 1000, a healthcare-data-management system 1005, and external devices 1007, 1009 as part of a system (FIG. 1A), wherein the system is configured to execute a method according to the present application. The reinforced-protection database 1000 comprises reinforced-protection-database nodes, wherein the reinforced-protection-database nodes include a DL 1001 and a secured central server 1003, wherein the DL 1001 and the secured central sever 1003 can exchange data 1002 via bidirectional communication connection. Reinforced-protection-database nodes can include a server or computing unit configured to exchange and store data and be configured to set up the reinforced-protection database 1000. Moreover, the reinforced-protection database 1000, the healthcare-data-management system 1005, and the external devices 1007, 1009 comprise unidirectional or bidirectional communication interfaces configured to exchange data 1004, 1006, 1008 with the reinforced-protection database 1000.

The reinforced-protection database 1000 can be a database including tamper-proof technologies for preventing unauthorized data access or data manipulation. Such a reinforced-protection database can include more than a single security technology to provide multiple layers of state-of-the-art security measures to protect sensitive data. The multiple layers of security measures can comprise software measures and/or hardware measures for providing data integrity and data security. For example, software measures can include state-of-the-art user authorization, user identification, ledger-type data architecture, and/or zero-trust software architecture. Hardware measures can include authorization/identification tokens, storage devices, or computing devices having reinforced security measures to protect the stored, processed, and/or transferred sensitive data.

The healthcare-data-management system 1005 and the external devices 1007, 1009 can also exchange data between each other, e.g., to improve treatments with healthcare devices which can be comprised in the healthcare-data-management system by correlating user data collected from data acquisition units like sensors integrated in the external device or healthcare devices with data from the respective treatment system, e.g., to control a treatment regimen wherein the collected data are exchanged with the reinforced-protection database 1000. The manner of communication can include communication technologies such as Ethernet, 5G, Wi-Fi, radio, or fiber-optic communication.

Healthcare-data-management system 1005 can communicate with healthcare systems such as treatment systems, e.g., dialysis systems, infusion systems, radiation-treatment systems and the like. Healthcare systems can also include or can communicate with examination systems, e.g., computer or magnetic-resonance tomography, or computer systems configured to manage and store electronic medical records, e.g., Electronic-Health Record (EHR) systems, or computer systems configured to generate, exchange, and manage medical prescriptions. Healthcare-data-management system 1005 or other healthcare systems can also comprise computing units for managing patients, hospitals, clinicians, or health data. The healthcare-data-management system 1005 or other healthcare systems can further comprise a data acquisition unit, e.g., a sensor for measuring patient vitals like blood pressure, wherein the data acquisition unit is configured to acquire interaction data of a user, wherein the interaction data include data of an interaction between a user and a healthcare system. An interaction in the sense of the present application can, e.g., include a treatment that a user receives from a healthcare system, a user operating a healthcare-data-management system 1005 or healthcare system to treat another user/patient, or a user-vitals measurement via a medical device like a blood-pressure monitor as a part of a healthcare system. The healthcare-data-management system can also comprise a communication interface for exchanging data with a reinforced-protection database, healthcare system, external device, and/or computing unit.

External devices 1007, 1009 can include external user devices, e.g., tablets, smartphones, or computers. Further external devices can include wearable electronics, e.g., smartwatches, to monitor user habits and/or user health in real time. A user can be a person who uses or interacts with a healthcare system including patients or healthcare professionals such as nurses and doctors. A user can also be an entity such as a healthcare provider, an insurance company, an external investor, or a medical-technology company.

The reinforced-protection database 1000 is configured to store requirement data and interaction data, wherein the interaction data and requirement data can be exchanged with the reinforced-protection database 1000. Interaction data can include various sorts of data related to a user interaction with a healthcare system. Requirement data can include various sorts of user procedures, wherein the performing or triggering the performing of the user procedures depend on a preconfigured conditional expression, e.g., written in a program language, and stored on the reinforced-protection database 1000. In one example, requirement data and interaction data are exclusively stored on the DL 1001 or the secured server 1003. In another example the requirement data and the interaction data are distributed between both data storages 1001, 1003 or, in general, the requirement data and the interaction data are distributed between more than one reinforced-protection database. Distributing certain data between the DL 1001 and the secured server 1003 or a plurality of reinforced-protection databases is technically advantageous since at least a fraction of sensitive data, e.g., as patient data, is non-accessible for public users. Since several reinforced-protection databases may have different security levels, more sensitive interaction data or requirement data can be separately stored on reinforced-protection databases having more and/or different manners of protection. For example, this can include additional authentication steps, authentication tokens, or improved encryption and security standards.

The DL 1001 can be a peer-to-peer-type network comprising a plurality of nodes, e.g., servers, computers, or smartphones, having communication interfaces for exchanging data with other nodes of the network. All nodes within the DL comprise storage, whereby the nodes store a copy of the DL's data records. Storage can include a hard-disc drive (HDD), solid-state drive, or other data-storage mediums. For new data records, e.g., a data record of a digital-asset transfer between two nodes within the DL, the other nodes of the DL verify the new data records and align to a new state of the DL via a consensus protocol.

Consensus protocols are utilized to verify data transfers on a DL and prevent single nodes of a user within the network from altering data records in its favor. Therefore, DLs are usually considered as highly manipulation-resistant and can be one example of a reinforced-protection database. Potential attackers would require unreasonable amounts of resources for altering the DLs data records. A plurality of consensus protocols is known in the state of the art including Proof of Work (PoW), Proof of Stake (PoS), Proof of Space (PoSpace), or Proof of Elapsed Time (PoET). Prominent examples of data systems on the DL can be used for storing data records including Blockchain-type (BC) or Directed-Acyclic-Graph-type (DAG) data systems. In contrast to BC-type data systems, the structure underlying DAG-type data systems have vertices and edges for recording transactions between various counterparties. Due to this tree-type structure, DAGs potentially provide faster, more energy-efficient, and cheaper transactions compared to common BC-type data systems.

DLs can be publicly available or private so that access is only granted to specific user groups. For example, manners of authentication and identification such as alphanumerical passphrases, identification cards, gestures, or biometrics like fingerprints are required to get access to private DLs. DLs can also be semi-private so that users or user groups can have different permission levels to view, modify, or exchange data records. User groups can be a subgroup of users like patients, doctors, nurses, or external stakeholder like healthcare companies, insurance companies, or private investors having different permission levels on the DL.

Examples for known DLs in the state of the art are Bitcoin and Ethereum DLs using PoW as the consensus protocol of choice. Bitcoin and Ethereum DLs are frequently used for securely trading virtual assets like crypto currencies or NFTs.

The reinforced-protection database 1000 further comprises a secured server 1003. A secured server can be a server, computing unit, or private network system with restricted availability and/or access for different user groups. For example, accessing the secured server via a computer may only be possible within a specific local-area networks (LAN) or virtual-private networks (VPN). Access to the secured server can be limited via identification and authentication technologies, which can include alphanumeric passphrases, authentication tokens like ID cards, gestures, or biometrics like fingerprints.

The secured server 1003 can store sensitive data records, which shall only be shared with specific nodes of the DL 1001. Examples for such sensitive records can include sensitive patient data, payment data, or other data types, which shall not be stored on publicly accessible DLs. The secured server can also be optional if, e.g., a private DL is integrated within the DL 1001. Therefore, the reinforced-protection database 1000 may only comprise a DL 1001 without the secured server 1003, or vice versa, e.g., to reduce the required amount of hardware resources. In such a case, accessing sensitive data on the private DL requires authentication and identification of the user as it is the case for the secured server 1003.

For enhancing data safety on the reinforced-protection database 1000, in one aspect, multi-factor authentication (MFA) can be used for accessing data records and/or modifying data records on the reinforced-protection database 1000, i.e., on the DL 1001 and/or the secure server 1003. MFA can comprise a combination of entering a passphrase on a computer and an additional external device such as a user smartphone or a transaction-number (TAN) generator. For example, in response to a log-in attempt of a user with a computer, an alphanumeric code is sent to the user's smartphone, wherein the alphanumeric code is required to get access to the reinforced-protection database 1000 with the computer.

Data records can also be stored as an information-reduced data object on the reinforced-protection database 1000. Instead of storing sensitive patient data as a plain-text data object or as an encrypted plain-text data object, an information-reduced data object is generated from the plain-text data object. For example, a hash-type data object or an anonymized data object is stored on the reinforced-protection database 1000. Hash functions such as Secure Hash Algorithm (SHA) take input values, e.g., sensitive patient data such as patient name, age, or sex, and map the sensitive data onto an alphanumeric and/or symbolic hashed value. Starting from the hashed value, it is impossible to extract the input value, i.e., initial plain-text data object. However, with the knowledge of the initial plain-text data object and the corresponding hash function the hashed value can be reproduced. Sensitive plain-text data objects can securely be stored on the secured server 1003 or another server external to the reinforced-protection database 1000.

Data records can also be encrypted and divided in data chunks, wherein the data chunks are distributed on more than a single database such as a DL or a secured server. One single data chunk, i.e., a fraction of the originally encrypted data record, cannot be used to extract information of the original data record. The recovering of the originally stored information requires all data chunks, such as described in International Patent Publication No. WO2021/083861, which is incorporated by reference herein.

FIG. 1B provides an illustration of a method according to the present application. The interaction data IDat 1100 comprises at least some data of a user interaction with a healthcare system, e.g., health data, omics data, or treatment data. The interaction data can be recorded via a data acquisition unit from an external device 1007, 1009, a healthcare system, or a healthcare-data-management system 1005 and stored at least partly on the reinforced-protection database 1000 as shown in FIG. 1A. The healthcare-data-management system may also comprise a subsystem like healthcare systems, and/or external devices comprising data acquisition units, wherein the subsystems may also be configured to generate interaction data via a respective data acquisition unit.

From the interaction data IDat 1100, at least a fraction of the stored interaction data is extracted for generating 1101 an activity gauge 1102. An activity gauge can be a measure, e.g., a single number or a plurality of numbers, wherein the measure quantifies a user's activity based on the interaction data IDat 1100 as recorded within the system as shown in FIG. 1A. Generating the activity gauge 1102 from the interaction data IDat 1100 can include a mathematical algorithm taking the recorded interaction data IDat 1100 as an input and mapping the interaction data on said measure using a predefined algorithm. For example, an algorithm may add, depending on the type of interaction data, a number of activity points to an activity account of a user, wherein the number of activity points would be the activity gauge of the respective user. Therefore, the user's interaction data would be transformed into a quantitative measure.

The generation 1101 of the activity gauge 1102 from the interaction data IDat 1100 can be performed on a computing unit, wherein the computing unit can be located either on the reinforced-protection database or an external computing device having a communication interface for exchanging data with the reinforced-protection database, the healthcare-data-management system and/or another healthcare system. Preferably, the activity gauge is a function of time A(t) 1102 or varies over time. In such case, the real-time activity gauge is a numerical representation of a user's current activity or the activity within an arbitrary time period. With that, the activity gauge 1102 can further be used to detect critical health conditions or unhealthy user behaviors just in time. For example, an emergency notification may be sent to a healthcare provider and/or the user if the activity gauge undercuts a critical activity-gauge threshold or remains within a critical activity-gauge interval or domain for a predefined/critical time period.

The interaction data 1100 can comprise a plurality of different data categories. For example, interaction data 1100 can comprise logging data, health data, omics data, healthcare-system data, adherence data, and/or treatment data. In general, interaction data 1100 can include data records associated with a user of a user group interacting with a healthcare system. For instance, interaction data can also comprise interactions of healthcare professionals such as nurses or doctors with a healthcare system to monitor their performance with respective performance metrics for assessing, e.g., the quality of care.

Logging data can comprise data records associated with user activities on online platforms or health applications, accessed via a user's external device, e.g., a smartphone or computer. In one example, the number of logins on an online platform for users is counted, or how often a user requests information from a health application. A health application can be a computer program which supports, patients, e.g., to live healthier lives by providing lifestyle recommendation like cooking recipes or workout advices. Logging data can also comprise data records of verifiable patient participation at an examination, treatment, or health teaching. Logging data can also comprise activity data of healthcare professional interacting with a healthcare system, e.g., treating or examining a patient with the healthcare system. Keeping track of logging data provides frequent data records so that a user's activity can be monitored within comparably short time scales.

Health data can comprise data records associated with a user's health, such as patient vitals, e.g., blood pressure, heart rate, data of blood screenings, and/or data regarding pre-existing and present diseases as well as treatment plans, or examination data. Health data can also comprise personal information of a user such as name, age, or sex.

Omics data can comprise data records associated with genomics, proteomics, metabolomics, metagenomics and transcriptomics of a user. For example, omics data can include epigenomics data of patients or relatives, e.g., for root-cause investigations regarding chronic diseases such as chronic kidney disease.

Healthcare-system data can comprise data records regarding the set-up or the maintenance of a healthcare system. Set-up or maintenance data can comprise data related to the interaction of a user and a healthcare system aside from usual treatments, e.g., data records verifying a correct device set-up. Healthcare-system data can also comprise data concerning technical status, e.g., data records regarding changed or repaired healthcare-system components or conducted functionality tests.

Adherence data can comprise data which verify correct application and dosing, i.e., as prescribed in quantity, quality, frequency, etc., of drugs, medical agents, or medical liquids. For example, various technologies for monitoring patient adherence are known in the art such as drug-ingestion tracking based on images or videos of a patient captured via a user device.

Treatment data comprise data aggregated from users during a medical treatment. For example, treatment data can include data such as medical-device-configuration data, patient-vitals data, or data related to treatment events. For example, medical-device-configuration data can comprise treatment pre-settings according to a treatment prescription such as a volume of dialysate used during a dialysis treatment. Patient-vitals data can include all recorded/measured/deduced patient vitals before, during, or after a treatment such as blood pressure, body temperature, or pulse rate. Data related to treatment events can be events which occurred during a treatment session such as treatment interruptions, e.g., due to device errors, warnings, or medical incidents.

In general, the various types of interaction data 1100 allow to monitor deviations from usual user behavior or healthcare-system behavior. Therefore, interaction data 1000 or the activity gauge 1102 as generated from the interaction data can be used, e.g., to anticipate a risk for adverse health events for a patient, like strokes, heart attacks, or acute renal diseases. In one aspect, a decrease or altered pattern of the activity gauge 1102 indicates an adverse health event for the respective user, wherein in response to determining that an adverse health event is expected to occur, an appropriate preconfigured user procedure is performed or triggered for performing. A preconfigured user procedure can be a user procedure which can only be modified by authorized user groups. Authorized user groups such as health-care professionals or healthcare companies can upload said preconfigured user procedures to the requirement data stored on the reinforced-protection database. A preconfigured user procedure can comprise first-aid suggestions or further information being sent to a patient, e.g., in response to determining a low activity gauge, so that the adverse health event is prevented. For example, it is detected that the activity gauge falls below a critical threshold because of missing/insufficient provided interaction data. Due to preconfigured requirement data, a user procedure may then be triggered, wherein the user procedure can comprise a message sent to the respective patient/user and/or the patient's healthcare provider wherein the message may include an activity request, e.g., for the patient/user to respond to the respective message or to log in on a patient web portal, and/or the respective healthcare provider to contact the patient due to an expected emergency or inferred hazardous situation for the patient.

The reinforced-protection database 1000 of FIG. 1A further stores requirement data 1104. Requirement data 1104 comprise requirements, e.g., conditional expressions C preferably in a program language for performing or triggering a performing of a user procedure U. In one example, a requirement is a threshold value for the activity gauge 1102 below or above which a user procedure U is performed or the performing of the user procedure U is triggered. A requirement can also be an interval of the activity gauge 1102 inside or outside said interval a user procedure U is performed. A user procedure U can be an operation on a set of data, e.g., a transfer of data between one or more users. For example, transferred data can comprise virtual assets like non-fungible tokens (NFTs) or notifications transferred to users, wherein said data transfer is triggered in case that an associated requirement is fulfilled, e.g., the activity gauge falls below one or a plurality of activity-gauge thresholds Ai.

The requirement data 1104 can be created or modified by authorized users or user groups having access to the reinforced-protection database of FIG. 1A1000, e.g., via an external device. Modifying requirement data 1104 can include that a user defines that a user procedure U is performed, or the performing is triggered, if the user's activity gauge 1102 undercuts/exceeds one or more critical values, e.g., threshold values. For example, such critical values can be associated with a user inactiveness, e.g., a patient terminates a healthcare program due to an organ transplant or due to death. Allowing users to add and modify requirement data 1104 on the reinforced-protection database allows them to create immutable legacy-type data records. Immutable data records, e.g., based on distributed-ledger technology, including the seamless performing of preconfigured user procedures provides the unique technical advantage to create both trusted and secure digital legacies. Such records technically simplify post-mortem transfers of digital assets so that data losses and/or losses of valuable assets are prevented. As the data transaction to pre-determined heirs is guaranteed due to distributed-ledger technology, only authorized individuals, i.e., usually the user, have control of the plurality of the preconfigured data transactions of a user procedure U.

In one example, a patient-monitoring device connected to a user/patient is in communication with the healthcare system, the healthcare-data-management system and/or a reinforced-protection database. A patient-monitoring device can comprise a smartwatch, wristband, or a brain chip for providing real-time interaction data. For instance, the patient-monitoring device may continuously monitor patient vitals, e.g., heart rate, blood pressure, or brain waves, and transmit the acquired interaction data to the reinforced-protection database. An advantage of real-time monitoring is that deviation of the user's health can be detected immediately so that first-aid or life-saving medication can be provided to the patent in due time.

Moreover, the patient-monitoring device can also detect the death of a person in real time. With that, respective user procedures comprised within the requirement data can be triggered shortly after the death incident. Due to the short time period between a user incident, e.g., the user's death, and the triggering of a user procedure, possible fraud can be prevented since attackers trying to steal the user's digital assets have a much smaller time frame to exploit the user's decease.

From the stored requirement data 1104 and the generated activity gauge 1102, a computing unit monitors 1103 if at least one of the stored requirements within the requirement data 1104 is fulfilled. Upon determining that at least one requirement within the requirement data 1104 is fulfilled, i.e., the conditions C are met, the associated user procedure U is performed, or the performing is triggered by the computing unit. The computing unit can be part of the reinforced-protection database, e.g., a node of the DL or the secured server, of an external device, of a healthcare-data-management system or of a healthcare system, wherein the external device, the healthcare-data-management system, or the healthcare system is configured to exchange data with the reinforced-protection database.

In one aspect, the requirement data 1104 and/or the respective user procedures U can be configured as a smart contract on a DL. More advanced DLs, e.g., the Ethereum blockchain, allow the implementation of smart contracts. A smart contract, in a more generalized meaning, can also comprise executable code on the reinforced-protection database, wherein the executable code is performed and/or triggered for performing if a predefined condition is met. In this sense, a DL is not necessarily required to employ smart contracts. For example, if no DL is available, a secured server may also send, receive, store, and/or perform or trigger the performing of a smart contract. Smart contracts can perform a preconfigured directive if a set of conditions is fulfilled. For example, a smart contract can comprise code in a program language, e.g., a conditional data transfer between two or more parties based on an activity gauge, which can only be triggered if the conditions regarding a specific state of the activity gauge is fulfilled. For data records, which are not stored on the DL, but are required for performing the smart contract, blockchain oracles are known in the art and can be used to extract missing data records on the DL from external data sources such as external servers, external devices, or external sensors.

In another aspect of the present application, based on the performed user procedure U as part of the requirement data 1104, triggering data is generated and stored on the reinforced-protection database. Triggering data comprise information regarding the performing of the user procedure U. For example, triggering data can include status data comprising information whether a user procedure U, e.g., a data transfer between two or more users, was performed and whether such execution was successful, i.e., without errors. Triggering data can also comprise information about the users taking part in the performed user procedure or about the type of user procedure that was performed, e.g., a health advice was sent to a smartphone of a user as the user's activity gauge fall below some threshold limit.

Triggering data can further be encrypted and/or stored as an information-reduced data object on the reinforced-protection database. In one example, triggering data of sensitive data are fractionally stored on the DL and the secured server so that extracting the information of the respective triggering data requires all data fractions from the DL and the secured server.

In another example, a hashed value is generated from the triggering data and uploaded on the reinforced-protection database. The plaintext version of the triggering data remains on the secured server, a user's device, e.g., a smartphone, or another data storage. The hashed value works as a receipt or a checksum for users to proof that the respective user procedure associated with the triggering data was performed.

The illustrated technical features of FIG. 1A and FIG. 1B underlying the present application provide a secure and reliable manner to generate and perform data transfers. Due to the reinforced-protection database. e.g., based on DL technology, users of the system are assured that preconfigured data transfers are performed if the respective conditions are met. From the user's activity gauge generated from the provided interaction data, critical conditions of patients can be detected early and appropriate countermeasures can be performed. The technical problem of providing forgery-proof, patient-consent-management data platforms in compliance with data-protection regulations is solved by the technical features according to FIGS. 1A and 1B. Moreover, the DL technology further allows user-activity-dependent data transfers where patient take full control of their data.

FIG. 2 illustrates an exemplary user procedure 2003 depending on the activity gauge 1102 of FIG. 1B. A computing unit determines that at least some requirements for performing the user procedure 2003 of previously stored requirement data are fulfilled, e.g., a user's generated activity gauge fails to exceed a predefined threshold limit after a critical time t>te 2000. From the requirement data retrieved 2002 from the reinforced-protection database 2001, the user procedure 2003 is selected, and the triggering is performed by the computing unit. The user procedure 2003 includes a plurality of data transfers associated with digital assets 2005a, 2005b, 2005c, 2005d, wherein the digital assets are stored on a safe data storage 2004. The safe data storage can be part of the reinforced-protection database 2001 or an external data-storage device. In one example, a server stores the digital assets, and the server can be accessed from the information stored on the reinforced-protection database 2001. Such information can, e.g., comprise encrypted hash keys granting access to the digital assets 2005a, 2005b, 2005c, 2005d.

Digital assets 2005a, 2005b, 2005c, 2005d can be valuable data. In FIG. 2, the digital assets include patient data 2005a, digital tokens 2005b, user statistics 2005c, and digital contracts 2005d. Patient data 2005a can comprise patient-related data such as interaction data. Digital tokens 2005b can comprise fungible and/or non-fungible tokens having monetary value. User statistics 2005c can include behavioral user data, whereby the behavioral user data may not be part of the patient data 2005a, e.g., data records regarding the user's consumer behavior or the user's personal preferences or beliefs. Digital contracts 2005d can include conditional obligations, wherein the conditional obligations are performed or come into action in response to a user procedure 2003. Digital contracts 2005d can include one or more smart contracts, so that further data transfers or owner/user right transfers are performed, or their triggering is performed.

In response to performing the user procedure 2003, the digital assets can be distributed to a plurality of user/parties 2006a, 2006b, 2006c. The parties can be natural persons 2006a, 2006b, e.g., the rightful heirs of a deceased patient, or a corporate body such as a healthcare company 2006c or external investor. The different parties receive digital keys 2007a, 2007b, 2007c for accessing the digital assets on the safe data storage 2004. Depending on the user procedure 2003, in one aspect, the ownership or the digital assets or the digital-asset rights are either fully or partly transferred to the plurality of parties. For example, each party can receive a specific key, which only grants limited access to the set of data. The extent of the right transfer can be part of the user procedure 2003 and controlled, e.g., by regulation stored on the reinforced-protection database 2001. The modification/change of the ownership of the set of digital assets can be securely recorded 2002 on a blockchain-type data structure on the DL of the reinforced-protection database 2001.

In one aspect, the step of performing or triggering the performing of a user procedure generates triggering data, wherein triggering data and/or log data thereof are stored on a reinforced-protection database 2001. Triggering data can be data regarding the accomplished or not-accomplished user procedure 2003. For example, triggering data can include information about the transferred digital assets, information regarding the participating parties, or triggering-metadata. Triggering-metadata can include all data related to the actual user procedure, e.g., type of the user procedure, time, or transfer costs.

FIGS. 3A and 3B show an implementation of the activity gauge 1102 of FIG. 1B in case of an adherent patient (FIG. 3A) and a non-adherent patient (FIG. 3B). In this example, the activity gauge A is a numeric value as a function of time t. FIG. 3A and FIG. 3B further show a value of the activity gauge associated with no activity A=0 as well as a threshold value of the activity gauge A=Ac wherein a user procedure is performed or triggered for performing in case that the activity gauge undercuts the threshold value of the activity gauge Ac. Each of FIG. 3A and FIG. 3B illustrate a table, wherein the first row of each table eI includes expected interaction data at a given point in time (t1-t6) and wherein the second row of the matrix eI? includes a status, wherein the status determines whether the expected interaction data eI was provided at the given point in time and received by the reinforced-protection database, i.e., whether a user indeed performed a scheduled user interaction.

FIG. 3A illustrates an exemplary activity gauge of a perfect adherent user, e.g., a patient. At a starting point in time ts the user starts tracking the user's activity, e.g., by creating a user account for the respective system. From the provided interaction data, a finite activity gauge is determined via a mathematical algorithm. At the points in time t1-t4, treatments, e.g., dialysis treatments, are scheduled. The user perfectly adheres to the associated prescriptions and receives at each of the time points t1-t4 the user's treatment. Due to the perfect user adherence, the determined activity-gauge curve based on the provided interaction data, i.e., the expected treatment data, remains on a constant value. At the time point t5, the user is required to take drugs, e.g., renal drugs. The user verifies the intake of the drugs, e.g., by filming the drug intake or by providing corresponding vitals indicating the compliant user behavior. At the point in time t6, the user provides health data, e.g., a body-composition measurement based on bioimpedance spectroscopy. As the user adheres to the required prescriptions by providing the required interaction data at the points in time t5 and t6, the activity gauge remains on the constant value as of the previous time points t1-t4.

FIG. 3B illustrates an exemplary activity gauge of a non-perfectly adherent user. Comparable to the perfectly adherent patient as illustrated in FIG. 3A, the user starts to track the user's activity, e.g., by creating a user account for the respective system at a starting point in time ts. From the provided interaction data, a finite activity gauge is generated via a mathematical algorithm. At the points in time t1-t2, treatments, e.g., dialysis treatments, are scheduled. The user (FIG. 3A) adheres to the associated prescriptions and receives at each of the time points t1-t2 the user's treatment. Due to the user's adherence, the generated activity-gauge curve based on the provided interaction data, i.e., the expected treatment data, remains on a constant value. At the point in time t3, the user misses to adhere to the user's prescribed treatment. As no interaction data is provided at t3, the newly generated activity gauge at t3 is lower compared to the generated activity gauge at the point in time t2. Since the user missed the treatment for the first time, the activity gauge remains above the threshold Ac so that no user procedure is performed/triggered. At the point in time t4, the user again adheres to the prescribed treatment. Therefore, interaction data is provided from the treatment at t4 so that the generated activity gauge is reinstated to its value at the point in time t2. As the user further adheres to the required prescriptions by providing the required interaction data at the points in time t5 and t6, the activity gauge remains on the constant value as of the time points t1-t4.

FIGS. 3C and 3D show an implementation of the activity gauge 1102 of FIG. 1B in case of a mostly adherent patient (FIG. 3C) and a mostly non-adherent patient (FIG. 3D) whereby the activity gauge includes a discount factor. A discount factor can be an activity gauge that when added to a first activity gauge yields a second activity gauge wherein the second activity gauge is associated with a reduced or no activity of a user compared to the first activity gauge. In one example, the discount factor comprises a negative number of activity-gauge units in which the user's activity gauge is measured. The negative number of activity-gauge units is added to a first number of activity-gauge units if a user does not adhere to a prescribed treatment, i.e., the expected interaction data of the respective treatment are not received by the reinforced-protection database. With that, a second number of activity-gauge units is generated wherein the second number of activity-gauge units is associated with a lower user activity compared to the first number of activity-gauge units.

The discount factor can further be a function of time and/or a function of the expected but absent interaction data. For instance, the first activity gauge can be altered towards a second activity gauge associated with a lower activity if no interaction data is received by the reinforced-protection database within a predefined period of time, e.g., a first activity-gauge value is reduced by a fixed or variable activity-gauge value towards a second activity-gauge value associated with a lower user activity, each second/hour/day where no interaction data is received by the reinforced-protection database. The activity gauge can also be reduced in response to an expected interaction-data record not being received by the reinforced-protection database, e.g., a patient is non-adherent to a prescribed treatment.

In the example of FIGS. 3C and 3D, the activity gauge A is a numeric value as a function of time t and includes a discount factor. FIG. 3C and FIG. 3D show a value of the activity gauge associated with no activity A=0 as well as a threshold value of the activity gauge A=Ac wherein a user procedure is triggered in case that the activity gauge undercuts the threshold value of the activity gauge Ac. At each of the points in time ti, a user interaction of the user is recorded and received by the reinforced-protection database. From the received user interaction, an activity gauge is generated using a mathematical algorithm.

FIG. 3C illustrates an exemplary activity gauge of a mostly adherent user. The user starts to track the user's activity at a starting point in time ts when first interaction data, e.g., treatment data, are recorded and transmitted to the reinforced-protection database. As no interaction data is received between the points in time ts and t1, the activity gauge continuously decreases towards activity-gauge values associated with a lower user activity. At the point in time t1, the user generates logging data so that the value of the activity gauge is again increased towards higher activity-gauge values associated with a higher user activity. The pattern repeats itself for the depicted following points in time t2-t5. For the time period between the points in time t2 and t3, the user does not provide intermediary interaction data so that the activity gauge decreases towards values close to the threshold Ac. As the user provides interaction data, i.e., health data, at t3 a positive activity-gauge value is added to the current activity-gauge value yielding an activity gauge close to the peak of the curve at the point in time t2.

FIG. 3D illustrates an exemplary activity gauge of a mostly non-adherent user. The user starts to track the user's activity at a starting point in time ts when first interaction data, e.g., treatment data, are recorded and transmitted to the reinforced-protection database. As no interaction data is received between the points in time ts and t1, the activity gauge continuously decreases towards activity-gauge values associated with a lower user activity. At the point in time t1, the user provides logging data so that the generated activity gauge is shifted towards activity-gauge values associated with a higher user activity. For the time period between the points in time t1 and t2, the user does not provide intermediary interaction data so that the activity gauge decreases towards values close to the threshold Ac. At t2, the user provides logging data, shifting the activity gauge upwards towards higher activity-gauge values. Between the points in time t2 and to no more interaction data of the user is received. The activity-gauge curve undercuts the threshold limit Ac so that a predefined user procedure is performed, e.g., a reminder is sent to the user to adhere to the user's treatment prescription. As no further interaction is provided, the activity gauge falls to A=0.

In the examples of FIGS. 3C and 3D, the disclosed discount factor is a constant value with dimension activity-gauge per unit time, whereby the constant value is subtracted from the current activity-gauge value in each time step. In general, the discount factor is not limited to a constant value and can, e.g., also include more involved functional mappings such as exponential-type or power-law-type scaling behaviors. For example, an exponential mapping can sanction long-term inactivity, more strictly, compared to a linear scaling of the discount factor so that users are more motivated to stay compliant to their prescription. The discount factor can also depend on the absolute time since the starting time is and vary over the time. This might be advantageous for better incentivizing long-term users with a variable discount factor.

In one aspect, the discount factor relies on an artificial-intelligence model. Historical user behavior can be employed to train a neural network to optimize a reward function, e.g., to maximize the activity gauge. A combination of a variation of discount factors, threshold limits and associated user procedures can be used to generate a strategy for motivating a user to stay active and adhere to the user's prescriptions or tasks. Mathematical models which can be employed to optimize such strategies can be based on Markov-Decision Processes (MDPs) in the framework of reinforcement learning as it is known in the state of the art.

In one aspect, the step of generating an activity gauge relies on a mathematical algorithm. A mathematical algorithm can be a functional connection or transformation between the acquired input, i.e., the interaction data, and generated output, i.e., the activity gauge. The activity gauge reflecting a user's activity based on the user's provided interaction data can be an alphanumeric value, symbol, color, or other type of visual, acoustic, or haptic feedback on a user device, e.g., a smartphone, a healthcare system and/or a database.

In another aspect, the activity gauge includes a mathematical metric. In general, a mathematical metric allows measuring a distance within an abstract mathematical space, e.g., Euclidean metrics are examples for metrics frequently used in Euclidean space. The mathematical metric can be employed to determine a distance between two activity-gauge values. For example, a distance between a predefined threshold value below/above which a user procedure is performed, and the current activity gauge of a user as generated from the user's interaction data. An activity gauge can be a numerical object, e.g., a single number, for which a plurality of mathematical metrics like the absolute value are known. For higher-dimensional representations of activity gauges, e.g., a matrix including a plurality of numbers, a plurality of matrix norms or operator norms such as p-norms:

${ x }_{p} \equiv {(\sum_{i = 1}^{n} {❘ x_{i} ❘}^{p})}^{1 / p}$

are known in the state of the art.

For non-numerical activity gauges, a mathematical metric can be defined. In one example, an associated numerical representation of a non-numerical activity gauge, e.g., a symbol or a color, on a computer system is used, e.g., a hexadecimal number associated with the symbol or color, to define a respective mathematical metric. For example, information-technology standards such as Unicode provide alphanumeric representations of symbols so that mathematical metrics can be deduced based on such alphanumeric representations. A type of mathematical metric can also be defined based on the non-numerical hierarchy of activity-gauge values. For example, in case of a binary system, e.g., having an “active” and “inactive” state, a numerical object such as a “1” is associated with the “active” state where the “inactive” is associated with a “0”. For the so-deduced numerical objects, mathematical metrics known in the art can be applied.

In another aspect, the mathematical algorithm includes a credit system whereby each user interaction is associated with a specific type and/or number of credits, whereby a credit score is associated with a user and whereby there is a one-to-one correspondence between the credit score and an activity gauge.

For example, in case that interaction data is generated, based on the data category and the modality of the interaction data, a specific amount of credits is added to a user's credit score stored on the reinforced-protection database. Modalities can include all types of information necessary for assessing the value or of the corresponding interaction data to adapt the credit weightings for the credit system. For example, such modalities can include information regarding the percentage and timeliness of exercised treatments or information regarding adherence habits to a medication according to a prescribed dosage. Specific data categories, e.g., treatment data, can result in a higher number of credits compared to other data categories, e.g., logging data.

In another aspect, specific interaction data associated with different data categories can contribute to different types of credit scores, i.e., different sorts of credits can only be associated with specific data categories of interaction data. Missing interaction data, e.g., due to patient non-adherence to a prescribed treatment, can lead to a decrease of the credit score by subtracting a predefined number of credits from a user's credit score, i.e., the activity gauge of a user decreases towards activity gauges associated with a lower user activity. The evaluation of an activity, i.e., the provided interaction data, to an amount of credit can depend, e.g., on the user and time, and is generally not fixed.

In another aspect, the mathematical algorithm comprises a stochastic algorithm. For example, based on new interaction data of a user, i.e., interaction data generated within a predefined short time scale, and history-interaction data, i.e., stored interaction data from a user's past or from other user's interaction data, an inference model is trained to generate an activity gauge wherein the activity gauge reflects the probability of a user for being active in a future time. For example, such a state can be defined such that a specific user has a high probability for further generating interaction data within a predefined future time or not.

Such inference models may be a supervised and/or unsupervised machine-learning model. For example, data such as first interaction data, of previous user behavior may be employed to train a machine-learning model, e.g., to predict first user procedures and/or a first generated activity gauge at later points in time. Such machine-learning model may comprise a neural network based on a tree-based-type architecture, long-short-term-memory-type architecture, or another type of neural-network architecture suited from the state of the art for predicting a user procedure and/or activity gauge at later points in time. Then, the trained machine-learning model can be employed for predicting most probable second user interactions which are expected to be triggered and/or a second activity gauge at later points in time from a user's second interaction data.

In another example, an unsupervised and/or self-learning machine-learning model based, e.g., on a neural network employing reinforcement learning based on a Markov-Decision Process, is employed for predicting a user procedure and/or an activity gauge at a later point in time from incoming interaction data. An unsupervised and/or self-learning machine-learning model has the advantage that the prediction accuracy and/or the model's decision quality can continuously be optimized. For example, the model may select at any point in time from a number of actions from a user, e.g., requesting specific interaction data like specific patient vitals. The machine-learning model may adjust the type and/or frequency of actions depending on the outcome, i.e., the triggered user procedures, and/or the user's activity gauge at later points time, of the set of performed actions so that a reward function is maximized/optimized. One reward function may be the activity gauge of the user, wherein the activity gauge shall be maximized Therefore, the machine-learning model may develop a strategy for maximizing a user's activity gauge so that, e.g., patient remain active and adhere to their prescribed treatments yielding measurable longer and heathier patient lives.

In another aspect, the step of generating an activity gauge associated with a user at least partly based on the interaction data includes a multi-dimensional activity gauge. A multi-dimensional activity gauge allows the tracking of a user's activity in cases in which a single activity gauge is insufficient to properly reflect a user's activity. For example, a user can have more than a single role, e.g., a patient and a clinician role, so that a multi-dimensional activity gauge allows to simultaneously track all user roles. Multi-dimensional activity gauges for different data categories of interaction data are also technically advantageous to prevent users to misuse the activity tracking, e.g., users must comply to life-saving treatments and cannot artificially elevate the user's activity gauge by only providing logging data.

In another aspect, a multi-dimensional activity gauge can be mapped on a single activity gauge to generate a compound activity gauge. In one example, a weighted sum or map such as an arithmetic mean or median or a norm, e.g., the absolute value, of the multi-dimensional activity gauge is used to generate a compound activity gauge from the plurality of activity gauges.

FIG. 3E illustrates a two-dimensional activity gauge as an example for a multi-dimensional activity gauge. The two-dimensional activity gauge comprises a first activity-gauge dimension A1, e.g., associated with a first data category such as treatment and health data, and a second activity-gauge dimension A2, e.g., associated with a second data category such as logging data, wherein both activity-gauge dimensions depend on the time t. FIG. 3E includes a point associated with no user activity 3402 (A1=A2=0) and a dotted threshold curve 3403 (Ac) as a function of A1 and A2, whereby inside the area as delimited by the axis A1, the axis A2, and the curve Ac, a user procedure is performed. At a first point in time ts, a user provides health data and logging data whereby the activity gauge acquires a finite value as generated based on the interaction data. At t1, the user performs a treatment and generates treatment data so that the new activity gauge is shifted towards higher A1 values. Since no logging data is provided at t1, the user's activity gauge is shifted towards lower A2 values due to a discount factor continuously shifting the activity gauge towards 3402. At t2, the user provides logging data so that the user's generated activity gauge is shifted towards larger A2 values. Due to the discount factor, the user's activity gauge is shifted towards smaller A1 values. Both treatment data and logging data are provided at t3 so that the generated activity gauge is increased in A1 and A2 dimensions. Since the user does not comply with the user's treatment prescription, the user's activity gauge strongly decreases towards small A1 values at t4. Since logging data is provided, the activity gauge is shifted to higher A2 values at t4. No further interaction data of any data category is provided so that the user's activity gauge undercuts the threshold curve 3403 (Ac) at the point in time to performing a user procedure or triggering the performing of a user procedure.

The advantage of multi-dimensional activity gauges relies in the elevated accuracy to measure a user's activity with respect to the provided type/data category of interaction data. The plurality of activity-gauge dimensions allows to generate/create multi-dimensional requirement data so that user-customized requirements, i.e., threshold curves/hyper planes, can be created. With that, the user's behavior can be tracked in more detail and compliant user behavior, e.g., adherence to prescriptions, can be fostered.

FIG. 4 shows an illustration of a quantity gauge according to an embodiment of the present application. At a first point in time t1 a user generates interaction data, e.g., logging data 4001 and health data 4002, and optionally authenticates via biometrics, e.g., fingerprints/palm prints 4003 or retina scan 4004, or an authentication token 4005, e.g., an identification card or passphrase. In this example, the quantity gauge is illustrated as a progression bar 4006 wherein the progression bar is filled if interaction data is generated within a predefined time limit. The intermediately generated quantity gauge 4006 can either be stored locally on a user's external device, a healthcare system, a healthcare-data-management system, and/or be stored on an external server, e.g., a reinforced-protection database.

A quantity gauge can be an activity gauge where the activity of a user is measured based on the frequency of generated interaction data. For example, no further information than the generation of interaction data is correlated to generate a quantity gauge. In another example, a multi-dimensional quantity gauge is generated, e.g., for each data category of the interaction data a separate quantity gauge is generated.

At the point in time t2 the user continues generating interaction data 4008, 4009 within the predefined time limit so that the progress bar 4010 associated with the quantity gauge progresses. The user continues generating interaction data 4012, 4015 within a predefined time limit at the time points t3 and t4 so that the progress bar 4013, 4014 is further filled. In case that sufficient interaction data is generated within the time limit, e.g., the number of generated interaction data exceeds one more threshold values within the predefined time, corresponding information from the quantity gauge is generated 4017. The quantity-gauge data 4018 generated from the quantity gauge includes a positively evaluated quantity of interaction data within the respective time limits so that the quantity gauge and/or the generated quantity-gauge data 4018 are transferred 4019 and stored on the reinforced-protection database 4020.

In one aspect, insufficient interaction data is generated within a time limit, e.g., due to user inactivity, whereby the quantity-gauge data 4018 generated from the quantity gauge includes a negatively evaluated quantity of interaction data within the time limit. In this case, the quantity gauge and/or the generated quantity-gauge data 4018 are not or only partly transferred and stored on the reinforced-protection database 4020.

In one aspect, the quantity gauge is part of an activity gauge wherein the quantity gauge is encoded in the activity-gauge value. In general, the activity gauge can be a numerical object, e.g., a number or a plurality of numbers, wherein the frequency of the generated interaction data, i.e., the quantity gauge, is comprised in the one or more activity-gauge values. With that the one or more activity-gauge value also reflects the quantity gauge. For example, a positively evaluated quantity of user interactions increases the other activity gauges, e.g., a bonus activity-gauge value is added to the other activity gauges.

In another aspect, the quantity gauge is a separate type of activity gauge of a multi-dimensional activity gauge. In such case, the activity gauge is split in two or more dimensions, e.g., in two or more numerical objects such as a tuple of numbers, wherein the two or more dimensions of the activity gauge independently reflect the quantity gauge and another type of generated activity gauge, e.g., based on the data category of the generated interaction data.

In another aspect, the quantity gauge is part of an activity gauge wherein the quantity gauge is encoded in the activity-gauge value and the quantity gauge is a separate type of activity gauge of a multi-dimensional activity gauge. In this case, the activity gauge comprises a multi-dimensional activity gauge wherein a first activity gauge comprises a combination of the quantity gauge and another activity gauge generated from the type/quality of provided interaction data and wherein a second type of activity gauge of the multi-dimensional activity gauge only includes the quantity gauge. The first and the second activity gauge can be numerical object and/or non-numerical objects. For example, the first activity gauge and/or the second activity gauge can be a symbol or a color, e.g., traffic-light colors.

In another aspect, a healthcare system for verifiably controlling data transfers may comprise a data acquisition unit configured to acquire interaction data of a user wherein interaction data include data of an interaction between a user and the healthcare system. The healthcare system may include a communication interface configured to exchange interaction data with a first reinforced-protection database, wherein the healthcare system is configured to transmit interaction data to the first reinforced-protection database. The healthcare system is further configured to generate an activity gauge at least partly based on the interaction data and wherein the first or a second reinforced-protection database is configured to store requirement data including information related to the performing of a user procedure associated with a data transfer depending on the activity gauge. The healthcare system and/or the first or second reinforced-protection database are further configured to communicate with a computing unit and wherein the computing unit is configured to perform and/or to trigger the performing of the user procedure depending on the activity gauge.

While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive. It will be understood that changes and modifications may be made by those of ordinary skill within the scope of the following claims. In particular, the present invention covers further embodiments with any combination of features from different embodiments described above and below. Additionally, statements made herein characterizing the invention refer to an embodiment of the invention and not necessarily all embodiments.

The terms used in the claims should be construed to have the broadest reasonable interpretation consistent with the foregoing description. For example, the use of the article “a” or “the” in introducing an element should not be interpreted as being exclusive of a plurality of elements. Likewise, the recitation of “or” should be interpreted as being inclusive, such that the recitation of “A or B” is not exclusive of “A and B,” unless it is clear from the context or the foregoing description that only one of A and B is intended. Further, the recitation of “at least one of A, B and C” should be interpreted as one or more of a group of elements consisting of A, B and C, and should not be interpreted as requiring at least one of each of the listed elements A, B and C, regardless of whether A, B and C are related as categories or otherwise. Moreover, the recitation of “A, B and/or C” or “at least one of A, B or C” should be interpreted as including any singular entity from the listed elements, e.g., A, any subset from the listed elements, e.g., A and B, or the entire list of elements A, B and C.

HEALTHCARE-ACTIVITY TRIGGERED DATA MANAGEMENT

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims

Priority Claims (1)