With the advent of health-enabling technologies, especially sensor technologies and advanced data analysis methods [11
], their gradual integration as supportive technologies in current care scenarios on the one hand [49
], and on the other hand by enabling new care services [27
], a gradual permeation of these technologies into actual health care and patients’ homes beyond purely scientific limits can be observed. The properties identified above may serve to arrange current decision support systems into different categories with regard to autonomy, localization and integration in current health information system structures (aim#1). First studies have been published, proving the effectiveness of technology usage in specific disease management scenarios using home-recorded data, for example in patients with heart failure [50
If the additional data that can be recorded using home-based or wearable technologies shall be used to generate more information resp. knowledge about a patient – and not lead to a data overload – the development of appropriate methods for analysis in terms of data reduction and information extraction are of paramount importance [52
]. Too much unprocessed data may lead to confusion and even disregard of data, and not to shedding light into areas relevant for decision making in health matters. This counts not only for health care providers (physicians, nurses) but also for the patient herself or himself and her or his relatives [53
]. Thus, ‘intelligent’ decision support systems or DS modules are necessary, and in fact are part of many system designs in the projects identified.
While the integration of solutions in health care settings is often ensured, details about the design of the decision support component, its contents and the methods used for decision making in most cases remain unclear. Furthermore, there is a lack of reports about the details of the DSS design infrastructure and about the formalization of the medical decision logic [30
]. On a more general scale this also holds true for the architectures of so-called sensor-enhanced health information systems, of which decision supports systems are only one – albeit a crucial one – among many components [54
]. Only few authors mention the integration of clinical knowledge sources such as institutional EHRs [10
], which should be regarded as a prerequisite for ‘intelligent’ and individualized decision making [41
], in analogy to the decision making process of a good general practitioner, who will always interpret data in the context of co-morbidities and co-medications, not to forget social context and personality. While the final decision about health-related measures should be taken by both the patient and the doctor as a consultant, a decision support module should be ‘intelligent’ enough to support this kind of decision process.
Many issues remain open considering decision support at home (DS@HOME). As mentioned before, there currently is no clear understanding about the way medical knowledge should be formalized for home care decision support. Most authors seem to use production rules. International standards for such logic, for example the Arden Syntax for Medical Logic Modules – for which an Open-Source compiler has recently been made available [55
] – or GELLO [56
], seem to be rarely – if at all – used. Without standardization, the exchange of decision components and their use beyond the specific scenario of a scientific project becomes very difficult. A similar development may be observed in clinical DSS which are often focused on specific problem areas and feature proprietary knowledge bases [8
]. While the general system architecture of a DSS is obvious, many variations exist in terms of where the actual decision logic is located – in the personal resp. home environment [21
] or in a centralized system (e.g. [12
]). This has implications with regard to the updateability and customization of medical logic components in analogy to a physician’s prescription as proposed by Bott et al. [31
], for example if the adaption of a medication dosage is necessary in a patient with chronic renal failure. Finally, the interfaces (if existent) to current clinical application systems containing the information (such as the diagnosis ICD-10 code N18.2
, ‘the patient suffers from chronic renal failure’) which is necessary to interpret home-based data or to make decisions on this basis, currently seem neither widely accepted nor used.
The assembled requirements (aim#2) may serve developers of DSS as helpful guiding criteria for successful implementations, yet the author does not claim them to be complete or ranked according to their importance.
The author cannot rule out that the literature analysis is to some extent subjective. Many of the identified articles do not focus on the decision support components but rather on the overall system design and evaluation issues. Therefore, important facts about the DSS’s features and its implementation might not have been reported there and therefore may have been failed to be gathered in the review process. The results of the literature search as presented in Table are ordered according to the first authors, yet some variations of a system have been described by different authors, for example by Finkelstein et al., Cross et al. and Joshi et al. While the basic system architecture remains the same, different application areas are addressed, and thus different decision components are used. Furthermore, the presentation does not make a difference between systems actually used in clinical practice and lab prototypes as e.g. in [24
]. In addition to this, as the use of decision support systems in home environments has not found its way into large clinical trials so far, the author was not able to make a sound analysis of system architectures in terms of an outcome evaluation on the basis of this analysis.