Insufficient knowledge of the patient history leads to severe medical, ethical and economical problems [5]. Adverse drug reactions (ADR) or repeated examinations are well-known results. The paper presents a blueprint of applying the VETO! principle to medical knowledge management. This helps to reduce such errors. VETO! is a system that exploits distributed knowledge of the patient record while keeping high medical security standards. The data is uncovered in a Clearinghouse where possible medical risks are identified. If problems are anticipated, a ”Veto!”-message is released to the originating entity. In severe cases additional information can be provided. Unlike other systems, VETO! is an evolutionary P2P system: the resulting quality increases with the number of contributors. It exploits several beneficial characteristics of Peer-to-Peer systems.
Knowledge plays an important role in medicine. Decision support systems (DSS)
can generate case and domain specific advice [8, chap. 16] from the provided
knowledge. DSS are part of artificial settings or can help human agents. They
are categorized into autonomous systems on one hand and solicited or unsolicited
advice systems on the other. In settings where human users are involved, each
system must handle inconsistencies, data gaps, errors and other problems that
occur in real life gracefully. The system design and its implementation has to
reflect these requirements to provide a convincing performance. Peer-to-Peer
(P2P) systems provide the required characteristics: superior performance of the
service based on massive parallel contributions of the peers, on the similarity
of the nodes and on non-determined dynamics of parts of the individual peers
[
The field of application puts special restrictions on the implementation of
the DSS. Medical applications, for example, have to deal with restrictions like
law (e.g. obligation to store medical data) or data security. On the other hand
such environment provides beneficial aspects like a controlled vocabularies or
common application and communication interfaces (e.g. HL/7 [
There still remain problems because of the traditional, unconnected ”data
islands” in healthcare. The missing integration of information in the healthcare
domain is reason for the afore mentioned problems [
This paper explains the ideas of a P2P based decision support system: the VETO! system gathers data from the peer community (here: healthcare providers) and checks it against domain specific knowledge of experts. VETO! works unsolicited, automatic and in near real-time. Because of the possible incompleteness of the knowledge base, the system is not able to prove a certain decision, but it is able to return a negative judgement (a ‘veto‘) if the decision is alarming or even harmful. 2
The main idea of VETO! is similar to falsification of a hypothesis: if there is a contradiction, the hypothesis must be discarded, if not, we do not know. If a decision is based on distributed data, all available information should be taken into account as each additional piece of data enhances the decision. Besides available case facts (e.g. start of treatment), intelligent systems also use an inference engine, rules (expert knowledge) and common pharmaceutical facts (cf. Fig. 1).
The case related part of the knowledge base changes over time as more and more information arrives from different data providers. The amount of knowledge increases as each examination or illness contributes to the underlying patient record. The patient record changes over time. One can briefly think of an erroneous and incomplete facts base: there is a need for gathering of the actual patient data in real-time and for dealing with incomplete and inconsistent data.
The reasoning rules represent the expert knowledge from previous experience with drugs or the treatment or guidelines (medical, economical or other). As example, an ADR rule can be written as:
f actA ∧ f actB → ADR with f actX = takes in drug X and ADR = degree of possible negative effect Besides simple logics, temporal logics and sometimes even spatial logics is needed to reason over the provided knowledge. E.g. drug interactions commonly only occur during some time after intake of another drug:
ADR ∧ (timeB − timeA < criticalT ime A B) → warning If a rule is fired, a possible negative effect can occur. This information is delivered to the physician who initiated the process.
The treating physician (lef in Fig. 2) triggers the surveillance process by issuing a prescription to the patient. Therefore some information is spread to his colleagues (1). The message itself (A) is encrypted (PKI with key of Clearinghouse), only a hashcode that identifies a group (!) of patients, is visible. The choice of the hashcode is founded by demographics of the population: the group size per hashcode should be big enough to prevent from identifying a single patient, but needs to be small enough to not produce too much unnecessary work for the Clearinghouse (CH). For example, the hashcode consists of one or two letters of the name and the month of birth. If patients are assigned sequential numbers with a patient card ID, a modulo operation (e.g. mod 100) can generate the group membership. So neither the message (A encrypted) nor the hash code (it identifies a group) unveils the identity of the patient. Each healthcare provider who has information that matches the hashcode adds its encrypted information (2,3) and sends this information to the CH. The CH decrypts the different message parts A,B (4). Iff the patient identity in both parts of the message match and the rules predict a harmful outcome, a notification (warning) is issued to the physician (5). He checks if the additional information is of relevance for his former decision.
The A and B part of the message can only be decrypted by the CH. The CH is the only part that needs to be operated by an official authority to ensure data safety. In general, the CH performs the same tasks as a standard inference engine in other expert systems. Therefore existing treatment surveillance systems and tools from the AI domain match the technical needs of the VETO! system. 3
Two competing approaches are based on different premises. The card approach
stores the data ‘near‘ the person, e.g. gathered on the patient card. Card solutions
demand for a similar control logic because of the increased amount of data to be
considered. Another solution includes a central ”global” repository to contain all
patient data. The NHS system is of the second type [
Ethical and economical reasons demand for an enhanced medical quality. VETO! is an automatic, reactive DSS that issues warnings related to medical treatment quality. The distributed patient record remains unchanged, information is gathered in realtime. This ressembles to P2P systems.
Events like a drug prescription or starting a new treatment trigger the automatic surveillance process. The initiating peer queries the medical community for information on the patient. A Clearinghouse processes the collected data. Identity information is unveiled only there. On principle only negative effects of the intended treatment can be detected. In the case of indicated danger, further information is reveiled to the physician, who can react accordingly. This helps the physician to avoid errorneous decisions and thus increases the quality of the treatment.
The VETO! system is not yet implemented, currently it is seen as a model how medical services can be implemented when new technological possibilities are available. As healthcare telematic platforms are currently under development, the idea of VETO! can initiate seminal discussions of how to softly implement the needed services. This is in contrast to ”revolutionary” approaches that demand for significant changes of the infrastructure.