On Tue, 17 Nov 1998, Joseph Dal Molin wrote:
>I would like to intitiate a dialogue on why it would be beneficial for a
>prospective healthcare client or an organization to agree to going open
>source. More specifically, to release the code that have paid to have
>developed.
Clinical software suffers from one of two deficiencies: (1) it contains
too little medical knowledge or (2) it contains too much. By "knowledge" I
do *not* mean expert systems or artificial intelligence but merely the
knowledge embedded in data structures and functional subroutines.
In the first instance, applications without specialized medical knowledge
are little more than gussied up word-processors or spreadsheets, just
clerical tools masquerading as clinical tools.
Applications designed for particular specialties are much more useful
clinically, because their data structures and functions *fit* the
situation. These applications, however, typically do not interface well
with applications designed for other specialties; they are nearly always
"designed" by a relatively small number of clinicians; and the knowledge
they contain is difficult to maintain and even more difficult to extend.
IMHO, these deficiencies are a direct result of proprietary software
development.
Medical knowledge, with rare exception, is not proprietary. The success of
medical science in this century is due to the widespread, open publication
of medical knowledge in the form of research results, clinical reports and
review articles. OTOH, perhaps the greatest failure of medical science in
this century is the inadequate distribution of medical knowledge *at* the
point of care.
To make medical knowledge available in point-of-care applications, we
need:
1. a conceptual model that adequately addresses:
+ the subjective/objective dichotomy in medical decision making,
+ the goal-oriented and problem-oriented aspects of healthcare,
+ event-oriented aspects of healthcare;
2. software development methods that facilitate widespread input from
clinicians, not only in terms of functionality and interface design, but
input of core knowledge, as well;
3. software development methods *and philosophies* that promote reuse,
extendibility and reliability.
Such requirements are unlikely to be achieved short of developing software
using *something like* the open source approach.
Donnal C. Walter, M.D., Ph.D.
Arkansas Children's Hospital and
University of Arkansas for Medical Sciences
[EMAIL PROTECTED]
[EMAIL PROTECTED]
