Abstract

The “doctor in the loop” is a new paradigm in information-driven medicine, picturing the doctor as authority inside a loop supplying an expert system with information on actual patients, treatment results, and possible additional (side-)effects, including general information in order to enhance data-driven medical science, as well as giving back treatment advice to the doctor himself. While this approach can be very beneficial for new medical approaches like P4 medicine (personal, predictive, preventive, and participatory), it also relies heavily on the authenticity of the data and thus increases the need for secure and reliable databases. In this paper, we propose a solution in order to protect the doctor in the loop against responsibility derived from manipulated data, thus enabling this new paradigm to gain acceptance in the medical community. This work is an extension of the conference paper Kieseberg et al. (Brain Informatics and Health, 2015), which includes extensions to the original concept.

Highlights

  • Introduction and MotivationWhile the concept of the ‘‘doctor in the loop’’ seems to be a logical consequence of the application of machine learning technologies and derived knowledge into medical science, one major problem arises: The doctor in question is forced to trust the results derived from algorithms based on the authenticity of stored data to a large extent, while being seen as the primary responsible party during information provisioning, as well as during treatment, i.e., the doctor retains responsibility or, in case he/she is involved in the selection of the source data, even gains more, while loosing control over the process

  • The data of the protected internal logging mechanisms are executed against an old trusted backup under the premise of T and compared to the investigated database instance. This works, when reverting the whole database to an old state: The pseudo random number generator (PRNG) is seeded with a seed unknown to the attacker, every iteration changes the state of the PRNG, which cannot be calculated backwards

  • The database management system (DBMS) must be modified in a way to provide the calculation of the respective witness as an atomic action, invisible to and uninterruptable by the administrator, i.e., the mechanism for writing the transaction log needs to be modified directly in the Database Management Systems (DBMSs)-code in order to fetch the random numbers ri and calculate the witness immediately, without leaking ri to the administrator

Read more

Summary

Introduction and Motivation

While the concept of the ‘‘doctor in the loop’’ seems to be a logical consequence of the application of machine learning technologies and derived knowledge into medical science, one major problem arises: The doctor in question is forced to trust the results derived from algorithms based on the authenticity of stored data to a large extent, while being seen as the primary responsible party during information provisioning, as well as during treatment, i.e., the doctor retains responsibility or, in case he/she is involved in the selection of the source data, even gains more, while loosing control over the process. With the technology available to tackle large amounts of complicated data in real time through Big-Data techniques, results derived from such processes may even become more uncontrollable This opens up the problem of acceptance of the ‘‘doctor in the loop’’ approach by medical personal. In order to mitigate these risks for the overall concept, manipulations in the underlying database need to be detected, as well as control over the information entered by the doctor needs to be safeguarded against subsequent manipulation. This includes the manipulation-secure logging of execution chains of enrichment and analytics algorithms and workflows. In-depth discussion of limitations and possible countermeasures (see Sect. 4.3)

Experts in the loop and medical databases
Chained witnesses
The doctor in the loop
Entities and relations
Interaction and chaining
Data provider
Data store
Decision maker
Trusted third party
Network providers
Data insertion
Verification of authenticity
Multiple decision makers
Adaption to closed-source environments
Attacker models and attack vectors
Data provider and decision maker
Manipulation of the DBMS
Combined attackers
Limitations
Conclusion and Future Outlook
Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call